UI improvements

[timlau]

Tracker isssue for make the Search/filter UI better

[timlau]

Relates to #54
Relates to #70

[timlau]

Make a test UI for how the search in yumex could look like

git clone https://github.com/timlau/poc.git
cd poc/python/gtk/yumex_ui
python3 app.py

[timlau]

@genodeftest @gitjod please take a look at this UI

[gitjod]

Big improvement, I think. I would try to implement the search options Prefix, Keyword, Fields and Name, Summary, Description using 6 radio buttons as follows:

[timlau]

@gitjod the problem with that it is harder for the user to see what type of searching is active

[gitjod]

I think from a discoverability point of view the radio buttons would be acceptable because as per the implementation in Gnome-Music the Gtk Arrow is inside the search box so in this way every thing relating to search is linked whereas the link between the search box & the search options is still somewhat broken in your current design

[timlau]

Ok @gitjod , here is another try

[gitjod]

Looks good to me. I would be interested to know what others think. It's consistent with gnome applications like Gnome-Music or Gnome-Boxes

[genodeftest]

Search bar

I like the usage of a separate search bar.

I'd prefer putting all options into the search bar, but that won't be possible (consider localizations). So your proposal is very good. I like the way the options are visible besides the search field.

Quite an improval too. I'd prefer putting those options in a GtkPopover so users actually see where these options belong to. This is more like e.g. gnome-calendar does it.

Search bar comments:

In both cases I would not use an arrow button since:

1. the arrow could be mistaken for a combobox
2. in some search fields, down and up arrows are used to go to the next/previous match
3. GtkArrow is deprecated
   Instead I would preferences-other-symbolic icon. And (optionally) separate the button from the search entry.

As far as I know those options still exist because searching the whole package database is horribly slow. Is there any chance of speeding search up so these buttons won't be necessary any more? To me it looks like these buttons (UI) exist to work around technical limitations. Ideally (in a perfect UI) this won't happen. Is it possible to e.g. load the whole package database into RAM when yumex-dnf/dnfdeamon starts?

GtkHeaderBar:

• I'd put the toggle buttons (you could use a GtkStackSwitcher) on the left as gnome-abrt and nautilus (and – partially – gnome-calendar) do.
• I'd put the other buttons (search, run, main menu) on the right as most gtk3 applications do (e.g. gedit, nautilus, epiphany, …)
• Main menu:
  • Instead of the arrow button in GtkHeaderBar I'd use a open-menu-symbolic icon.
  • use a GtkPopover instead of a GtkPopupMenu

GtkPopovers

I'd prefer GtkPopovers instead of menus. They fit better to buttons and have a visual indication to where they belong to. Furthermore you can move to GMenu and don't have to create all the Gtk*Buttons manually.

This is what I thought:

I forked your poc repo and put some of these changes there.

[timlau]

I changed to look a little and used popover for seach options

[timlau]

Here is how it will look in gnome

[gitjod]

Happy with that. Popover for search option is good

[timlau]

I have made a new-ui branch of yumex-dnf with the gui changes.

Use the following to test it.

git clone https://github.com/timlau/yumex-dnf.git
cd yumex-dnf
git checkout new-ui
cd src
python3 new-main.py

It is only the basic seach & filtering is implemented yet.

[genodeftest]

Wow, yumex feels way more responsive now! Making the UI not disabled while still adding new packages improves user experience a lot. I hope this change can be permanent! It causes an issue though: If changing the view (left buttons in GtkHeaderBar) while yumex is still adding packages to its GtkTreeView, packages end up in the new GtkTreeView where they don't belong.

I see you improved the dark theme handling. I see two issues:

1. Some animated icons (busy indicators) are using gfx/spinner.gif or gfx/spinner-small.gif. Those gifs have white borders and thus don't look perfect on a dark theme. How about using a GtkSpinner instead? It provides a simple and clean interface.
2. Your theme detection differs from what Gtk uses. When running gnome with dark theme enabled but specifying GTK_THEME=Adwaita:light on command line (or the other way round) widget behavior is inconsistent. You are reading the gtk-application-prefer-dark-theme GSettings property which is correct. Looks like a Gtk+ bug to me, but they keep say the GTK_THEME environment variable is only intended for debugging so this is not an issue for yumex. I'm just noting it here so nobody will stumble upon that later.

