A bit rough around the edges, but it’s getting there! Many thanks to Denis and Jens for helping out with this. My current thoughts are:
- Do we want the Style tab in a seperate window (opened from the Theme tab). Yes, we know what the HIG says about changing options in other tabs
- Open button on the Themes tab should be Install, but we don’t have a stock icon for this action, and it looks odd without an icon when the other buttons do
- Simplify the Fonts tab if possible
- How many people require the Details window on the Font tab?
- Add some extra preferences to the Preferences tab such as:
- Toolbar icon size
- “Show icons in buttons” option
- Scrollbar buttons position might be useful too (i.e. top and bottom, or together such as in OS X)
- Do people want to configure the text colours (since more often than not they’re just black or white)
looking good, i think the style tab should be a separate window, when i think about changing things i wouldn’t be looking for it in another tab. the current customize button works very well.
it has the added benefit of cutting down the options to borders controls color and icons and not having them all on 1 page.
– I think having “Style” as a tab is fine. If this was put in a new window, “Desktop” would also have to be moved there
– Where’s the problem of giving the button a custom icon?
– The font details window is confusing at best. Smoothing and Hinting are mostly covered on the fron page, Subpixel order seems to be quite useless (I never saw a visible change with that)
– the extra preferences sound good!
– text color… well, I don’t think that is needed. Should always be theme depending?
Anyway, great work!
A tab with cursor theme?
I like it!
The font details is needed as long as LCD screens and RGB/BGR/etc.. is not detected automatically.
For a rework, it should be a wizard like MS has done on their fonts homepage. Comparing of rendering instead of weird options. I don’t care if it’s ‘LIGHT’ or ‘FULL’ 😉
Oh forgot, great work this stuff is needed badly! 😉
I think that the style tab should be a separate “Details…” window for Themes, like the Also, shouldn’t “Preferences” be “Menus and Toolbars”? It is too long, I know, but the whole thing is about preferences, there shouldn’t be a tab for “Preferences”.
Another thing is that the font dialog needs to die. I like the ideas here: http://primates.ximian.com/~federico/news-2007-01.html#31.
As for the Subpixel order, maybe someone can come up with
some images that should display differently?
I experimented a little with four XPM files that
consisted of alternating single pixel lines in red, green and blue. The lines were either horizontal or vertical and
the color order was either RGB or BGR. If the actual color
“stripes” on your LCD monitor are, say, vertical, then the
images with horizontal lines will look identical, while
there is a slight visual difference between the two
images with vertical lines: one looks like alternating
black and white lines, the other shows red, green, and blue
lines.
Oops, there was something missing in the post above. I meant to say that the style tab should be a separate “Details…” window for Themes, like the Edit… window in the current gnome-theme-manager.
If you move “Style” to a “Details..” window, you would also need do move the “Desktop” icon tab there (because the first tab also changes icons), leaving only three tabs… I think a meta theme can also change the background? In that case this would need to be moved as well…
I think this would totally defeat the reason of a new combined dialog?
I have several small issues, but it might be just me 🙂
– I find names of colors on the Style tab quite confusing (like: does ‘Window’ change ‘background of windows’, or does it change ‘background of window borders’.)
– ‘Desktop’ contains definition of the ‘Desktop background’ only. When I saw desktop for the first, I have thought it will contain font used on desktop, use thumbnails with different sizes etc.
– Preview in the Preference tab feels little bit extra. There is no preview for other options in the Dialog
But it feels quite positive 🙂
There are also some interesting points in the Novell Product Design Wiki about the (un)usability of the font configuration dialog: http://primates.ximian.com/~glesage/wiki/doku.php?id=font-config-dialog.
So it’s all coming together now… Joy!
– style: what andrew said, it’s just too weird selecting a theme in one tab and having the settings in the other tab change automatically; should be clear that it’s dependent so button will do better
– fonts: should indeed be simplified
– extra preferences: are there people who want to hide icons on buttons? okay otherwise
Other thoughts:
– move save button in themes tab to style window; as it is now its purpose isn’t clear when not altering themes
– text colors (black or white) could be automatically guessed out of background color, not coded in theme because I would like to be able to change a bright theme into a dark one
– fonts: as michael said, currently the relation between the settings on details window and main window aren’t very clear: smoothing and hinting override settings in main window, other settings are new. Maybe just delete smoothing and hinting settings
– preferences: tab name is too general, they’re all preferences; hope this is a temporary name
I think the first tab should just have a note that the themes below apply
– Control Style
– Window Style
– Desktop Icon Theme
and perhaps also provide checkboxes to optionally
apply a wallpaper or cursor theme?
And… +1 for removing the preview area in the preferences tab, it feels out of place there, doesn’t really stand out as just a preview and only has minimal use I think (as fluffysheep already pointed out, not all other preferences in GNOME have such a preview, it’s just overkill)
WTF are you guys are thinking. This looks just BAD. Especially Themes tab… reminds me windows.
Think outside the box.
I like the idea of putting all these together, but I’m not too hot on the new layout of the Theme and Style tabs. Most importantly, the themes seem to be in completely random order? I also think it was easier to look through as a single-column vertical list.
Also, with the Styles tab, I can no longer see the rest of the themes in a list and easily select a new one – combo-boxes are ok for a few options, but looking at my styles at the moment I have 33 there – that’d be pretty clunky to go through with a combo box…
Perhaps the cursor should be a separate tab too, not being able to see cursor previews before changing them seems a bit backwards again – as soon as I have more than a couple of themes, it becomes awkward to try them out.
And ‘Preferences’ seems a bit generic – Would ‘Controls’, or ‘Interface’, or something along those lines make more sense?
I modify the DPI fonts option on most of my installs. 96 DPI hasn’t matched one of my monitors yet.
I want to start by thanking you for making this happen, it would be a huge improvement to have these capplets merged into one. However, I have two comments on the current draft:
* I agree with some of the comments that mentions that it would make sense to move the style tab to a separate dialog, accessible through a “Details” or “Customize” button in the theme tab.
* For me, it’s a bit confusing that I’m able to choose a background color even if I use a wallpaper. Would it make sense to choose between having a background color or a wallpaper using two radio buttons, so that the wallpaper widgets are disabled when you have chosen to use a colored background and vice versa?
Hei,
did only scarcely browse the other comments, so might duplicate some things…but here’s what i think:
– Styles should definitely be a separate window.
– Thinking about that…would it make sense to change the way the themes tab works to something like “new”, “import”, “edit”, “remove” rather than “open”, “details”, “save”, “delete”? It would feel more consistent with other lists of packaged property entities in applications. Note that thereby, “new” and “edit” would automatically save the changes, which is a different bahaviour that might cause other difficulties…namely a “duplicate” button/context menu entry would probably be needed…or that could actually be implemented in “new” (select a theme, click on new -> opens theme details dialog inheriting the selected themes settings). Would feel better to me.
– If not, though, how about changing “open” to “import”?
– The advanced font properties should be settable somewhere, but they might not be needed here. The reasoning would be that this is a capplet that’s for a user to change his settings WITHIN the same system…whereas things like dpi and subpixel order settings will never change for that system (although are important settings), so don’t need to be present here. Maybe a completely separate capplet would be appropriate? (But would add confusion?) Maybe gconf-editor would be solution enough for that? Note that a separate capplet had the advantage of visually changing the settings, while distributors could use it as an “initial gnome settings” kind of thing that is run once after installation and then isn’t visible anywhere anymore.
– Text color settings should be merged into the theme details window…for two reasons: firstly, they are part of the theme, secondly, the user will most likely need to change background and font colors in relation to each other, so causing him to switch between tabs or windows for that is not very nice. Alternatively, a colors tab could be created, if we want to have the colors “superimposed” on the theme. But then we’d have to provide ways to save and manage color sets like KDE does, as well.
– Calling the “porperties” tab properties is ugly. The whole thing is properties, so it’s not telling the user anything. Even with your extended proposals it’s covering “Menus, Toolbars and Buttons”…maybe some summarizing term could be found?
– Similar thing about “Desktop”. Don’t just copy from windows…what you actually have there is a “Wallpaper” or “Background” tab. Again, the whole capplet deals with desktop settings in a way, plus other desktop settings are found in the nautlius properties capplet, so calling the tab desktop is not correct. Either merge other desktop settings in there, or relabel the thing, preferrably the latter, since “Desktop” is just a bad excuse…a meaningless bubble word that virtually no user really knows what you mean with it.
André.
Johan: wallpapers can be translucent, in which case the background color very much matters. However, you are right that this should probably be made more obvious. Also, labelling is a bit funny here: The heading is “Colors” and then you can select between solid color or gradients. Maybe both issues can be resolved at the same time by relabelling the aspects of it. Can’t come up with something good right now…but something making more clear that the selected image actually sits on top of the colored/gradiented background might be clearer.
Alternatively, but more complicated, on import the pictures could potentially be analyzed for having translucent parts and the color selection widget could be hidden for non-translucent pictures? This seems to be a bit of a rediculous effort, though. 😉
Another little but significant improvement would be to add a “scalable” hint to SVG pictures. In the context of background selection, the file format (currently displayed) doesn’t matter at all. What matters is if it’s losslessly scaleable or not, so i’d rather indicate that.
Moreover, look at this:
http://drapes.mindtouchsoftware.com/Screenshot.jpg
Categorizing by aspect ration makes a lot of sense to the user. On switching to the “Background” tab, the listview could even jump to the section of the aspect ration that matches the one it derives (to be implemented) from the screen resolution. Quite a few improvements possible in that area.
André.