Re: [fltk.development] Class hierarchy for Fl_Device

2010-06-03 Thread manolo gouy
Albrecht: thanks for having fixed makedepend files. A reformat of the 1.3 doc would be useful to reflect the new Fl_Device class hierarchy. (I feel sorry to keep asking you that). Do you think you can do that ? ___ fltk-dev mailing list

Re: [fltk.development] Class hierarchy for Fl_Device

2010-05-27 Thread manolo gouy
+-- Fl_Device | +- Fl_Surface_Device || * points to possible Graphics Devices || |+- Fl_Screen_Device || |+- Fl_Printer_Device | | | +- Fl_System_Printer | | |

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-24 Thread manolo gouy
Fl_Plugin | +-- Fl_Device | +- Fl_Surface_Device || * points to a Window Manager || * points to possible Graphics Devices || |+- Fl_Screen_Device || |+- Fl_Printer_Device ||| ||

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-21 Thread manolo gouy
Development branch branch-1.3-Fl_Printer has been updated with a new proposal to document class Fl_Printer that's implemented in a platform-specific way. The device tree is now completely explicit without hiding any of the platform-specific classes. The branch compiles under all platforms.

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-19 Thread Albrecht Schlosser
On 18.04.2010, at 08:06, manolo gouy wrote: [Matthias wrote] Fl_Plugin | +-- Fl_Device | +- Fl_Surface_Device || * points to a Window Manager || * points to possible Graphics Devices || |+- Fl_Screen_Device |

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-19 Thread manolo gouy
Hi developers, I have prepared in development branch-1.3-Fl_Printer a new device hierarchy according to the idea suggested by Matt. It's as follows, starting from Matt's own description: Fl_Device | +- Fl_Surface_Device || * points to a Window Manager (not

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-18 Thread manolo gouy
Hi guys, this will be a lengthy mail, so I will start with my findings ;-) Fl_Plugin | +-- Fl_Device | +- Fl_Surface_Device || * points to a Window Manager || * points to possible Graphics Devices || |+- Fl_Screen_Device

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-18 Thread manolo gouy
Hi all: I have committed r. 7522 that's exactly identical to r. 7519, thus multiple inheritance is gone. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-18 Thread Albrecht Schlosser
On 18.04.2010, at 09:03, manolo gouy wrote: Hi all: I have committed r. 7522 that's exactly identical to r. 7519, thus multiple inheritance is gone. Thanks! Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-18 Thread imacarthur
On 17 Apr 2010, at 12:25, Matthias Melcher wrote: This is possible because my version of FLTK can open windows on different screens, even when they use different window managers. I believe that this feature would set FLTK apart from other GUI libraries and make it very valuable for

[fltk.development] Class hierarchy for Fl_Device

2010-04-17 Thread Matthias Melcher
Hi guys, this will be a lengthy mail, so I will start with my findings ;-) Fl_Plugin | +-- Fl_Device | +- Fl_Surface_Device || * points to a Window Manager || * points to possible Graphics Devices || |+- Fl_Screen_Device ||

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-17 Thread Albrecht Schlosser
On 17.04.2010, at 13:26, Matthias Melcher wrote: Hi guys, this will be a lengthy mail, so I will start with my findings ;-) I'm always interested in your visions ;-) Thanks for this long mail. I think that your ideas are very interesting, and I can recognize some of my ideas/thoughts/visions

Re: [fltk.development] Class hierarchy for Fl_Device

2010-04-17 Thread Matthias Melcher
Thanks for your input, Albrecht. On 17.04.2010, at 20:54, Albrecht Schlosser wrote: But, as said before: I feel that we should postpone such a redesign until we pushed FLTK 1.3, and then we would have to decide how to proceed anyway: in which order should we do the following steps: -