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 in your writing. But we should keep in mind
that we should try to launch FLTK 1.3 and that we should not start
redesigning the FLTK core now...
That said, let's discuss our ideas.
> Fl_Plugin
> |
I don't know if Fl_Device should inherit Fl_Plugin. Maybe, but I feel
that adding other devices, maybe as plugins, would probably not need
this. Just a feeling right now, but KISS applies here.
> +--> Fl_Device
> |
> +-> Fl_Surface_Device
> | | * points to a Window Manager
> | | * points to possible Graphics Devices
> | |
> | +-> Fl_Screen_Device
> | |
> | +-> Fl_Printer_Device
> | | |
> | | +-> Fl_System_Printer
> | | |
> | | +-> Fl_Postscript_Printer
> | |
> | +-> Fl_Bitmap_Device
> |
> +-> Fl_Window_Manager
> | * points to a list of System_Windows
> | * System_Windows can have their own Graphics Device
Yes, if I interpret this correctly, then we are here separating any kind
of device management (above) and drawing functions (below). That's a
good step. Something that is probably not optimal with our current
Fl_Printer hierarchy.
> |
> +-> Fl_Graphics_Device
> | * contains all FLTK rendering functions
> |
> +-> Fl_Bitmap_Graphics_Device
> |
> +-> Fl_Cocoa_Graphics_Device
> |
> +-> Fl_X11_Graphics_Device
> |
> +-> Fl_GDI_Graphics_Device
|
+ Fl_GDI_Printer_Device
Would override all drawing methods that are different than on a normal
GDI display device. There are some that need different scaling, for
instance. They are currently implemented by using an internal device
type instead of overring specific methods.
> |
> +-> Fl_OpenGL_Graphics_Device
> |
> +-> Fl_DirectX_Graphics_Device
> |
> +-> Fl_Ciro_Graphics_Device
>
>
> OK, now that I have that off my chest, let's explain it:
>
> I have been trying to find a configuration that works for embedded systems
> and desktop systems alike and allows for a great flexibility when rendering a
> UI or just graphics. This does not include any thoughts on input devices like
> keyboards, mice, multitouch, etc.
>
>
> 1: every output goes to some sort of rectangular twodimensional surface,
> right? So Fl_Surface_Device is the class that manages any kind of graphics
> surface. This does not define *how* the graphics get there, it just defines
> what this rectangle is. This device can return physical dimensions,
> resolution, width, height, depth, color capabilities, etc. but most
> importantly, it can may return a graphics driver.
>
> 1.1: the user never needs to know the nature of the graphics driver. It could
> be a Postscript File, but also an MSWindows GDI file, or even some array in
> memory that stores uncompressed RGB to be later used as a texture.
>
> 1.2: the main screen driver will return the default graphics driver for all
> windows on that screen, but individual Windows may override this (for example
> Fl_GL_Window).
>
> 1.3: some surfaces have a window manager. This by their nature will usually
> not allow direct rendering into their graphics driver, whereas a printer or
> bitmap has no window manager and only provides direct rendering
>
>
> 2: surfaces may or may not have a Window Manager. In 99% of all cases, the OS
> provides the one and only window manager. The class Fl_Window_Manager should
> provide a standard interface to creating new windows, just like what we have
> already with the "xid" interface. By abstracting this a little more, we make
> it possible to have truly minimal window managers on embedded devices.
>
> By allowing a per-system-window graphics driver, we can keep the current
> OpenGL implementation as-is. We will gain the ability to render a standard
> FLTK user interface right into the OpenGL window. Wow! The same would work
> with Cairo and DirectX. It would all be completely transparent for the
> application programmer!
>
>
> 3: graphics devices, maybe they should be called Driver instead, are the
> interface between user code and the rendering surface.
>
> 3.1: by keeping the surface and graphics device separate, we avoid the
> multiple inheritance that would be introduced if a Printer also was a
> graphics device.
>
> 3.2: a single surface device has a single native graphics device. It should
> be possible to request compatibility devices though. The surface can decide
> which graphics devices are supported. That way, it would be possible to
> render OpenGL to a Postscript device. I know that we do this already, which
> is great, and would fit into this scheme.
>
>
> I feel that this approach is incredibly flexible.
Yep.
> It solves not only all printing issues, but also alternative outputs like
> external screen buffers, and other raster displays that are attached to PCs
> and embedded devices everywhere.
>
> A pretty complex example: I have an application that works as a cash
> register. It's running on WindowsXP on a touch screen, but the cashiers
> should never see the WindowsXP desktop. Maintenance was originally done via
> VNC, but that really creeps the cashiers out! A mouse pointer suddenly
> appears on what they thought was just a "dumb" register, wildly clicking
> buttons, going down to system levels, DOS shells appearing, etc. etc. .
>
> The solution is an application that uses two screens: the cashier still looks
> at the full-screen app on his touch screen, but the whole maintenance
> interface appears on a remote X11 server. Now whenever a register is in
> trouble, the error message pops up on the maintainers screen, *not* the
> cashiers screen. The maintainer can then simply use the software on the
> remote X11 server without interfering with the ongoing register at all.
> Essentially, two people are using the same application at the same time.
>
> 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 embedded device developers.
I agree. I also wrote once that I think that we should come to a point
where we can have hybrid application programs that can use different
display devices (Windows: GDI or X11, Mac OS X: native or X11, etc.).
Your proposal (and application scenario) is even one more logical step
forward: we would be able to use more than one device type
simultaneously. I really like this idea.
This would need getting rid of all #ifdef's that bind the code
to a special platform. Then we could compile the code for different
graphics devices as needed (and possible on a given platform).
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:
- adding new features (STR's from 1.3-feature and 1.4-feature)
- completing device separation after discussion and consensus
- fusion of FLTK 1 and 2 to FLTK 3
- ???
Big steps are coming...
Albrecht
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
