| |
| |
On 10/29/21 7:27 PM Karsten Pedersen wrote:
Hi Albrecht,
I am very glad that people are liking this system. In response to your
queries;
(0) Fl_Flex is actually my project too ;)
Why did I not check this? ;-)
My previous tests of Fl_Flex (some time ago) indicated that it was worth
considering for inclusion but it had also some positioning issues and
the usage of std::containers which we can't use. I mentioned it in one
of the issues (see my previous message).
In the past I have certainly been looking into ways to make GUI
management more fun. Fl_Flex was good and works pretty well but it
isn't nearly as fun. I do find Fl_Flow much faster.
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?
(1) The template code is purely so that the entire system could be
collated into a single header file and used from multiple .cpp files
without causing duplicate symbols. The is kind of the C++ alternative
to how this is done with C libraries such as stb_image. GLM (C++ maths
library) for example does this. As you have noticed, it is very easy
to strip out. It isn't depended upon by the library in any real way.
Ah yes, thanks for the explanation. My tests were all with only one C++
file.
(2) Very happy to. Though do I need to look up at how FLTK deals with
operator new() throwing exceptions on OOM situations.
We don't. ;-)
(3) std::string is easy, I barely use it. I could just use standard
C-Style strings. I will have a look through FLTK and see what you guys
use for containers. If not I can put together some C-style linked
list, etc.
We don't use any containers yet (officially) although there are some
(inofficial, i.e. not public) containers used in some implementations,
for instance Fl_Table::IntVector. Picking existing container types,
putting them in classes etc., making them kinda "protected" or "public"
is on my todo (ehm, wish) list though. With "protected" I mean in this
context that they could be inside the library code base but not in the
public header files. Public would mean that they'd be in the FL/
directory for public usage.
Bill wrote in his comment "I don't have any problem with using
std::vector, it was not used back in the day because it used much more
memory and was slower than naive C implementations, but this is not true
any more." We *might* reconsider using std::vector in the future which
would simplify some, particularly new code.
OTOH the strings used could likely be simple char* arrays as Bill
mentioned as well.
(4) Fl_Flow isn't very large. I will have a look through FLTK codebase
and mimic what you guys do.
Caution, there's some code that doesn't comply with the "rules" which
are in https://www.fltk.org/cmp.php and particularly the "Coding
Standards" section: https://www.fltk.org/cmp.php#CODING_STANDARDS .
However, some parts are ancient and maybe outdated as well.
(5) OK, I will push to my repo on GitHub an LGPL LICENSE file. I can
perhaps grab one with the exceptions in it from the FLTK project repo.
Great.
(6) There is some amount of sharing going on between the structures. I
will have a look at putting them private. Perhaps FLTK already has
some private headers?
If we want to use "private" headers we put them into the 'src'
directory. These headers will not be installed. The problem is that they
must not be used in the public header FL/Fl_Flow.H unless they can be
simple forward references like 'class Fl_xyz;'.
(7) Ah I am using it basically in place of std::weak_ptr<T>. I get a
free "observer pattern" and it means I don't get any dangling pointers
if Widgets get destroyed.
... however, I do have logic in there that checks if the widget has
been removed so technically I don't need it. I just like that warm
fuzzy feeling of avoiding (some) memory issues and use-after-free. I
can possibly remove it. Or at least conditionally compile it in as
debug builds?
As I said already I'm not sure that you used Fl_Widget_Tracker correctly
in all cases and the second point is its inefficiency. After reading
more of your code I'm coming to the conclusion that it's very likely not
necessary to use it at all. If an Fl_Widget is deleted it removes itself
from its parent group. Your prepare() method checks if a widget is still
a member of the group and adds "missing" widgets to the internal states.
This can all be done by examining the children() array of Fl_Group, and
since Fl_Flow is derived from Fl_Group you get this for free. If you
have questions I can assist.
(8) Ah. This could well be my window managers (spectrwm and dwm) that
cause the initial resize event as it gets tiled. Darn, embarrassingly
I didn't think of that. I will fix that today. I basically just need
to get it to reposition all children on the initial show() (and add()
if already shown).
Great if you can do that. I just didn't want to dive too deep into the code.
(9) In some way this works really well and if the window is too small,
it will drop down to the next line. You can get really far just by
changing the order of the flow instructions.
Yes, I saw that it works pretty well. Until ...
... unfortunately if the window is simply too small, Widgets will stay
at the bottom right because they collide immediately with other
widgets or the bounds. One workaround is to start the components
really small and then expand later on. Personally I just set the
minimum window size to something a little larger and in practice this
avoids these issues. But I will have a further think on this.
I'm not sure what the Fl_Flow implementation could do about this. Maybe
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). The minimum window
size is something you need to set for all GUI's anyway, thus I don't
think this is a big issue. We can simply document it. If the window is
too small, it's too small. ;-)
Many thanks,
Karsten
Thanks for your contribution!
PS: Can you please avoid top-posting in this group? This makes reading
the threads easier with their context (keep the context as small as
possible by trimming unnecessary parts). Thanks.
https://en.wikipedia.org/wiki/Posting_style#Top-posting
--
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/72e77558-5e1c-2e78-d94d-9278cd4e6ae8%40online.de.
[ Direct Link to Message ] | |
|
| |
