Re: Theme suggestion: use shared libraries

[raster redhat com]

On  6 Feb, Maciej Stachowiak shouted:
->  
->  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.

there is no reason why the first can't be a subset of the second.
Infact that is my desing idea.

->  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.

already discussed.. and the idea.. but it needs some major modifying of
the drawing system - there are several functions that are called just
to draw a button (i've bene looking at gtk's button code for now) I had
to re-direct some functions to only call gdk_button_draw (the paint,
focuse etc. functions aren't used anymore).

This centralises drawing which is good and makes it easier for this
plugin interface.

i am ONLY talking buttons for now, but there would be 3 functions
needed:

_init
_draw
_destroy

for a theme lib - there should be a standard theme lib that is a
superset of 95% of all themes (be they win95, mac, next etc) - those
other themes ar just small bits of line drawing code for bevels - the
pixmap code is tny thanks to imlib - infact using pixmaps is LESS code
that what gtk currently uses... I have juts doen a quick mod to a test
gtk I'm playing with.

->  * 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. 

yet again.. you are talking form a programmers point of view - simple
rule:

Programmers can't draw, Artists can't program.

You need a theme system that allows artists - those who will be
designing themes, to be able to do a theme withotu touching one line of
code. This is NOT hard at all.. that is the attempt of desing on the
themes page - the only thing missing is options for different border
drawing styles. I am busy documenting Imlib right now, and after tha
I'm coming back to the theme debate and updating the page with new
ideas.

->  * 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.

Why have several? just have one that handles all cases - literally for
a draw function it is NOT much code. It standardises things and does
allow for it to be replaced or updated later - but it saves having 10
billion plugins.

->  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.

gtk infact can be rather inefficient in how it draws and redraws
widgets. I've looked at the code. It needs a revamp of its drawing
system. It was nto desinged ot be modified much. The pixmap code is
tiny compared to gtk's current drawing code... to draw a pixmap in a
button of the correct size and shape int he right location in all bit
depths and handle caching, resacaling, super-imposition, etc. is a
single function call. Imlib handles all the rest already in a shared
library.

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

The only addition we need is a series of optimised border (the bevels)
drawing routines for the current "nextish" style, motif, win95, Amiga,
mac etc. styles. that is all that is needed. imlbi can do bordeers via
efficient border pixmapping (I put that in especially after Owen's
suggestions for this purpose). then you have border on/off - if on,
select a pixmap for the borders (in all states) OR select a  drawing
routine.. it can be the gtk/next/win95 one (the current drawing routine
basically is exactly like these). all these  routines sit in the
drawing (theme) lib that doesnt' handle events or anythign else except
drawing. this lib can be updated and added to as time goes on.

->  * It is more flexible. There's things that you can't easily express
->  with a pixmap-based system, options that people might reasonably

There isn't much the pixmap system can't do. I specifcally added
extensions to imlib for this... I have spent a lot of time thinking of
it and it should handle all cases - you just need a little imagination,
and the gimp :)

->  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

this is stage 2 and needs BIG reworkings in gtk's internal core,
somehting i think is best left alone for a while. this could be put
into another library outside gtk later.

->  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.

it may provide mroe freedom.. but will anyone usefulyl use it? see
above about artists and programmers. believe it or not the pixmap
system does handle a huge number of cases - I have  sat down and
thought about them.. for many hours on end. Owne brought up a few
optimisations I coudl possibly put in, which I did. 

Please come up with examples of situation (okay.. I'm NOT talkign
animted widgets - just stills for now. yes.. we can replace the library
later with one that does animated pixmaps), that a pixmap situation
wont' handle. I'd be interested to hear of one.

->  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.

that was assumed.. the whole thing was goign to be a shared lib. we are
discussing what shoudl go into this lib - there needs to be a default
theme library that is board enough to handle the current case and more
advanced theme cases for a long time to come before it needs a revamp.

->  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.

that was the idea.. :) the same shared lib does the currnet crawing
style and pixmaps.. it jsut doesnt access any imlib rotuines if pixmaps
aren't used.

->  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.

that is what I told him... work WITH others - take his ideas and
present them in a generic form that can be put into a generic theme
library that witht he correct settign will handle his win95 case
perfectly, and wiht a few more changes of config will handle a MacOS
lookk, or an AMigaOS MUI look, or an Enlightenment pixmap look - no
needs for more libraries.. just a good generic one. If in future more
optins are wanted/needed it can be expanded without touching gtk.

->   - Maciej Stachowiak
->  
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/