The GtkPopovers should have a useful direction set (in this case: down) by using Gtk.Popver.set_position(Gtk.PositionType.BOTTOM). If not they will be placed topwards on wayland which makes them partly unreachable on wayland. This is a known issue in Gtk+ with no permanent solution on the toolkit side yet. See these bugs: 1, 2, 3, 4, 5.

In GtkHeaderBar, the GtkSpinner is placed most right which will make the search, apply, menu buttons move around. I guess this is not intended. You could remove it completely in my (weak) opinion since there is another progress indication below.

[genodeftest]

There is one major thing I don't like yet (but don't have a solution for). Due to its impact on #74 I post it now although it is not finished. Please put it into a separate issue if you think this is better (I am undecided about that). It is affecting the way how views work (and are chosen/activated) in yumex.

Current situation:

1. in main menu you select one of Packages, Groups, History, Pending. I'll call this the primary-level view.
2. In GtkHeaderBar you select one of Updates, Installed, Available, All. I'll call this the second-level view. It is only useful with Packages view right now and can only be useful with Packages and Groups view semantically.

What is not perfect with that:

1. primary-level view is not permanently visible but secondary-level is. From a logical point of view it should be the other way around. This is actually worse because users will miss these buttons.
2. layout (or something like that. English is not my native language so this word might be chosen incorrectly).
   • Groups is the same as Packages with a sidebar (and additional filtering capabilities). How about moving those in the same primary-level view?
   • History is completely different and thus should remain on primary-level
   • Pending could probably be merged into "Packages" view as well. yumex is just showing packages there.

So a new layout could look like this:

show primary-level view switcher (History, Packages) in GtkHeaderBar instead of current second-level view switcher. If History is active, show history (as yumex does currently) but without all the disabled second-level views.
If Packages view is active, show the secondary-level switcher (Updates, Installed, Available, Pending, All) with another button to toggle Groups. I don't really know where to place it. Probably in the Packages view stack, maybe in some kind of toolbar.

Notes

I hope this proposal is not too hard to implement on limited time and will have some upsides on the code (reduced number of views ⇒ less lines of code to maintain). I'm open for suggestions. I'll make some mockups if you are interested.

PS: You could use a GtkStackSwitcher for those view switchers. It is supported by F23's glade 3.19.0 and has been in Gtk3 since 3.10, should be available on all dnf-based Linux distributions.

[timlau]

I agree with it is not logic that the primary views (pages) is not visible but the second-level (filters) is.

I have added a StackSwitcher for selecting the pages and is only showing the filters when the Packages page is selected.

Maybe the filters shold be moved to a toolbar instead of being shown in the headerbar ?

[timlau]

I have added all the new UI parts to current master branch there will become yumex-dnf 4.2
yumex-dnf 4.1.x is move to the rel_41X branch.
So the new UI can be tested by

git clone https://github.com/timlau/yumex-dnf.git
cd yumex-dnf
cd src
./main.py

Most features is moved to the new UI.

The following is not implemented yet:

• StatusIcon : Not sure if this should continue, it make things complex and error prone.
• History Undo

[genodeftest]

Maybe the filters shold be moved to a toolbar instead of being shown in the headerbar ?

That's what I suggested in #74 (comment), same with the group thing. Users then would be able (again) to half-maximize yumex-dnf on a fullHD monitor or to maximize on small (≤ 1024 px wide) monitors

[timlau]

Latest updates

[genodeftest]

Hm, infobar applies to all views, doesn't it? So I guess it should be displayed in every view. I'm not sure about the search bar.

[timlau]

If you by infobar, mean the progress bar, then it applies to all views.
searchbar is currently only used by the packages view, but for future use it could be useful in history and groups view too.

[genodeftest]

Yes, I mean the GtkRevealer including the progress bar.

[gitjod]

I don't like the latest update. I think it is confused. I think the solution here is a SideBar. The primary filters can remain Packages, Groups, History & Actions and these filters should be located on the HeaderBar. They should be centred.

