[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XForms] Handler for ConfigureNotify events
From: |
Jens Thoms Toerring |
Subject: |
Re: [XForms] Handler for ConfigureNotify events |
Date: |
Fri, 29 Jul 2016 22:10:35 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi,
On Tue, Jul 26, 2016 at 07:26:16PM -0500, SBP wrote:
> I was wondering if it's possible to register a handler for
> ConfigureNotify events. I tried already with fl_register_raw_callback
> and got "Unsupported mask 0x20000" for StructureNotifyMask. I checked
> the code (and the manual) and there's no support for anything besides
> what FL_ALL_EVENT includes. Why is this so? Would it be possible to add
> support for other types of events, e.g. move and resize?
There are two things that make adding support for
StructureNotifyMask to receive ConfigureNotify events
problematic:
a) All the other events for which you can register a "raw"
callback will be handled in the following way: the user
supplied handler gets called. If this returns FL_PREEMPT
the event is not further handled by XForms. That works
pretty well for the events for which you can set a mask
bit now.
It's not the simple with ConfigureNotify: XForms must
evaluate it - or shoul it if e.g. the form is resized
leave resizing and redrawing the objects in the form (or
moving them around in the form according to the gravity
settings) to the user? And it must keep track of the forms
position when the window is moved. So it's not that easy
to say "when the user wants that event and returns
FL_PREEMPT simply forget about the event". Additionally,
there are some hacks in the code for a certain window ma-
nager that (at least at one point in time) did not behave
correctly by sending bogus ConfigureNotify events.
So there would be the question: do we call the user
supplied handler and ignore what it returns? But then,
when do we call this handler? Before XForms deals with
the event or afterwards?
I'd guess that it would be cleaner to add callbacks that
don't rely on setting masks, but something like
fl_set_form_resize_handler(HANDER *)
fl_set_form_move_handler(HANDLER *)
for handlers that get called when XForms is done with what-
ever it got to do with the ConfigureNotify event (including
redrawing the form as far as necessary).
b) Introducing this would make the library backward-incom-
patible since we'd need to add new fields (with the func-
tion pointers of the handlers) to the FL_FORMS structure.
That's something I try to avoid if possible since it re-
quires that not just the library but all programs need to
be recompiled in order for them to be able to use the new
version. Thus it should only be done when there's a major
revision and not because of a single feature.
At least that's what I came up with when thinking about this
problem. But perhaps there are better/simpler solutions!
> By the way, I'm interested in having a form move when another one
> does, so their relative positions remain the same.
For the time being a solution might be that you add a timer
and in the timer handler requests the position of the form
and, it changed, move the other form.
Best regards, Jens
--
\ Jens Thoms Toerring ________ address@hidden
\_______________________________ http://toerring.de