-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add column for checkboxes/radiobuttons/menu icons #32
base: master
Are you sure you want to change the base?
Conversation
These features look really cool at first, so it is with a heavy heart that I must tell you that I will not merge this PR. I had considered adding both check/radio indicators and icons myself in the past, and ultimately decided against it. First, the radio buttons. Those just don't make sense when combined with a filterable list. The purpose of radio buttons is to represent a group of mutually exclusive options. Filtering and re-sorting destroys that group association, and can give the confusing impression that items from multiple radio groups are mutually exclusive, or that multiple radio buttons from the same group are active at the same time. Menu item icons are something I associate with the early 2000s, and I believe it's for a good reason that GNOME hides them by default now. Menus are a list of text options. Action icons are for buttons. If this UI split had been clearer from the start, something like Plotinus might have been built into GTK+ years ago, since text = searchable. This leaves only checkboxes then. I do see some value in indicating state for those, but I really don't like the idea of adding another column just for checkboxes. Also, indicating check but not radio state makes no sense. So overall, I prefer the layout to stay as it is now. I really am very sorry to reject this effort so outright. It is for reasons such as these that the README request any additions be discussed in an issue before creating a PR. |
I can see your point, but I tend to disagree.
- regarding radio buttons: menus can have radio buttons on them right next
to other options. Nemo for example has (symbols|list|compact) at the end of
the "View" menu, below the other options. I think that the very point of
plotinus is to show an entire menu hierarchy in a flattened list, so it
should be obvious that it may contain multiple radio groups. Especially
during filtering, I really find it useful to see which option is currently
active.
- regarding icons: I know the gnome ideology on menu icons, and I've
implemented their guidelines: icons should only represent nouns (like
places and bookmarks in Nemo), but not verbs (like copy, new, delete). My
version only displays icons when the menu has forced them to display (which
according to gnome should only be used for nouns) or if the user whishes it
(and has changed their gtk settings).
Would you consider this if it was an optional feature?
|
In case my opinion can help on this issue, listing check-boxes can be seen as a free improvement to the usefulness of this cool piece of software.
Then about radios, p-e-w made a point and my p.o.v. is that this widget shouldn't be listed at all OR (because, as fkloft stated it can be usefull) by considering semantic groups as one immutable entity and display it in totality whenever at least one option is matched by a search. Finally, about icons and after trying your version, fkloft, there is at least one problem which probably is a corner case : some window states are expressed by check-boxes e.g. « full screen » option in gedit. tl;dr: check-boxes add useful, free of charge information ; group of radio buttons should be considered as an unsplitable entity ; state widgets should be prioritized over icons. |
I think it is fun to note that gnome mockups for palette include icons for actions: |
Add a column to show the current state for checkboxes and radiobuttons.
I also wanted to include menu icons, but since
Command
is exported via DBus, I didn't know how to declare functions with unserializable parameters/return values. I have no experience with Vala, but I did my best to write proper code, including null checks.