A box appears round an Fl_Help_View instance

[pvr...@btinternet.com]

I am generating labels from my database and am generating HTML using a template and fields from the database. I then send this HTML to an instance of Fl_Help_View. Despite setting box(FL_NO_BOX) on the instance I still see a box appear. The only place I see box not-zero is in the scrollbar children of the help view. The scrollbars are not being shown.

I see this both when I display the view on screen or send it to a printer.

I don't really want the box vixible when I print. Any suggestions how I get around this?

Thanks Phil.

[Greg Ercolano]

    I'm guessing you can't disable the box for a scrolling widget, because it needs a
    box to redraw the background during scrolling, otherwise the content being scrolled
    would 'smear' (leave leftovers from the previous draw).

    Instead of disabling the box(), try setting it to FL_FLAT_BOX.
    If you make sure the color() of the background is the same as the parent widget,
    it won't seem visible.

[Albrecht Schlosser]

On 7/14/22 17:21 Greg Ercolano wrote:
>
> On 7/14/22 07:04, 'pvr...@btinternet.com' via fltk.general wrote:
>
>> I am generating labels from my database and am generating HTML using
>> a template and fields from the database. I then send this HTML to an
>> instance of Fl_Help_View. Despite setting box(FL_NO_BOX) on the
>> instance I still see a box appear.

>> [...]

>> I don't really want the box vixible when I print. Any suggestions how
>> I get around this?

Unfortunately this widget uses FL_DOWN_BOX internally if you don't set a
box type or set it to FL_NO_BOX.

> Instead of disabling the box(), try setting it to FL_FLAT_BOX.

Yep, that's probably the best way to work around this "special feature".
I don't know why this was done but it's this way since Fl_Help_View was
added to FLTK around 2001. Thus it can't be changed but I documented
this special behavior a few minutes ago. The docs should be updated
within an hour on our gitlab server:
https://fltk.gitlab.io/fltk/classFl__Help__View.html

>     If you make sure the color() of the background is the same as the
> parent widget,
>     it won't seem visible.

That's a good hint.

[Albrecht Schlosser]

On 7/14/22 17:21 Greg Ercolano wrote:
>

>     I'm guessing you can't disable the box for a scrolling widget,
> because it needs a
>     box to redraw the background during scrolling, otherwise the
> content being scrolled
>     would 'smear' (leave leftovers from the previous draw).

OK, I tried it (I removed the "special" behavior) and you're absolutely
correct. Scrolling would smear the text all over the widget.

> Instead of disabling the box(), try setting it to FL_FLAT_BOX.
>     If you make sure the color() of the background is the same as the
> parent widget,
>     it won't seem visible.

Again, that's the correct way to solve the issue as a user.

[Albrecht Schlosser]

On Am 7/14/22 20:16 schrieb Albrecht Schlosser wrote:
>
> Unfortunately this widget uses FL_DOWN_BOX internally if you don't set
> a box type or set it to FL_NO_BOX.
>
>> Instead of disabling the box(), try setting it to FL_FLAT_BOX.
>
> Yep, that's probably the best way to work around this "special
> feature". I don't know why this was done but it's this way since
> Fl_Help_View was added to FLTK around 2001. Thus it can't be changed
> but I documented this special behavior a few minutes ago.

Thinking about it again, I believe we could set the boxtype to
FL_DOWN_BOX in the constructor and then remove the "special feature" to
replace the box type internally. Most users wouldn't notice the change
if they didn't set the boxtype explicitly to FL_NO_BOX.

This change would have the benefit that users could set FL_NO_BOX if
they want to do so (for whatever reason, background image or anything
else) and if they make sure that the text wouldn't scroll, i.e. it would
fit in the widget.

Greg and others, what do you think? Should we change this?

Although I wrote before that it couldn't be changed I believe now that
his proposal would not do any harm but be more like expected.

[Philip Rose]

Thanks Greg. 

That fixed the problem ok.

