Community
Participate
Working Groups
opening the "color and fonts" configuration lists in a tree different categories and in each category color and font catgeories. while the colors a re shown in small squares, to see the font selected one has to select one foint category and hit "change". it would be nice to have in parentheses the name and size of the selected font ie Part title Font (Bitsream Vera Sans 7) additionally, being able to expand the whole tree at once, making all fonts/colors visible at once and to resize the area the tree occupies in the config tab, to view as much as possible w/o scrolling, would also be nice. i upgraded to kde4 and now the fonts of the main menu and in several views (package, navigation, ant) are rather huge compared to before. while my search for a way to change these fonts proved ultimately futile, it was rather a pita to expand every single node, select every single font and for every font hit "change" to see the selected font and size.
(In reply to comment #0) > opening the "color and fonts" configuration lists in a tree different > categories and in each category color and font catgeories. > while the colors a re shown in small squares, to see the font selected one has > to select one foint category and hit "change". > > it would be nice to have in parentheses the name and size of the selected font > ie > Part title Font (Bitsream Vera Sans 7) See drop 0428-0100 and later (3.5 M7), we now have a details are where we show the font name/size and some sample text. I believe this addresses the issue although in a different manner than you describe. > additionally, being able to expand the whole tree at once, making all > fonts/colors visible at once Given the above, would you be ok if we changed the title of this bug to just address this second issue (ie. change to "Provide 'Expand All' option in colors and fonts list". > and to resize the area the tree occupies in the > config tab, to view as much as possible w/o scrolling, would also be nice. I'm not sure we'd provide that, I can't think of any pref page where we have a split bar for resizing just one area. But we could make the Preview and Description areas fixed height so that when resizing the pref page taller all height increase would go to the tree. If yes we should log this as separate bug.
re details: as long as it is possible to retrive all information at once, i' ok with it. re expand: i'm fine with it, provided after expanding all information is visible, ie no additional "details" or so that still have to used to see all details. re resizing: ok.
(In reply to comment #2) > re details: > as long as it is possible to retrive all information at once, i' ok with it. I think it now should suite your requirements. Please open a new bug against it if there's something more specifically you think we should be providing. > re expand: > i'm fine with it, provided after expanding all information is visible, ie no > additional "details" or so that still have to used to see all details. Thanks. I've renamed bug from [Themes] "Colors and Fonts": show font name and size in tree to [Themes] "Colors and Fonts": expand all property tree to describe this last aspect of wanting to see all the properties expanded. > re resizing: > ok. See bug #274583 with regards to resize behaviour.
Susan is now responsible for watching the [Themes] category.
I would like to fix this in context of the #greatfix, so please assign me and add the greatfix keyword. I have already added the expand all button, but the next question is whether we need a collapse all to accompany that, as: * pressing OK saves the expanded state * pressing cancel does not save the expanded state * after expand all, and pressing OK, the user will have no option but collapse each node manually, which could be inconvenient.
New Gerrit change created: https://git.eclipse.org/r/44688
Gerrit change https://git.eclipse.org/r/44688 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9a703cccb4561f9b22b4cb96261cc694db0ecb64
Thanks Robert. Nice to see a long standing bug fixed.
(In reply to Lars Vogel from comment #8) > Thanks Robert. Nice to see a long standing bug fixed. Is this button really useful now that we have the search field? I can't think of a scenario where I would ever use it. Also note that we never (correct me if I missed a case) use 'Expand All' and 'Collapse All' buttons, but instead have [+] and [-] "buttons".
(In reply to Dani Megert from comment #9) > Is this button really useful now that we have the search field? I can't > think of a scenario where I would ever use it. > Still waiting for the reporter to respond on that. > Also note that we never (correct me if I missed a case) use 'Expand All' and > 'Collapse All' buttons, but instead have [+] and [-] "buttons". I guess you mean that icon button from toolbars (navigator, package explorer, etc. - although these only have collapse all) . Should I update the gerrit with this, or should I revert the previous one (or maybe wait some more for the reporter to respond)?
(In reply to Robert Roth from comment #10) > (In reply to Dani Megert from comment #9) > > > Is this button really useful now that we have the search field? I can't > > think of a scenario where I would ever use it. > > > Still waiting for the reporter to respond on that. What is your opinion on this?
> What is your opinion on this? I personally use the search box wherever there is one, so I also wouldn't use the expand all button often. However, the reporter seems to be requesting it for another reason, to be able to see as many of the colors as possible without scrolling, as a quick theme overview (although there are some plugins which are a better fit to do this, as there are lots of better ways for previewing a color theme than a tree with some colored boxes) to see how the colors look together, which is not possible when using something filtered out.
I'm one of the persons who like this option to expand the entries but if someone feels strong about this, I'm also OK to revert the commit and mark this bug as wontfix
I really feel that this button looks odd on that page, but [+] and [-] would probably even look worse. Personally I would remove that button again, but I won't force this.
Validated in 4.5.0.I20150428-0100
