Re: Transparent Window, or event carcher

[Lars Sonchocky-Helldorf]

> > From: "Lars Sonchocky-Helldorf" 
<Lars.Sonchocky-Helldorf@bbdo-interone.de>
> > Date: Mon, 11 Feb 2002 16:25:50 +0100
> > 
> > >IIRC, on NeXT,  the dock is managed by  the WorkspaceManager.app. 
It's
> > >not a  separate application.  The WorkspaceManager is  the 
application
> > >that handle the drag-and-drop of icons. Therefore, it's easy for it 
to
> > >check if an icon is moved over a dock position.
> > >
> > >Personnaly, I don't  see any reason why the dock  should be a 
separate
> > >application.  (If we  wanted to change the behavior of  the dock or 
of
> > >GWorkspace,  we  have  the  sources   to  do  it  and  subclass their
> > >implementation).
> > 
> > Dunno if this is a "strong" argument, but the reason for me is that 
> > GWorkspace is also ported to Mac OS X where a dock (separate 
application 
> > here) already exists. Why have all the stuff in one "big ugly monster" 

> > where it would be easier maintainable to have "little cute one purpose 

> > apps".
> > 
> > just my 0,02 E
> > 
> > Lars
> 
> A solution must be found.
> 
> If I  used GWorkspace on  MacOSX, I'd use  it as a replacement  of the
> Finder, therefore  there would not be  any MacOSX dock.  Well, I'm not
> sure here, I've not used MacOSX up to now, but I guess it's structured
> like on NeXT.

Well, Finder and Dock are two separate apps in Mac OS X (Finder isn't even 
a Cocoa app). 

> 
> Now,  in the  case  where we  have  several instances  of a  workspace
> manager running in  the same session, either the  user want both docks
> (which are  different in the  case of Finder+GWorkspace or  similar in
> the  cases of GWorspace*2  or WorkspaceManager+GWorkspace).   In those
> cases, we  could just allow  horizontal moving of the  GWorkspace dock
> and be done. Or she wants a preference to have it hidden or not.
> 
> Of course, the presence of  the dock within GWorkspace does not impose
> a "big ugly monster" implementation.  It can be provided as a separate
> bundle and a GWorkspace internal protocol. In this way, it can even be
> easily replaced by custom versions of a dock.
> 
> 
> 
> The point is that it's much more simple to implement a dock within the
> GWorkspace process than it is as a separate application. Just check if
> the mouse is  dragged over a dock position  during an application icon
> dragging session.
> 
> 
> 
> As a separate application, the problem you have is to get mouseEntered
> events over rectangles in the screen  that don't belong to a window of
> the dock application. I know  of a addTrackingRect:... method only for
> NSViews, while there is a  draggingLocation method to get the position
> in a dragging session from within the origin of the drag.
> 
> That  is, if  you  want to  use  "native" API,  with  a separate  dock
> appliction, you  must open a window  (or several) over  the whole dock
> and copy in them what happens behind.
> 
> Otherwise, you  need to extend  the dragging mechanisms  and/or cursor
> tracking to allow tracking the cursor over any area of the screen, and
> detect when  the mouseEntered even  occurs when some  dragging happens
> over the window of another window,  just because it happens to be over
> a free cell of the dock. 
> 
> In either case, that seems a lot of complications to me.

This may sound arrogant and beaten to death, but I think the easiest way 
is not always the best way.

Greetings, Lars