I haven't tested this yet, but will your other changes make a youtube custom format selector with a lot of formats narrower? My preferences dialog is almost the width of my screen and vertical tabs would make it wider.

In the adaptive version the label and the combobox are split to separate lines in the Video tab, so yes, it's narrower.

I'm thinking about also adding a GtkFlowBox there (and elsewhere) so the dialog adapts better to various widths.

So nothing can really be done about a super long format selector, other than replacing it with resolution/quality selectors that choose the format per-site?

Oops, the sidebar widget was supposed to be GtkStackSidebar, not GtkStackSwitcher. Fixed now.

@auouymous, it looks like the combobox in the 'Preferred YouTube format' selector always has the width of the largest option string, so unless the strings can be shortened, the combobox will be wide. I'm not sure what you mean by 'selectors that choose the format per-site'?

... and I was wrong again, the strings can of course be ellipsized with a cell renderer property. This patch does the trick:

diff --git a/src/gpodder/gtkui/desktop/preferences.py b/src/gpodder/gtkui/desktop/preferences.py
index 371d1c3d..16e61a87 100644
--- a/src/gpodder/gtkui/desktop/preferences.py
+++ b/src/gpodder/gtkui/desktop/preferences.py
@@ -209,6 +209,7 @@ class gPodderPreferences(BuilderWidget):
         self.preferred_youtube_format_model = YouTubeVideoFormatListModel(self._config)
         self.combobox_preferred_youtube_format.set_model(self.preferred_youtube_format_model)
         cellrenderer = Gtk.CellRendererText()
+        cellrenderer.set_property('ellipsize', Pango.EllipsizeMode.END)
         self.combobox_preferred_youtube_format.pack_start(cellrenderer, True)
         self.combobox_preferred_youtube_format.add_attribute(cellrenderer, 'text', self.preferred_youtube_format_model.C_CAPTION)
         self.combobox_preferred_youtube_format.set_active(self.preferred_youtube_format_model.get_index())
@@ -216,6 +217,7 @@ class gPodderPreferences(BuilderWidget):
         self.preferred_youtube_hls_format_model = YouTubeVideoHLSFormatListModel(self._config)
         self.combobox_preferred_youtube_hls_format.set_model(self.preferred_youtube_hls_format_model)
         cellrenderer = Gtk.CellRendererText()
+        cellrenderer.set_property('ellipsize', Pango.EllipsizeMode.END)
         self.combobox_preferred_youtube_hls_format.pack_start(cellrenderer, True)
         self.combobox_preferred_youtube_hls_format.add_attribute(cellrenderer, 'text', self.preferred_youtube_hls_format_model.C_CAPTION)
         self.combobox_preferred_youtube_hls_format.set_active(self.preferred_youtube_hls_format_model.get_index())
@@ -223,6 +225,7 @@ class gPodderPreferences(BuilderWidget):
         self.preferred_vimeo_format_model = VimeoVideoFormatListModel(self._config)
         self.combobox_preferred_vimeo_format.set_model(self.preferred_vimeo_format_model)
         cellrenderer = Gtk.CellRendererText()
+        cellrenderer.set_property('ellipsize', Pango.EllipsizeMode.END)
         self.combobox_preferred_vimeo_format.pack_start(cellrenderer, True)
         self.combobox_preferred_vimeo_format.add_attribute(cellrenderer, 'text', self.preferred_vimeo_format_model.C_CAPTION)
         self.combobox_preferred_vimeo_format.set_active(self.preferred_vimeo_format_model.get_index())

Thank you so much! That patched allowed the window to be downsized and adding more formats didn't widen it again. You should definitely include that in your patches to narrow the preferences pages.

The sidebar has some odd tab focus behavior. Tab cycles through the sidebar now and right arrow is needed to move focus to the page, but it jumps to the nearest widget, instead of the top widget. This makes it impossible to navigate the widgets without using shift-tab.

I'm not sure how the tab focus should work, but it seems logical to me: tab / shift-tab goes forward and backward in the sidebar and ctrl-tab switches from the sidebar to the page. Could this be improved?

Multi-key combos like shift-tab and ctrl-tab can be difficult to press, and might be avoided except when going back a widget or two after overshooting a widget in a long chain of widgets. It can be easier to press tab a dozen times then to press shift-tab once.

In the notebook preferences, tab key cycles from current tab, through widgets in page, to the edit/close buttons at bottom, and back to current tab. The left and right arrow keys cycle through tabs. Ctrl-tab cycles between current tab and the edit/close buttons. No multi-key presses are required to use it.

With the sidebar, tab cycles through the sidebar buttons, to the extensions list, to edit/close buttons, and then it jumps back to the extensions sidebar button. There is no way to cycle through the sidebar again without shift-tab, and no way to get to the non-extension page widgets without ctrl-tab.

Setting can-focus to true for GtkStackSidebar restores the notebook behavior, but there is no way to cycle through the sidebar buttons.

Replacing the GtkStackSidebar with a vertical GtkStackSwitcher looks similar and tab cycles through every widget on the dialog. It requires more tab presses but would be acceptable if it works for the adaptive branch.

Ok, let's revert back to GtkStackSwitcher.

LGTM, but should there be a vertical separator between the stack switcher and stack?

Also, I did not know extensions could add preferences tabs until I saw this (youtube-dl will definitely be getting one). The window height grows if a lot of extensions add preferences, and also if an extension adds a lot of widgets to its stack. Would this cause issues on mobile or do you wrap the switcher and stack in scrolled windows? It might be good for both desktop and mobile to do this.

Ok, I added the separator, put the StackSwitcher and the Stack into separate ScrolledWindows and removed the (now redundant) ScrolledWindow from the Extension page.

The dialog can now be squeezed to a very small size vertically. Horizontally, there are some pages which take a lot of space (mostly Video), but I'll fix them in a another PR.

Also rebased to master. Should be probably squashed before merging.

LGTM, thanks. Is #1268 narrow enough or does it need changes?