UI enhancements to plugin manager

[declension]

• Add filter combo for plugin type (songsmenu, event, editing etc)
• Use larger icons in keeping with other UI trends
• Better padding, and increase window size to allow for extra width
• Some minor tidying.

This fixes #1460.

[declension]

Made it a PR as some UI changes are opinion-driven and we can discuss / improve.

@lazka especially, when you can get some time please see what you think.

[lazka]

Random thoughts:

• I get lots of

Traceback (most recent call last):
  File "/home/lazka/Desktop/quodlibet/quodlibet/quodlibet/qltk/pluginwin.py", line 221, in cell_data2
    width, height)
GLib.Error: g-file-error-quark: Failed to open file '/org/gtk/libgtk/icons/24x24/actions/gtk-edit.png': No such file or directory (4)

while scrolling. haven't looked why.

• I know that I always have a hard time adjusting to more/less padding, so while it looks to much to me I guess it just takes time. Is there some middle ground maybe?
• The top search bar looks a bit crammed, especially with translations QUODLIBET_TEST_TRANS=##### ./quodlibet/quodlibet.py . Maybe we can use Gtk.SearchBar? https://developer.gnome.org/gtk3/stable/GtkSearchBar.html Can be seen in gnome-system-monitor if you press ctrl+f in the process list.

[declension]

Not sure about the GLib.Errors - I don't seem to get them. Maybe need to test for existence of theme icons before using anyway?

I know that I always have a hard time adjusting to more/less padding, so while it looks to much to me I guess it just takes time. Is there some middle ground maybe?

Of course - I've just pushed a smaller version (I might prefer this also actually). Wanted to start the discussion...

The top search bar looks a bit crammed, especially with translations QUODLIBET_TEST_TRANS=##### ./quodlibet/quodlibet.py. Maybe we can use Gtk.SearchBar? https://developer.gnome.org/gtk3/stable/GtkSearchBar.html Can be seen in gnome-system-monitor if you press ctrl+f in the process list.

Agreed, and I did worry about translations. A few options (not mutually exclusive):

• increase the width a bit more.
• Use that Gtk.SearchBar - but not sure it affects the width much
• Move to using two rows, i.e. move the search bar somewhere else
• The option I've considered since the beginning - lose the new combo and use a real TreeView for the plugins with grouping by plugin type....

[lazka]

Not sure about the GLib.Errors - I don't seem to get them. Maybe need to test for existence of theme icons before using anyway?

I'll have a look later.

Of course - I've just pushed a smaller version (I might prefer this also actually). Wanted to start the discussion...

looks good to me now, thanks

The top search bar looks a bit crammed, especially with translations QUODLIBET_TEST_TRANS=##### ./quodlibet/quodlibet.py. Maybe we can use Gtk.SearchBar? https://developer.gnome.org/gtk3/stable/GtkSearchBar.html Can be seen in gnome-system-monitor if you press ctrl+f in the process list.

Agreed, and I did worry about translations. A few options (not mutually exclusive):

• increase the width a bit more.
• Use that Gtk.SearchBar - but not sure it affects the width much
• Move to using two rows, i.e. move the search bar somewhere else

Yeah, I was thinking have the comboboxes always shown and slide in the search bar underneath.
Maybe with a search button on the right in addition to the ctrl+f shortcut.

Or we merge the two comboboxes. That would lose you the ability to e.g. show all activated cover plugins..

• The option I've considered since the beginning - lose the new combo and use a real TreeView for the plugins with grouping by plugin type....

Probably less confusing.. but more work I guess.

[lazka]

scratch all that and just use render.set_property('stock-size', Gtk.IconSize.LARGE_TOOLBAR)

[declension]

I played around with Treeview for the plugins instead, but it's still a bit ugly / clunky currently - not sure which is better really.

@lazka do you know if there's a way of having GTK+ render the group rows entirely differently to the "normal" ones (e.g. no / different columns)?

[lazka]

Hm, never needed that. What happens if you set props.visible=False for the cell renderers on the top level.

[declension]

@lazka - thanks. Changing visible works, but:

• is inherited by the children, so you have to override it (back to True) there
• permanently adjusts the rendering once you expand one of the groups - i.e. pushes the alignment of the Group title out to the same place as the children (as above really)... so probably not usable here.

I guess the simpler way is to ditch the columns entirely (or make one) and make a single cell renderer that packs an HBox full of all the components, with some careful alignment to make it look consistent). Probably lose a few native view features though, not sure.

[ptitjes]

@declension Are we sure the plugin type is the most understandable way to group for users ? I feel it is more a technical point of view and that we need some more semantic plugin attributes to group plugins together.

Just as an example, your screenshot tells me that maybe the covers type plugin instances and the songsmenu 'album art' could be grouped in the tree.

[ptitjes]

And there is also the existing tag mechanism to take in account, BTW. See #2283.

[declension]

@lazka went with just a simple SearchEntry below in the end, works well and no width issues (full SearchBar felt a bit out of place there). Parking any TreeView discussions for now, too many things in flight. Tidied up some other GUI niggles whilst there too.

You happy for me to merge this?

[lazka]

I'm not a fan of the new window margin and search frame

[declension]

@lazka is that better BTW?

[lazka]

ok

[declension]

@lazka OK thanks for reviewing - merging