Skip to content
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

Color picker: Never use native dialog #2425

Merged
merged 2 commits into from
Dec 13, 2018
Merged

Conversation

ferdnyc
Copy link
Contributor

@ferdnyc ferdnyc commented Dec 4, 2018

This change modifies the color picker invocations in blender_listview.py and properties_tableview.py to exclude use of the (inferior) native color picker dialog, the way title_editor.py was already doing.

Dialog without this change, on some systems running under Gnome Shell:

image

Dialog after this change, on all supported systems/platforms:

image

Fixes #2326

ferdnyc and others added 2 commits December 3, 2018 20:59
This change modifies the color picker invocations in
`blender_listview.py` and `properties_tableview.py` to exclude use of
the (inferior) native color picker dialog, the way `title_editor.py` was
already doing.
@DylanC
Copy link
Collaborator

DylanC commented Dec 13, 2018

@ferdnyc - Nice! I should probably do this for my own app. The normal Qt colour picker is much better and also provides that nice consistent experience across all systems.

@DylanC DylanC merged commit 7a15ffc into OpenShot:develop Dec 13, 2018
@ferdnyc
Copy link
Contributor Author

ferdnyc commented Dec 13, 2018

Nice! I should probably do this for my own app. The normal Qt colour picker is much better and also provides that nice consistent experience across all systems.

Yeah, it's the one exception where the native dialogs are actually stinky and undesirable. Gnome sure has some strange ideas about color-picker functionality.

@ferdnyc ferdnyc deleted the qt-color-picker branch December 13, 2018 10:37
@DylanC
Copy link
Collaborator

DylanC commented Dec 13, 2018

@ferdnyc - Isn't it the usual less is more attitude? We wouldn't want to "confuse" users. 🤣

@ferdnyc
Copy link
Contributor Author

ferdnyc commented Dec 14, 2018

The funny thing about it, though, is that I can't really conceive of a more confusing dialog than that... mess! I may not agree with them on their lowest-common-denominator view of their userbase and its ability to handle complexity or detail, but it's at least a guiding principle. So it's one thing when they make decisions based on that principle, that I can understand. (Even if I don't have to like it.)

But then they come up with this other bullshit, like that color picker, and I'm left wondering which member of the Gnome team suffered a silent stroke at some point, that they somehow imagine it's less confusing for people than any of the sane alternatives would be. And where are they finding these people, who reinforce that impression for them!?

Along similar lines is the push to rename applications (in their user-facing form) to generic words like "Movies" (Totem), "Files" (Nautilus), etc. Because while the package names don't match up to what's displayed anymore, obviously it's still way less confusing for the users, duh! As any fool can plainly see:

image

Phew! Good thing we avoided all that "confusion". 😑