If Packages is selected then the options in the SideBar should be Updates, Installed, Available & All with the list of packages appearing in the main window. As these options in the SideBar are currently searchable then the search icon should be available in the HeaderBar.

If Groups is selected then the options in the SideBar should be as currently implemented with the list of packages appearing in the main window. As these options in the SideBar are not currently searchable then the search icon should disappear when the Groups filter has been selected in the HeaderBar.

If History is selected then the options in the SideBar should be the History date & time with the list of packages installed/updated/removed appearing in the main window. As these options in the SideBar are not currently searchable then the search icon should disappear when the History filter has been selected in the HeaderBar.

If Actions is selected then the options in the SideBar should be Updates, Installed, Available & All with the list of packages appearing in the main window. As these options in the SideBar are currently searchable then the search icon should be available in the HeaderBar.

See these screenshots of an implementation of a sidebar in Gnome-Music

[genodeftest]

@gitjod: Interesting idea. Only downside I find for that is that it takes quite much horizontal space. I thought about putting the font vertically but I guess that will break readability.

[timlau]

Here is a version with filters in a sidebar

[timlau]

Investigated the search box used in gnome-music and totem, they use a special Gd.TaggedEntry custom widget defined i a special gnome libgd.

https://git.gnome.org/browse/libgd/tree/README

This lib has no API/ABI stability and is meant to be included as a private lib in each project.
So this is not something I will use. Hope this widget will be included in GTK at some point in time.

[timlau]

@gitjod @genodeftest

I have reworked the the options in the main menu and added a new look for the Preferences and added a new Extra Filter option menu, let me know what you think.

[genodeftest]

I have a hard time testing yumex-dnf due to an dnf issue when a mirror is offline. Reporting that against dnf on Fedora Bugzilla.

I like this filter option menu. Maybe you could put it above the GtkStackSwitcher?

I'd use a 'preferences-other-symbolic' or 'view-list-symbolic' icon instead of 'open-menu-symbolic'. 'open-menu-symbolic' is already in use for the main menu and shouldn't be reused for semething completely different I think. What do you think?

Btw: The main menu GtkPopover is nice. It has an issue on wayland though: The GtkPopover gets placed topwards in some cases being painted outside of the screen. See https://bugzilla.gnome.org/show_bug.cgi?id=757474 for a more detailed explanation and a workaround.

[timlau]

@genodeftest :

• I have changed the icon to view-list-symbolic
• I also a little unsure about the placement of the extra filters button, it shows filters like updates, installed, available etc. So it should be grouped with them, it could be placed in the left side of the headerbar, but it only relates to the packages page, so it must be grayed out on other pages. hiding buttons on page swiching is giving "flickering" and having to many buttons will make the UI harder to use.

The following placement could be used.

• above filters (updates, installed etc)
• bellow filters (Current placement)
• left side of headerbar
• right side of headerbar (with other buttons)

Another idea i have is to have a pref button in the right side of the headerbar where the content is changing based on the selected page. On packages it would show extra filters, on groups something else etc.

[genodeftest]

I thought about placing it above filters. I wouldn't change menu contents based on UI state.

Besides: I noticed that the search bar filter menu behaves slightly wrong. Steps to reproduce:

