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 https://github.com/timlau/yumex-dnf/issues/74#issuecomment-157045271, 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

[gitjod]

Very nice work Tim. I have tested it & like it very much now. Thanks for taking on the ideas of both myself & Christian. The only change now that I would make would be to center Packages, Groups, History & Actions on the HeaderBar but that is a minor criticism. Thanks again, John

[timlau]

More gui tweaks.

[timlau]

@gitjod, the page switcher is now centered on the Headerbar

[timlau]

I have made build of the current master branch available on the yumex-dnf Copr Repository https://copr.fedoraproject.org/coprs/timlau/yumex-dnf/

To make it easier to test.

I will update them frequently

[gitjod]

Hi Tim

Just a few remaining inconsistencies I have found in the new design:

Packages, Groups, History & Actions (Pending Changes) appear in both the Headerbar & the Main Menu button. Should these filters be removed now from the Main Menu button?

Also shouldn't the Main Menu button be a popover to match the search options button?

Also perhaps the Run button should only appear in the Headerbar when there is a package selected by the user to install/delete/update? See example from Gnome-Boxes below:

Just a minor point in that there is an inconsistency in the lines or lack thereof that divide the panes in the windows for Packages, Groups, History & Actions:

I hope these observations are of help to you.

[genodeftest]

Oh, thank you! What I noticed from your copr build:

1. Ctrl+F for search doesn't work
2. Pending actions was renamed to Actions. Is that intended? I'd prefer Pending Actions since the Actions is a bit unclear.
3. After restarting the window it sometimes defaults to a small size (ca. 800x150 px). 3b. Sometimes the lower window part (package info) is reduced to a height of 0 px. Possibly a good idea to add some minimum size requirements to glade. Possibly a wayland-specific gtk3 bug, if you can't reproduce.
4. yumex doesn't seem to remember search filter options.

Packages, Groups, History & Actions (Pending Changes) appear in both the Headerbar & the Main Menu button. Should these filters be remove now from the Main Menu button?

+1

6.

Also shouldn't the Main Menu button be a popover to match the search options button?

+1

7.

Also perhaps the Run button should only appear when there is a package selected by the user to install/delete/update?

I'd not say "only appear when packages selected" but rather "only be sensitive when packages are selected to install/delete/update/…". Same for Pending Actions.

8. When in packages view and having a package selected clicking on package info, filelist, dependency, updates buttons, some parts of the UI flash for a short time. This includes the view switcher and the SidebarSelector.
9. Tooltips to sidebar buttons would be nice to have.

[timlau]

@gitjod : Thanks for your feedback.

1. I have removed the pages from the main menu.
2. I will look into the line issue.
3. I wll make the 'Apply pending actions' button insensitive when there is nothing in the the queue.

[timlau]

@genodeftest: Thanks for the feedback.

1. Ctrl-F is giving med troubles, it is already bound to quick search, if something is selected in the TreeView, So i have used Ctrl-S for now, until i figure out how to overrule it.
2. I have renamed Actiond to Pending Actions
3. The current window size is saved between session, so it should remember the user specified size.
4. I will look into saving the search options.
5. I will look into making the main menu a Gtk:PopoverMenu instead, it have been added in Gtk 3.16, so it sould work in F22 and later.
6. I will make the 'Apply pending actions' button insensitive when there is nothing in the the queue.
7. I will look into the flickering, I can reproduce it.
8. I have added tooltips yesterday, but I have not yet figured out how to add them to the stack switcher yet.

[genodeftest]

Tooltips work now (except for being misplaced on wayland, but that's a known Gtk bug), flickering is gone, main menu is cleaned of view switcher. "Pending" was re-renamed to "Pending Actions". That was fast ;)

Without a status icon, "Close will minimize window" doesn't make sense any more and could be removed.

[gitjod]

Making the 'Apply pending actions' button insensitive works very well. I think you could go this route for the search icon in the headerbar (rather than making it appear/disappear depending on the primary filter chosen as I had originally suggested).

In relation to the popover for the search options, I think this should be right beside the search box or inside it as it seems a bit detached at the moment. I think you need to remove the gap between them.

As for renaming Actions to Pending Actions, I think Pending Actions is too long & this button isnow out of proportion with the other ones for Packages, Groups & History. Could you use Pending instead or keep it as Actions & use a tooltip to give an explanation of what these buttons mean?

This is my last comment on this issue. Thanks for all the work. The redesign has progressed greatly!

[timlau]

@genodeftest, that do you think about @gitjod proposals.

1. make search button insensitive instead of hide it (I the future search could be implemented in the other pages.
2. Making the 'Pending Actions' shorter (Pending, Queue or ???)
3. should the search options, be on a extra bar under the search entry there is revealed when the search option button is pressed

[genodeftest]

1. Yes, I prefer making it insensitive over hiding it. Adding and removing UI elements sometimes baffles users (especially the inexperienced ones).
2. That's ok for me. I just asked some days ago because it could have been a mistake. Keep in mind though that translations might not be that short, so they will still take up more space.
3. I'd rather not remove the gap between search bar and button, but I don't really care. Pro removing the gap: Make very sure that this filter button is perceived as "belongs to search bar". Contra removing the gap: In many search bars the right button is the "do search" action, the same as what you get when pressing the [Enter] key. Putting the button directly besides a search bar might make users not expect a menu at this button.

[gitjod]

Not a new observation just a clarification of my comment in relation to the search box & the popover.

Currently there is a space:

If the space was removed:

Or if the popover was inside the box as in Gnome Videos:

[genodeftest]

@gitjod I understood that. My previous comment (3.) applies for your screenshots.

[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) https://github.com/timlau/yumex-dnf/commit/1fe4b33061ce9ea1970e783eebda1fc8bf6f56fe

[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