-
Notifications
You must be signed in to change notification settings - Fork 548
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
Conversation
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.
@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. |
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 - Isn't it the usual less is more attitude? We wouldn't want to "confuse" users. 🤣 |
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: 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.) |
@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 |
Well, Gnome Shell isn't created for people running Yeah, Firefox is And then there are other issues, like the fact that the process for my file browser windows is 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
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.)
Sure, you could edit the The better way would be to do this:
As long as the filename of the 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 |
@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. 😄 |
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).
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).
This change modifies the color picker invocations in
blender_listview.py
andproperties_tableview.py
to exclude use of the (inferior) native color picker dialog, the waytitle_editor.py
was already doing.Dialog without this change, on some systems running under Gnome Shell:
Dialog after this change, on all supported systems/platforms:
Fixes #2326