is there a workaround to clip child sub-windows within an Fl_Scroll?

[Paul Hahn]

I am using bleeding edge 1.4.

I need to use a scrolled region containing a mix of child widgets including sub-windows (i.e., derived from Fl_Double_Window).

When I try this, the sub-windows do not get clipped. This behavior is in fact documented under https://www.fltk.org/doc-1.4/classFl__Scroll.html#details thus:

"You cannot use Fl_Window as a child of this since the clipping is not conveyed to it when drawn, and it will draw over the scrollbars and neighboring objects."

Is there a workaround someone knows that will work for me?

[imm]

Without knowing more of what you are doing, my gut reaction is that you should use group rather than (sub) window as your container widgets.

I think with group the clipping is propagated.

-- 
Ian
From my Fairphone FP3
   

[Paul Hahn]

These are my chart widgets, subclassed from Fl_Double_Window (for what I believe to be good reasons, at least heretofore). It's not practical at this point for me to re-implement as subclassed from Fl_Group.

I think with group the clipping is propagated.

Yes I understand that is correct. But unforunately it's not an option for me at this point.

What might help would be for my widget code to figure out that it is contained within an Fl_Scroll in the parent chain (or not). Then it could perhaps query that Fl_Scroll inside draw() for information that can be used to implement a proper clip within its window context. But unfortunately there is no "as_scroll()" method under Fl_Widget that would allow detection of the Fl_Scroll container via a parent traversal. Could that be added to FLTK?

[imm]

On Mon, 24 Aug 2020, 21:58 Paul Hahn, wrote:

On Monday, August 24, 2020 at 3:25:18 PM UTC-5 Ian MacArthur wrote:

Without knowing more of what you are doing, my gut reaction is that you should use group rather than (sub) window as your container widgets.

These are my chart widgets, subclassed from Fl_Double_Window (for what I believe to be good reasons, at least heretofore). It's not practical at this point for me to re-implement as subclassed from Fl_Group.

Ah. OK.

That's maybe unfortunate...

I think with group the clipping is propagated.

Yes I understand that is correct. But unforunately it's not an option for me at this point.

What might help would be for my widget code to figure out that it is contained within an Fl_Scroll in the parent chain (or not). Then it could perhaps query that Fl_Scroll inside draw() for information that can be used to implement a proper clip within its window context. But unfortunately there is no "as_scroll()" method under Fl_Widget that would allow detection of the Fl_Scroll container via a parent traversal. Could that be added to FLTK?

Hmm...

In the short term, how do you feel about RTTI? 

That's not used by fltk per se, but is not precluded, and could be leveraged here to detect a parent widget that was an Fl_Scroll...

[Paul Hahn]

Yes RTTI will work. Thanks for confirming it is not precluded with FLTK. Nevertheless, I am always reluctant to infect my application code with RTTI, but I guess sometimes it is the expedient choice.

[Paul Hahn]

LOL! What I said in my previous post -- that I'd try a solution with a "viewport" and "scene" thing -- is just basically re-inventing Fl_Scroll and cannot work either! Please ignore my misguided musings.

In a bit of a quandary indeed...

[Paul Hahn]

For whom it may concern --

Well I went down a rabbit trail trying to do some kind of "clip" given knowledge of the Fl_Scroll settings. It was futile. I now get that the futility is because (at least with X windows on Linux???)  child sub-windows will draw above/over their parent window (e.g., as necessary for menus, dialog windows, etc). I also tried setting "non-modal" for the child sub-windows in a guesswork attempt to overturn that behavior, but to no avail.

So I suppose this scrolling exercise for me is finished. In retrospect, I probably should have subclassed my widgets under Fl_Group not Fl_Window. Lesson learned. I may have an escape using a zoom-based approach, however -- I will try that next. Sort of like a viewport into a scene where the viewport is scrolled/dragged around over the larger scene.

[Paul Hahn]

UPDATE: I successfully refactored all of my chart code so it is now derived from FL_Group instead of Fl_Double_Window. Now the scrolling container works fine. Thanks to Ian for the inspiration for action that comes from an expert's "there is no way out" advisement (i.e., using my old approach).

[Ian MacArthur]

On 11 Sep 2020, at 00:01, Paul Hahn wrote:
>
> UPDATE: I successfully refactored all of my chart code so it is now derived from FL_Group instead of Fl_Double_Window. Now the scrolling container works fine. Thanks to Ian for the inspiration for action that comes from an expert's "there is no way out" advisement (i.e., using my old approach).

I think “expert” may be overstating it...
I was more thinking of the grumpy old bloke, on being asked for directions, shaking his head and saying “Well, you wouldn't want to be starting from here...”