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
| |
| +-> 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
|
+-> 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_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.
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.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
