Re: Proposal: Replace all references to master/slave in GNOME modules
As a person from a part of the world where slavery has been basically nonexistent after the end of the Middle Ages, it is very hard for me to imagine the effect the word itself has on people from areas where the presence of slavery is still felt today. Being an engineer, whenever I encounter a problem, I am trying to understand it better. This is also why I pointed out the word “leader”, hoping to hear something that would make the problem clearer to me. I am not really opposed to using a more inclusive vocabulary but, first, I need to grasp what that actually is. If we choose the criterion “we will not use words that invoke traumatic memories for protected groups of people”, then the word “leader” can be problematic, as I can imagine it can be be painful for Jonestown survivors. How can I really be better without sacrificing the language? I would assume many of the people critical to this proposal are not actually averse to using more inclusive language either but, rather, fear the vagueness of such goals. Again, with a developer hat on, we try to imagine the worst case scenarios, so we are reluctant to give any way to progress, unless we have at least some degree of certainty it will not come back to bite us. Ignoring those fears can lead to a backslash that will cause the exact opposite of inclusiveness we are aiming for, just look at US presidential elections. 凌:-O Maybe linking some research on how self-moderation increases the inclusiveness without devolving into Orwellian thought police level hell would pacify those critics. On Thu, 25 Apr 2019, 16:56 , wrote: > Hard to believe this is a serious discussion that we're actually having. > > On Thu, Apr 25, 2019 at 7:02 AM, jtojnar--- via desktop-devel-list > wrote: > > On Thu, 25 Apr, 2019 at 11:21 AM, Daniel Playfair Cal via > > desktop-devel-list wrote: > >> "master/slave" -> "leader/follower" > > > > Please note that leader/follower terms are commonly associated with > > exploitation of people by cults and should be avoided as well. > > Since it's impossible to tell what the intended tone here is: was this > a serious request to avoid the terminology, or a joke intended to make > a point? (I'm guessing the later?) > > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I believe we should reconsider our sys-tray removal
Since GNOME is just badly copying Android design , we can just do it properly and display the symbolic icons of applications showing notifications next to the clock. We need to make sure the notifications are not abused like tray icons were, though. It is good we can already disable notifications per-app in the GNOME Settings. We should make the option more visible by adding a right click/long tap menu that will take us directly to the appropriate Settings page. Also we should open issues with the Apps that abuse the notifications as, you claim, Rhythmbox does. Currently playing track should be handled by MPRIS, not notifications. On Mon, 25 Mar 2019, 15:49 Pat Suwalski, wrote: > On 2019-03-25 10:37 a.m., Emmanuele Bassi via desktop-devel-list wrote: > > On a default gnome install on any modern screen, only > > about 25% of the top bar contains any information at all. It can't be > > "the most important real estate" and be so underutilized. > > > > It's important because it's the UI element that is *always visible* at > > all times. > > So let me hide it. Everyone's happy. > > > Same reasoning > > why it is rare to have a park in the middle of downtown. > > > > I literally have no idea what this even means. > > It's not important real-estate if it is completely underutilized. > > The only time empty space is important real estate is when that empty > space is more important than information that could be there. Same > applies to buildings. That was the analogy. > > > That said, notification icons are literally the most useful > information > > points for the many applications I have running in the background. So > > they deserve prominent placement. > > > > If an application is in the background, why do you need to see an icon > > all the time? > > Because I got an IM while I was away from my desk. It shows up in the > completely useless notification menu that is under the clock. Its > notification got clobbered by Rhythmbox's notification that the song > changed while I was on the can. I wonder why I never see my original > notification. > > Alternative: oh hey, the Pidgin icon is flashing! > > > If the application needs to notify you of any state change while it's > > hidden, it can use a notification; if you need an icon to interact with > > a background application, you can literally re-launch it from the dash > > or from the applications grid, and you'll get an application window. > > Keepass: I want the icon so I can click it and it makes the correct > password available o nthe clipboard. Screen recording: I want a place on > screen to click to stop it without recording a window change. There are > a gazillion uses. Screen sharing: icon shows me that someone is > connected (this information is useless hidden in a menu). I can think of > dozens more. > > > If there are no state changes and you don't need to interact with it, > > then the icon is pointless waste of space. > > And yet, on my Mac, I'm not overwhelmed with icons. A balance can be > struck. > > Anyway, all that to say, I'm perfectly happy with KNotifier, but it's a > no-brainer that it should be core and it should be modernized for all of > the *technical* reasons mentioned in other messages. If you don't want > to see it, hide it. > > --Pat > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab mirror considered harmful
In my opinion, GitHub is still superior for viewing code: 1. It is much faster. Code loads with the page instead of having to wait for AJAX request. 2. GitHub offers a feature to jump to blame from parent commit of the change: https://gitlab.com/gitlab-org/gitlab-ce/issues/30749 3. GitLab does not support any references from gitrevisions(7) other than commit hash, compare https://github.com/GNOME/gnome-shell/commit/af34b7c25e39e727f7dbd6e3dae0e7c5fe60f141%5E and https://gitlab.gnome.org/GNOME/gnome-shell/commit/af34b7c25e39e727f7dbd6e3dae0e7c5fe60f141%5E Until these are addressed, we should keep GitHub. On Po, úno 4, 2019 at 2:40 AM, Michael Gratton wrote: Hi all, While the GitHub mirror may have been useful back before GitLab, it actually discourages contributions because PRs aren't accepted there. I've not seen from any positive outcomes from it that I can remember, only negative ones. As such I think it should be deleted. Because of this I just filed: https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/86 – any thoughts? //Mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
