Re: Good read from a new GNOME user
On Thu, 2019-05-02 at 11:26 +0200, Carmen Bianca Bakker wrote: > > 8c. GNOME Tweaks shouldn't exist. > > Slight agree, with a caveat. The thing I appreciate about GNOME is > that I don't have to go through a lot of settings to find what I'm > looking for. The mental load of using GNOME Settings is very low, and > I like that. > > GNOME Tweaks is the opposite world. I don't need 95% of the settings > in GNOME Tweaks. But 5% of the settings are important to me. The > problem is: Those 5% are different for everyone. I would love it if > my 5% were moved from Tweaks to Settings, but that might just clutter > the Settings app for some other people. > > So from a user perspective: Yes, it's annoying that some settings are > in GNOME Tweaks, and there is no way to know which settings are where > short of simply remembering. But from a design perspective, I can > appreciate that GNOME Settings is as clutter-free as possible. Maybe "hidden" settings that have been changed (using Gnome Tweaks or some other method) should show up in Gnome Settings after that. -- Jan Claeys (please don't CC me when replying to the list) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On Wed, 2019-05-01 at 15:53 +0200, Carmen Bianca Bakker wrote: > Je mer, 2019-05-01 je 23:31 +1000, Michael Gratton skribis: > > On Wed, May 1, 2019 at 15:19, Carmen Bianca Bakker > > > > > > I did however point out that Python has replaced uses of the > > > > term > > > > "master", and we should do the same. > > > > > > We should. But not all instances of "master" are equally > > > problematic—that's the main debate here. I don't see anybody here > > > disagreeing against replacing instances of master that are NOT > > > related > > > to Git. > > > > Because this has been addressed several times over already. From > > tonight alone: > > > > > This has already been covered in the original proposal under > > > objection (1) "It doesn't matter". As has already been discussed, > > > what actually doesn't matter is what you or I think, it is the people > > > who have been affected by the language we use that matter. These are > > > the people who won't contribute to GNOME because of these terms, and > > > it is the project that loses out in the end. > > You didn't demonstrate this. I suggested various ways to demonstrate > this in a previous e-mail in this thread, but you completely ignored > it. To be honest, I would also be interested in exactly such a demonstration. In this thread people were somewhat rightfully called out for lines of reasoning that were not applicable to the problem at hand for various reasons. Yet, it seems that the original line of reasoning in favour of this change has similar issues, and even when asked for it no further evidence has apparently been provided. It is fair to say that the only thing that matters in your view is whether there is a group of people who is affected by this. However, this is a point that can be studied to some extend, yet it *appears* like we are only second guessing that the term "master" as used in this context is problematic for a group of people who we don't actually know much about. Yet this assumption is essential to whole argument and the conclusion that changing the name will make GNOME more inclusive. Now, maybe there is information available (maybe even in this thread already, I have *not* read the whole thread). But the current responses are evasive rather than producing the relevant evidence. > You keep asserting this to be true, but never back it up with > anything > other than references to other projects who renamed various instances > of the word "master" (and "slave"), but none of them renamed the Git > master branch. It's a false equivalence. > > Moreover, it's not enough to demonstrate that the word "master" > sucks—it does. Rather, it needs to be demonstrated that the word—in > this specific context(!!!)—is actively harmful and/or prevents > contributions from people who object to its use. > > > > In any case, if you would care to actually read the diffs on the > > > Python change, you'll see that it covered a number of instances > > > of > > > using another word for "master" when "slave" wasn't involved. > > > It's > > > not the pair of terms that is problematic, it's either term in > > > isolation that is. > > > > It is telling that no one is complaining about replacing uses of > > "slave" by itself alone. > > This is not a charitable argument at all. There are uses of the word > "master" that are not—in any way, shape or form—related to the > practice > of slavery. No such arguments can be made for the word "slave". > > I'm getting a bit tired of this back-and-forth, though. You don't > want > to entertain any argument against changing the name of the master > branch at all, asserting that the word is completely verboten and any > instance of it might harm the inclusivity of GNOME. You write off > these > arguments because they affect a group for whom you appear to speak, > but > you haven't demonstrated that this group exists, or that their > interests align with what you claim. > > So I'm withdrawing conversation, because I've already said my bit a > few > times over and have been ignored a few times over. In summary, please > consider: > > - Contacting several organisations who have more expertise on this > subject to inform our next steps. > > - Contacting Git upstream (or places like GitHub/GitLab, why not) to > change the name of the default branch. > > With kindness, > Carmen > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
On Thu, May 2, 2019 at 1:27 PM Allan Day wrote: > > > 4. Unnecessary notifications (e.g., "Application is ready") > > Indeed, my feeling is that those notifications do more harm than good. > I can't see an issue for this; does anyone know of one? There are several bugs in bugzilla, but IMHO the notification isn't the actual issue. The notification is shown when a window "demands attention". That's something applications may request themselves, for example after a longer operation finished (a big download, cd burning (the two people who still do that), ...). It would be wrong to pop up the window out of nowhere, and simply ignoring the hint doesn't seem right either. A notification seems very appropriate here, although we'd rather have applications send them themselves instead of using an old hint. The other case (and that's the one we are really talking about) is mutter setting the hint on a window after focus-stealing-prevention kicked in. That means that an application tried to focus a window, but mutter rejected the request because there was some user action after the event that triggered the focus request. The problem here is that while not allowing applications to pop up windows randomly - the canonical example is entering your banking data in a chat window that pops up - there are cases where focus-stealing-prevention kicks in when it shouldn't. Those are the cases where the notification is perceived as annoying and useless, but removing it isn't an actual solution - it doesn't mean that the window is shown to the user directly, it means they don't get any response at all to their action! The big hammer fix would be to stop doing any focus-stealing prevention altogether, at the price of having misbehaving applications interrupt the user at any moment. The better fix would be to find the cases where we expect focus requests to succeed, analyze why they don't and address the underlying issue. Which unfortunately isn't trivial - for notifications for example, we need to get the click timestamp into GApplication's platform data, then have GTK inject it into gtk_window_present(). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
Thanks Britt for starting this discussion, and thanks to Carmen for the useful summary. I don't agree with every point raised, but there are a lot of valid ones. I'll provide some brief comments from a design perspective. Obviously there are a lot of issues here: individual discussions should probably happen elsewhere. Carmen Bianca Bakker wrote: ... > 1. The desktop does nothing. There is no functionality other than on > the top bar. ... This is a long-known issue that was discussed around the time of the original GNOME 3 designs, and is currently being discussed again by the design team [1]. It's a tricky issue that's the result of some of the core GNOME 3 design choices. ... > 2b. No battery percentage on status bar. I'd be interested in showing the percentage when the status menu is open [2], but having an option to permanently show it seems fine too [3]. > 2c. No app indicators. Yes, I think we need to return to that discussion. > 2d. No suspend button. I agree we can improve this, and I did some design work for it a little while ago [4]. > 3a. It is difficult to reach the app drawer. I've explored this previously; it's a bit tricky and depends on some other more fundamental questions (do we have dock, what do we show in the top bar, etc). > 3b. Application names are cut off. This is a long-standing issue which I believe has a design agreed. We just need to land the MR [5]. > 3c. Folders in the app drawer aren't customisable. We've been wanting to have Endless's drag and drop app folders upstreamed for some time now: we're just waiting for it to happen. > 4. Unnecessary notifications (e.g., "Application is ready") Indeed, my feeling is that those notifications do more harm than good. I can't see an issue for this; does anyone know of one? ... > 5b. Icons in Nautilus are confusing. That doesn't look like GNOME's icon theme - it would be clearer if it was. My understanding is that the lack of tooltips is a technical limitation of popover menus. On a related topic: the design team is currently evaluating these buttons in menus, and are waiting on the menus to be updated in order to do some usability testing [6]. > 5d. The file picker isn't very good. I did a review of our file picker a little while ago [7] and it generally looked OK to me. The main issue seems to be the lack of icon view, which I agree would be good to have, and have included in my latest experimental mockups. ... > 8b. Difficult to set custom wallpaper. The latest designs [8] have a button to select a file. However, I think we'd like to revisit these designs before anything gets implemented, and they've been stuck in our design backlog for a little while. A concluding remark: quite a few of these issues relate to the shell, and on the design side we've wanted to make improvements in that area for a long time, but have been held back due to a lack of developer resources. It would be amazing if we had more developers working in that area, to help us resolve these prominent issues. Allan -- [1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1216 [2] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1241 [3] https://gitlab.gnome.org/GNOME/gnome-control-center/issues/481 [4] https://gitlab.gnome.org/GNOME/gnome-shell/issues/270 [5] https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/109 [6] https://discourse.gnome.org/t/gtk-support-for-gnome-design-patterns/551/20?u=allanday [7] https://wiki.gnome.org/Design/OS/FileSelection#Tentative_Design [8] https://wiki.gnome.org/Design/SystemSettings/Background#Tentative_Design ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
On Thu, 2019-05-02 at 11:01 +0200, Carmen Bianca Bakker wrote: > I'll summarise the raised points quickly here for everyone's > convenience: For the records, the user also created tasks for many topics: https://gitlab.gnome.org/groups/GNOME/-/issues?scope=all_username=uncertainquark Specific topics brought up should likely be discussed in the corresponding tasks, instead of a catch-all email thread. andre -- Andre Klapper | ak...@gmx.net https://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
On 2 May 2019, at 10:26, Carmen Bianca Bakker wrote: > > Je ĵaŭ, 2019-05-02 je 11:01 +0200, Carmen Bianca Bakker skribis: > >> 5e. Bookmarking folders isn't discoverable. > > Agree. Putting this under right-click should be an easy fix. If you want to make something discoverable, putting it on right-click isn't usually the answer. Most users don't habitually right click things. Cheers, Calum. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
On Thu, 2019-05-02 at 11:26 +0200, Carmen Bianca Bakker wrote: > > 2b. No battery percentage on status bar. > > Slight agree on all, but do not know how to fix this. I implemented this: $ gsettings set org.gnome.desktop.interface show-battery-percentage true but it doesn't have a UI: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/481 Feel free to thumbs up the original report or my reply. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
Having written the summary, I'll make a slight effort to give some input on the points. I hope that, like the summary, they are insightful. I'm removing the points on which I have no strong/informed opinion. Je ĵaŭ, 2019-05-02 je 11:01 +0200, Carmen Bianca Bakker skribis: > 1. The desktop does nothing. There is no functionality other than on > the top bar. Specifically: There is no dash/dock. The desktop doing nothing is desirable. GNOME gets out of the way. The dash/dock is such a common pain point for some people, though, that it seems worth it to (a.) enable a toggle for this and (b.) do some research into what the default state of this toggle should be. > 2. The status bar does very little. Specifically: Indicators like wi-fi > are hidden inside sub-menus. > > 2a. Connecting to wi-fi is too many steps. > > 2b. No battery percentage on status bar. Slight agree on all, but do not know how to fix this. > 2d. No suspend button. Full agree. This isn't a problem on laptops, but on desktops it is kind of annoying. > 3a. It is difficult to reach the app drawer. Slight disagree. It is 2 steps to the app drawer (versus 1 step). But I reckon that most people's workflow will be (a.) using keyboard search instead or (b.) pinning often-used application as favourite. This would be solved if the dash/dock became an officially supported feature of GNOME. > 3b. Application names are cut off. Full agree. This is annoying specifically for translations of GNOME. > 5e. Bookmarking folders isn't discoverable. Agree. Putting this under right-click should be an easy fix. > 8b. Difficult to set custom wallpaper. Agree. > 8c. GNOME Tweaks shouldn't exist. Slight agree, with a caveat. The thing I appreciate about GNOME is that I don't have to go through a lot of settings to find what I'm looking for. The mental load of using GNOME Settings is very low, and I like that. GNOME Tweaks is the opposite world. I don't need 95% of the settings in GNOME Tweaks. But 5% of the settings are important to me. The problem is: Those 5% are different for everyone. I would love it if my 5% were moved from Tweaks to Settings, but that might just clutter the Settings app for some other people. So from a user perspective: Yes, it's annoying that some settings are in GNOME Tweaks, and there is no way to know which settings are where short of simply remembering. But from a design perspective, I can appreciate that GNOME Settings is as clutter-free as possible. With kindness, Carmen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
Hi Britt, Thanks for posting this to the mailing list. I'll summarise the raised points quickly here for everyone's convenience: 1. The desktop does nothing. There is no functionality other than on the top bar. Specifically: There is no dash/dock. 2. The status bar does very little. Specifically: Indicators like wi-fi are hidden inside sub-menus. 2a. Connecting to wi-fi is too many steps. 2b. No battery percentage on status bar. 2c. No app indicators. 2d. No suspend button. 3a. It is difficult to reach the app drawer. 3b. Application names are cut off. 3c. Folders in the app drawer aren't customisable. 4. Unnecessary notifications (e.g., "Application is ready") 5a. Can't create file by right-clicking in Nautilus. 5b. Icons in Nautilus are confusing. 5c. Same icons for different file types. 5d. The file picker isn't very good. 5e. Bookmarking folders isn't discoverable. 6. Evince has no tabs. 7. Two photo apps (eog, Photos) 8a. Some settings are undiscoverable. Specifically: Connecting to a hidden network is hidden behind three dots. 8b. Difficult to set custom wallpaper. 8c. GNOME Tweaks shouldn't exist. 9. GNOME Software doesn't show change logs. I took some liberties here and there in summarising these points, but I hope that they are useful. Kindly, Carmen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
