Re: I believe we should reconsider our sys-tray removal

[Matthias Klumpp]

Am Mo., 25. März 2019 um 19:39 Uhr schrieb Emmanuele Bassi via
desktop-devel-list :
>
>
>
> 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
> ```

Urgh...

> 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.

Just assume people are willing to constructively work on this. The
StatusNotifier spec is quite old now and has gone through many hands,
and I am quite confident that people from KDE and other interested
parties would have an interest in working on improving its flaws or
creating a new unified specification that GNOME also adopts. On all
sides, there might be new people now and existing perspectives can be
changed.

This all doesn't matter though if GNOME does not want to adopt
something like the StatusNotifier spec in the first place, so any
discussion about its quality and whether adopting it is a good idea or
not comes second to answering the question of whether GNOME actually
*wants* to have a solution for this.
Some more methodical usability testing would actually be nice here, I guess.
Personally, I think a desktop like GNOME has to keep at least a base
level of compatibility for existing apps, and since tray icons are
such a widespread concept still used by so many apps despite a push
from GNOME to remove them, it's fair to ask the question of whether
having some solution for displaying their information again would be
good. People don't care about GNOME as much as they care about using
their apps on it, and if a change in the desktop suddenly "breaks" a
bunch of them, it actually *is* the desktop's fault.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/
___
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

[Britt Yazel]

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

Re: I believe we should reconsider our sys-tray removal

[Emmanuele Bassi via desktop-devel-list]

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

Re: I believe we should reconsider our sys-tray removal

[Florian Müllner]

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

Re: I believe we should reconsider our sys-tray removal

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 17:34, Florian Müllner  wrote:

> On Mon, Mar 25, 2019 at 5:36 PM Emmanuele Bassi via desktop-devel-list
>  wrote:
> >
> > If the answer to status icons is to adopt/adapt the appindicator API,
> I'm also fine with that;
>
> I'm not. The StatusNotifier spec is seriously flawed, and I don't want
> to support it unless at least the issues that were raised ten years
> ago are addressed (the spec was put up for "review" on xdg-list, but
> then any comments were hand-waived away with "if you don't like it,
> don't implement it").
>

You cut the part where I said the appindicator implementation should be
changed. :-)

I also completely agree that the StatusNotifier spec is broken by design;
Canonical tried to fix it, but the changes ended up into the Unity silo,
and drifted apart from the baseline KDE implementation (even though I think
KDE changed their own code to match expectations with Unity after a while).

Seriously, the spec is so crappy that there are two implementations
> that are both compliant, but interpret the spec in different and
> incompatible ways (see the implementation-specific handling in [0]).
>

The spec is so badly designed that we could literally claim that we're
implementing it right now, if we just owned a name on the bus without
plugging it to anything.

If we want to support something *like* appindicators, it must be a new
> and fixed API[1] that apps can port to, not the existing API, sorry.
>

I wholeheartedly agree. The problem remains that applications would now
have to port to this new API, and support:

 - spangly new API
 - libappindicator
 - GtkStatusIcon

in their code.

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

Re: I believe we should reconsider our sys-tray removal

[Florian Müllner]

On Mon, Mar 25, 2019 at 5:36 PM Emmanuele Bassi via desktop-devel-list
 wrote:
>
> If the answer to status icons is to adopt/adapt the appindicator API, I'm 
> also fine with that;

I'm not. The StatusNotifier spec is seriously flawed, and I don't want
to support it unless at least the issues that were raised ten years
ago are addressed (the spec was put up for "review" on xdg-list, but
then any comments were hand-waived away with "if you don't like it,
don't implement it").

Seriously, the spec is so crappy that there are two implementations
that are both compliant, but interpret the spec in different and
incompatible ways (see the implementation-specific handling in [0]).

If we want to support something *like* appindicators, it must be a new
and fixed API[1] that apps can port to, not the existing API, sorry.

Cheers,
Florian

[0] 
https://gitlab.gnome.org/Community/Ubuntu/gnome-shell-extension-appindicator/blob/master/statusNotifierWatcher.js#L137
[1] ideally tying in with the newer org.freedesktop.Application stuff and GMenu
___
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

[Mattias Bengtsson via desktop-devel-list]

On Mon, 2019-03-25 at 12:22 -0400, Will Thompson wrote:
> 
> [...] In particular, several third-party, non-free apps like Dropbox
> which are partially or totally unusable without a status notifier
> already support it. (Not to make this all about Dropbox – it's just
> an app I use that falls into the "totally unusable" category.)

Hm. I'd like to challenge this. I've used Dropbox for 10+ years and I
forgot it even had a notification icon.

From my experience there aren't many (or even any?) apps that fall on
the partially- to totally unusable scale.

Regards, Mattias

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Managing Google API key secrets

[Michael Terry]

There was a previous thread about how GOA's keys are only intended for 
GNOME-core apps and that third party apps should use their own keys. But there 
was also some uncertainty around how to do that for Google, since Google's TOS 
requires that you not commit key secrets to an open git.

Here's a solution that worked for me. Hopefully it will be useful for third 
party app developers looking to migrate away from GOA and maybe could even let 
GOA stop having a public secret key.

tl;dr; Register and use an iOS client key, which allows for a login flow that 
doesn't need a secret key.

The main problem is: you need an API secret to log in, but Google won't let you 
commit that secret anywhere public. So what's an open source app supposed to do?

Well, Google admits that installed apps can't keep a secret. So they allow 
mobile apps to use an alternative login flow that does not require a secret. 
Though for some reason, the "Other" key type for installed apps (vs "Android" 
or "iOS") does *not* allow that flow. But unfortunately, "Other" is exactly the 
key type that a GNOME developer would naturally use.

But if you *do* register as a mobile app, Google will let you do a "Proof Key 
for Code Exchange" (PKCE pronounced pixy) which is just basically giving Google 
an arbitrary string that you create at runtime and then include in all your 
requests. And you need to run a localhost http server on an arbitraty port, to 
accept the access token from Google. If you do all this, Google won't require a 
client secret, just a client id, which _can_ be public.

Now, none of this prevents someone from stealing your client id and 
masquerading as your app... But :shrug: at least you're following TOS. And 
that's the same risk any mobile app is currently taking.

When you register an iOS key, they'll ask for an application ID - but you can 
just give it your appid like org.gnome.XXX - they don't confirm that it's 
registered with the iOS store or anything.

Registering as a mobile app _is_ a lie, but a white one. I feel like it's 
following the spirit of the law, at least.

Here's documentation from Google about this flow and how to use it: 
https://developers.google.com/identity/protocols/OAuth2InstalledApp

Another interesting tidbit from that page is that Google prefers that you send 
the user to the system browser for the consent screen, rather than loading it 
in-app in a GtkWebKit frame or whatever (presumably so that the user knows 
they're actually on a Google page and the app isn't phishing them for their 
Google password).___
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

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 16:29, Will Thompson  wrote:


> On the other hand: this API under its various names is already
> widely-supported both by (non-GNOME) apps, and by widely-used desktop
> environments – a virtuous cycle. In particular, several third-party,
> non-free apps like Dropbox which are partially or totally
>
unusable without a status notifier already support it. (Not to make this
> all about Dropbox – it's just an app I use that falls into the "totally
> unusable" category.)
>
> I'm sure it's not as simple as "copy
> https://github.com/ubuntu/gnome-shell-extension-appindicator into the
> gnome-shell tree" – though it seems to work fine after a few days' testing
> – but supporting and improving this API would at least mean that many
> existing apps would behave as intended by their developers without needing
> to be changed (immediately).
>

If the answer to status icons is to adopt/adapt the appindicator API, I'm
also fine with that; a bunch of applications do use it, since it's
basically Ubuntu integration, and apparently "Linux == Ubuntu" for some
vendors.

Of course, a lot of the crappy "let's inspect GtkMenu at run time and
serialize it over DBus assuming nothing preserves state on top of the
menu/menu items" needs to go, and we need to handle the GMenu
serialization. But we're still back to the issue of: we need to port
applications.

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

Re: I believe we should reconsider our sys-tray removal

[Pat Suwalski]

On 2019-03-25 12:15 p.m., mcatanz...@gnome.org wrote:
I wonder if there's been any serious design consideration of this 
proposal? The dash seems like it might be a safer place to put things 
than allowing applications to clutter the precious top bar.


Not to be impertinent, but attached is my top bar. Please indicate where 
there is clutter? Is it the 24 pixels of the dropbox icon?


--Pat
___
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

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 16:15,  wrote:

The dash seems like it might be a safer place to put things
> than allowing applications to clutter the precious top bar.
>

Like every other solution for placing stuff into the overview, this fails
to take into account menus created by status icons; the stacking of
override-redirect windows (i.e. menus) inside the overview, coupled with
grabs, is never going to work correctly.

Additionally, it fails to answer the question as to what happens when an
application raises its window while we're still inside the overview.

The tray notification has specific constraints that are caused by being a
component designed in 2004. These constraints cannot be magicked away
because they are encoded in how the whole thing works. If we change the
terms of the problem—introduce new API, change the behaviour of the tray or
of the status icons embedded into it—then we'll need to change all the
applications that use it, and we still won't solve the problem of the
existing tray icons being crap technology from 15 years ago.

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

Re: I believe we should reconsider our sys-tray removal

[Will Thompson]

I agree with Britt. In Endless we currently ship an in-tree copy of TopIcons, 
but this won't fly in a Wayland world, so we're considering what to do in 
future.

On Mon, 25 Mar 2019, at 11:20, Emmanuele Bassi via desktop-devel-list wrote:
> Sadly, this means a complete API change, which makes the point moot: 
> applications would need to be changed.
> 
> […]
> 
> The appindicator API/StatusNotifier specification comes close to this, but:
> 
>  - [… several major shortcomings …]

For another example off the top of my head, the spec at 
https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/
 says that apps should register a name of the form 
“org.freedesktop.StatusNotifierItem-PID-ID”, which in a Flatpak world means 
allowing the app to own any name in the “org.freedesktop.*” namespace.

On the other hand: this API under its various names is already widely-supported 
both by (non-GNOME) apps, and by widely-used desktop environments – a virtuous 
cycle. In particular, several third-party, non-free apps like Dropbox which are 
partially or totally unusable without a status notifier already support it. 
(Not to make this all about Dropbox – it's just an app I use that falls into 
the "totally unusable" category.)

I'm sure it's not as simple as "copy 
https://github.com/ubuntu/gnome-shell-extension-appindicator into the 
gnome-shell tree" – though it seems to work fine after a few days' testing – 
but supporting and improving this API would at least mean that many existing 
apps would behave as intended by their developers without needing to be changed 
(immediately).

> 
>> Permanently adding the extension code to the shell (which, if I've 
>> undesrtood properly, "moves" icons from tray to topbar) will be a dirty but 
>> effective solution.
> 
> Which would achieve nothing except, once again, shoving icons and menus into 
> one of the most important pieces of screen real estate we have just because 
> some application developers simply cannot live without their application 
> icons being visible at all times. If you want to do that, use the extension. 
> It's there for a reason.

The problem with the extension route is that it shifts the burden onto each 
individual user (assuming app developers don't redesign their apps to remove 
the indicators, which many haven't, and assuming distributors don't intervene 
as described by Britt). If Shell supported indicators out of the box, then 
there would be two cases:
 1. user doesn't use any apps which show indicators: great, no junk on the 
panel.
 2. user does: their panel has some icons on it. (Ideally, some mechanism would 
exist for them to be disabled just like Settings → Notifications.)
If there were a blessed extension, the two cases would be:
 1. they don't use any apps which show indicators: great, no junk on the panel.
 2. they do: these apps don't work properly. Each user has to independently 
discover that an extension exists; they enable it and now their apps work.
The status quo is:
 1. they don't use any apps which show indicators: great, no junk on the panel.
 2. they do: these apps don't work properly. Each user has to independently 
discover that many different extensions exist which purport to make their apps 
work, decide which one to use, and enable it.
A blessed extension in gnome-shell-extensions would be an improvement but I 
don't really see the advantage of not enabling it by default.

> The tray icons were designed and meant for system status notifications: 
> network state connectivity, volume level, battery level, IM status (when it 
> was a thing). They were hijacked by application developers to have panel 
> applets that would work across desktop environments. It was a bad idea then, 
> and nothing has changed in that regard.

I agree that status icon proliferation is a bad experience, but they exist and 
apps rely on them being shown. Perhaps a design similar to what Chromium does 
with extensions, where icons overflow into the hamburger menu, could be a 
reasonable compromise.

– Will___
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

[Mattias Bengtsson via desktop-devel-list]

On Mon, 2019-03-25 at 10:21 -0400, Pat Suwalski wrote:
> 
> [...]
> Is that a joke? 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 really can. One stated goal for GNOME 3 was to provide a distraction
free environment to work in. If you expose too much information you'll
add distraction while diluting the information actually provided.

> 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.

This is rather anecdotal and hard (for the GNOME developers) to act on.
It would be more interesting to know what problems you have with the
current notification system.

> You think "application developers simply cannot live without their 
> application icons being visible at all times"? That's why Windows
> lets you hide them. Problem solved. Like, since XP in 2001.

I think what they did to the notification bar in Windows XP is pretty
weak to be honest. Closer to worst-of-both-worlds than to a solution in
my perspective.

Regards,
Mattias

___
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

[Jan Tojnar via desktop-devel-list]

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: I believe we should reconsider our sys-tray removal

[mcatanzaro]

On Sat, Mar 23, 2019 at 1:06 PM, Britt Yazel  wrote:
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.


I wonder if there's been any serious design consideration of this 
proposal? The dash seems like it might be a safer place to put things 
than allowing applications to clutter the precious top bar.


On the other hand, we might just walk into user complaints that the 
icons are not visible enough there.


Michael


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extension review

[mcatanzaro]

On Mon, Mar 25, 2019 at 6:16 AM, Neil McGovern  wrote:

Just to confirm though, is this for working on the extension review
infrastructure, or actually doing reviews? That may change the answer
:)


Actually doing reviews, I think. Dunno, I'll pass him on to you.


___
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

[Pat Suwalski]

On 2019-03-25 11:07 a.m., Andre Klapper wrote:

You may want to disable "Plugins > Notifications" in Rhythmbox to not
flood your notification area with things you don't consider helpful.


I think you have just corroborated my point. You can hide notifications 
you don't want.


The notification system treats all notifications as equals. They are not 
all equal. Maybe I want a notification area for important messages and 
one for everything else. I don't mind an extra icon for that. If it 
needs to flash to get my attention, fine. That's a preference. I can 
disable it.


Should icons be shown all the time? No, usually. But that should be up 
to the program. If I'm annoyed by it, I won't use it. Or I'll hide it. 
Or disable the notification.


--Pat
___
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

[Pat Suwalski]

On 2019-03-25 7:19 a.m., Emmanuele Bassi via desktop-devel-list wrote:
Which would achieve nothing except, once again, shoving icons and menus 
into one of the most important pieces of screen real estate we have just 
because some application developers simply cannot live without their 
application icons being visible at all times.


Is that a joke? 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. Same reasoning 
why it is rare to have a park in the middle of downtown.


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.


You think "application developers simply cannot live without their 
application icons being visible at all times"? That's why Windows lets 
you hide them. Problem solved. Like, since XP in 2001.


--Pat
___
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

[Andre Klapper]

On Mon, 2019-03-25 at 10:49 -0400, Pat Suwalski wrote:
> On 2019-03-25 10:37 a.m., Emmanuele Bassi 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.

Off-topic different conversation - feel free to find the corresponding
ticket (which likely will explain GNOME's visual identity to you).

> > 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.

You may want to disable "Plugins > Notifications" in Rhythmbox to not
flood your notification area with things you don't consider helpful.

> Alternative: oh hey, the Pidgin icon is flashing!

Some flashing stuff is a good description of super annoying distracting
behavior (compared to a default notification in the notification area).

> > 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.

I don't see a big issue in switching to a window in which Keepass is
running. That's probably two clicks instead of one though, admitted.

> Screen recording: I want a place on
> screen to click to stop it without recording a window change.

Ctrl+Alt+Shift+R exists:
https://help.gnome.org/users/gnome-help/stable/shell-keyboard-shortcuts.html

> Screen sharing: icon shows me that someone is connected (this
> information is useless hidden in a menu).

I'd expect an icon in the upper right corner (like for screencasts).

Cheers,
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: I believe we should reconsider our sys-tray removal

[Florian Müllner]

On Mon, Mar 25, 2019 at 2:38 PM Alexandre Franke  wrote:
>
> On Sat, Mar 23, 2019 at 7:07 PM Britt Yazel  wrote:
> > I want to re-poen an old argument now that we have seen the effects of
> >
> > 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.
>
> That is indeed an issue, I acknowledge this. It doesn’t mean the
> premise of this email is correct.

It *can* be an issue.

In this particular case it does look like it was triggered by some
change in mutter/gnome-shell, so the blame isn't misplaced and moving
tray icons back into the shell itself wouldn't fix it.

Cheers,
Florian
___
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

[Pat Suwalski]

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

Re: I believe we should reconsider our sys-tray removal

[Leslie S Satenstein via desktop-devel-list]

I am an end user.   I was an avid Gnome user for the past 10 years, until 3.28. 
 Then I had enough. Gnome's changes have driven me to use KDE.  

I will accept performance improvements, bot not improvements that take away 
convenience.  Want me back? I just find that Gnome does not publish a roadmap 
of intentions for the public, and that means, Gnome does not get user feedback, 
except as rant or rave.  

My own experience is closer to rant, than rave, particularly when extensions 
are broken, with no advice to developers as to what they have to change in 
their extension to meet Gnome's whimsical moving target.


Regards 
 Leslie
 Leslie Satenstein
Montréal Québec, Canada

 

On Monday, March 25, 2019, 9:38:56 a.m. EDT, Alexandre Franke 
 wrote:  
 
 On Sat, Mar 23, 2019 at 7:07 PM Britt Yazel  wrote:
> 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.

*Some* users. Please refrain from making such dubious claims when
there is no data to support it. Even “most people I talk to” is
unreliable, as for every person that complains about it there are 9.7
users who don’t.

I am a user and I am happy about the change.


> 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.

None of the apps I use seem to have a problem with the lack of
systray, and it’s clear that 15 years ago some of them would have had
an icon there (e.g. Music, Fractal). This has had a positive impact on
my daily experience and I am thankful for GNOME to be behind this
push.


> Our users (myself included) and our software partners (Ubuntu, System76,
> Purism) have reverted to using extensions to return this behavior.

Again, *some* users. Count me as one of those who don’t.


> we have forced our users to fragment themselves between many solutions,

I don’t feel forced.


> 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.

That is indeed an issue, I acknowledge this. It doesn’t mean the
premise of this email is correct.


> 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.

Please consider how unnecessarily pushy this sounds.

-- 
Alexandre Franke
GNOME Hacker
___
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

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 14:29, Pat Suwalski  wrote:

> On 2019-03-25 7:19 a.m., Emmanuele Bassi via desktop-devel-list wrote:
> > Which would achieve nothing except, once again, shoving icons and menus
> > into one of the most important pieces of screen real estate we have just
> > because some application developers simply cannot live without their
> > application icons being visible at all times.
>
> Is that a joke?


No.


> 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.

Not every square millimeter of your screen need to be lit up by something
that can be interacted by the user.


> Same reasoning
> why it is rare to have a park in the middle of downtown.
>

I literally have no idea what this even means.


> 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?

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.

If there are no state changes and you don't need to interact with it, then
the icon is pointless waste of space.

You think "application developers simply cannot live without their
> application icons being visible at all times"? That's why Windows lets
> you hide them. Problem solved. Like, since XP in 2001.
>

It's so much solved by Windows that tray icons are discouraged there as
well, and are generally left for legacy applications or custom hardware
settings.

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

Re: I believe we should reconsider our sys-tray removal

[Alexandre Franke]

On Sat, Mar 23, 2019 at 7:07 PM Britt Yazel  wrote:
> 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.

*Some* users. Please refrain from making such dubious claims when
there is no data to support it. Even “most people I talk to” is
unreliable, as for every person that complains about it there are 9.7
users who don’t.

I am a user and I am happy about the change.


> 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.

None of the apps I use seem to have a problem with the lack of
systray, and it’s clear that 15 years ago some of them would have had
an icon there (e.g. Music, Fractal). This has had a positive impact on
my daily experience and I am thankful for GNOME to be behind this
push.


> Our users (myself included) and our software partners (Ubuntu, System76,
> Purism) have reverted to using extensions to return this behavior.

Again, *some* users. Count me as one of those who don’t.


> we have forced our users to fragment themselves between many solutions,

I don’t feel forced.


> 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.

That is indeed an issue, I acknowledge this. It doesn’t mean the
premise of this email is correct.


> 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.

Please consider how unnecessarily pushy this sounds.

-- 
Alexandre Franke
GNOME Hacker
___
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

[Florian Müllner]

On Mon, Mar 25, 2019 at 9:57 AM Allan Day via desktop-devel-list
 wrote:

>> 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.
>
>
> Can we can do a better job at sign-posting which extension people should use?

A couple of months ago I said I was willing to maintain an "official"
fork of the extension[0].

Except for the ID the fork should use (I really don't want to use the
private e-mail of the former maintainer), everything is lined up[1],
but unfortunately the name issue is still waiting for a conclusion[2].

Cheers,
Florian

[0] https://gitlab.gnome.org/GNOME/gnome-shell-extensions/issues/116
[1] https://gitlab.gnome.org/fmuellner/top-icons/tree/import
[2] https://gitlab.gnome.org/Infrastructure/GitLab/issues/367
___
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

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 10:39, Daniel Mustieles García via
desktop-devel-list  wrote:

> Can't GtkStatusIcon be modified to show icons in the top bar?
>

No.

GtkStatusIcon encodes the XEMBED-based tray icon specification; this means
that the application code is responsible for:

 - sending icon data over the wire (no HiDPI, and transparency is a hack
that breaks every other release)
 - responding to pointer and keyboard events

The latter part means that applications that show a menu are responsible
for creating and managing the menu window and placing it at the right
coordinates—which simply does not work in a compositor and in Wayland,
respectively. The menu would also be styled by the toolkit, instead of
being styled by the compositor.

The only way to integrate "status icons" inside the shell UI is to move to
a purely descriptive format:

 - send the icon name from the theme
 - send the description of the menu over the wire

This would let the compositor display the icon using the appropriate
resolution and transparency, and it would let the compositor build and
display the menu. Sadly, this means a complete API change, which makes the
point moot: applications would need to be changed.

In any case, we do have API to achieve this—it's GMenu, and we used it for
the application menu and for integration inside Unity for the global menus;
it's also not used outside of GTK3 applications, and even then people do
like using GtkMenu so much, so the point is still moot.

The appindicator API/StatusNotifier specification comes close to this, but:

 - appindicator is a deprecated and unmaintained API, which still falls
back to the XEMBED protocol
 - it's also a hack that takes a GtkMenu, serialises it, and sends it over
the wire
 - the StatusNotifier specification is all kinds of terrible, and basically
the only implementation (appindicator and the KDE one) are normative
because, according to the letter of the StatusNotifier specification,
implementations that didn't do anything, or sent your status icons to Alpha
Centauri and waited for user input there, are perfectly conformant


> Permanently adding the extension code to the shell (which, if I've
> undesrtood properly, "moves" icons from tray to topbar) will be a dirty but
> effective solution.
>

Which would achieve nothing except, once again, shoving icons and menus
into one of the most important pieces of screen real estate we have just
because some application developers simply cannot live without their
application icons being visible at all times. If you want to do that, use
the extension. It's there for a reason.

The tray icons were designed and meant for system status notifications:
network state connectivity, volume level, battery level, IM status (when it
was a thing). They were hijacked by application developers to have panel
applets that would work across desktop environments. It was a bad idea
then, and nothing has changed in that regard.

Maybe we should maintain top-icons inside gnome-shell-extensions, so that
it doesn't fall into disrepair because its maintainers are busy or bored.


> I think, from my deep lack of knowledge about how it works, thak
> GtkStatusIcon could be modified to show icons in the topbar, so
> applications will keep calling to it without modifications, but icons would
> appear in the topbar instead of in the tray.
>
> If this is technically impossible just forget about it :-)
>

Believe me, I would *love* if people "forgot about it"; but it seems this
things have to be explained every six months, on every forum in existence,
until the end of time, so here we are.

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

Re: I believe we should reconsider our sys-tray removal

[Daniel Mustieles García via desktop-devel-list]

El lun., 25 mar. 2019 a las 12:19, Emmanuele Bassi ()
escribió:

> On Mon, 25 Mar 2019 at 10:39, Daniel Mustieles García via
> desktop-devel-list  wrote:
>
>> Can't GtkStatusIcon be modified to show icons in the top bar?
>>
>
> No.
>
> GtkStatusIcon encodes the XEMBED-based tray icon specification; this means
> that the application code is responsible for:
>
>  - sending icon data over the wire (no HiDPI, and transparency is a hack
> that breaks every other release)
>  - responding to pointer and keyboard events
>
> The latter part means that applications that show a menu are responsible
> for creating and managing the menu window and placing it at the right
> coordinates—which simply does not work in a compositor and in Wayland,
> respectively. The menu would also be styled by the toolkit, instead of
> being styled by the compositor.
>
> The only way to integrate "status icons" inside the shell UI is to move to
> a purely descriptive format:
>
>  - send the icon name from the theme
>  - send the description of the menu over the wire
>
> This would let the compositor display the icon using the appropriate
> resolution and transparency, and it would let the compositor build and
> display the menu. Sadly, this means a complete API change, which makes the
> point moot: applications would need to be changed.
>
> In any case, we do have API to achieve this—it's GMenu, and we used it for
> the application menu and for integration inside Unity for the global menus;
> it's also not used outside of GTK3 applications, and even then people do
> like using GtkMenu so much, so the point is still moot.
>
> The appindicator API/StatusNotifier specification comes close to this, but:
>
>  - appindicator is a deprecated and unmaintained API, which still falls
> back to the XEMBED protocol
>  - it's also a hack that takes a GtkMenu, serialises it, and sends it over
> the wire
>  - the StatusNotifier specification is all kinds of terrible, and
> basically the only implementation (appindicator and the KDE one) are
> normative because, according to the letter of the StatusNotifier
> specification, implementations that didn't do anything, or sent your status
> icons to Alpha Centauri and waited for user input there, are perfectly
> conformant
>
>
>> Permanently adding the extension code to the shell (which, if I've
>> undesrtood properly, "moves" icons from tray to topbar) will be a dirty but
>> effective solution.
>>
>
> Which would achieve nothing except, once again, shoving icons and menus
> into one of the most important pieces of screen real estate we have just
> because some application developers simply cannot live without their
> application icons being visible at all times. If you want to do that, use
> the extension. It's there for a reason.
>
> The tray icons were designed and meant for system status notifications:
> network state connectivity, volume level, battery level, IM status (when it
> was a thing). They were hijacked by application developers to have panel
> applets that would work across desktop environments. It was a bad idea
> then, and nothing has changed in that regard.
>
> Maybe we should maintain top-icons inside gnome-shell-extensions, so that
> it doesn't fall into disrepair because its maintainers are busy or bored.
>
>
>> I think, from my deep lack of knowledge about how it works, thak
>> GtkStatusIcon could be modified to show icons in the topbar, so
>> applications will keep calling to it without modifications, but icons would
>> appear in the topbar instead of in the tray.
>>
>> If this is technically impossible just forget about it :-)
>>
>
> Believe me, I would *love* if people "forgot about it"; but it seems this
> things have to be explained every six months, on every forum in existence,
> until the end of time, so here we are.
>

Sure, I am the first who would love to remove status icons, system-trays
and so from the desktop experience. Just considered the option of the
topbar the less bad place for them, but if it's not possible, theres
nothing to do.

Thanks for your explanation!

>
> 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

Re: Extension review

[Neil McGovern]

On Sun, 2019-03-24 at 21:43 -0400, Sriram Ramkrishna wrote:
> Talk to me and Neil.  We have a general idea on what we want done ..
> 

Just to confirm though, is this for working on the extension review
infrastructure, or actually doing reviews? That may change the answer
:)

Neil
-- 
Neil McGovern
Executive Director, The GNOME Foundation

___
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

[Daniel Mustieles García via desktop-devel-list]

Can't GtkStatusIcon be modified to show icons in the top bar? Permanently
adding the extension code to the shell (which, if I've undesrtood properly,
"moves" icons from tray to topbar) will be a dirty but effective solution.

I think, from my deep lack of knowledge about how it works, thak
GtkStatusIcon could be modified to show icons in the topbar, so
applications will keep calling to it without modifications, but icons would
appear in the topbar instead of in the tray.

If this is technically impossible just forget about it :-)

El lun., 25 mar. 2019 a las 10:28, Allan Day () escribió:

> Link Dupont  wrote:
> ...
>
>>  Is there a place
>> in the System menu (the top-right corner menu) where these application
>> icons + menus could live? The GSConnect extension adds an entry there.
>>
> ...
>
> Unfortunately, GtkStatusIcon is limited in what it allows us to do: you
> can't embed the icons in another place like this.
>
> 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: I believe we should reconsider our sys-tray removal

[Niels De Graef via desktop-devel-list]

Hey Justin,

You can do so by going to the following link: 
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

At the bottom, you will find the appropriate button to unsubscribe.

Cheers,
nielsdg

On ma, Mar 25, 2019 at 11:18 AM, Justin Joseph via desktop-devel-list 
 wrote:

Sorry, how do I unsubscribe from this list? I can't find any option.

On Mon, 25 Mar, 2019, 2:27 PM Allan Day via desktop-devel-list, 
 wrote:

Hey Britt,

Britt Yazel  wrote:


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.


As I recently wrote on GitLab [1], I'm open to re-evaluating this 
from a design perspective. However, I think we'd need a different 
implementation from GtkStatusIcon, and to my knowledge acceptable 
alternative isn't available.


I believe our goals of putting pressure on application developers 
to ditch the antiquated app-indicator model fell mostly on deaf ears


The goal was never to force app developers to do anything, and they 
can include a status indicator if they want. It's just that it won't 
be shown by default. If you haven't seen it, I wrote a lengthy 
account on my blog [2].


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.


Can we can do a better job at sign-posting which extension people 
should use?


Allan
--
[1] 
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_457856

[2] https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
 ___
 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

[Justin Joseph via desktop-devel-list]

Sorry, how do I unsubscribe from this list? I can't find any option.

On Mon, 25 Mar, 2019, 2:27 PM Allan Day via desktop-devel-list, <
desktop-devel-list@gnome.org> wrote:

> Hey Britt,
>
> Britt Yazel  wrote:
>
>>
>> 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.
>>
>
> As I recently wrote on GitLab [1], I'm open to re-evaluating this from a
> design perspective. However, I think we'd need a different implementation
> from GtkStatusIcon, and to my knowledge acceptable alternative isn't
> available.
>
>
>> I believe our goals of putting pressure on application developers to
>> ditch the antiquated app-indicator model fell mostly on deaf ears
>>
>
> The goal was never to force app developers to do anything, and they can
> include a status indicator if they want. It's just that it won't be shown
> by default. If you haven't seen it, I wrote a lengthy account on my blog
> [2].
>
>
>> 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.
>>
>
> Can we can do a better job at sign-posting which extension people should
> use?
>
> Allan
> --
> [1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_457856
> [2] https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
> ___
> 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

[Allan Day]

Link Dupont  wrote:
...

>  Is there a place
> in the System menu (the top-right corner menu) where these application
> icons + menus could live? The GSConnect extension adds an entry there.
>
...

Unfortunately, GtkStatusIcon is limited in what it allows us to do: you
can't embed the icons in another place like this.

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

[Daniel Mustieles García via desktop-devel-list]

Hi

This extension 
(Topicons) shows tray icons in the topbar so it would be possible to always
show them in the topbar instead of using the tray without touching the code
in the source applications.

Regards

El lun., 25 mar. 2019 a las 9:57, Allan Day via desktop-devel-list (<
desktop-devel-list@gnome.org>) escribió:

> Hey Britt,
>
> Britt Yazel  wrote:
>
>>
>> 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.
>>
>
> As I recently wrote on GitLab [1], I'm open to re-evaluating this from a
> design perspective. However, I think we'd need a different implementation
> from GtkStatusIcon, and to my knowledge acceptable alternative isn't
> available.
>
>
>> I believe our goals of putting pressure on application developers to
>> ditch the antiquated app-indicator model fell mostly on deaf ears
>>
>
> The goal was never to force app developers to do anything, and they can
> include a status indicator if they want. It's just that it won't be shown
> by default. If you haven't seen it, I wrote a lengthy account on my blog
> [2].
>
>
>> 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.
>>
>
> Can we can do a better job at sign-posting which extension people should
> use?
>
> Allan
> --
> [1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_457856
> [2] https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
> ___
> 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

[Allan Day via desktop-devel-list]

Hey Britt,

Britt Yazel  wrote:

>
> 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.
>

As I recently wrote on GitLab [1], I'm open to re-evaluating this from a
design perspective. However, I think we'd need a different implementation
from GtkStatusIcon, and to my knowledge acceptable alternative isn't
available.


> I believe our goals of putting pressure on application developers to ditch
> the antiquated app-indicator model fell mostly on deaf ears
>

The goal was never to force app developers to do anything, and they can
include a status indicator if they want. It's just that it won't be shown
by default. If you haven't seen it, I wrote a lengthy account on my blog
[2].


> 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.
>

Can we can do a better job at sign-posting which extension people should
use?

Allan
-- 
[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1014#note_457856
[2] https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
___
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

[Bastien Nocera]

On Sat, 2019-03-23 at 11:06 -0700, Britt Yazel wrote:
> 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.
> 

> 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.

The status icons were removed for technical and design reasons. The
design reasons haven't changed:
https://wiki.gnome.org/Initiatives/StatusIconMigration

And the technical reasons haven't either, as those status icons are X11
only and will stop working as more more apps are ported to Wayland.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list