[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transparent Window, or event carcher
From: |
Lars Sonchocky-Helldorf |
Subject: |
Re: Transparent Window, or event carcher |
Date: |
Mon, 11 Feb 2002 22:05:08 +0100 |
> > 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
Re: Transparent Window, or event carcher, Dan Grillo, 2002/02/11
Re: Transparent Window, or event carcher,
Lars Sonchocky-Helldorf <=