| |
| |
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.)
--
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/19afdd7b-ca58-668c-da25-92a70be4d4d8%40online.de.
[ Direct Link to Message ] | |
|
| |
