Oliver Graf <ograf(a)fga.de> writes:
What I have done in the last hours is the following:
- I removed the extra drag and drop events
- I made the OffiX drop catcher in event-Xt.c generate misc-user-events
with a function of dragdrop-drop-dispatcher and the dnd-data as object.
This runs fine (now with egcs -O3 -mpentium -- without -fno-caller-saves).
But to make the thing really work, the function called
(dragdrop-drop-dispatch) must have access to the position, button,
and modifiers where the drop happened. The question is where to put
them to get the easiest transition to the new model
Why don't you add them to the event DND data?
Extending the misc_user_data by the data provided in a button_data is
not
enough. If I do it this way, I must change the way XEmacs calls
misc_user_events from
/* this is from event-stream.c */
if (XEVENT (event)->event_type == misc_user_event)
{
call1 (XEVENT (event)->event.eval.function,
XEVENT (event)->event.eval.object);
}
to
if (XEVENT (event)->event_type == misc_user_event)
{
call2 (XEVENT (event)->event.misc.function,
XEVENT (event)->event.misc.object,
event);
}
But I thing this is evil
I agree that this is evil.
Another possible is to add the button, mod and pos info into the
object list. dragdrop-drop-dispatch could then create a dummy
button-xy event with the actual values (channel must also be stored
in object) so the function can use the internal functions
event-point (and others) to get the position in the buffer and the
action the user wanted.
I don't understand this.
To pinpoint the whole thing again: A drop needs to know where it
happened to create the correct reaction (insert the text, change a
value in customize, create a new buffer, etc...),
OK, this is clear -- but why should it create dummy events afterwards?
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Don't hit a man when he's down -- kick him; it's easier.