Re: button themes

[raster redhat com]

On 28 Jan, Shawn T. Amundson shouted:
->  
->  Here are my thoughts on the button stuff so far...
->  
->  If a shaped button is made, what extra work is involved in making
->  it react correctly (so if you can't press where the button is
->  transparent).  Is that just a matter of feeding the transparent
->  part as a mask to X to create the shaped window and like magic it 
->  is done?  (sorry, not played with anything like that before...)

Yes. That can be done that way - but gtk currently does not always
create a child window for the buton which is a problem. If this were the
case the shape mask could be set for the button, the background pixmap
set to the pixmap and that would be he end of it. The shape mask is the
event mask, so only events inside that shape would be honoured by X.

->  
->  Assuming it is simple to do this, how much overhead is produced
->  if we allow multiple shapes per button, one for each state?  Will 
->  it even be practical to allow a button to change shape?

not much. It's an extra 1-bit deep pixmap mask - and you just call an X
call to change the mask. Imlib and gdk_imlib can produce these masks
for you out of the images. (I designed imlib to do things like themes,
so it has most of the mechanisms needed which is why my desing is like
it is, but if there are better ideas I haven't thought of, I want to
know about them.)

->  -
->  
->  A button should not know anything about it's child
->  widget.  Therefore, the last step that is on the web page now
->  doesn't make sense to the toolkit.  Instead, it belongs in 
->  GNOME stock someplace, not GTK.  I suggest we start breaking 
->  these up now for clarity.
->  
->  -
->  
->  It seems to me that we want will want to have some other 
->  faster method for creating parts of themes instead of only
->  pixmaps.  For example, we could have one theme that just
->  changes how reliefs are drawn by specifying the drawing
->  color and lines:
->  
->  color #FFFFFF 
->  drawline 0,0 to 0,-1
->  ...
->  
->  This way we could define a fully motif/win95/mac without
->  the overhead of pixmaps.  This would allow us to have some
->  standard themes as well if we can do this in a efficient fashion.
->  
->  Basically all the above would be done by replacing the draw
->  function with a function that knew how to work with the special
->  info once it was read in and such.
->  
->  The syntax of a button would be in a gtkbutton.theme file.
->  
->  Images then would just be a special entry in this file:
->  
->  image "button.ppm"
->  
->  Of course the file would be broken up into the available
->  states like:
->  
->  [state normal]
->  image "button.ppm"
->  ...
->  [state pressed]
->  image "button.ppm"
->  ...
->  
->  All other attributes would be defined in these files as well.
->  Perhaps distributed in tar files like E's theme balls.  It would
->  be nice perhaps to make some way to compile them into a library
->  if that would speed things up.
->  
->  -
->  
->  So where does the prototype code start?  I think we start with
->  defining what needs to change for gtkobject (if anything), 
->  gtkwidget, gtkcontainer, and gtkbutton.
->  
->  My initial feelings are:
->  
->  gtkobject: not much if anything
->  gtkwidget: a lot of things, including the interface to setting
->             the current theme
->  gtkcontainer: some issues, most trivial
->  gtkbutton: no external interface changes, but core changes
->  
->  Core new functions:
->  
->  gtk_widget_set_theme(widget, theme);
->  gtk_container_set_theme(container, theme);
->  
->  Calling gtk_widget_set_theme should only change the current
->  widget.  gtk_container_set_theme should propogate down through
->  all the children and call gtk_widget_set_theme.  So changing an
->  entire window would take nothing more than:
->  
->  gtk_container_set_theme(window, theme);
->  
->  The question then becomes how the widgets know how to get the
->  theme information.  First we need to initialize the theme 
->  into memory:
->  
->  gtk_theme_set_path("/usr/local/lib/gtk/themes:/opt/gnome/themes/gtk");
->  gtk_theme_load("57chevy");
->  
->  We will assume for now that works like magic and found all 
->  the files and such.  We need a couple more functions for
->  working with loaded themes (note - more than one theme can
->  be loaded at once to allow switching at runtime).
->  
->  gtk_theme_unload("57chevy");
->  gtk_theme_refresh("57chevy");
->  
->  To work with the unload/refresh commands we may wish to 
->  keep track of a couple of things - such as which widgets
->  think they can use the things being unloaded or refreshed.
->  To do this, widgets should be able to register themselves
->  as using the theme:
->  
->  gtk_theme_register_widget("57chevy", widget);
->  gtk_theme_unregister_widget("57chevy", widget);
->  
->  Note, we can optimise this by registering only a container:
->  
->  gtk_theme_register_container("57chevy", container);
->  gtk_theme_unregister_container("57chevy", container);
->  
->  This will allow us to notify widgets when they can no longer
->  use a theme or when they should redraw because the theme
->  has been refreshed.
->  
->  Ok, lets go back to gtk_widget_set_theme().  When called, the
->  widget asks the theme manager what functions it should use for
->  doing various things like drawing - defaults to these will be
->  defined as they are now.
->  
->  func = gtk_theme_get_draw_function("57chevy", "gtkbutton");
->  widget->draw_func = func;
->  
->  Ok, discuss.
->  
->  --
->  Shawn T. Amundson		Complete Internet Solutions
->  Senior Systems Administrator	Minneapolis, Minnesota, USA
->  amundson@CompleteIS.com		http://www.CompleteIS.com/~amundson
->  
->  while (i) { last }
->      i, do exist.
->      forever;
->  
->  

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