Hmm, it occurs to me: should the example programs have
LGPL headers same as the FLTK code does, or should they have regular
*GPL* headers since they're not really library code?
For instance, the end user might start with an example program
and derive their own
The stock fltk-1.3 configure assumes --enable-xdbe, and it appears
that does not work satisfactorily, at least under ubuntu/gnome/
compiz/whatever that these boxes have.
I assume it is *not* a graphics driver problem as one box is ATI,
the other nvidia.
Yep, so do I. I can see
On Jun 7, 2010, at 12:42 AM, imacarthur wrote:
Hmm, it occurs to me: should the example programs have
LGPL headers same as the FLTK code does, or should they have regular
*GPL* headers since they're not really library code?
For instance, the end user might start with an
Michael Sweet wrote:
On Jun 7, 2010, at 12:42 AM, imacarthur wrote:
Hmm, it occurs to me: should the example programs have
LGPL headers same as the FLTK code does, or should they have regular
*GPL* headers since they're not really library code?
For instance, the end user
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2341
Version: 1.3-feature
If moving Fl_Tree oriented preferences code into the Fl_Tree module will
solve the problem, can (someone) provide a patch and I can bless it?
acr's fix in STR#2366 seems to solve several STRs.
The fix seems to ensure the keysym setting below the change
is processed by XKeycodeToKeysym(), but seems like it may also
short circuit a lot of UTF8 related work above it.
So I'm guessing either the fix is correct, or the UTF8 related code
