Hi,
I'm a experienced C++ programmer, but a complete fltk novice. So I'll
just apologise now for asking something that's probably buried in a FAQ
sheet somewhere, and doubtless pestering people on the wrong list as well :-)
I took a brief look at the fltk-2 sources, and noticed that under X
you use a fixed set of XVisualInfos, GCs, Colormaps, and the like,
instead of having them be associated with individual fltk windows. This
in turn requires that multiple screens can only be used via Xinerama,
and restricts use to a single X display.
In My Ideal World, fltk would seamlessly provide a Xinerama-like
single coordinate space across an arbitrary set of X screens, spanning
multiple X displays. But that'd be a fair bit of work, and probably more
bloat than you'd like to see in such a trim library -- especially for
a feature that I'm almost certain nobody besides me wants.
I'd be happy with having the ability to create multiple,
noncontiguous fltk windows that reside on arbitrary X displays, and
leaving the illusion of a single coordinate space for my application to
provide. A naive implementation would just be to change
fltk::gc, fltk::xcolormap, fltk::xvisual, fltk::xdisplay and friends
from scalars into arrays. Then add some ints to x11.h's CreatedWindow
that bind that window to particular entries in the global arrays. Then
update all the various Xlib calls to use the correct display, gc, and such
for the given CreatedWindow being operated upon.
In this model, Monitor::list would still return 1 (in a non-XINERAMA
environment), but you'd be able to manually create windows on other
screens and/or displays and hand them off to fltk and have things still
work. In a single screen environment, you'd still only have one of each
of the globals -- I'm only proposing to add items to the arrays when
manually created X windows on different screens were handed off to fltk
with CreatedWindow::set_xid.
Does this seem at all plausible? I'd be happy to whip up a patch
in my (regrettably not copious) free time and send it in if the idea
isn't completely at odds with where you'd like fltk to go.
Thanks for writing fltk -- it looks pretty cool from here. Aloha,
Adam Greenblatt
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