Phil.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/16874dc4-a667-c1e5-b8b5-4be6a315ab4e%40seriss.com.

[Philip Rose]

From: Greg Ercolano
Sent: 14 July 2022 16:21
To: fltkg...@googlegroups.com
Subject: Re: [fltk.general] A box appears round an Fl_Help_View instance

Thanks Greg, that worked perfectly, both on screen and the resulting print to PDF.

[Greg Ercolano]

On 7/14/22 11:42, Albrecht Schlosser wrote:

This change would have the benefit that users could set FL_NO_BOX if they want to do so (for whatever reason, background image or anything else) and if they make sure that the text wouldn't scroll, i.e. it would fit in the widget.

Greg and others, what do you think? Should we change this?

    I figure a possible downside would be if we change it,
    an old app setting box(FL_NO_BOX) accidentally (e.g. a stray setting in fluid)
    would cause that app to smear during scrolling if rebuilt against 1.4.x.

    If so, that might be bad..?

    I figure showing a background image "under" a help view without a scrollbar
    would be a narrow use case. I figure to do anything 'fancy' is best done
    in an external web browser by saving the html to a file and then calling fl_open_uri()
 

[Albrecht Schlosser]

On 7/15/22 10:21 Greg Ercolano wrote:

On 7/14/22 11:42, Albrecht Schlosser wrote:

This change would have the benefit that users could set FL_NO_BOX if they want to do so (for whatever reason, background image or anything else) and if they make sure that the text wouldn't scroll, i.e. it would fit in the widget.

Greg and others, what do you think? Should we change this?

    I figure a possible downside would be if we change it,
    an old app setting box(FL_NO_BOX) accidentally (e.g. a stray setting in fluid)
    would cause that app to smear during scrolling if rebuilt against 1.4.x.

    If so, that might be bad..?

Yes, indeed, this would be bad. But my thought was that doing so would be very unlikely.

Before you read on: 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. But see below [1].

Just FYI, read on if you are interested in details: In fact the existing 'fluid' wouldn't allow setting box(FL_NO_BOX) via the GUI, obviously because it is the default anyway. I didn't check the fluid source code (too much) but what I saw was that this setting would be ignored and not written to the .fl and to the generated .cxx files, i.e. you *can* do it via the GUI but it is ignored. You can, of course, do it in the 'code' section, but that's what I thought was very unlikely to happen.

Anyway, since I had already patched the library to see how it would work, I tried the "new" fluid and found that it used the default setting FL_UP_BOX in the GUI. Now if I set FL_NO_BOX, this is definitely written to the .fl and .cxx files - obviously because it is no longer the default value (still guessing). However, the user would actively have to select FL_NO_BOX which *might* obviously happen (see this topic). And this would have the negative smearing effect.

Interesting: using this .fl file (i.e. the one created with the new fluid) again with the "old" fluid the FL_NO_BOX setting would be ignored and the default (FL_DOWN_BOX) would apply.

These were tests done in about 30 minutes but there could be many more ways to set FL_NO_BOX and don't notice it until runtime (maybe after deployment) when the contents of the widget becomes larger than anticipated and the smearing effect appears.

So the "(non-)solution" [1] is to leave it as is and document the fact which I did already.

    I figure showing a background image "under" a help view without a scrollbar
    would be a narrow use case. I figure to do anything 'fancy' is best done
    in an external web browser by saving the html to a file and then calling fl_open_uri()

Sure, but that's not really the point, is it? I mean, there are lots of other ways to do something to this effect. We can't imagine what users do with the toolkit.

-----

[1] Note that the user could always and can still set any FL_*_FRAME boxtype and this will cause the same smearing effect as FL_NO_BOX. That's why I wrote "(non-)solution". If we wanted to "fix" this we wouldn't accept any of these FRAME types but this would not be doable: how to "replace" each of them with an approprioate box type with background? (Think of user defined boxtypes and you know why this is not doable.)

[Albrecht Schlosser]

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.