Nested ScrolledWindow locks scrolling for both ScrolledWindows

[LynxesExe]

Hello! I’m building an application which needs to nest an horizontal GtkScrolledWindow within a vertical GtkScrolledWindow, by default this composition produces and unfortunate behavior where scrolling the vertical window gets interrupted when the cursor goes over the horizontal scrolled window, which doesn’t scroll at all.

This forces me to place the cursor over either a vertical or an horizontal scrollbar to continue navigation.

I would like for the user to be able to scroll the vertical window uninterrupted, and to use the scrollbar for the horizontal window.

I managed to get the desired behavior via the Gtk Ispector, specifically I saw how the GtkScrolledWindow widget have different children, including two GtkEvenControllerScrol, by editing the flags property of this object I can remove the vertical flags and I will end up with the expected behavior.

The issue is that I could do this in code, but it seems redundant to set a static property in code, it would be cleaner if there was a way to do it directly from the UI XML file that specifies the Scrolled Window to begin with, is there a way to achieve this?

I’ve seen mentioned somewhere that it can be done, but I didn’t get any examples…

Thanks in advance!

---

Edit:
I decided to rename the question since it was based off of what my supposed solution was, even though it seemed to be the wrong approach, the issue is still not solved though.

When having two GtkScrolledWindow nested, one vertical and one horizontal, and the cursor is over both of them, both lock up and you can’t scroll.

Any idea is welcome and appreciated!

Thanks in advance!

[ebassi (Emmanuele Bassi)]

You cannot modify the event controller that GtkScrolledWindow uses internally—either from code, or from the XML description file.

At most, you can add an event controller in your XML, using:

<object class="GtkScrolledWindow">
  ...
  <child>
    <object class="GtkEventControllerScroll">
      ...
    </object>
  </child>
</object>

[LynxesExe]

I tried appending the GtkEventControllerScroll as a child with the desired flags, but this didn’t do (from what I saw from the Inspector) anything.

<object class="GtkScrolledWindow">
    <property name="vscrollbar-policy">never</property>
    <child>
        <object class="GtkEventControllerScroll" id="scroll-controller">
            <property name="flags">kinetic|horizontal</property>
        </object>
    </child>
    <child>
        <object class="GtkBox" id="explore-featured">
            <property name="spacing">25</property>
            <property name="orientation">horizontal</property>
        </object>
    </child>
</object>

from the Inspector I still see two GtkEventControllerScroll with their default flags, I don’t see a new one with the flags I set.

Maybe I’m trying the wrong approach to solve this issue? Is there a suggested way to fix scrolling for nested GtkScrolledWindows?

[LynxesExe]

I ended up coming with a pretty ugly workaround that however, works.

You need to get a pointer to the GtkScrolledWindow, get a list of every controller, iterate through the list and check if the type is GtkEventControllerScroll, if it is set the necessary flags.

An example of the implementation can be found [here]( Fixed scrolling bug · Kurozora/kurozora-linux@4237789 (github.com)), it’s not pretty, but it works; it’s a utility function that looks for every widget with a specific nomenclature and applies the fix. It’s not perfect, but it’s a good starting point for who has this issue.

If there is a better solution I’m all hears!

[dboles]

How you tried adding the controller in the ui file is categorically wrong, and you already got shown the proper way to do it, but seemingly ignored it…?

If there is a problem with the default controller, and you really can’t ‘override’ that with your own added controller and/or it seems wrong - file an issue with GTK, instead of writing convoluted workarounds that will only confuse people and break in a future major version. Please

[LynxesExe]

The “proper solution” was not a solution. I asked for a way to solve a problem and I highlighted what I thought might have been the right path, I was told the idea was wrong and that at best a different thing could be done, but as it turns out doing that didn’t solve anything.

After more testing I decided to look for a new and different solution, and it worked. I didn’t ignore anything.

Why would I bother opening an issue with GTK? I don’t know if it’s an issue or if I’m doing it wrong, there is no documentation and the help I’ve been given has been rather limited, I came up with my solution and it works, and since I know that other users won’t be treated differently I hope my solution can help them; if you got a proper solution to the problem that isn’t a workaround, you are very welcome to share it here.
If someone here replied with saying “Hey, this is a GTK4 issue, please open an issue”, sure, I’d be delighted, that’s not what happened.

Please stop saying that other people’s solutions are bad, we know, we don’t have a comprehensible documentation or any help to implement a correct one at times, so this is what can be achieved.

I also made it abundantly clear that mine is an ugly workaround and that if there is a better solution I’m all ears

Edit:
Also, please refrain from just saying:

How you tried adding the controller in the ui file is categorically wrong

I know, could you kindly point out where the mistake was? What would be an acceptable example? Link to documentation for this sort of thing? Give a comprehensive example?

No? Then you’re telling me something that I already know.