Re: GNOME Shell 3.25.90
On Mon, 14 Aug 2017, at 02:10, Florian Müllner wrote: > On Sun, Aug 13, 2017 at 11:41 PM, Jan Niklas Hasse wrote: > > On Fri, 11 Aug 2017, at 18:33, Florian Müllner wrote: > >> (Unfortunately the release was already overdue, so we had to push the > >> change in time for the freeze before getting the communication out) > > > > So change it before communicating it? Why not do the blog post before the > > final decision? (I think the reason is because you know what the reaction > > is going to be) > > Right, ignore that I mentioned the UI freeze (that was scheduled > *days* after GUADEC ended, where lots of discussions happened), and > assume malice or cowardice instead. I'm sorry, I don't really know what the UI freeze (which you called just "freeze" in your previous email, so I assumed it was the feature freeze for 3.26) means. Could you or someone else elaborate? ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME Shell 3.25.90
On Sun, Aug 13, 2017 at 11:41 PM, Jan Niklas Hasse wrote: > On Fri, 11 Aug 2017, at 18:33, Florian Müllner wrote: >> (Unfortunately the release was already overdue, so we had to push the change >> in time for the freeze before getting the communication out) > > So change it before communicating it? Why not do the blog post before the > final decision? (I think the reason is because you know what the reaction is > going to be) Right, ignore that I mentioned the UI freeze (that was scheduled *days* after GUADEC ended, where lots of discussions happened), and assume malice or cowardice instead. In that case you'll have to wait for the blog post - I'm too busy being evil, so I'll chicken out now. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME Shell 3.25.90
On Fri, 11 Aug 2017, at 18:33, Florian Müllner wrote: > On Fri, Aug 11, 2017 at 9:32 AM Jan Niklas Hasse wrote: >> On Fri, 11 Aug 2017, at 02:58, Florian Müllner wrote: >> > * Remove legacy status icon tray [Florian; #785956] >> >> To make this less painfull for users, what do you think about adding native >> support for a DBus based approach like >> https://github.com/rgcjonas/gnome-shell-extension-appindicator ? > > (Disclaimer: There will be a blog post from the design team to outline the > details behind the change. Unfortunately the release was already overdue, so > we had to push the change in time for the freeze before getting the > communication out) So change it before communicating it? Why not do the blog post before the final decision? (I think the reason is because you know what the reaction is going to be) > To answer your question: > No. When we were referring to status icons as 'legacy', we didn't mean the > underlying XEmbed technology, but the UI concept of allowing apps to put > their small icon into the system area. Trying to convince developers to stop > using status icons (at least when running in GNOME) has been going on for > years[0], but without too much success - after all, why change something that > still works (somehow). This is a very controversial topic, but have you considered, that *maybe* the reason for the missing success is that you're wrong? > In the huge majority of cases, applications work perfectly fine without > status icons, So your opinion is fact? I think a lot of applications work worse without status icons. For example chat applications or screen recorders. I don't want to install an extension for those! > and more often than not the primary purpose of the icon is brand recognition. So? That's also the purpose of most app icons! > For the few cases that do indeed depend on status icons - namely where > there's no other UI, as for nextcloud, dropbox and the likes - there is > ongoing work on a cloud provider API in the filemanager[1]. It is expected to > make its appearance in the upcoming 3.26 release, and will be supported by > the NextCloud client. We do hope that other cloud providers like Dropbox will > follow suit. That's not a replacement and missing many features tray icons provide right now. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME Shell 3.25.90
On Fri, Aug 11, 2017 at 9:32 AM Jan Niklas Hasse wrote: > On Fri, 11 Aug 2017, at 02:58, Florian Müllner wrote: > > * Remove legacy status icon tray [Florian; #785956] > > To make this less painfull for users, what do you think about adding > native support for a DBus based approach like > https://github.com/rgcjonas/gnome-shell-extension-appindicator ? > (Disclaimer: There will be a blog post from the design team to outline the details behind the change. Unfortunately the release was already overdue, so we had to push the change in time for the freeze before getting the communication out) To answer your question: No. When we were referring to status icons as 'legacy', we didn't mean the underlying XEmbed technology, but the UI concept of allowing apps to put their small icon into the system area. Trying to convince developers to stop using status icons (at least when running in GNOME) has been going on for years[0], but without too much success - after all, why change something that still works (somehow). While StatusNotifiers are nicer than XEmbed ui-wise (when used with canonical's dbus-menu extension, and ignoring all kinds of ugly in the spec/implementation), supporting them wouldn't help the goal of moving away from status icons. In the huge majority of cases, applications work perfectly fine without status icons, and more often than not the primary purpose of the icon is brand recognition. For users who don't mind that and like the "quick access" feature, there are extensions available to add that support, but in our opinion, not having that functionality at all makes for a better out-of-the-box experience (there's even an extension for this, so at least *some* of our users agree ;-) ). For the few cases that do indeed depend on status icons - namely where there's no other UI, as for nextcloud, dropbox and the likes - there is ongoing work on a cloud provider API in the filemanager[1]. It is expected to make its appearance in the upcoming 3.26 release, and will be supported by the NextCloud client. We do hope that other cloud providers like Dropbox will follow suit. [0] https://wiki.gnome.org/Design/Whiteboards/StatusIcons [2] https://blog.juliushaertl.de/index.php/2017/07/12/an-update-on-cloud-providers-integration/ ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: GNOME Shell 3.25.90
On Fri, 11 Aug 2017, at 02:58, Florian Müllner wrote: > * Remove legacy status icon tray [Florian; #785956] To make this less painfull for users, what do you think about adding native support for a DBus based approach like https://github.com/rgcjonas/gnome-shell-extension-appindicator ? Otherwise I think lots of people will complain about the missing Dropbox icon in GNOME's default set-up. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
