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

["Christopher E. Hassell" <hassell lobotomus h2net net>]

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.

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

-- 
// {if(me==chris)me->confuse(yu);} // DubleTawk+SinglThots+AntiFathe: UnRome II
### C>H> ### jeezfrk@h2net.net ////////////////// {"Nietzsche is dead."-God} //