gtk+ theme suggestions

[Allan Rae <Allan Rae mailbox uq edu au>]

Hello,

Firstly,  I'd like to congratulate everyone on the fantastic
gtk+ toolkit.  I can't say that I've seen a simpler GUI toolkit
anywhere.  Thanks for making sure I don't have to worry about 
fiddly alignments, offsets and positioning anymore!  Autosizing 
via the containers are an absolute godsend.  

I've been skimming through the documentation for gtk+ (including
the tutorial, reference and some of the source of 1.0.6 and 1.1.3) 
looking for details about the themes support so I could see whether
anyone had thought of the ideas I'd like to propose below. I didn't
find much so I figure you may not have gotten around to planning
anything as fancy as I'm about to suggest...

Toolbar Themes
--------------

The current toolbars look something like this:

        [Save][New] [Cut][Copy][Paste] [Undo][Redo]

that is, either rectangular or square buttons with a pixmap icon
and/or a single word caption with a tooltip.  I'd like to suggest 
that buttons (and toolbar buttons in particular) be allowed to have a 
few other interesting variations such as ellipses, circles, rounded
rectangular clusters (a group of buttons without a space between them)
in the following simple formats:

a)      (Save)(New) (Cut)(Copy)(Paste) (Undo)(Redo)

        Elliptical buttons which should, IMO, be domed.
        Maybe only a pixmap not much room for a caption.
        A particularly impressive (though a bit large) example
        can be found on the http://www.sasg.com/mui.html web page.

b)      (S)(N) (C)(C)(P) (U)(R)

        Domed circular buttons similar to those used in Sun's HotJava.
        Only show a pixmap and tooltip since there's no room for a
        caption.

c)      (Save][New) (Cut][Copy][Paste) (Undo][Redo)

        This style looks particularly impressive because it keeps
        a cluster of buttons looking like they are meant to be 
        together.  Only the ends of a cluster are rounded.
        Plenty of examples on web pages (see the above URL for
        another nice example).


There are probably hundreds of wild ideas for button shapes but
I've chosen these because they are already in common use in web 
pages or even in existing software and do look very professional
and distictive. (There are plenty of other interesting widgets
waiting to be implemented like the GIMP's home page navigation 
widget)

The user (me :) should be able to select a single toolbar button
format for all their applications.  Thus rendering all applications
with those neat looking rounded clusters.  Obviously, the shape 
chosen will have implications for which GtkToolbarStyle can be 
supported -- and would need to override or ignore those that aren't 
supported.

Of course similar support should be provided for buttonboxes and 
other types of widgets.  In fact it'd be rather nice if most/all
widgets had a specific implementation for a given shape theme that
way a user could simply start with a default widget shape of
elliptical for example and through the inheritance mechanism have 
consistently shaped widgets throughout the interface.

Something like:

/* in gtkenums.h */
/* Shapes for widgets */
typedef enum {
   GTK_WIDGET_RECTANGULAR,
   GTK_WIDGET_CIRCULAR,
   GTK_WIDGET_ELLIPTICAL,
   GTK_WIDGET_ROUNDEDCLUSTER
} GtkWidgetShape;

with a corresponding variable in the _GtkStyle struct.

The rounded-cluster would appear to be the most difficult to 
implement however this isn't necessarily true.  If the developer
tells the widget at compile time that it is the first or 
last of a cluster then there is no need for difficult on-the-fly
decisions to be made in the container_class->forall() for instance.
Then two new GtkWidgetFlags could be used, one for GTK_CLUSTER_FIRST
and one for GTK_CLUSTER_LAST, to hold the cluster info.  A single 
button could then be both first and last have two rounded sides.
In fact that would also make it very easy to support a rounded
rectangle look -- simply treat all buttons as if they are both
first and last.  Of course the trouble now is knowing which two 
sides should be rounded.  This should be obtainable via a call to 
the parent to determine its orientation shouldn't it?

I had thought of suggesting that the "clusters" I mentioned above
only be pack boxes but a pack box can be very loosely spaced ruining
to a degree the effect of the rounded clustering.  So it probably
would be better to have 

A variation of this idea could be applied to things like scrollbars
so users could have their scrollbars look like OpenLook scrollbars
(with the up/down buttons on the slider) or with both buttons at one
end of a scrollbar.

Hmmm... I've been looking through the code for a couple of hours now
so I'm still only a newbie but I reckon this could be quite simple to 
implement.  It's a shame I'm overloaded with work for LyX and my PhD 
otherwise I'd get some code done for this.  (I'll have time after 
Christmas ;-)

Toolbar breaking 
----------------

(when a toolbar won't fit horizontally across a window)
At present there appears to be no breaking such that the toolbar
simply disappears offscreen. I'd like to suggest an improvement over
the simple wordwrap style that others are probably considering at
present that doesn't break button clusters if possible.  Here's how
things would look with word-wrap style breaking:
        
        (Save][New) (Cut][Copy]
        [Paste) (Undo][Redo)

or 
        (Save][New) 
        (Cut][Copy][Paste)
        (Undo][Redo)

the first doesn't look very good when used with rounded clusters so a
simple solution would look like:

        (Save][New) (Undo][Redo)
        (Cut][Copy][Paste)

where adjacent clusters are reordered (onscreen) to try to ensure 
that as many clusters as possible remain unbroken while also 
ensuring that the toolbar ordering isn't disrupted too much (the 
application developer would have clustered these buttons for a reason
and there is also likely to be a reason for the ordering of the 
clusters after all).

Then again if a developer uses pack boxes to create the clusters the
breaking cannot possibly look like the first example above. 


Button Pixmap Scaling
---------------------

Perhaps a standard pixmap size of 64x64 could be used and these
scaled to suit the users preferred button sizes.  This pixmap 
resizing would only need to be done whenever a user decides to
change the standard size of the buttons or their shape.


Enlightenment/Gnome Window Borders and Titlebars
------------------------------------------------

I've included this here because I know Raster is working on gtk+
themes so I figured I'd save an email and maybe prompt other 
discussions also.

This is a little further out into left field but could be a very
groovy addition.  How about allowing the execution of an external
program *inside* the titlebar or borders of a window!  
(From a gtk perspective this could equally apply to having an
 external program widget)

Something like xscreensaver's Qix running in the titlebar of the
active window would be a very distinctive feature for Linux/Unix
that would blow the average GUI users mind.

The application I actually want to run that requires this capability
is considerably less compute intensive but just as crazy.

What I'd really like to do is have the lighting/shadows of all the 
widgets (although I'd settle for just the window title bar and 
borders) controlled by the time of day.  That way my windows would 
appear to be lit by a lamp rotating around the border of my screen
as if it was strapped to the hour hand of a clock.  (Making sense?)
Since its "attached" to the hour hand it'd only require updating
once every couple of minutes.  I'd always know roughly what time it
was without having to find space for a clock on my desktop :)

Just image the kinds of demos you could have running at your local 
computer expo or USENIX or Windows-Worshippers group! 

I'd be very happy to discuss these ideas further so please CC me 
if I don't respond to a post to the list.  My intray is always 
full so I may not remain subscribed to the list for more than a few
days. 

Regards,
Allan. (ARRae)

P.S. I'd like to help implement these ideas but at present I'm 
     trying to finish my PhD and get the gui-independence of LyX
     finished and then implement a bunch of new stuff for LyX and 
     assist in the porting to Gnome/Gtk-- ... after Christmas I 
     should have a bit more time available.