Themes, Icons, Desktop Integration/Consistency, and The GNOME Architecture

[Rodney Dawes <dobey free fr>]

So,

        It seems there are several problems in GNOME 2.2 revolving
around the Icon Themes, and even Themes in general, despite the fact
that both Icon Themes and Desktop Themes seem to be a major part of the
core in 2.2. The Icon Theme Spec specifies that Icon Themes go in the
~/.icons and $datadir/icons/ directories. The Theme Manager installs
them into ~/.themes and then does not list them in the UI where the
available themes are supposed to be listed.

        On top of that, there is no Desktop Theme specification, and
yet they are a major part of the desktop. The Theme Manager also seems
to require that some Desktop Theme be installed on the system, and can
not work without a $themedir/$themename/index.theme existing somewhere.
However, while my desktop is very pretty and is constructed as a
"Custom" theme in the UI, if I have another theme installed, it is not
good enough for the Theme Manager to deal with, without having other
Desktop Themes installed.

        There is also a random horizontal line in the middle of the
Theme Manager on the right side of the dialog, under the buttons to
change the theme, install new themes, or save the current one. These
buttons also don't have icons in theme, though it seems as if they
should, as they are fairly common actions and stock icons exist that
would be great for all of them.

        Then we have the GnomeIconTheme implementation of the Icon Theme
Spec, which lives in libgnomeui. Why is this in libgnomeui anyway? As
is, nothing "just works" for developers. You have to write extra code to
get the correct icon from an icon theme, and bend over backwards to make
your application look "integrated" with icon themes. Recently there has
been discussion and work on merging the gnome-desktop code into
gnome-vfs. I think this is a great idea and a move in the right
direction. It would be wonderful if the icon theme implementation were
merged into gnome-vfs also, and then when you ask vfs for the icon for a
mime type, or desktop file, you just automatically get the right one. I
see no real reason that the GnomeIconTheme code should be in libgnomeui,
as it is just a GObject derivitive. An even better place may be glib,
so that non-gnome/non-X applications could have icon themes, such as a
module for apache for a web forum or similar, and users could have icons
that match what they have on their desktop. These things should be
automatic. Gnome VFS should also just be able to automatically give you
the correct information from desktop files. It would make a lot of the
code in GNOME able to be removed in favor of just having the data
already. This may require some new API in gnome-vfs, but if the desktop
stuff is being merged in to gnome-vfs anyway, I don't see why we can't
add the necessary API to make it better and more automagic.

        It would also be nice to have a sane theme detection API.
Something where one could find a theme by name (user-visible name,
maybe?), and just pass something like "appname/index.theme" or whatever,
to get a list of all the themes that work with the appname application.
This would make it easy to put the UI for app-specific themes, or such,
in the individual preferences dialogs for the apps. It would also be
really nice to have vfs-enabled theme/image stuff in
gnome-settings-daemon, or somewhere appropriate for it, especially if
GTK+ is getting the ability to have colors set by XSettings. The
settings daemon could just read the gtkrc from a remote location, cache
it locally in the user's home directory somewhere, and just export the
necessary XSettings.

        Also, as far as consistency goes, the UI Prefs for deciding
which toolbar style to use, and icon size in the toolbar, seem to have
the ability to be set with XSettings, though the settings daemon doesn't
seem to export those configuration options to GTK+. It really should.

        And, now back to the toolbar inconsistencies. GtkToolbar draws
differently than BonoboUIToolbar. GnomeApp uses a BonoboDockItem (I'm
not even going into that inconsistency right now), with a GtkToolbar
embedded inside of it, with a border width of 1. The BonoboUIToolbar
has a border_width of 2 (which looks better). BonoboUIToolbar doesn't
have a shadow_type at all, which looks fine, with the dockitem bevel.
The GtkToolbar shadow_type defaults to OUT, and the shadow is drawn
offset by the number of pixels that border_width is set to, but only
on the top/left sides, so the bottom/right gets drawn over top of with
the internal part of the box, so it looks really bad. There are two
possible ways to fix this. A patch to just make the toolbar shadow
draw on top of the handlebox shadow, is attached to the bug I filed
against GtkToolbar. In the comments there is a modified version of
the patch which makes the shadow of the toolbar draw internally with
the correct (intended) dimensions, and suggests changing the default
shadow_type to GTK_SHADOW_NONE. This doesn't look as good UI-wise if
shadow_type is sest to anything other than GTK_SHADOW_NONE, as there is
no border between the children and the bevel. I have patched libgnomeui
also, to change the border_width setting of the toolbar, to 2, instead
of 1. I have then also patched libbonoboui to add a shadow_type style
property to BonoboUIToolbar, move the border_width setting call to a
more appropriate place so it gets set properly, and branched gnome-2-2
and committed this to HEAD with Michael's approval. If owen accepts the
latter patch to gtktoolbar.c as opposed to the original submission, I
will modify BonoboUIToolbar to do the same. Preferrably this is accepted
with shadow_type defaulting to NONE, if the original is not the accepted
version (assuming it gets accepted in a time frame compatible with human
life expectancies). The relevant bugs are listed below:

GtkToolbar: http://bugzilla.gnome.org/show_bug.cgi?id=106336
libgnomeui: http://bugzilla.gnome.org/show_bug.cgi?id=106342
BonoboUIToolbar: http://bugzilla.gnome.org/show_bug.cgi?id=106361

        These things are pretty major it seems to me, if we are trying
to create a nice, easy-to-use desktop environment that just works. It
would also make developing gnome applications, which use themes, or
to make the icons for certain parts of applications themeable with the
icon themes, much much easier, and more people would probably be abliged
to do so. I think it would help some of the consistency/integration
issues that exist in the desktop a fair amount. And yes, I will be
filing bugs for all of these things, but I figured I would send mail to
the lists for discussion/flamewar bait. ;)

-- dobey