Drag and Drop, events, and embedding. Help!
Mike Pinkerton
figured I'd solicit some ideas here.
Here's how Mac D&D is working so far:
- each window (mac window) registers a tracking handler and a receive
handler with the drag manager
- the tracking handler gets called when the mouse enters/leaves the
window and when the mouse moves within the window.
- the receive handler gets called when a drop over a window occurs.
Since the granularity of the DragManager is on the window level, we have
to get the information into gecko in some way, since we can't register
things w/in gecko directly with teh DragManager (like we can on win32 or
gtk). The only way "in" right now is through the nsMacEventHandler held
onto by the window that the drag event is in. As of today, the only
thing that the event handler accepts is a native EventRecord.
What I need is a way to tell the event handler that a drop occured so
that an NS_DRAG_DROP Gecko event is created. I also need a way to make
sure that the nsEventStateManager gets tickled correctly for drag enter
and drag exit events on frames. (NS_DRAG_ENTER, NS_DRAG_EXIT).
There are a couple ways to do this:
1) hack the internals of the event handler to magically know that a drag
is going on and at the last minute change the gecko event to a drag
event instead of the regular mouse_move event
2) add a "hint" parameter to the HandleOSEvent API that says what the
caller thinks the event should end up as regardless of what the event
handler determines the event to be.
3) add a new API that takes a nsGUIEvent (a gecko event) and have the
caller create one and pass it in instead of an EventRecord
4) add a new api that just says "hey, a drop occured" or "hey, the mouse
moved during a drag" and put the code that creates the nsGUIEvent w/in
the event handler
1 and 4 have the benefit that they keep all the event translation code
w/in the event handler. 1, however, is probably a smarmy hack and would
be a nightmare to change once it worked. I don't care for 2 at all but...
So assuming I did 3 or 4, what impact would this have on embedding
applications and their drag and drop?
--
Mike Pinkerton
Mac Browser Weenie
pink...@netscape.com http://people.netscape.com/pinkerton
Kirk A. Baker
<pink...@netscape.com> wrote:
> Need some feedback on event stuff wrt drag and drop on MacOS so i
> figured I'd solicit some ideas here.
>
> Here's how Mac D&D is working so far:
>
...
> There are a couple ways to do this:
>
> 1) hack the internals of the event handler to magically know that a drag
> is going on and at the last minute change the gecko event to a drag
> event instead of the regular mouse_move event
> 2) add a "hint" parameter to the HandleOSEvent API that says what the
> caller thinks the event should end up as regardless of what the event
> handler determines the event to be.
> 3) add a new API that takes a nsGUIEvent (a gecko event) and have the
> caller create one and pass it in instead of an EventRecord
> 4) add a new api that just says "hey, a drop occured" or "hey, the mouse
> moved during a drag" and put the code that creates the nsGUIEvent w/in
> the event handler
>
> So assuming I did 3 or 4, what impact would this have on embedding
> applications and their drag and drop?
I'd vote for #3 because in my current incarnation of my RaptorCanvas
for Java, on the Mac, just passing nsGUIEvents to the nsIWidget does
nothing, even if I package it with a correct Mac native EventRecord.
I have to use the nsMacMessageSink and nsRepeater. It would be great
if I could just pass the nsGUIEvents converted from Java. That would
make the Mac version more like what I expected when looking at the APIs
for nsIWidget and nsIWebShell. Having just barely started on the Win32
port of my code, I am assuming that passing the nsGUIEvents to the
widget will work on Win32 systems.
With the current Mac Gecko event system, update events are a source of
problems in Java, because the JVM handles the BeginUpdate()/EndUpdate()
wrapping around a call to the update() method of the Canvas class. I
have no control over this.
It might be kinda neat to have a function in the API that would convert
an EventRecord to a nsGUIEvent, and a functions to build an nsGUIEvent
from a tracking handler (BuildDragEvent()) and from a receive handler
(BuildDropEvent()).
What would also be necessary would be a function like
nsGuiEventToNativeEvent() that could convert a nsGUIEvent (that didn't
have a native event packaged into it yet) into a native event.
Then the nsGUIEvent system could be used by lots of different kinds of
embedding apps, not just C++ apps that have access to the Mac event
queue. Those embedding environments that don't have access to the Mac
event queue would be responsible for creating the nsGUIEvents
themselves, but they could use nsGuiEventToNativeEvent() to get a
native event and package it up before sending it to the widget.
Thanks,
-Kirk
Alex Curylo
(Mike Pinkerton) wrote:
> Since the granularity of the DragManager is on the window level, we have
> to get the information into gecko in some way, since we can't register
> things w/in gecko directly with teh DragManager (like we can on win32 or
> gtk).
Why wouldn't some strategy along the lines of PowerPlant's LDropArea
mixin class (LDragAndDrop.cp) work for you?
--
Alex Curylo -- al...@witty.com -- http://alexc.webjump.com/
"Just say no okay Alex, you are the only sane one left!"
-- Tanya Perkins
Mike Pinkerton
> Why wouldn't some strategy along the lines of PowerPlant's LDropArea
> mixin class (LDragAndDrop.cp) work for you?
That still relies on the event getting down to the appropriate pane.
PowerPlant (since it created all the subviews) can easily dispatch the
event down the view tree. However we're at a top level pouring events
into a black box.