Re: Matrix IRC bridge considered harmful
Huh? RocketChat Experimental + the dark theme it comes with is pretty fabulous IMO. I genuinely like the React Native app they have for IOs and Android. On Wed, Feb 12, 2020 at 4:20 PM Zander Brown wrote: > > I do not use it mobile that much, but enough to notice Riot is not > > mature yet. I have not tested RocketChat mobile app. YMMV. > > I suggest you continue in your innocence :-) > ___ > 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: Matrix IRC bridge considered harmful
I appreciate your candor in sharing your reasons. I'd also like to make it clear that I wasn't digging for any uncomfortable sharing of information. That said, what makes an electron application (since we're avoiding web browsers here, which I understand) significantly more distracting than an IRC window? If you use the RocketChat compact theme + dark mode, is that significantly more distracting that an IRC window? That said, would a Matrix window be significantly more distracting than an IRC window as well? So is your stance here that you aren't going to move away from IRC, or that you need whatever the option is to be able to be stripped down to something as bare bones as IRC? Or is that you only can tolerate one chat app being open, and therefor whatever it is has to be universal? If I remember correctly our conversation last month, you said you didn't want a web browser open as it provided tabs to distractions. At which point I mentioned the electron Flatpak (which contains no such tabs), but you weren't having it. Attached is an image of the compact mode + dark theme. Just for the record. https://imgur.com/a/79rnzKc (appologies to Christian who got this email twice) On Wed, Feb 12, 2020 at 3:59 PM Christian Hergert wrote: > On 2/12/20 3:32 PM, Britt Yazel wrote: > > Can you explain to me what the big issue with web clients are? I keep > > hearing over and over again that developers don't want to use web > > clients, either in browser or with Electron, but I don't recall ever > > hearing a "why" in there. > > I'll repeat what I told you last month. > > I don't want a browser open when I work, yet I need to collaborate with > other GNOME developers on code and platform issues. I keep Builder open, > a terminal, and IRC. That's it. > > For those of our community with ADHD and similar neuro-divergence, this > can be a necessity to get things done. The only way I get through my > todo list is to reduce all possibilities for distraction. > > I suspect you wont get many people telling you that though, because to > do so requires a level of emotional labor to share with the world their > medical history. > > -- Christian > ___ > 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: Matrix IRC bridge considered harmful
Can you explain to me what the big issue with web clients are? I keep hearing over and over again that developers don't want to use web clients, either in browser or with Electron, but I don't recall ever hearing a "why" in there. On Wed, Feb 12, 2020 at 3:24 PM Michael Catanzaro wrote: > On Wed, Feb 12, 2020 at 2:41 pm, Britt Yazel wrote: > > No offense Michael, but the argument that you are making seems a > > whole lot like "we're not going to use RocketChat, or even consider > > it a legitimate option, so the rest of you can either fracture the > > community (which will be on you) or you can get on board Matrix" > > > > Unfortunately, you've done nothing to quell my anxiety of using > > Matrix, the complexity therein, or explain how it's a better > > experience than RocketChat, but rather placed an ultimatum upon me > > (and the foundation). Do you see an issue here? > > Perhaps my language was too strong. > > Honestly I think you should just poll the community to see whether it > wants to use Rocket.Chat or not. I'm assuming support will be pretty > low, because I don't think many devs will want to keep a web browser > window dedicated to chat where a GNOME client would otherwise work. But > if I'm wrong and people like it, then I will shut up, and you can > proceed. :) > > Basically anything would be better than status quo, messages going to > nowhere > > Michael > > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
Here's my two cents, granted this is not going to be an academically backed response, just my personal take. I have had horrible experiences with Matrix/Riot.im. I'm not sure which of those is due to the IRC bridge or which is due to Matrix itself, or which is due to the clients, but I really shouldn't 'have' to know the chat system at that level. My experience has been awful. Rocket.Chat hosted at chat.gnome.org on the other hand has been pretty much consistently awesome since it first spun up, and has gotten better consistently over the last few months with weekly or bi-weekly updates. On top of that, I don't want to put words in the mouths of the sysadmins, but it seems like it's been really easy on their end to keep running and maintained. There was a small issue with NTP not working right on the server, but that was sorted out by Bart in not much time. So, y'all are talking about bridge this and federation that, this client, that client, yada yada. This isn't making me yearn to use Matrix. I really don't want to have to have a MS degree to use a basic chat tool (exaggeration to make a point). RocketChat works, is simple, has nice mobile apps, has tons of features, and Matrix has to offer me a LOT of benefit over RocketChat to pull me in that direction. So my question to you is this. Why is Matrix a technically and usability-wise superior option over RocketChat? And in that question, I'm not asking for theoretical benefits, I really am interested in practical use-case benefits. I could see an argument being that Matrix has Fractal and therefor is a nice GTK client, but, unfortunately as it is to say, my experience with Fractal was a bit iffy at best. I cannot even count the number of messages just dropped into the ether using Fractal. So, the last thing I'll say is this. As a project that is trying to attract more users, many of whom are young, new to FOSS, and or are non-technology skilled professionals such as artists, designers, writers, etc, is Matrix really the best option? Or do you just want it to be the best option? On Wed, Feb 12, 2020 at 1:53 PM Michael Catanzaro wrote: > On Wed, Feb 12, 2020 at 4:23 pm, Georges Basile Stavracas Neto via > desktop-devel-list wrote: > > The Riot application is hard to use. It took me days to figure out > > how to connect > > to a GNOME room. It doesn't allow me to log out of the servers. > > These are all problems with the IRC bridge, not with normal Matrix. I > agree the quality of the IRC bridge is catastrophic. Joining rooms is > extremely difficult, and it is a Hotel California bridge (you can check > out, but you can never leave! that's why we have all these trap ghost > accounts from Matrix who never see the PMs you send them, basically the > inverse of the problem I started this thread to complain about). > > Anyway, normal Matrix has none of those problems. Please don't judge it > based on the quality of the IRC bridge. > > It is a shame that the Matrix developers continue to operate IRC > bridges that are clearly serving to harm the reputation of Matrix. I > know there's value in bridging to IRC, but it should be done well if > it's going to be done at all. No doubt the Matrix developers have > limited time and competing priorities, just like we do ourselves > > > Fractal is nice, > > as I really like native clients, but Polari feels more polished. > > Matrix apparently > > doesn't allow turning off federation, and to me that's a no-go aspect > > of it. At > > last, I have a strong impression that Matrix suffers from feature > > bloat. > > Fractal needs some love, for sure. I wouldn't want Matrix to be judged > by the quality of Fractal today. (In particular, all PMs you send to > users are silently discarded until the other user joins the room, and > there is no UI to indicate the user has joined the room. You really > have to create PMs from Riot, which is pretty awful.) But Fractal's > problems are all well within the skills of our community to solve. > > Jan-Michael also likes the Chatty app from Purism. I didn't realize > that was a Matrix client until today, so I haven't tried it and can't > vouch for it myself, but it looks similar to Polari or Fractal. So it > seems we have two GNOME clients for Matrix, zero for Rocket.Chat > > > Rocket.Chat has been apparently more responsive to out contact, and > > even > > accepted a few pull requests from us. I believe it has a brighter > > future, specially > > if a native GTK client shows up. > > I've never seen any core Rocket.Chat developers flying to us to give > talks at GUADEC, like Matthew has done. I think Matthew has perhaps > stopped focusing on GNOME due to perceived lack of interest on our side > (and competing time pressures; I guess keeping Mozilla and the France > government connected is not easy. ;) > > Basically my opinion would be: there's a pretty clear industry leader > here, other open organizations are selecting Matrix after investigating > available options, why
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
I don't like the direction this thread has taken. It has devolved into infighting between one another, and as such I think it best to end it here. People have made their opinions known, and no more minds are likely to be changed in either direction with the tone of the discussion as it is now. On Sat, May 4, 2019, 7:05 AM wrote: > On Sat, May 4, 2019 at 4:22 AM, Bastien Nocera > wrote: > > The person you quoted is a troll. In fact, I'm not sure there's any > > comments on that issue that aren't trolls (apart from the OP and the > > repository owner). > > Ah OK then, fooled me because he took a such strong plausibly-sincere > stance against "master" in [1]. > > [1] > > https://github.com/ContributorCovenant/contributor_covenant/issues/569#issuecomment-423285329 > > > This is the sort of comment that person made on another platform: > > https://dev.to/rkfg/comment/6bj4 > > (yes, they're so useful that they just get removed, you can see > > snippets of the transphobic nature of them in the full thread if you > > want to read) > > > > I don't think you want to align yourself with this person. > > I actually don't see any non-removed comments from him there, but I'll > take your word for it. Clearly not. > > > The rest of > > your interactions in this thread and the original thread are coming > > out > > as disruptive for the sake of it. Is changing the default git branch > > really something you feel strongly about? > > Well clearly I'm very unimpressed by the proposal and don't want to do > this, yes, but I don't think I have anything more to add to the > discussion at this point, so I guess I'll stop "disrupting." > > Michael > > > ___ > 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
Good read from a new GNOME user
Ladies and Gentlemen, If we can all take a quick break from discussing Git branch naming, I came across this users' review of GNOME 3.32 after using it for the first time, and I thought he had a pretty well thought out set of criticisms. https://jatan.tech/2019/05/01/gnome-3-32-is-awesome-but-still-has-key-areas-for-improvements/ Now, none of what this user is saying is news to any of us, but I think this is a very good example of the new user experience with GNOME. Managing the GNOME subreddit, Twitter, and Facebook pages, I continually see these same arguments brought up time and time again (literally countless times), and perhaps it might be a good exercise to go down the list and re-justify and reconsider our stance on the issues brought up in this list. While it might seem a waste of time to go through these points one by one, and even if it is decided to change nothing, at the very least those of us on the Engagement team will be better equipped to explain to our users our stance on these points. On the other hand, perhaps collectively our stance has changed on some of these core concepts, and maybe it's time to set the ground work for some usability changes. We have built A LOT of good will with our community and the broader ecosystem with 3.32, with it being generally regarded (based purely on user interactions and not qualitative surveying) as a huge success. Hopefully we can keep that ball rolling to try to hit the pain points one at a time. Because, sadly, these pain points ARE real, and they need to be addressed in some way, shape, or form. I'd be nice to know which items are 1) definitely not going to change, 2) are open to change pending the manpower to enact it, or 3) are actively being changed in the near future. Cheers everyone! -Britt ___ 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
How does KDE deal with appindicators? Is there something we could partner with then on? Are they trying to solve this also? Did KDE modify the spec? Not knowing much about the nuance of the different indicator solutions, my experience with kstatusnotifier has been fairly great. 5/6 icons show up there as they should (I think discord is the only one that doesn't) and the theme on the drop-down menu when clicking matches the shell theme perfectly. This is in contrast to TopIcons/Plus/Redux that shows all of the icons, but the drop-down themeing is terrible. A couple of thoughts on my mind that maybe someone can answer: 1) When an application has an open window there is a notification dot on the dash to show that it is open. However, when the app window is closed but the process is still running, I.e. steam, telegram, etc, there is no dot to indicate visually that the app is still open. Why is this? On OSX they keep the dot up until the app is fully quit. 2) Back in early GNOME3 we had the slide up tray from the bottom. Am I the only one who thought that was super cool? It had nice big icons for touch and accessibility purposes, and it was just really cool looking imo. I was sad when that went away for usability reasons. Is there any chance on resurrecting that and polishing it's usability issues as a solution? 3) realistically what are the chances of us working with the other interested parties and creating a functional/unified spec once and for all. We could do the whole Mantle-->Vulkan transition with appindicator-->XDG-appicon or something of the sort. My dream is to create a solution for everyone, not just GNOME On Mon, Mar 25, 2019, 11:28 AM Florian Müllner wrote: > On Mon, Mar 25, 2019 at 6:50 PM Emmanuele Bassi wrote: > > > > You cut the part where I said the appindicator implementation should be > changed. :-) > > I thought you were referring to the client library, not the underlying > spec :-) > > Cheers, > Florian > ___ > 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: I believe we should reconsider our sys-tray removal
Ok, expanding on Sri's email I think we have two related but separate use cases here: 1) Having an indicator to let us know of running background apps after the window has been closed. 2) Having an indicator that has some level of user interaction, i.e. a messaging app With that said, we have some users ( I fall into this category) who are mostly concerned with #1. I don't like not knowing if Telegram/Discord/Steam are still running after I close them, and I sometimes get surprised that I'm still logged into telegram even after I've closed the window. I rarely interact with the icon itself except to right click -> close. I'm not sure why exactly these apps don't show a running indicator in the Dash for this use case. For apps such as these, closing the window is really just an analog of "minimize", which is as annoying as it is confusing. OSX goes about this by keeping the running app indicator dot on the dock until the app is fully closed to avoid confusion such as this. With this use case, we could probably solve it without the need for a TopIcons solution, and it would solve a huge pain point with my usage. Now the second group actually use the indicator for a functional purpose, and this is the group that would require a TopIcons like solution. These individuals use the notification icons to respond to chats, to play/pause screen recording, and many other usages that I'm not thinking of. This is the use case that I think requires some deep thought about what to do. Does this split between usages make sense to you all? I would personally be entirely satisfied if the dash would continue to show the running apps when after the window has been closed. However, I don't speak for all the users, many of whom expressed dissatisfaction with #2 On Tue, Mar 26, 2019, 3:17 PM wrote: > On Tue, 2019-03-26 at 18:06 -0400, Matthias Clasen wrote: > > > > > > On Tue, Mar 26, 2019 at 3:24 PM wrote: > > > > > > > > > > I am too, but there is more to this. I'm forced to use topicons or > > > some other because when I ask an application to quit, I have found > > > that > > > some applications don't really quit but instead are sitting in the > > > notification area. That's kind of sub-optimal. So even if you > > > like > > > the change we are forced to put topicons back invalidating the > > > design > > > because not everyone is playing fair. > > > > > > > The strategy we went for with the message tray removal was to say: > > If you have applications that insist on using status icons in this > > way, > > use the topicons extension. > > > > You make it sound like using topicions is somehow impure or bad. > > It isn't. > > Yes, that's true. I don't think it's bad or impure, but it isn't as > designed. Obviously we would want to have an experience without having > to use topicons as our end state. > > In the end, we're going to always use topicons unless something > dramatically changes in the status quo. For me, it's mixed messaging. > It's further complicated by the fact that users pick one of many > topicons type extensions and have an issue. It's not a big deal now, > but something worth addressing going forward if it happens that the lag > between desktop release and when it appears on distros continues to > shorten. > > sri > > ___ > 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: I believe we should reconsider our sys-tray removal
I don't think that using TopIcons is somehow bad or impure, it is just inconsistent in whether or not it is maintained or not. The fact that we have Topicons, TopIcons Plus, and TopIcons Redux just shows the inconsistency. And our end-users all probably don't know which of the three is the the one they should use. And this doesn't even begin to mention KStatusNotifier which is Ubuntu's solution. An extension for this purpose is fine imo, as long as it is made very well clear WHICH extension. I love @fmullner's idea of him taking on a "GNOME official" extension, something that could even be bundled by default in the "gnome-shell-extensions" package that many distros have: https://www.archlinux.org/packages/extra/any/gnome-shell-extensions/ It seems like Florian has already expressed a willingness to step up in this instance On Tue, Mar 26, 2019 at 3:06 PM Matthias Clasen via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > > > On Tue, Mar 26, 2019 at 3:24 PM wrote: > >> >> > >> >> I am too, but there is more to this. I'm forced to use topicons or >> some other because when I ask an application to quit, I have found that >> some applications don't really quit but instead are sitting in the >> notification area. That's kind of sub-optimal. So even if you like >> the change we are forced to put topicons back invalidating the design >> because not everyone is playing fair. >> > > The strategy we went for with the message tray removal was to say: > If you have applications that insist on using status icons in this way, > use the topicons extension. > > You make it sound like using topicions is somehow impure or bad. > It isn't. > ___ > 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: I believe we should reconsider our sys-tray removal
Ok, expanding on Sri's email I think we have two related but separate use cases here: 1) Having an indicator to let us know of running background apps after the window has been closed. 2) Having an indicator that has some level of user interaction, i.e. a messaging app With that said, we have some users ( I fall into this category) who are mostly concerned with #1. I don't like not knowing if Telegram/Discord/Steam are still running after I close them, and I sometimes get surprised that I'm still logged into telegram even after I've closed the window. I rarely interact with the icon itself except to right click -> close. I'm not sure why exactly these apps don't show a running indicator in the Dash for this use case. For apps such as these, closing the window is really just an analog of "minimize", which is as annoying as it is confusing. OSX goes about this by keeping the running app indicator dot on the dock until the app is fully closed to avoid confusion such as this. With this use case, we could probably solve it without the need for a TopIcons solution, and it would solve a huge pain point with my usage. Now the second group actually use the indicator for a functional purpose, and this is the group that would require a TopIcons like solution. These individuals use the notification icons to respond to chats, to play/pause screen recording, and many other usages that I'm not thinking of. This is the use case that I think requires some deep thought about what to do. Does this split between usages make sense to you all? I would personally be entirely satisfied if the dash would continue to show the running apps when after the window has been closed. However, I don't speak for all the users, many of whom expressed dissatisfaction with #2 On Tue, Mar 26, 2019 at 3:17 PM wrote: > On Tue, 2019-03-26 at 18:06 -0400, Matthias Clasen wrote: > > > > > > On Tue, Mar 26, 2019 at 3:24 PM wrote: > > > > > > > > > > I am too, but there is more to this. I'm forced to use topicons or > > > some other because when I ask an application to quit, I have found > > > that > > > some applications don't really quit but instead are sitting in the > > > notification area. That's kind of sub-optimal. So even if you > > > like > > > the change we are forced to put topicons back invalidating the > > > design > > > because not everyone is playing fair. > > > > > > > The strategy we went for with the message tray removal was to say: > > If you have applications that insist on using status icons in this > > way, > > use the topicons extension. > > > > You make it sound like using topicions is somehow impure or bad. > > It isn't. > > Yes, that's true. I don't think it's bad or impure, but it isn't as > designed. Obviously we would want to have an experience without having > to use topicons as our end state. > > In the end, we're going to always use topicons unless something > dramatically changes in the status quo. For me, it's mixed messaging. > It's further complicated by the fact that users pick one of many > topicons type extensions and have an issue. It's not a big deal now, > but something worth addressing going forward if it happens that the lag > between desktop release and when it appears on distros continues to > shorten. > > sri > > ___ > 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: I believe we should reconsider our sys-tray removal
Is there not away to improve the spec while also maintaining backwards compatibility with the current statusnotifier (I'm not sure if that's the right name) spec? Kstatusnotifier works well on the surface, it sounds like behind the scenes there may be issues, but even if we just used the current tech that runs kstatusnotifier it would be an improvement for many of our users. It seems like the folks at Ubuntu already did a good job of turning many apps onto that spec On Tue, Mar 26, 2019, 2:28 AM Allan Day wrote: > Hi Britt, > > Just commenting on the parts I have answers to... > > Britt Yazel wrote: > ... > > 2) Back in early GNOME3 we had the slide up tray from the bottom. Am I > the only one who thought that was super cool? It had nice big icons for > touch and accessibility purposes, and it was just really cool looking imo. > I was sad when that went away for usability reasons. Is there any chance on > resurrecting that and polishing it's usability issues as a solution? > > I thought the tray was cool too! Unfortunately, we could never get it > behave reliably for everyone (and we really did try). I think this was > mostly a combination of variable hardware and the ergonomics of > exerting pressure on the bottom screen-edge. We also had ongoing > issues with the position of the notifications at the bottom of the > screen: people didn't notice them. > > > 3) realistically what are the chances of us working with the other > interested parties and creating a functional/unified spec once and for all. > We could do the whole Mantle-->Vulkan transition with > appindicator-->XDG-appicon or something of the sort. My dream is to create > a solution for everyone, not just GNOME > > The challenge with doing anything new is adoption. One of the main > issues we face with status icons today is the long tail - all those > old apps that don't follow upstream all that closely (if at all). > Getting all of those on a new protocol is unlikely to happen. > > A more general comment: back when we last made changes to status > icons, we had a two-part strategy: > > 1. Push libcloudproviders as the way for apps like Dropbox to integrate > 2. Make sure there was a well-publicised, well-functioning extension > for when people do need status icons > > Unfortunately it seems like 1 hasn't really happened, and poking > around this morning I couldn't find a single functioning extension for > status icons. So there's that. :( > > Allan > ___ 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
How does KDE deal with appindicators? Is there something we could partner with then on? Are they trying to solve this also? Did KDE modify the spec? Not knowing much about the nuance of the different indicator solutions, my experience with kstatusnotifier has been fairly great. 5/6 icons show up there as they should (I think discord is the only one that doesn't) and the theme on the drop-down menu when clicking matches the shell theme perfectly. This is in contrast to TopIcons/Plus/Redux that shows all of the icons, but the drop-down themeing is terrible. A couple of thoughts on my mind that maybe someone can answer: 1) When an application has an open window there is a notification dot on the dash to show that it is open. However, when the app window is closed but the process is still running, I.e. steam, telegram, etc, there is no dot to indicate visually that the app is still open. Why is this? On OSX they keep the dot up until the app is fully quit. 2) Back in early GNOME3 we had the slide up tray from the bottom. Am I the only one who thought that was super cool? It had nice big icons for touch and accessibility purposes, and it was just really cool looking imo. I was sad when that went away for usability reasons. Is there any chance on resurrecting that and polishing it's usability issues as a solution? 3) realistically what are the chances of us working with the other interested parties and creating a functional/unified spec once and for all. We could do the whole Mantle-->Vulkan transition with appindicator-->XDG-appicon or something of the sort. My dream is to create a solution for everyone, not just GNOME On Mon, Mar 25, 2019 at 11:39 AM Emmanuele Bassi via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > > > On Mon, 25 Mar 2019 at 18:27, Florian Müllner wrote: > >> On Mon, Mar 25, 2019 at 6:50 PM Emmanuele Bassi wrote: >> > >> > You cut the part where I said the appindicator implementation should be >> changed. :-) >> >> I thought you were referring to the client library, not the underlying >> spec :-) >> > > AFAIK the spec still assumes X11 like: > > > ``` > org.freedesktop.StatusNotifierItem.WindowId > > UINT32 org.freedesktop.StatusNotifierItem.WindowId (); > > It's the windowing-system dependent identifier for a window, the > application can chose one of its windows to be available through this > property or just set 0 if it's not interested. > > ``` > > > or DBus-Menu: > > > ``` > > org.freedesktop.StatusNotifierItem.Menu > > OBJECT PATH: DBus path to an object which should implement the > com.canonical.dbusmenu interface > ``` > > on top of the whole wishy-washy "don't implement this if you don't like > it, Mercury is retrograde, or it's Thursday", so it's definitely needs to > be changed as well. > > Ciao, > Emmanuele. > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > ___ > 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
I believe we should reconsider our sys-tray removal
Ladies and Gentlemen, Congrats on an excellent 3.32 release! As the one handling the front facing side of our social media accounts, I can safely say that the users are EXTREMELY happy with the changes, both features and performance, so give yourselves a nice pat on the back :-) I want to re-poen an old argument now that we have seen the effects of removing the sys-tray/app-indicator tray for well over a year. In short, the users are not happy. I believe our goals of putting pressure on application developers to ditch the antiquated app-indicator model fell mostly on deaf ears, and not having the sys-tray icons is mostly a nuisance for people, and big pain point for many. Our users (myself included) and our software partners (Ubuntu, System76, Purism) have reverted to using extensions to return this behavior. Some use KStatusNotifier, some use TopIcons/Plus/Redux, and the point I'm making is that we have forced our users to fragment themselves between many solutions, some decent and some fully broken, for what they perceive as base level functionality. An example of this biting us in the arse is that with 3.32 TopIcons is causing the CPU usage to run through the roof, and people are blaming the Shell for the CPU usage, not the extension, leaving our users with a bad taste in their mouths. So to sum up, most users who I talk to on social media and in person are using many different 3rd party solutions for sys-tray icons, and this fragmented approach is hurting our image, annoying our users, and is fragmenting our user experience to the point of actual detriment. I think we need to re-evaluate a solution for 3.34, and that this should be a focus this cycle. I believe that there is an elegant solution to handling sys-tray icons without sacrificing our core goals, one idea being to incorporate it into the Dash. However, I don't think we should go forward into 3.34+ without a 1st party solutions in place for how to treat sys-tray icons, because (sadly) they're not going anywhere. Cheers! -Britt Yazel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
Folks, I don't have anything technical to add to this discussion, so as someone just following along with the thread I think we should take our emotions down a couple notches. Calling each other out, playing the blame game, and dredging up stuff from the past is not going to help us come up with a clear path forward. We're all friends and colleagues, let's not forget that first and foremost. :-) On Sun, Jan 27, 2019 at 10:26 PM Debarshi Ray wrote: > Jeremy, > > You already attempted to slander me once before in this thread: > > https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00027.html > > It's been one week since I produced evidence against that: > > https://mail.gnome.org/archives/desktop-devel-list/2019-January/msg00035.html > > You had enough time to clarify your original statement or recant it. I > no longer consider anything you say to be in good faith. > > On Wed, Jan 23, 2019 at 03:21:57PM -0500, Jeremy Bicha wrote: > > But you're talking about removing even more online accounts providers > > even though apps that support them have not yet implemented a > > replacement. > > Nice reversal of cause and effect there. Good job. > > The decision to retire GNOME Documents was the reason the integration > point was dropped from GOA. > > > Interestingly, Ubuntu Online Accounts was ahead of its time here. What > > it offers in Ubuntu 16.04 LTS sort of foreshadows how this could work. > > Oh, yeah, Ubuntu Online Accounts - the purveyor of shady downstream > patches against applications (read: Shotwell) that replace upstream > branding and reward with crashes. > ___ > 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
Fwd: Official GNOME subreddit
Hello all, I know this is going out to everyone, so I'll keep this short and sweet. We recently gutted and cleaned the official GNOME subreddit: https://www.reddit.com/r/gnome/ I believe this page is probably the easiest and most transparent place for us to interact with the community, as it offers a low barrier to entry and less-officialness than either mailing lists, IRC, or GitLab. This subreddit is a good place to make announcements, bounce ideas, get trolled, have open discussions, the works. With that said, we have implemented special badges called "flairs" that we can assign to you if you so choose that will set you apart from the rest of the community. If you would like a flair added to your account 1) you need to be subscribed, and 2) you need to contact a moderator. Right now your choices are "GNOME Foundation", "GNOME Developer", "GNOME Contributor", or "GNOME Designer". We can make more if we need. I hope you guys take a moment to look at this subreddit and perhaps consider using it as part of your information dissemination strategy. The more of us that use it regularly, the better it is overall. Cheers and happy holidays, -Britt Yazel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Renaming gitg project file to GNOME Commits
I'm fine with idea of giving it a fresh name. Gitg never really made sense to me, though I never knew the reasoning behind it. GNOME Commits might be clear to all people familiar with git, but for the average user they might think it's an activist app or something. Or like a charity app. This might not be a legitimate concern, just a thought On Tue, Oct 9, 2018, 11:35 PM Alberto Fanjul Alonso wrote: > On gitg we are considering to adopt GNOME Commits as project name. > > Same as nautilus is GNOME Files, we though that gitg (a joke around > gitx and software which at some point in time use to have a G around to > denote it is under GNOME) is not easy to locate for people looking for a > git GUI viewer. > > We want to be sure that do not cause any problem downstream or in > development. > > There's an open issue about that > https://gitlab.gnome.org/GNOME/gitg/issues/138 > > Side note: We are looking for a new icon, since now we use the one from > git. Drafts on: https://gitlab.gnome.org/GNOME/gitg/issues/137 > > thoughs? > ___ > 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: Retiring app menus - planning for 3.32.0
Just my 2 cents I think one of the bigger issues isn't necessarily the difference between close and quit (though disambiguation would be great), it's instead that since we retired showing appindicators there is now no way of visually knowing if an app is still running or not. Granted, not all apps used appindicators, but most apps that continued to stay open in the background did have some sort of appindicators (chat apps like slack/discord etc). My suggestion is *not* to bring back appindicators, but rather to make better use of the dash to show all running applications, even the background apps. Right now the dash does a good job showing running apps that have a visible window, but background apps are invisible to the dash. This would at the very least give a visual indicator of background running applications, so in the case of quit/close ambiguity, it would only last as long as until they see the dash and notice that the application still shows running. On Sep 28, 2018 7:33 AM, "Allan Day" wrote: Florian Müllner wrote: > > With regard to dropping the 'quit' action, is there any guidance for > background applications? That is, apps where closing all windows does > *not* exit the application, but the explicit 'quit' action does. Sorry for the slow reply - it's been a busy week. This question is something that has been on my mind too. Having an explicit way to stop an app from running in the background is interesting, but then I wonder how desirable it is to have an action to completely quit just once. I also wonder how obvious the function is. How does someone know that quit stops the app completely, whereas close doesn't? And would we just show quit in the case that an app runs in the background...? Another issue about quit which has occurred to me is that we show it in the dash context menus... Allan ___ 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 minor-reorganization to Community group
Carlos, Excellent! Thank you so much. Under teams the proposal had a few more teams listed such as "board" and others. Those have to go through you if they want to be added to the "teams" group yes? I don't have anything to do with those groups, so I'll let them sort it out, I just want to know for clarification On Mon, Sep 24, 2018 at 9:21 AM Carlos Soriano wrote: > This is done now, please check everything is alright. > > Left to be done: > - The translation team, whether they want a group, projects, or something > else. To be discussed. > - The DeveloperPortal, since they weren't part of the disscussion afaik so > I want to double check with them. > - Creating "Marketing" and "Outreach" groups/projects under Engagement. > The owners have permissions so they can create them, since I don't know > exactly what they will be used for. > > Cheers > > On Mon, 24 Sep 2018 at 18:05, Piotr Drąg via desktop-devel-list < > desktop-devel-list@gnome.org> wrote: > >> 2018-09-23 2:52 GMT+02:00 Petr Kovar : >> > On Fri, 14 Sep 2018 10:58:30 +0200 >> > Andre Klapper wrote: >> > >> >> [CC'ing gnome-i18n@] >> >> >> >> On Mon, 2018-09-10 at 11:46 -0600, Britt Yazel wrote: >> >> > There's been an ongoing discussion about reorganizing the "community" >> >> > top level group from containing both our community partner repos >> >> > (purism, ubuntu, fedora) as well as a myriad of other repositories. >> >> > As of right now, the Community top level is somewhat of a catch-all, >> >> > and we have proposed a fix to split Community into both 'Community' >> >> > and 'Teams' repositories, with the new 'Teams' top level being where >> >> > we will organize all of our Foundation teams, i.e. Engagement, >> >> > Design, Translation, Events, etc. >> >> [...] >> >> > >> https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162 >> >> >> >> Re Translation: >> >> >> >> It's unclear to me where in Gitlab people are supposed to file bug >> >> reports against a translation in a specific language, which would allow >> >> translators of a language to get aware of bugs in their translations. >> >> >> >> There is a "8. Translation" label at >> >> https://gitlab.gnome.org/groups/GNOME/-/labels which allows >> subscribing >> >> but does not allow differentiating per language. It should probably be >> >> renamed to "8. Internationalization" and only be about code which does >> >> not allow proper translation; the label description could link to >> >> https://wiki.gnome.org/TranslationProject/DevGuidelines . >> >> >> >> +1 >> >> >> Currently there is an "L10N" product in GNOME Bugzilla with >> >> subcomponents for each language. Each subcomponent can be watched >> >> separately by folks interested in that subcomponent (=language). >> >> >> >> Maybe some Gitlab setup / ideas already exists that I'm not aware of? >> > >> > Can we use https://gitlab.gnome.org/Community/Translation and set up >> > translation teams as issue labels there? >> > >> > Alternatively, we could make Community/Translation a group and set up >> > languages as individual projects within that team. That could give teams >> > a better control over where and how to submit issues against their >> language. >> > >> >> I like the second idea. I opened >> https://gitlab.gnome.org/Infrastructure/GitLab/issues/341 to >> kick-start the process. >> >> Best regards, >> >> -- >> Piotr Drąg >> https://piotrdrag.fedorapeople.org >> ___ >> 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GitLab minor-reorganization to Community group
Hello all, There's been an ongoing discussion about reorganizing the "community" top level group from containing both our community partner repos (purism, ubuntu, fedora) as well as a myriad of other repositories. As of right now, the Community top level is somewhat of a catch-all, and we have proposed a fix to split Community into both 'Community' and 'Teams' repositories, with the new 'Teams' top level being where we will organize all of our Foundation teams, i.e. Engagement, Design, Translation, Events, etc. A direct link to the latest version of the proposal is linked blow. If you wish to read through the long backlog of discussion, feel free, though it's important to note the initial proposal was much more comprehensive, and this last version really only affects the repositories in that current Community group. Any talk of what to do with other top level groups is being shelved until a future time and isn't in the scope of this specific issue. If nobody has objections to this proposal, in two weeks time I'd like to see this implemented. Thanks all! https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162 -Britt Yazel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
