Attached is a screenshot of the typical LyX screen after it's resized using the mouse.
I suspect that we get these problems because we aren't using the xforms event
loop properly. (The gurus keep muttering about this occasionally I think, but
I've never got to the bottom of what was wrong until now).
As I understand it, the event loop works so:
do
do
* watch for XEvents for SHORT_PAUSE ms
(hardcoded as 10ms).
* handle these XEvents, putting the affected FL_OBJECT
on a stack for more expensive processing.
while (XEvents to process)
* process the FL_OBJECTs on this stack by calling
obj->object_callback and popping off the stack.
done
obj->handle is meant to provide cheap, initial processing.
obj->object_callback can be more expensive.
I think that we bugger things up in the XWorkArea by having a handle that
does everything. Ie, it handles the event and then calls the LyX core to
finish processing it with calls like
dispatch(FuncRequest(LFUN_MOUSE_PRESS,
ev->xbutton.x - ob->x,
ev->xbutton.y - ob->y,
x_button_state(key)));
It strikes me that all we need to do is put these FuncRequests onto a stack
in the handler and then pop-them off and dispatch them in the subsequent
callback routine.
I think that adding a FuncStack member variable, below, to XWorkArea would do
the trick. Have I got the right end of this stick? If not would someone
knowledgable provide me with illumination!
Regards,
Angus
class FuncStack {
public:
FuncStack(XworkArea & parent) : parent_(parent) {}
push_back(FuncRequest const & request) { store.push_back(request); }
process() {
Store::iterator it = store.begin();
Store::iterator end = store.end();
for (; it != end; ++it) {
parent_.dispatch(*it);
}
store.clear();
}
private:
XworkArea & parent_;
typedef list<FuncRequest> Store;
Store store;
};
<<attachment: screenshot.png>>
