Going in to read this thread, I had two issues regarding the premises
behind the removal of status icons:
1. Status icons' use-cases are already 100% covered by other design patterns
2. Applications will change to conform to the new HID guidelines.
I take issue with both. For starters, a lot of a
I think we could have a set number of icons displayed and more in the
system menu. The problems comes from the usability with touchscreens, where
the icons would be to small.
I wonder how Windows doors it with its Tablet mode though. Does it just
hide everything?
Le dim. 24 mars 2019 à 04:58, Lin
A solution would be for distribution package maintainers to use the
binary tarball as a base instead of sources - this way the build can be
done with secrets (ie. using GitLab CI and environment variable
secrets) and sent to distributions for packaging. This certainly puts
GNOME in a unique positio
Given what I've read about the Google policy (and I don't know how much
of that was added with the Jan. 15 revision), but it seems like the
very concept of GOA as a centralized account repository goes against
Google rules. Google wants to know by whom the OAuth key will be used,
and how. Under
Le jeu. 24 janv. 2019 à 14:29, Matthew Paul Thomas via
desktop-devel-list a écrit :
None of that is to say that GOA shouldn’t exist. It has the
potential to
save people time. “I set up an account in App A. Now it will be
quicker
to use the same account in App B.” Anything more than that is noi
As much as Feeding the troll is bad, I think it brings to light a lot
of the public criticism towards GNOME; and I believe this is a problem
of communication rather than you guys actually being evil developers.
The problem is, all the public hears about GNOME is the project
removing things. Na
My main hesitation to having the app level menu items (preferences,
keyboard shortcuts, help, about) always available is that it could
make the menus unpredictable - there is a clarity in having a definite
place for those items. Also, given that many of them are infrequently
used, requiring the us
I feel like having the primary menu hidden in an in-window navigation
app would be a regression from current, as a primary menu may apply
anywhere, and having the user modify (and especially here, undo)
application state in order to access a particular menu item (that,
again, by its definition
