Re: Transparent Window, or event catcher

[Pascal Bourguignon]

> From: Luis Garcia Alanis <luis@sogrp.com>
> Date: 11 Feb 2002 12:55:12 +0000
> 
> Well
> 
> 
> the way I have been doing this is, to have the dock receve a
> notification (Distributed) that the icon is on a drag candidate spot, or
> doking position. I would need to add a notification to tell GWorkspace
> that Dock.app is present. and it can be extended to a list of posible
> ares into where the dock(s) can be and we could have multiples docks and
> different kinds of them.

Good idea.  And we  could have other applications allowing application
icons to be docked. 

(And why not (optionaly) dock documents or folders too?)

 
> and separated code.
> 
> But enrico does not seem to be happy about making notifications for an
> external app.
 
Why? 

That could  be a good way  to do it after  all. The point  is that the
dock as  it's designed on NeXT  has holes. Otherwise it  would be very
easy to  use the normal inter-applications  drag mechanism. Therefore,
having applications  sending a  list of screen  area to  the workspace
manager  to   register  interest  could  effectively   allow  a  clean
implementation of external docks.

This  is only  needed because  of these  holes.  Othewise,  the normal
interappplication drag is all we need. For example, in the case of the
MacOSX  dock, it seems  to have  an opaque  background to  receive the
docked icons.


But still,

- Note that the  dock must learn when the  workspace manager launch an
  application  that's  in the  dock,  either  by  double-click on  the
  application package,  or on a document  that must be  opened by this
  application (to change from "..." to "   ").


- Leaving alone  WindowMaker and its  own (X) application  icons, when
  the icon miniwindow  of a GNUstep application is  moved, it too must
  know where there are dockable areas. That means that all the GNUstep
  applications must be observers to the dock's notification center for
  these   notifications.  The  notification   center  does   not  keep
  notifications  for  later   applications, does  it.  Therefore  some
  protocol  should be  added to  allow  new applications to learn  the
  dockable areas.



 
> On Mon, 2002-02-11 at 17:54, Pascal Bourguignon wrote:
> > 
> > 
> > > 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------