I believe this is an offspring of Fl_Device abstraction patch which Oxid
combined with his utf-8 patch. However this version is outdated and many
improvements to the drawing primitives went to now dead 1.2 tree.
Fl_Device consisted of
Now I believe that direct patching 1.3 with this code would bring the
mess associated with various code incorporated. To bring printing
cleanly I would suggest to make abstraction layer first and then
everybody can work with whatever device implementation independently
(cairo, postscript, ...) without breaking the core functionality.
Abstraction layer itself is not a big deal, it is rather code/file
organisation which is messy. The biggest mistake in 2.0 and 1.2 was
implementation of new features and changing functionality which
introduced incompatibilities and bugs and harmed stability.
To be able to move forward without breaking old things and to give us
reasonable target which can be easily achieved I would suggest
implementing following device abstraction:
1) define base device class in a header FL/Fl_Device.H like
FL_EXPORT class Fl_Device{
virtual ~Fl_Device(){};
};
2) define display class in FL/Fl_Display.H
FL_EXPORT Fl_Display:public Fl_Device{
};
3) instantiate single instance of the display and assign it to current
device pointer eg in Fl.cxx:
Fl_Display fl_display; // single display device instantiation
Fl_Device * fl_device = &fl_display; // handler to current device.
and that's it. Now whenever you wand to abstract a new primitive (eg
original fl_draw_something(...) function), you do three things:
a) add to Fl_Device class pure abstract method
virtual void draw_something(...)=0;
b) add to Fl_Display class declaration
void draw_something();
c) implement it using original drawing code (in original file):
void fl_draw_something(...){
// new code inserted
fl_device->draw_something(...);
}
void Fl_Display::draw_something(...){
// end of new code, continuing with original implementation
...
The code for Fl_Display within the files can be gradually reorganised in
separate subfolders/files at any time later if required.
The above can be done very quickly for all drawings so there is no ABI
break after 1.3 is released. If available, other devices can be declared
experimental until stabilised, they should also be compiled as separate
libraries. Also people can work with their own devices without touching
the core. It would also enable independent implementation of cairo
backend without the rush (which would ultimatelly bring all the zoo of
other backends).
Matthias Melcher wrote:
>
> Great! I will take a look at that an see to getting this into the core,
> possibly combined with whatever support for printing is in Fluid.
I believe fluid is using offscreen draw and the resulting pixels are
sent to the printer. So it is not the vectorised drawing and there is
not too much in common with the printing device and vectorised output
like postscript, gdi printer drivers or pdf.
R.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
