FLTK logo

Re: [fltk.general] Re: [Fl_Flow] A new layout manager for FLTK

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Re: [Fl_Flow] A new layout manager for FLTK Karsten Pedersen Oct 29, 2021  
  Firstly,

> PS: Can you please avoid top-posting in this group?

Ah geez, my apologies. I didn't notice that the Google Groups web
form was hiding all that content inside a tiny collapsed ellipsis and
sending it all after my message. I will remember that in future!

> 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.

> 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. I didn't expect resize()
to not be called before draw but as mentioned in a few of the
Fl_Group comments, many window managers do overly send resize events.

> 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.

> 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

and a more robust one in my private CVS repo. This provides
containers, smart pointers, etc but with some additional safety. For
example it locks on -> and [] access avoiding almost any chance of
getting a dangling pointer, dangling reference or dangling "this".

Thanks,

Karsten

--
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/73b7cad3-6d80-4e65-aea4-b101e46b01dbn%40googlegroups.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.