Re: AppIcon patch revisited

[Robert J. Slover]

Richard,

Would it be reasonable for the backend to relay the
mouse events if they occur within the outer 2 pixels
of the tile and convert anything else to a GNUStep
event?  This should give behaviour consistent with
the X-based 'dock apps'.  The only dock app I have
that will allow an arbitrary drag is wmclock.app. All
of the rest expect you to drag within a 2 pixel
border.  Also, test for the 'Alt' modifier and relay
those mouse events...since WindowMaker expects to be
able to drag anything with 'Alt' (or maybe it already
keeps these events to itself, I dunno).

HTH

--Robert

Richard Frith-Macdonald wrote:
> 
> On Saturday, February 10, 2001, at 07:43 AM, Dan Pascu wrote:
> 
> > On  9 Feb, Richard Frith-Macdonald wrote:
> > >> Relaying the left click to wmaker allows wmaker to move the appicon
> > >> around.
> > >
> > > If the backend gives the left mouse click to Window Maker, then the
> > > app (ie the code written using the OpenStep API) doesn't get it, and
> >
> > Of course it does. Relaying doesn't mean that you completely give away
> > the event. you receive the event, process as you need, then duplicate
> > it (send a copy of it) to wmaker. So _both_ your app and wmaker get the
> > event (if you decide the events needs to be relayed to wmaker).
> > You can pass it to your app to do whatever it needs with it, then if
> > necessary send a copy to wmaker too.
> 
> Of course, the above is nonsense in the context of a GNUstep app ...
> if you have both Window Maker and the GNUstep app (OpenStep API code)\
> trying to deal with the same event then you get total confusion.
> 
> I think you are suggesting this because you still don't understand the
> nature of the system ... I've tried to explain a few times, and I'll try
> again ... but perhaps you need to resort to looking at the code?
> 
> The GNUstep application consists of three separate layers ...
> 
> 1. The application proper, written by some developer using the OpenStep
> API (plus MacOS-X and GNUstep specific extensions perhaps).
> Code at this level operates purely with the OpenStep/GNUstep API
> 
> 2. The GNUstep gui (frontend) library ... a collection of objects that 
> provide the
> API that the developer uses to write the application.
> Code at this level operates purely with the system independant API to the
> backend library.
> 
> 3. The GNUstep xgps (backend) library (or xdps library, or in future perhaps 
> other
> non-X libraries).  This library is the only part of the code that even knows 
> that
> X exists.  It handles all the interface with the X system and the window 
> manager.
> 
> Just to stress a point ... each layer communicates with the other layers by a 
> well
> defined API, and *no* knowledge of X exists in the top two layers.
> 
> So, when an X event arrives, the xgps library converts it to an OpenStep event
> and inserts it into the event queue in the gui library.  The gui library then
> presents it to the application code, and the application code decides what
> action to perform in response to the event.
> 
> There is obviously no way for the application code at the top level to know if
> the bottom level xgps code has forwarded a copy of an event to the X window
> manager - nor should a developer working at the top layer *need* to know
> anything about what is going on in the bottom X-windows layer.
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep