| |
| |
On 10/29/21 9:55 PM Karsten Pedersen wrote:
> Would you recommend not to use Fl_Flex at all in FLTK in favor of
> Fl_Flow? Or do they both have their (different) usage patterns?
I suppose they are quite different and some guys might prefer Fl_Flex
because it is more similar to what they already use coming from
Gtk, wxWidgets, Java, etc.
OK, then we should consider adding both.
[ ... initial resize ... ]
> Great if you can do that. I just didn't want to dive too deep
> into the code.
OK, I have made a change that should fix this. Interestingly I
couldn't recreate it in MWM and TWM. However I could in CWM. I
believe the fix pushed to my repo is OK.
Thanks, the fix worked for me.
> it could let widgets overlap as a better visual indication that
> something is wrong which could help the author testing (and the user
> would "know" they need to increase the window size).
Yes, that isn't a bad idea to do. We could potentially even hide
them if they don't fit. That way as in your example you will simply
see the excess buttons disappear if they don't fit rather than
giving any clue that things are a bit squashed. Perhaps I could
even recalculate the entire layout again but with every initial
widget size halved.
Don't try too much, this effort would only make it more complicated for
no real effect. My intention was only to let the developer and end user
know when something goes awry. Often you don't know that there *should*
be another widget which has been hidden behind the other widgets.
Therefore I would suggest not to keep them all at the bottom but present
them somehow overlapping such that you can see that there is something
behind the other widgets. But, as I said before, that's not very
important. We should concentrate on the real important things first.
> We don't use any containers yet (officially) although there are some
> (inofficial, i.e. not public) containers used in some implementations
As an aside, is there any interest in a custom lighter STL containing
only the stuff FLTK needs? I have a project here:
https://github.com/osen/sr1
Basically yes, but a first look at this didn't give me evidence that
this would be something useful for us. But I can be wrong...
FWIW, I removed Fl_Widget_Tracker in my personal test version and
uploaded the result to my FLTK fork in branch feature-Fl_Flow:
https://github.com/Albrecht-S/fltk/tree/feature-Fl_Flow
Note that this is mostly untested code but I hope I got everything
right. Your prepare() method could be adjusted to use the parent/child
relationship and I basically replaced every Fl_Widget_Tracker with an
'Fl_Widget *'. This seems to work fine. I also tried the demo program
(below) with valgrind and didn't find any invalid memory errors (and no
leaks).
I extended the (no longer minimal) "test/flow_minimal.cxx" demo program
to delete and add buttons dynamically. Click on any button to delete it
and use the button at the bottom of the window to add new buttons to the
Fl_Flow widget.
Here's the Git statistics of my changes:
$ git diff --stat master..
FL/Fl_Flow.H | 486 ++++++++++++++++++++++++++++++++++++++++++
test/CMakeLists.txt | 2 +-
test/flow.cxx | 36 ++++
test/flow_center.cxx | 22 ++
test/flow_minimal.cxx | 46 ++++
5 files changed, 591 insertions(+), 1 deletion(-)
The three demo programs are functional and all demos are built if you
use CMake.
Note that I reformatted 'FL/Fl_Flow.H' and used this single header file
rather than your original sources for my modifications.
Commit 40e23c163584f is the one with all the necessary modifications to
remove Fl_Widget_Tracker. Feel free to use my changes in your process to
make it more FLTK compatible. TIA.
PS: I encourage everybody to download from my FLTK fork for easier
testing. The demo programs would be readily available.
--
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/eeb48f62-e31a-09fd-7924-91129459c643%40online.de.
[ Direct Link to Message ] | |
|
| |
