|
Bugzilla – Full Text Bug Listing |
| Summary: | software repositories: enabled/disabled switching still not clear enough | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Jiri Dluhos <jdluhos> |
| Component: | YaST2 | Assignee: | Stefan Hundhammer <shundhammer> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Minor | ||
| Priority: | P5 - None | CC: | jsuchome |
| Version: | Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
screenshot
Screen shot: Repo with very long name, yet spacings are preserved |
||
|
Description
Jiri Dluhos
2007-08-13 13:37:19 UTC
If the coloring of the line is not technically possible, we could instead increase the visibility of the checkmark even more by putting empty squares at lines where the checkmark would be for disabled sources. > - coloring the whole line slight gray if it is disabled unfortunately this is not possible with our UI > - centering the checkmark glyph in its column so it is better visible That's questionable. For example I think it is very well visible and that it is nicer on the left side that it would be in the center (JFYI, I didn't write it, so I'm not biased :-)) > - a doubleclick on the line should toggle the enabled/disabled status Makes sense. Created attachment 157079 [details]
screenshot
If the repository name is too long, it widens the frame that's around it (see the screenshot). Stefan, could it be avoided somehow? > - a doubleclick on the line should toggle the enabled/disabled status
yast2-packager-2.15.60
(In reply to comment #5 from Jiri Suchomel) > If the repository name is too long, it widens the frame that's around it (see > the screenshot). Stefan, could it be avoided somehow? Not with the way our table widget works right now. Qt (-3 and -4) can also internally cut off over-long texts in colum and add an elipsis ("...") instead so the user can still make the column wider. But just how wide is "too wide"? Do we want to avoid scrolling horizonatlly completely, always using the cut-off-and-add-elipsis technique? (the underlying Qt widget can do that, too AFAIK). We could add yet another widget option for that behaviour. Or we could let the application specify wich columns should auto-strech to fit their content and which ones should cut off, but that would be an API change (or at least an API extension). Let me think about this. Maybe there is a good (preferably generic) long-term solution. Stefan, the widget in question is not meant to be scrollable. It's just the static label inside a frame (the bold one on the screenshot). Anyway, I'll reassign it to you to think about it :-) The double-click is done and the centering of the checkmark won't be done. Summarizing an IRC conversation about this: This is not (as I had misunderstood it) about the width of the columns in the table widget. Rather, it's about the details of the currently selected repository below that table. The name (in this case the URL) is cut off. Idea: Use a RichText widget for those details. We could do more fancy stuff with that, too; for example using icons for status. But the problem is not that the name is cut off - actually it has to be if it is too long. My only concern was that in the case, the frame around this label gets wider that it should and ignores the HSpacing's around it. Hm - the layout engine intentionally kills any spacings before it tries to cut off any widget with real content. That was actually meant as an improvement... And in this case, you'd like to give the spacings more priority than the widget with content - the frame that gets blown up so much because it contains that over-long repo name. I fear this is not possible right now. I experimented with HWeight() which reduces the widget with a weight in layout priority, but still HSpacing() has even less priority. So this does not work. Disregard the last comment. I hadn't properly installed my changed version.
As a matter of fact, using HWeight() helps. It reduces the layout priority of the content of the HWeight widget so that first all other widgets in the same layout box are satisfied, then the rest is distributed among the widgets with a weight. If there is only one, it will get the remaining space (the weight value is not important if it's only one widget with a weight).
So I changed
`HBox(
`HSpacing(),
`Frame( ... )
)
to
`HBox(
`HSpacing(),
`HWeight(1, `Frame( ... )
)
and now the spacing appears again, even if the frame content uses more space than available.
BTW this is a general layout technique that is useful in many pathological cases like this one.
Created attachment 159492 [details]
Screen shot: Repo with very long name, yet spacings are preserved
|