1. open yumex-dnf. Search for something. Set filter to "Fields". You might (but don't need to) check any checkboxes on the right side.
2. close yumex-dnf.
3. open yumex-dnf
4. open search bar
5. open search bar filter menu

What happens:
Filter is set to "Fields" but checkboxes are insensitive (greyed out).

What should happen:
checkboxes should be sensitive in this case

[timlau]

@genodeftest ok, I have moved the button, check latest copr build to test it.

The fields insensitive problem is fixed here: (not in build)
1fe4b33

[genodeftest]

Oh, nice. I prefer it that way. @gitjod what do you think?

[gitjod]

Hi Tim, I am not convinced by moving the extra filter button from below the filters (updates, installed etc) to the left of the headerbar. I think your first idea of placing it below the filters was correct or you could look at this very similar implementation in the application gitg where there are 2 buttons below some filters:

I very much like the bottom bar in the History page where you have placed a button Undo. I think this is a good idea, though it doesn't seem to be very reliable at the moment. Perhaps you could do a similar implementation on the Packages page & on the Queue page with a button called Apply instead of the current button on the headerbar to apply the pending actions. Perhaps the extra filter button could be on this bottom bar on the Packages page.

[genodeftest]

Hm, I was just running yumex-dnf in a KDE plasma session with dark Breeze theme. Dark theme detection doesn't work correctly there. Any ideas?

[timlau]

Sorry for being MIA for a couple of months, Work and Life, has stolen all my time.

A button bar could be an option i could try out in the other pages, but could feel a little confusing for the extra filter, but I will give it a try, to see how it feels

[gitjod]

Welcome back!

I think the extra filter should go where you had it originally....see your own screenshot of 15th December or my screenshot from the 22nd. The extra filter shouldn't be the first thing a user encounters in the application and given its present location on the top left corner on the headerbar it currently is the first filter you encounter.

I think the pending actions button should go on the button bar on the bottom as per the History page where you have placed a button Undo

[genodeftest]

I'm sorry, but I disagree on moving the extra filter button down, again. This time for another reason:

With "extra filters" on header bar, one could filter in both packages and groups view.

With "extra filters" outside of header bar (in this case: In package view below package status selection), one can only filter in package view. This filter is meant for both views though.

Since @gitjod doesn't like it on the left for arguable reasons, how about putting it on the right or into the sandwich menu?

[genodeftest]

I've got an idea to keep the filter down there without removing it from the "Groups" view:
How about merging "Packages" and "Groups" views? Both use the same GtkTreeView on the right and the same widgets for displaying package info/metadata. In "Packages" view, the structure on the left would change to something like this:

State
    Upgrade
    Installed
    Available
    All
Groups
    (+) Applications
    (+) Base System
    (+) Cinnamon Desktop
    …

[gap]
[extra filters button]

Upside: Once repositories are available through DNF API, they could be added here too.

[timlau]

That is a good idea, a group is just a collection of packages, like updates, installed etc. is

[genodeftest]

I've created a new proof of concept for my previous comment. Please have a look at it at https://github.com/genodeftest/poc/tree/sidebar/python/gtk/sidebar. You can simply start it using python3 ./sidebar.py.
There are some screenshots there too.

The style probably needs some work, but I'd rather wait to have it implemented. Any feedback on the way this filter looks like?

[timlau]

A step in the right direction, but we need to work on the look & feel, The UI feels a little confusion a lot of clicking is needed.
Maybe the summary current selection in each filter category should be shown after the category title

ex.

Version (latest)
Architecture (all)

or like this a big button with content like this

And when you click on the button the selections shows in a popover or in a dedicated area in the bottom of the list of Category buttons

[genodeftest]

Ok, I've implemented it in a way that it will be shown only when the filter category is collapsed.

Yes, you're right, my proposal involves a lot of clicking because only one filter category can be uncollapsed. I did this out of couriosity and because without it, users always have to collapse categories or scroll, this way I wanted to prevent both from happening.
Is your comment a general criticism of this concept (I wouldn't mind changing it)?

Something pretty bad is that the summary label on a collapsed list entry is hard to distinguish visually from a list of choices. I don't really know what to do about that. Always show the "summary" label? Change the font to be "lighter"? Put it on the same line as the title (could be too long)?

[timlau]

Like the concept that you have a number of filter categories in a sidebar and each category can a number of choices there can be made and the selections is only shown when you highlight it.
I am just brainstorming ideas on how to present it to the user in a way.

• Easy to see what choices is currently made
• Easy and logical how to change the choices.
• I looks good and clean, not to much noise

I have to do some thinking and looking around in other apps and maybe some mockups to find a good way to present it to the user

[genodeftest]

Ok. I've updated my mockups and tried to improve it a bit. See commit df48baddaa0bbe587f67632cfa8f2bb954a7777f plus its description.

[timlau]

Looks better

What about make it work like the settings menu in gnome:

For example the "Architecture" label is not needed, the selected archs is enough

[genodeftest]

Look: I like the use of a expander which makes it clear which sections are expanded and which are not.

Content: I don't like the idea of having the section title removed and only the status displayed. This especially applies to groups and repositories, where it is hard to find a caption for all child items. For other items this could work, I wouldn't like to mix different behaviours though.