| |
| |
On 7/15/22 16:04 Albrecht Schlosser
wrote:
... I withdraw my proposal to remove the internal FL_NO_BOX ->
FL_DOWN_BOX hack because it would be possible to create unwanted
and unpredictable side effects.
Obviously my brain doesn't allow me to stop thinking about this
issue. I'm no longer sure that leaving it as-is is the best
decision.
The OP Phil made clear that he was talking about the issue in a
printing context: "I don't really want the box visible when I print.
Any suggestions how I get around this?"
In a printing context scrolling can never happen, hence "removing"
the box around the widget is IMO a legitimate request. When this
widget was created FLTK did not yet have print support, but times
have changed.
Note also that we have similar issues in other places and setting
FRAME boxtypes (or FL_NO_BOX) is allowed in other widgets that would
suffer from similar effects. One notable and well-known effect is
label redrawing since the advent of Xft (decades ago!) which would
make the labels bolder and bolder with every drawing.
There are some attempts to "fix" such issues as well, but they are
not working correctly anyway, like the following code which is only
one example of many such issues:
src/Fl.cxx:1440: if (box() == FL_NO_BOX) {
src/Fl.cxx:1441: // Widgets with the FL_NO_BOX boxtype need a parent to
src/Fl.cxx-1442- // redraw, since it is responsible for redrawing the
src/Fl.cxx-1443- // background...
Whatever is done in this if clause it not "correct" because
it does not consider any FL_*_FRAME boxtypes which also need a
parent with a background.
That said, I have already been thinking about setting a boxtype
attribute "NO_BACKGROUND" in the table of boxtypes which would help
in this case rather than querying the exact boxtype but this is
another topic.
Back to the topic: IMHO we should really consider changing this
as I proposed earlier in this thread:
(1) set a boxtype with a background in the constructor as the
default (i.e. FL_DOWN_BOX for backwards compatibility)
(2) remove the "FL_NO_BOX -> FL_DOWN_BOX hack" to enable users to
set FL_NO_BOX explicitly.
Rationale:
- The reason this hack was done originally (in the year 2000 or even
earlier) might have had to do with the fact that the default boxtype
was FL_NO_BOX and not setting a boxtype in user code would result in
bad behavior (smearing). Setting FL_DOWN_BOX in the constructor
removes this particular issue and leaves the choice to the user.
- Programs that set FL_NO_BOX explicitly and expect it to work like
FL_DOWN_BOX (as it is now) are broken and should be fixed.
- Doing so with the old fluid was very unlikely because fluid
ignored this setting if done via the GUI (see previous reply).
- If the contents fit in the Fl_Help_View area there's no scrolling
and hence no smearing effects. This would likely be so in many cases
because Fl_Help_View is intended to show static HTML (like "help" or
"about" messages) rather than being used as a browser with unknown
HTML contents.
- Printing with FL_NO_BOX would not be affected by smearing effects
(there's no scrolling).
- Other FL_*_FRAME boxtypes would have the same effect as FL_NO_BOX
and would not be affected by the FL_NO_BOX hack anyway. So why
bother?
- Finally, overriding user settings is always bad and unexpected
behavior and should not be done in our toolkit. As we have seen,
this particular behavior was unexpected and such issues should be
avoided. Ideally users should notice the smearing effect in the test
phase of their applications and we should better document this
behavior for *all* boxtypes w/o a background, and that's it.
IMHO we can't try to "fix user errors" in every case and doing so
can often cause unexpected effects. The proposed change would
guarantee a good backwards compatibility with some exceptions
(broken programs).
So after thinking about this issue for a longer time I vote now:
+1 for removing the "FL_NO_BOX hack" as described above.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/a89f0292-ac57-e2f2-0e04-031e46674790%40online.de.
[ Direct Link to Message ] | |
|
| |
