GNOME Bugzilla – Bug 334866
implement menu sensitivity
Last modified: 2021-06-10 11:22:57 UTC
all menu items are always sensitive. For instance save as and print should be insensitive when no word has been looked up. Find next should not be sensitive when no match was found. Etc.
As of today, sensitivity is switched for some menu items. But it remains unhandled for others, e.g. copy and find.
Created attachment 299368 [details] [review] Add ::selection-changed signal to GdictDefbox
Created attachment 299369 [details] [review] Improve sensitivity: find* and copy
Created attachment 299372 [details] [review] Improve sensitivity: find* and copy
I think it's okay for 3.16.1, but honestly I think the whole menu bar should just go away after that. The look up entry should go in an headerbar, and there should be a gear menu for the couple of actions that are still available, like showing the side bar or printing and saving to file.
Challenge accepted :) However, I thought no changes to UI can be made during a cycle.
(In reply to Juan R. Garcia Blanco from comment #6) > Challenge accepted :) Make sure to involve #gnome-design — but basically, my idea is to kill most of the UI. > However, I thought no changes to UI can be made during a cycle. That's true for 3.16, but not for 3.17.
Created attachment 300009 [details] Proposal of new UI Very tentative design.
I will commit this patch then, so it can get into 3.16.1; and start working on the new UI.
(In reply to Juan R. Garcia Blanco from comment #8) > Created attachment 300009 [details] > Proposal of new UI > > Very tentative design. This looks excellent. The search bar in the middle is great, and the button menu is in the correct position. Some small suggestions: * Follow the standard design pattern for search - use GtkSearchEntry, and don't include a "Look up" button - see how other apps handle this, like Maps. * Removing the padding around the white box with reduce the amount of unnecessary visual noise - the box within a box isn't needed.
(In reply to Juan R. Garcia Blanco from comment #8) > Created attachment 300009 [details] > Proposal of new UI > > Very tentative design. We could also have a button with starred-symbolic icon if we want to have favorite words, and i think a bit more width for the GtkSearchEntry could be nice too. For presenting similar words i would suggest a similar approach done by Builder and Maps which use a GtkPopover but i think in a dictionary application, accessing similar words after the look up is finished is also important. so my suggestion is having a sidebar which gets updated whenever search entry changes, this way it could help in both the look up process and also after it's done. Another idea could be having a history button(which shows the history via a GtkPopover) at the left side of the GtkHeaderBar instead of back/forward buttons which is pointed out in report #550937, to provide a better usability and also avoid the look of a web browser.
I have just created wip/ui-redesign, where I have committed all changes done so far, and where development will continue.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gnome-dictionary, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/gnome-dictionary/-/issues/ Thank you for your understanding and your help.