Theme suggestion: use shared libraries

[Maciej Stachowiak <mstachow mit edu>]

I have some comments on the recent theme discussion. I'm posting to
both lists because someone posted on the gnome-gui list advertising 
a hacked Win95/Qt-looking Gtk.

I agree with Raster's comments at the time that bifurcating Gtk
development would be a very bad idea. However, I do not agree that the
theme plan as outlined currently, based entirely on pixmaps, solves
all of the problems that the gtk95 thing was intended to solve, nor
does it solve all theme-related problems. As I see it, theme-like
functionality has two purposes:

* Emulate the native loook of various OS's and windowing systems that
people are used to and like.

* Provide various highly customized "flashy" looks.

These two goals have slightly different requirements. The first goal,
it seems to me, is best achieved by something with minimal resource
overhead (low memory usage, high speed, low load on X server, etc),
and maximum accuracy in emulating the target systems. The second is
best achieved by a framework that provides maximum flexibility, and
allows new looks to be implemented easily, without actual programming.

I think what we should shoot for is a system that can satisfy both
these sets of somewhat contradictory constraints, as well as
efficiently implementing the current native Gtk look. 

What I suggest to solve this is the use of shared library
plugins. This has been discussed before on the main gnome-list, but
I'd like to flesh out the idea, and suggest some reasosns why it's
preferrable to the approach that it appears is currently being taken.

How this could be implemented:

* Modify the gtk core so that instead of drawing functions being
statically attached to each widget class, each widget class (or
perhaps even each individual widget) would have a pointer to a drawing
function that would be changed at runtime. Also provide an interface
so that this could be changed on the fly, and so that new drawing
functions could be dynamically loaded and added to existing widgets.

* Package available sets of drawing functions as separate libraries
that are loaded at runtime. Allow libraries that provide various looks
to be statically linked in with gtk, or dynamically loaded at
runtime. It may be advisable to compile the native gtk look in
directly by default, but I don't think this is useful on systems with
good shared library support; you may want to just unload the native
gtk look if you are using the pixmap-based look, or the mac look. 

* From code that has already hacked on to some degree, it would be
possible provide a native gtk look plugin, a win95-style look plugin,
and a pixmap-based highly configurable "enlightened" look plugin for
starters, and then allow other developers to go off and contribute
their own additions if so inclined.


Here are the reasons I think this is better than just adding style
attributes to the gtk core in a somewhat ad-hoc manner:

* It guarantees absolutely that the native gtk look will not have a
significantly higher resource consumption than it does now. This is
unclear with an all-pixmap themes plan - at the very least, all the
pixmap code as well as all the gtk code will have to be compiled in.

* It allows popular emulations of popular OS's to be implemented very
efficiently.

* It is more flexible. There's things that you can't easily express
with a pixmap-based system, options that people might reasonably
want. For example, suppose I wanted a custom look where I could put
animated backgrounds into widgets. No sane person would want the code
for this in the gtk core - yet some people may actually want to use it
on their desktops at least occasionally to show off. Another example
would be looks that change not just the shapes and looks of the
individual parts of a widget, but ones that rearrange the
configuration of the parts on the screen. One example would be the gtk
option menu widget. The whole option menu is an active region that, if
clicked on, will drop down the relevant menu. If someone were to write
a really accurate win95-style look, this should be replaced with a
windows-style drop-down list box, where only a button to the side is
supposed to drop down the list. You can't express changes like that
very well with a solely pixmap-based approach.

* It allows more freedom for the pixmap-based system. The pixmap-based
look plugin in a shared library framework would need to worry less
about issues like efficiently implementing normal beveled looks. There
would also be less need to limit the available options to make sure
standard gtk resource consumption does not go too high - flexibility
and power could explixitly be the number one goal.


I know there have been suggestions to partially adress some of these
issues with a pixmap-based framework - for example, to add control
over positioning of the parts to some specific widgets, or to try to
draw beveled looks in some efficient way from pixmaps. But I'm not
sure that these efforts can adress these issues as well as a
shared-library approach can. The shared-library approach also includes
the full power of the pixmap approach indirectly, as a specific look
plugin. So why not do it this way? I haven't yet heard any meaningful
criticism of the shared library approach.

Now don't get me wrong, I'm not trying to criticize the pixmap-based
approach. I think Enlightenment proves how powerful it is. What I'm
suggesting is that it be augmented by something that allows all that
power and then some, but also allows ultra-low resource consumption
for those who prefer - or will settle for - simplicity.

So I advise the poster who advertised the gtk95 hack not to abandon
his code, but to try to work with others interested in themes and gui
issues to develop a shared library look-plugin framework that his code
could be worked into, rather than being wasted.

 - Maciej Stachowiak