(That's Nemo and Nautilus, installed side-by-side on my system. The low-res Nautilus icon is just gravy.)

@peanutbutterandcrackers
Copy link
Contributor

@ferdnyc - I so totally agree with you on that one. Esp. the generic name thingy... that does suck. Say for instance something stops working, and I need to killall the process, it's extra confusing. I think people like you should be there in the gnome foundation mailing lists or something, providing constructive criticisms regarding issues like these.
On second thought, do you reckon there is a way to change the behaviour, in the .config files, somewhere?

@ferdnyc
Copy link
Contributor Author

ferdnyc commented Dec 14, 2018

@ferdnyc - I so totally agree with you on that one. Esp. the generic name thingy... that does suck. Say for instance something stops working, and I need to killall the process, it's extra confusing.

Well, Gnome Shell isn't created for people running killall from a terminal — or doing anything from a terminal, really. And on that point I'm sympathetic. I mean, it's not as if process names can be expected to map to "application" names anyway.

Yeah, Firefox is firefox, Nautilus is nautilus (for now, eventually it will likely be org.gnome.Nautilus), and Chrome is chrome (though it's /opt/google/$channel/chrome specifically; one of chrome-stable, chrome-unstable, etc.) But Gnome Weather is /usr/bin/gjs /usr/share/org.gnome.Weather/org.gnome.Weather.Application. Tweaks is gnome-tweaks, Software is gnome-software, BiglyBT (nee Azureus) is java, and if you're running it installed, OpenShot itself is /usr/bin/python3 /usr/bin/openshot-qt — a double whammy, since even though killall has been enhanced to ignore interpreter names so you can't shoot yourself in the foot by typing killall python3, you still have to know to type killall openshot-qt.

And then there are other issues, like the fact that the process for my file browser windows is nautilus, but for my desktop icons it's nemo-desktop because that's the way I've configured things. It's expected that if you're on the terminal, not to mention if you're configuring things at that level, that you're savvy enough to figure it out regardless what the GUI displays, and I think that's fair.

In the Gnome System Monitor application, processes are listed with their process name (minus the interpreter, where possible, so "openshot-qt" and "org.gnome.Weather.Application", but also "java" for BiglyBT since the only obvious identifier is buried deep at the far end of the command line), but the processes are shown with their application icons in most cases so it helps to build the association. And g-s-m is fairly old software at this point; I have to believe that if they were writing it today, they'd use the identifier from the .desktop file and display e.g. "Files" for nautilus.

I think people like you should be there in the gnome foundation mailing lists or something, providing constructive criticisms regarding issues like these.

That is very hurtful. Did I do or say something to upset you, that you would wish such misery on me??? 😭

Trust me, these are not things the Gnome team are unaware of for lack of hearing. They've had plenty such criticism leveled at them, by people much more dedicted to it than myself (and with much more fetching tinfoil hats, it must be said), and they have actively chosen to reject the line of thinking that disagrees with their approach.

These issues are not a question of too little discussion/consideration, but of too much (and too isolated) — enough that they were able to talk themselves into the shared notion that they know better than the user community. Which is why it's been their mission to drag us kicking and screaming away from our comfort zones, in order to achieve the bold, shining new future they envision. (Except that eventually the drugs started to wear off.)

On second thought, do you reckon there is a way to change the behaviour, in the .config files, somewhere?

Sure, you could edit the Name= key in the /usr/share/applications/foo.desktop file for any software you wanted to rename, and call it whatever you wanted to. But if you did it that way, it would get overwritten with every update.

The better way would be to do this:

  1. Copy the foo.desktop file into $HOME/.local/share/applications/ for any foo you wanted to change the name (or anything else) for
  2. Edit the file there, putting whatever you like in the Name= or other keys
  3. Save the edited file
  4. Run update-desktop-database $HOME/.local/share/applications/
    (Or add the -v command line flag if you want to see any warning messages about file content issues, but be aware that even officially-packaged software will register copious warnings. Running it on my /usr/share/applications/ produces 250 lines of output, most of them irrelevant false positives.)

As long as the filename of the $HOME/.local/share/applications/foo.desktop file is the same as the original copy in /usr/share/applications/foo.desktop, your local foo.desktop will override the one in the system applications directory. So you won't end up with two icons for the same thing under different names, you'll only see your updated copy.

The only downside (other than the fact that it means you're diverging from the shared user experience, which has its own negatives in terms of collaboration or discussion from common ground — for example, if I did this for Nautilus, then I couldn't take a screenshot like the one above without changing it back first, because my customized desktop is no longer generally applicable to other users) is that you won't automatically benefit from any updates to the /usr/share/applications/ version of the file. So it's a good idea to check every few weeks/months, and make sure your copied files are in sync with the system ones — aside from any keys you modified, obviously.

@peanutbutterandcrackers
Copy link
Contributor

@ferdnyc - I see. Thank you for the information. I have been using Elementary at times and the worst thing about that has been that I don't even know what the file-manager/terminal/ etc. without going to read the release notes. :/ I'm currently on a Linux Mint MATE machine. So, yeah. Gnome 2, FTW. 😄

twwn added a commit to twwn/anki that referenced this pull request Jul 5, 2020
On Linux only Gnome uses its own color dialog, and it's inferior to QT's own: See the same issue @ OpenShot/openshot-qt#2425

(This is/was visible only on some distributions' packaged versions of Anki, not via ./run.)

isLin check since QT on Windows already uses the default, whereas Mac's own picker seems superior (from what I can judge by screenshots).
twwn added a commit to twwn/anki that referenced this pull request Jul 5, 2020
On Linux only Gnome uses its own color dialog, and it's inferior to QT's own: See the same issue @ OpenShot/openshot-qt#2425

(This is/was visible only on some distributions' packaged versions of Anki, not via ./run.)

isLin check since QT on Windows already uses the default, whereas Mac's own picker seems superior (from what I can judge by screenshots).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants