GNOME Bugzilla – Bug 100622
UI is problematic if you want to create your own theme
Last modified: 2007-11-11 20:00:40 UTC
To the naive user (including myself) the theme manager offers no way to customize a theme that's not already present. Here was my first experience with the theme manager: *run *see 'save custom theme', ignore it, figuring I can do it later *switch to high contrast theme, figuring that I want to see what bill h. has wrought *discover that I can no longer switch to a custom theme. *'install theme' goes nowhere [presumably a bug] *'details' apparently lets me edit the current theme, though the name 'details' doesn't indicate that at all. *Since the details window pops up in front of the main window, there is no indication that I'm now changing a 'custom theme' instead of the theme I was previously using. So, suggestions: *'details...' be renamed to 'customize theme details...' or something along those lines. *'custom theme' always be present, so that it can be more obvious that a custom theme can be created. [I assumed that 'details' on a theme modified that theme, not the custom theme. Having a custom theme option always present would make it more clear that editing a theme won't permanently screw up a pre-existing theme.] *when a custom theme is saved, it show up in the theme list. [This may be a bug instead of a design choice, not sure?] Anyway, that's my two cents. I'm marking it a 2.2.0 target/blocker because the current UI will surely confuse Real Users if it confused me.
Luis: is this still applicable for 2.2.0 considering the UI freeze? If it is we should probably get some usability comments fairly quickly. Hard string freeze is 10 days away IIRC.
Look at bug 102274 for more about a custom theme not always being present
FWIW, although this is a release blocker in my and Luis' opinions, patches need to go via the release team because they will break UI and string freezes. And because it breaks string freeze, the sooner the better since things need to be translated.
* The install button being broken is bug 101695 * Custom theme should not dissapear: bug 102274 * Maybe details should be greyed out when an un-editable theme is selected. ATM all it does it edit the custom theme. I think that once custom theme is always there you can just select it and press details. None of that would require string changes which is nice, but is that enough? I think that it would make more sense with those three changes.
> *'details' apparently lets me edit the current theme, though the name > 'details' doesn't indicate that at all. Not really. AFAIK there is not way to edit the preinstalled themes through the applet. If you press details and what you select corresponds to a pre-installed theme then that theme will be selected otherwise Custom Theme will be selected. So it is really only for editing the "Custom theme".
I think that "details" edits the currently selected theme but sets your changes to the custom theme - so you don't overwrite preset themes but make a copy, with modifications, in the custom theme. I think? And that's confusing.
Combination of bugs and a confusing interaction model. The bugs should be dead soon. I think the real problem stems from the idea of a custom theme as being present "whenever your current settings don't match any predetermined theme". jrb wanted to do this to neatly handle edge cases where the user manually tweaked GConf and consequently the current settings didn't match any of the themes. I think this exposes confusing and unnecessary details about the theme system. I would suggest the following instead, which handles the edge case without modifying the typical interaction model in a confusing way: * Buttons on the right are (in order): "Install theme", "New theme", vertical space of 12 pixels, "Theme Properties", "Delete" * Theme properties has one tab more than the current "details" window (the first tab), which contains two text boxes for setting the theme's name and its description * New theme creates a new theme using the currently selected theme as its default settings for sub-themes, and brings up the theme properties window * "Custom theme" only appears in the edge case that the user manually tweaks GConf settings and the current sub-themes don't jive with the current selected GNOME theme. In this case, the theme will no longer be considered a "Custom theme" if the user renames it, and should automatically be saved in the user's ~/.themes/ directory at this point. * "Delete" is disabled for themes to which the user does not have write access (system themes). They can bring up "Theme Properties", but not change any of its settings (might be wise to have a label at the bottom of the theme properties window when this is in effect).
*** Bug 95306 has been marked as a duplicate of this bug. ***
Any Theme dialog look/rework will have to happen for GNOME 2.6. This won't hit 2.4
Seth's proposal seems pretty reasonable. I'm a little concerned about how 'Delete' will work, but we can start by making the other changes.
For 2.8, we mean. :/
Given that no one else seems to think this is a problem, dropping in priority. I'd still like to see Seth's suggestions implemented, of course :)
Created attachment 56923 [details] Glade implementation of Seth's suggestions Here is a glade file of Seth's suggestions. It also removes the drag to install text as per bug 99535.
Using that .glade, the capplet crashes: Backtrace was generated from '/usr/bin/gnome-theme-manager' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1224739136 (LWP 17571)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 65052
That is printed too: (gnome-theme-manager:17619): Gtk-CRITICAL **: gtk_size_group_add_widget: assertion `GTK_IS_WIDGET (widget)' failed (gnome-theme-manager:17619): Gtk-CRITICAL **: gtk_size_group_add_widget: assertion `GTK_IS_WIDGET (widget)' failed (gnome-theme-manager:17619): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed (gnome-theme-manager:17619): GLib-GObject-WARNING **: invalid (NULL) pointer instance (gnome-theme-manager:17619): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (gnome-theme-manager:17619): GLib-GObject-WARNING **: invalid (NULL) pointer instance (gnome-theme-manager:17619): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (gnome-theme-manager:17619): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed
Out of that the changes looks fine from glade
I haven't actually implemented the changes necassary to the code (which is why I didn't attach a patch - and why it doesn't work with the code). It was just a mockup of Seth's suggestions. If the problems with the UI mentioned in this bug are fixed by the new glade file, then I will go ahead and create a patch.
The mockup looks fine to me, patch is welcome!
FWIW, I think the word "Theme" is redundant in a couple of places in the attached mockup: - Main window: "Theme Properties" could just be "Properties" - Details dialog, "Theme Name" and "Theme Description" could just be Name and Description (also, shouldn't be in bold, should end in a colon, and need mnemonics). Also, shouldn't the dialog title now be "Theme Properties" (or better still, "<theme-name> Properties")? Save dialog: hmm, doesn't look like it's sure whether it's an alert or a dialog; consequently, repetition of "Save Theme" at the top is a bit ugly. Think I'd try and make it look more like the regular gtk Save dialog, i.e.: +---------------------------------------------+ | Save Theme As... | +---------------------------------------------+ | | | Theme name: [ ] | | | | Description +--------------------------+ | | | | | | | | | | +--------------------------+ | | | | [ Cancel ] [ Save ] | +---------------------------------------------+
Just having another look at fixing this bug... The buttons down the side of the theme manager could become: New, Install, Edit and Delete. The New and Edit buttons would then open the details window, with the extra name/description tab mentioned above. This would remove the need for a seperate Save Theme dialog, but I think the details/edit dialog would then have to become explicit apply, perhaps even with Save/Cancel buttons. Any one got any thoughts on this idea?
I suppose this is now fixed with the new appearance capplet? Please reopen if it's not...