Fltk2.0 did add a way to create a window with an arbitrary visual and colormap, but it did not store them. Any attempt to draw would assume you are using the default visual and colormap. But you could create a Window object and if you overrode draw() you could draw it using your own X code.
Making this more general is probalby ok as long as anything about X is kept out of the public interface (ie no methods on Window). I'm not clear how this fixed your composite extension issues. It lets you specify the visual, but isn't the real problem that the defualt visual is wrong? Yann Droneaud wrote: > DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. > > [STR New] > > Link: http://www.fltk.org/str.php?L1990 > Version: 2.0-feature > > > Related to the problem reported in message > <[EMAIL PROTECTED]> > Using X11 Composite extension with fltk-2.0 > > See: > http://fltk.org/newsgroups.php?gfltk.general+v:25908 > http://fltk.org/newsgroups.php?gfltk.general+v:25978 > > To fix my problem, I tried to do something uglier than using a global > visual: let each window have it own context: a visual, a colormap and a > graphic context. Since fltk use global variables to store those data, a > lot of code need to be adapted. > > The patch provided do the following things: > > - renamed xvisual to xvisualinfo and gc to xgc > (not really useful change, comestic but broke API). > - XDBE is now enable per window > - per window XVisualInfo, Colormap, GC. > > At the end, I'm able to run the test programs, and my own program are able > to use different visuals with window created by FLTK. > > There are many issues added by the patch and it's not really the good way > to fix my problem, but it could be a way to improve FLTK 2.0 and a way for > me to discover the internals of the library.. > > > Link: http://www.fltk.org/str.php?L1990 > Version: 2.0-feature > _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
