Sorry for the long delay ...
On 8/25/25 21:40 Eric Sokolowsky wrote:
I'm constructing a new application that runs primarily under
Linux/X11, but this question is not platform-specific. I'm designing
it to have a custom look and feel [...] I'm now trying to figure out
how to derive from Fl_Scroll so I can have a scrolling list that is
too large for a single screen. The problem is the scrollbars that are
instanced within Fl_Scroll. If they were pointers, I could remove the
default instances and replace them with my own, but since they are not
pointers, I cannot override their default drawing behavior (at least
how to do so is not immediately obvious to me).
You're right, this is a known issue (at least I'm aware of this). I
thought about it and came to the conclusion that it would be better to
have pointers and - eventually - methods to replace the default
scrollbar widgets with ones derived by the user. Fl_Scroll has some more
issues, particularly the fact that the scrollbars are (implemented as)
real children of the widget which needs special treatment by the widget
code and by users if they want to work on children. For instance,
children() returns two more than the number of "real children", i.e.
when the widget is instantiated, there are already two children not
added by the user (the scrollbars).
OTOH, the drawback of using pointers for the scrollbars is that we need
two more separate memory allocations, but IMHO this is negligible.
Does anyone have suggestions on how I might make a scrolling box with
a custom look without having to reimplement everything already in
Fl_Scroll? If it helps, I plan on only using a vertical scroll bar and
not a horizontal scroll bar.
Thanks in advance for any advice.
Well, I don't know if this counts as "advice":
I've been working on another widget with project name Fl_Scroll_New. It
works well as a proof of concept but it is not sufficiently tested yet,
and there are no methods yet to replace the scrollbars by user-derived
subclasses. Therefore I'm hesitating to publish it ...
New features and modifications:
- scrollbars are allocated separately
- scrollbars are NOT visible children of the Fl_Scrollbar_New class,
i.e. they are not children of its Fl_Group
- children() returns the number of real children, i.e. 0 (zero) when the
widget is instantiated
- all code to reorder children to make the scrollbars the last children
(in Fl_Scroll) has been removed
- scrollbars are no longer directly accessible as members as in
Fl_Scroll (members `scrollbar` and `hscrollbar` IIRC)
- maybe more...
All these changes mean that we can't just replace the old Fl_Scroll
widget with the new implementation because of backwards compatibility. I
don't know of a better way than to offer another widget, may it be
called Fl_Scroll_New or whatever.
Other suggestions would be appreciated, but I'd like to avoid just
setting a `type` and intermixing old and new code within the same code
base (for maintenance reasons). Maintaining two different widgets is not
ideal as well, but anyway...
The "advice" would be to wait until we decided how to proceed and
published the new Fl_Scroll[_New] widget which you can use to derive
your own subclass of Fl_Scrollbar (and its draw() method). This will not
be done before FLTK 1.5, but the widget itself would probably be
compileable with FLTK 1.4.x.
Comments and suggestions (by devs and users) would be appreciated!
--
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 visit https://groups.google.com/d/msgid/fltkgeneral/7ca020ef-6a72-46ab-b24e-aa87c73331f6%40aljus.de.
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
