| |
| |
On 6/7/21 10:01 PM Bill Spitzak wrote:
I think there is some mistakes in current FLTK, in particular the
"Driver" api, which uses virtual functions for no reason whatsoever as
the called code is chosen at compile time, and as seen here the design
makes it really difficult to share code. Would prefer to use #if
statements like they are supposed to. I don't consider the current
design readable or maintainable. I may be missing some function of
Driver where more than one can be used, please correct me if I am wrong.
It's true that the selection of the standard display and system driver
is done at library build time. However, the driver design was chosen to
get rid of the unmaintainable #ifdef stuff. Currently there should only
be #if statements to differentiate compilers and/or options (for
instance Xft vs Pango, VS (MSVC) vs. GNU, etc.). You can really use more
than one graphics driver (although still only one at a time) for
printing (Fl_Printer), copying to the clipboard (Fl_Copy_Surface),
Fl_PostScript (files) and Fl_Offscreen. This is all done by changing the
driver(s) on the fly. I'm using this in some applications. For an
example see test/device.cxx (the code may be historically grown and not
as clean as possible but it shows the options).
Regarding the driver selection at build time: I would also like to see
an option to combine two or more "platforms" in one executable program,
i.e. in one FLTK library. The idea is to decide at program startup which
"driver" we want to use, for instance X11 for remote display, macOS
native display driver, or (in the future) Wayland or Cairo. An
environment variable or commandline switch would then decide at program
startup which device/driver to use on platforms that allow different
connections. This should not be difficult to achieve...
The "Device" is somewhat useful as it allows you to draw widgets in GL
windows. I think there is also an attempt to allow it to print, though
I am unclear if it is actually possible to use it for that and if
anybody has done so. I still feel the number of virtual functions on
it is excessive.
Yes, it is used for printing and even more stuff (see above). And it
works pretty well. A recent extension is to "draw" to an Fl_SVG_Surface
which eventually outputs real SVG files.
The number of virtual functions may be excessive in some parts (it's the
'.0' version), I'm sure there's room for improvement.
It sounds like Cairo is nowhere near as slow as others have claimed.
It would be great to get a real working implementation that can be
used both by this and X11.
... which may be a logical step when the Wayland platform is done as
Manolo wrote already. Experience with Wayland is a good first step
(let's do one step after the other) before we go to the next (Cairo)
device. I could also have imagined to create a Cairo driver on X11
first, before Wayland, but now Wayland won.
I think all transformations have to be done by the calling code, as
there is a need to adjust all paths for fill and stroke to remove
antialiasing on horizontal and vertical lines, and allow 1-pixel lines
to be usable. This indicates to me that transforms at least can be
removed from the Device virtual functions.
I'm not sure what this means.
Read through the libdecor code and it appears to be drawing everything
directly. There is a "plugin", perhaps with the intention that the
style of the window borders can change by changing the plugin, but I
don't agree with this as the api to the plugin is going to swiftly
grow to a baroque monstrosity, just like every other attempt to
control the borders.
ISTR that the "plugin" is really for defining other border and
decoration styles. I think I read about this in the README files of
libdecor in connection with setting up the demo program or something
like that.
There was a good reason Wayland wanted CSD.
What is CSD? Client Server XXX ???
I personally do not see any problem with drawing the window borders
ourselves, any complaint that they look different is IMHO not logical
if the difference in appearance of every other widget is considered
acceptable. Also not using this library will mean a single Wayland
surface can be used, instead of two.
I agree that this would be logical. I can't speak for Manolo but I think
using a library was considered easier than writing everything from
scratch. Would your (Bill's) old flwm code be helpful in doing window
decorations and stuff? Should be take a look at it? It's still available
somewhere...
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/e4a0e0de-768f-bb04-013a-63be0aa89d2b%40online.de.
[ Direct Link to Message ] | |
|
| |
