How do i change the orientation of a widget?

[JamesClarke7283]

I am trying to make a Vertical scale to make a volume rocker. But i cant seem to find out how to change the orientation in Toga.

I looked at the relevent documentation and did not find anything for changing orientation
https://toga.readthedocs.io/en/latest/reference/api/widgets/slider.html#toga.widgets.slider.Slider

Here is the code for the slider implementation in GTK:
https://github.com/beeware/toga/blob/main/src/gtk/toga_gtk/widgets/slider.py

I saw this hard coded value Gtk.Orientation.HORIZONTAL
in the line which creates the widget in GTK

self.native = Gtk.Scale.new(Gtk.Orientation.HORIZONTAL, self.adj)

I know For GNU/Linux, GTK is used so i looked at that, and i found this:
https://lazka.github.io/pgi-docs/Gtk-3.0/classes/Orientable.html#Gtk.Orientable.set_orientation

How would i change the orientation of a widget in beeware, in a UI framework independent way?

[freakboy3742]

Right now, there's no cross-platform API for a vertical slider.

Toga has precedent for having vertical/horizontal control in APIs - the Divider widget is probably the easiest example of this - and it looks like Cocoa and Winforms both have direction control exposed on their slider widget APIs. If you're up for a FLOSS contribution challenge, I wouldn't be opposed to a PR that adds direction control to the Slider widget.

In the immediate term, you can use the GTK API directly - if your app code contains a slider widget myslider, myslider._impl.native will be the native Gtk.Scale widget, so you could invoke my slider._impl.native.set_orientation(Gtk.Orientation.VERTICAL). This obviously won't be platform independent, though.

[JamesClarke7283]

Thank you for your quick response.

I have been considering implementing some missing functionality in toga, Most my experience is in GNU/Linux and frameworks like TKinter and GTK, Not lots of experience with WinForms yet, other than for Uni.

I was thinking. That orientation could first be implemented in the base widget classes first.
So we have something which is not as Widget specific.

Would a public set_orientation(orientation) like method in the base widget class's, be good to have?

As for the program, a free/libre hearing aid control program. Would it be feasible to detect the UI framework and run the relevant method, for that framework, inside the app.py file?
I know it's not ideal for my program, but if feasible, it might be a good way to prototype the cross-platform solution as a side bonus.

I think cross-platform, OS Native, UI framework's, solve a lot of problems when implemented well.

[freakboy3742]

To clarify - It's perfectly acceptable to submit an implementation for a new feature that only works on a single platform. If you only know GTK, you can add the feature an only provide the GTK implementation - we don't expect you to learn 4 other GUI APIs to submit a minor feature improvement. Of course, we won't complain if you decide to take on that challenge... :-)

There are only 2 requirements to adding new features:

1. The feature you are proposing needs to be fundamentally possible on every supported platform - ideally, without too much custom work. You need to do a little research to make sure that the feature you are proposing could actually be implemented. In this case, I've done this research for you - Cocoa and Winforms both appear to have vertical settings. iOS and Android don't appear to have a direct API, ... however, a quick search showed up a few tutorials that suggested some approaches on both platforms. It's also OK for a feature to be "desktop only" if there's a reasonable argument to be made that the feature doesn't make sense on mobile. In this case, mobile APIs very heavily lean towards "horizontal" because of how thumb swiping works, so I could live with a world where there isn't an option for vertical sliders on mobile platforms.

2. When you add the API on the backend to support the feature, you also need to add the matching API on the "dummy" backend". This will, in turn, require you to add a stub "not implemented" implementation on every platform. You also need to add tests in the core module for the new API, and a demonstration of the new widget in one of the example programs.

It's also entirely likely that if you submit a good 1-platform implementation, and the APIs for the other platforms are obvious (as they appear to be here), you'll nerd-snipe me (or another core team member) into doing the legwork on the remaining platforms.

A base widget-level "set orientation" is an interesting idea - however, I suspect you'll find that the number of widgets that will support an orientation is much lower than the number that won't. We definitely want to retain a consistent API when orientation is supported; but we don't want to have an orientation API for, say, Button, and then raise an exception if you try to use it.

As for the detecting the UI platform: toga.platform.current_platform will tell you which platform backend is currently active; you can use that to select platform-specific behaviour. This is essentially the same as sys.platform, but with some tweaks on a couple of platforms (for... reasons... sys.platform == 'linux' on Android).

[JamesClarke7283]

Thanks for your advise.

I started working on it. I will likely open a PR tomorrow.
https://github.com/JamesClarke7283/toga/

One thing I have noticed is that the implementation, in GTK, is largely the same for Divider and SplitContainer. Both of which are orientable Widgets(Gtk.Orientable).
Perhaps defaulting to a generic is ideal.

I think a combination of Per Widget And Base Widget implementation, is possible, if needed.
For cases when the base widget class is too generic on its own to work well for that Widget. A Widget specific implementation could override it.
And if it's not at all supported by that widget on that framework, Can just have the @NotImplemented decorator on it.
I am starting with GTK.

But I likely will also try to work on some other frameworks, implementations, if needed.
For example, the Android one. Which I am deploying my app on primarily.