Re: AppIcon patch revisited

[Richard Frith-Macdonald]

On Friday, February 9, 2001, at 02:27 AM, Dan Pascu wrote:

> On  8 Feb, Richard Frith-Macdonald wrote: 
> > What we lose from this is - 
> >  
> > The ability to move the appicon/miniwindow under program control 
> > The ability to handle drag-and-drop in appicon/miniwindows 
> > The ability to make use of mouse actions inside appicon/miniwindows 
>  
> I don't quite understand why this is not possible. The window in the 
> appicon belongs to gnustep, so it should have control over it to do 
> whatever it likes, maybe except moving it. But if it implements dnd it 
> should respond to an object dropped on it.

I was thinking of starting a drag session ... it can't do that if it
has handed over the mouse click to Window Maker.

> And it should already 
> receive mouse actions. If it wants to open a menu on right mouse click 
> on it, its free to do so, and if it doesn't want wmaker to open its own 
> right click menu, then it should not relay the right click to wmaker. 

True .. it should be able to use right click (I forgot about that ...
the right mouse click is almost never used in OpenStep).

> 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
can't tell when/if anywhere on the window has been clicked on.  It
therefore can't have button actions, and while it can get mouse
movement information, apps are generally expected to ignore mouse
movements except when they are doing something in response to a click.
In practice, almost all mouse operations are initiated by a left
mouse click - so to lose that is to lose most of what you want to do
with the mouse.

An example is the NeXTstep app Fiend.app - this application had
three little buttons on its appicon, used to switch between workspace levels
and to unhide the fiend menus.  This can't be implemented if the app
(ie code written to OpenStep API) never gets the mouse click.

Now, all the problems *can* in theory be worked around in some way ... but
workarounds require the front-end library and/or the app (OpenStep code)
to be modified and to know they are working with Window Maker.  This is of
course fundamentally against the principles of OpenStep/GNUstep .... which
want to encapsulate system dependencies at a low level, so that the programmer
using the system never has to deal with them.  The GNUstep app developer should
not need to know they are using X, let alone that they are using a particular
window manager aas far as the code they write is concerned.

A solution that doesn't require *any* workarounds for developers, is if
Window Maker could handle the movements of icon windows exactly like it
does with any other window.  GNUstep apps could then treat icon windows
just like any other window and no workarounds would be required.