Re: Transparent Window, or event carcher

[Pascal Bourguignon]

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

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.




-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------