Re: Theme suggestion: use shared libraries

[Maciej Stachowiak <mstachow MIT EDU>]

Before I go into replying to this message, I want to make something
absolutely clear. I do not in any way intend to disparage the
themability ideas presented already, or suggest that they should not
be implemented. All I'm saying is that there should be a plugin
architecture to go along with the pixmap stuff, and the pixmap stuff
should be made into a module within that plugin architecture. I don't
see how this limits your code in any way. 

If you have soom good reasons why loadable plugins + pixmaps is either
actively bad in some way, or is not better than just pixmaps (I think
my examples below show that it does offer added functionality) please
post them.

If not, please read the suggestions with an open mind.

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

My claim is that they have somewhat contradictory design goals which
can be dealt with better through a loadable plugin mechanism, rather
than trying for full generality in one chunk of code.

> 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
 
That's fine, I don't see how it makes the shared library idea harder
to implement.

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

Well, what I am suggesting is that there be separate libs for each of
these looks, demand-loaded as needed. The other themes are not just
bevels or just line-drawing; the Next look for instance uses 3-D
elaborations on top of widgets which in some cases should _not_ be
scaled and are not just bevels on the edge.

> yet again.. you are talking form a programmers point of view - simple
> rule:
> 
> Programmers can't draw, Artists can't program.

The point of the plugin architecture is not draw fancy art, it is to
emulate existing looks efficiently and accurately. That being said, I
don't think it's generally true that artists and programmers are a
disjoint set.

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

Keep in mind again that I don't want to stop you from doing anything
that you are currently doing. I agree that the pixmap stuff is
great. I'm just suggesting that the loadable plugin stuff be added _in
addition_, not instead, and the pixmap themability be added into that
framework. I don't want to take away from anything you're doing, I
want to suggest additions to it.

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

The reason to have several is simple: people who want wacky features
can implement all the wacky features they want, and people who want
simplicity don't have to pay the price in resource overhead.

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

If gtk/pixmap-themes _plus_ imlib is less code total than the current
gtk, I will be very impressed. It's not really fair to not count code
in a separate library that is doing most of the work. That being said,
I think the real problem is not code size, but load on the X
server. If you need a different scaled pixmap for each different size
of button, that puts a lot of load on the server. If you use this to
draw simple beveled widgets, people are paying for a lot more than
they get. People have suggested workarounds - like special-casing
particular pixmaps and drawing bevels from them instead. But I don't
think that adresses the whole issue, and it will _definitely_ not be
as small or as fast as the current gtk.

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

Well, if you allow special routines to draw various bevels, why not
allow routines to draw the whole darned widget? And bevels are not the
only difference here - take a look at the gtk option widget and the
win95 drop-down list control and tell me how the difference between
those could be expressed completely with pixmaps and bevel routines/

> 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.
 
But why not allow people to add routines without as a result clogging
up the whole library? Or add routines that aren's distributed with the
core gtk distribution? Or add their own custom ones without having to
recompile gtk? I don't see any reason _not_ to provide this
functionality, and many reasons to do so, first and foremost that it
would not be very hard.

> ->  * 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 :)

I could spend all day thinking of cases I couldn't do that I could
with custom code, but I'll save that for below.

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

Well, my whole suggestion is to restructure gtk so that this library
could be added later. That's what loadable plugins are all about.


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

Yes, people will usefully use it. Someone has already coded hacked
routines to do the win95 look. We should have a plugin architecture
ready so people willing to do things like that will have a good
framework to put their code in.

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

OK, I will list several, some of them are rather contrived, some are
possibly quite useful. But first let me add that I don't think any
animation code should go in the gtk core ever - that's gigantic over
kill. That's why plugins should exist - so someone could do it
_without_ having to touch the core. That being said, here's some
things you can't easily do with the pixmap approach as it currently
stands, which involve only a static display:

* Suppose I am insane and I want my buttons to be a different color
based on their size. With a loadable plugin, I could write a button
drawing routine that would calculate the area and set the background
color to a different hue based on the area, so that for example, the
smallest buttons are red, they scale up slowly through orange and
yellow, and so on. You get the idea. But there's no easy way to do it
with pixmaps. You may well question the sanity of anyone who would
want to do this in teh first place, but the same has been said of
Enlightenment:-)

* Suppose I want to draw buttons with a fixed-with bevel and a
fixed-size 3-D-looking bump, always centered some fixed number of
pixels from the right edge. In other words, the background color or
even pixmap should scale

Crazy, you say? Well, that is more or less what the GtkOptionMenu
widget does, maybe I want to do that for buttons.

* Suppose I want buttons to be rectangular if they're smaller than
some cutoff size

* Stepping away from buttons, let's take a look at the checkbutton
widget. Someone might want to change it in such a way that the label
would be to the left of the checkbutton instead of to the right, or
even inside it for some weird reason, or to make the text change color
in addition to the normal button toggling. Can't really express that
with pixmaps.


So as I see it, pixmaps, insanely great though they are, have two
major limitations: sometimes you want an image to change with size in
ways other than scaling.


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

My suggestion is _not_ to have them be the same shared lib, but in
separate lodable modules so you don't need to load the code for both
if you don't want it.

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

Well, I think the way to achieve that goal is to provide look library
plugin functionality for gtk. Then you're guaranteed you never need to
touch gtk simply to change the appearance, and you can implement
anything you want in a generic framework, including all the looks you
mention. So what's the real problem with that? I think that plus a
really good Enlightened pixmap plugin will opimally satisfy the
minimalists, the people who want the look of some other OS, the
artistic people, and people who want to do weird things we haven't
even thought of yet. I can't see any downside. I don't think you have
mentioned a real downside yet either, you've just denied the need for
this system. But I think the need is clear, and it really shouldn't be
that hard to implement. And none of this would imply that any of your
code should fail to be included - it would just be in a plugin, not
the gtk core.


I'm somewhat embarassed now, because Marc Ewing has just posted a
message which says what I wanted to say much more concisely and
effectively, but I'll send this anyway. See his message for an
executive summary.

 - Maciej Stachowiak