nanogui: FLNX mods to fltk
Subject:
Re: FLNX mods to fltk
From:
Jason Kingan ####@####.####
Date:
16 Feb 2001 16:16:02 -0000
Message-Id: <01021609194902.00923@pc224.censoft.com>
On Thursday 15 February 2001 15:42, you wrote:
> Hi,
>
> I have been playing around with one of those Agenda VR3 Linux PDAs for a
> day now.
>
> So far it looks pretty cool.
>
> I have come across a puzzle with the X11 version of FLTK that I hope
> might already be solved in FLNX by you guys.
>
> Could you please let me know if you modified FTLK so that each widget
> had its own window, and if you have it setup so that only input type
> windows are associated with them?
No we haven't, though see some of the following paragraphs for some history.
> My understadning of FLTK is as follows:
> FLTK basically creates a single window into which it draws almost all
> its widgets, so there is only a single event mask used.
Basically, Fl_Window and anything derived from it have their own physical
Nano-X or X window. Anything dervied from FL_Widget directly don't have their
own window with the exception of the Fl_Window noted above.
In both the original FLTK and FLNX there are two basic event masks used - one
for top level windows (children of the root) and one for child windows (where
an FLTK window is its parent.)
In the original version FLNX, the creation of windows and the coordinate
systems were pretty messy. This was changed heavily during the translation of
X->Nano-X. This also causes massive havoc when trying to port programs, and
in some cases write new ones (like ViewML)
I changed a bunch of code one afternoon that makes it operate more or less
identitcally with the X version, which greatly simplified things.
> In Motif (and others), each widget has its own X window (except for
> gadgets), so it is pretty easy to see which widgets will get what type
> of event.
I too was used to this model. It's what just about every widget set I've ever
used has worked. I was suprised when I dug into FLTK and saw how it worked.
> This becomes important for hand writing recognition (HWR), because it
> would be so simple for the X server to just look at the event mask when
> it changes focus to a new window, and then let the HWR applet know where
> to send XKey events to.
Under the FL{TK,NX} model, focus for widgets is kept directly by the widget
set, not by the server. Under this scheme, all key events go to the top-level
window and get propagated.
> On a battery powered PDA, code efficiency is important, so it would be
> great if these unneeded events could be ignored before getting into the
> users app.
I don't know that this would save enough battery power to be really useful -
but you never know.
> I have half a mind to just create an X window for each widget, and then
> change the input mask as appropriate for the type of widget it is.
While this is certainly possible, I think you'll run into some significant
code changes during the conversion. You'll have to change the way all the
event routing currently happens, the way key events are propagated, etc.
> Is this a "bad bad idea" you have already rejected, or would it be
> useful the world at large?
Not necessarily a bad idea, but could be very difficult to implement with
very little real gain. One big thing to consider when doing this is backward
compatibility, which is what eventually led me to redo part of FLNX to
operate like the X version - we couldn't get the damn menus to work like the
X version before the change. After the change, they worked fine as written.
jason
