Re: External Dynamic GUI-Mods (was Re: The concept from MUI (Amiga))

[raster redhat com]

On 21 Feb, Christopher E. Hassell shouted:
->  On Wed, Feb 18, 1998 at 03:57:36PM +0000, Joel Dillon wrote:
->  
->  # > I don't CORBA is higher level above gdk and gtk... it should be done at
->  # > gdk and gtk level - fairly simple using XClientMessage Events to the
->  # > base window of each client. GTK can listen for this easily by extending
->  # > its event mask and  apon certain client message events unload then
->  # > reload the theme stuff...
->  
->  #   That's a good point, I'd forgotten about ClientMessages. Of course
->  # you'd need the editor to get the window IDs - by having the user click
->  # on widgets perhaps?
->  # 
->  # 	Jo
->  
->  Which gets to several other points, and some I've wanted to consider.
->  
->     I've written an request-event-filter-through client before, and we used it
->     for direct automated testing.  (i.e. a pass-thru like Xnest etc..)
->  
->  If we had a reasonable *base* for identifying WID<->widgets, then the entire 
->  widget tree becomes almost a scriptable language (as long as "identification"
->  can be as concerete as a useful language's actions).   This is only showing 
->  now what could --finally-- be taken advantage of in X11.  
->  
->  *All* the X capabilities (pixmaps, drop&drag interaction, serialized 
->  transport) that have lain dormant for so many years since X11 came out!
->  That kind of Power->Integration is what X needs, and the interface glue at 
->  every level can help.  X is a very porous system, and yet pretty secure from 
->  interaction-crashes (as opposed to others designed well (Apple) or badly
->  (unnamed)).
->  
->  For example, for gtk (maybe gdk?) it would be nice to have an explicit 
->  "widget-tree" readout that maps WID to widget (I know, not an Xt-style 
->  widget).  When that happens then all sorts of stuff can occur (with a filter 
->  or with the R6 RECORD Xtention):
->  
->  (Note that I believe none of these require -much- help from the client!!!)
->  
->     * Event-simulation-macros (record->playback macros on the title bar?)
->     	(y'know all that "Wizard" crap from M$?  Scriptized GUI is all 'tis!)
->     * External changes of various GC attributes [font, colors, line styles]
->         (relying on re-use of GC-ID by widgets) 
->     * Refresh of modified shapes/fonts etc.. with "ClearArea" to produce an
->         expose of the updated patch.
->     * Sounds/Events associated with appearance of various results (i.e.
->         external input *and* monitoring of externals)
->  
->  Having a GC's contents modified on the fly should nearly never crash an app's
->  interface.  It might only botch the screen badly if done wrong.  The
->  transparency from the user's perspective might as well be seamless if desired.
->  
->  Monitoring readouts on X11 apps would be almost the same.
->  
->  The only real requirement is a vaporlock on the WID-->Widget-->Action
->  association.  For appearances, a cosmetically "accurate" setup would work.
->  For actions, a label or pixmap match would be needed.

there is 1 major flaw in this... GTK has some nasty habits.. and that
is that many widgets do not have windows... they draw in their parents.
This makes this kind of work hard. The best we can probably do it use
the client's base window id and ask the client for the rest. GTK does
not make any use of backgroundpixmaps for pixmap widgets and other
widgets using pixmaps (strange - because this saves redraws) - but some
of this reason is due to not having child windows in many situations...

->  # -- 
->  #          To unsubscribe: mail gnome-themes-list-request@gnome.org with 
->  #                        "unsubscribe" as the Subject.
->  

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