After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748622 - Hot corner of the status bar icons (legacy) does not work properly.
Hot corner of the status bar icons (legacy) does not work properly.
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: message-tray
3.16.x
Other Linux
: Normal enhancement
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2015-04-29 08:42 UTC by Bastián Díaz
Modified: 2017-08-12 22:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastián Díaz 2015-04-29 08:42:53 UTC
The new style to display status icons is promising, however, to expand button is not very comfortable and intuitive. It would be a good improvement to show and hide the status bar icons through a hot corner in addition to a keyboard shortcut.

If you lay your cursor over the button to expand the status icon bar (near the corner), it begins to shiver and move quickly, which prevents work with a mouse click.

Thanks
Comment 1 André Klapper 2015-04-29 11:16:54 UTC
(In reply to Bastián Díaz from comment #0)
> It would be a good improvement to show and hide the status bar icons 
> through a hot corner in addition to a keyboard shortcut.

Why? It would be a better improvement to kill status bar icons instead.
Comment 2 Allan Day 2015-04-29 11:38:33 UTC
(In reply to Bastián Díaz from comment #0)
> The new style to display status icons is promising, however, to expand
> button is not very comfortable and intuitive. 

Can you expand on that? Is this just due to the jitter issue, or something else?

> It would be a good improvement
> to show and hide the status bar icons through a hot corner in addition to a
> keyboard shortcut.

It kind of is a hot corner, in the sense that it partially reveals on hover...

> If you lay your cursor over the button to expand the status icon bar (near
> the corner), it begins to shiver and move quickly, which prevents work with
> a mouse click.

That's a separate bug that can be fixed within the current design.
Comment 3 Florian Müllner 2015-04-29 11:49:28 UTC
(In reply to Allan Day from comment #2)
> (In reply to Bastián Díaz from comment #0)
> > It would be a good improvement
> > to show and hide the status bar icons through a hot corner in addition to a
> > keyboard shortcut.
> 
> It kind of is a hot corner, in the sense that it partially reveals on
> hover...

It also uses a pressure barrier, so with enough intent the tray will open without the extra click.



> > If you lay your cursor over the button to expand the status icon bar (near
> > the corner), it begins to shiver and move quickly, which prevents work with
> > a mouse click.
> 
> That's a separate bug that can be fixed within the current design.

Bug 747957, to be precise ...
Comment 4 Bastián Díaz 2015-04-29 16:46:35 UTC
(In reply to André Klapper from comment #1)
> (In reply to Bastián Díaz from comment #0)
> > It would be a good improvement to show and hide the status bar icons 
> > through a hot corner in addition to a keyboard shortcut.
> 
> Why? It would be a better improvement to kill status bar icons instead.

I understand that for Gnome-shell design, the status icons have no reason to be, but unfortunately there are applications that rely on this functionality or are cross-platform applications that also run on systems with support for status icons. Moreover there are also older applications that are useful but hardly will be updated to match the new system.

I've seen a single attempt to adapt an application to the shell and through an extension (Skype).
Comment 5 Bastián Díaz 2015-04-29 16:58:22 UTC
(In reply to Allan Day from comment #2)
> (In reply to Bastián Díaz from comment #0)
> > The new style to display status icons is promising, however, to expand
> > button is not very comfortable and intuitive. 
> 
> Can you expand on that? Is this just due to the jitter issue, or something
> else?
> 

The following bug is very close to my dissatisfaction with the functioning of the bar status icons. Bug 747957

> > It would be a good improvement
> > to show and hide the status bar icons through a hot corner in addition to a
> > keyboard shortcut.
> 
> It kind of is a hot corner, in the sense that it partially reveals on
> hover...
> 

Button to reveal itself, but to show the bar require additional click.It would be much easier to show the bar with a similar gesture to open the activity menu.

Moreover, I discovered that the keyboard shortcut Control+Alt+Tab , works with bar status icons, but I can not take any action with icons (dropbox, megasync, trasmageddon, etc) from the keyboard (that's a new bug?)

> > If you lay your cursor over the button to expand the status icon bar (near
> > the corner), it begins to shiver and move quickly, which prevents work with
> > a mouse click.
> 
> That's a separate bug that can be fixed within the current design.

This bug has already been reported.

Thanks
Comment 6 Bastián Díaz 2015-04-29 17:02:02 UTC
(In reply to Florian Müllner from comment #3)
> 
> It also uses a pressure barrier, so with enough intent the tray will open
> without the extra click.
> 

The idea is that work just the activities menu.

> 
 > 
> > That's a separate bug that can be fixed within the current design.
> 
> Bug 747957, to be precise ...

That's exactly.

Thanks
Comment 7 l300lvl 2015-04-30 01:19:34 UTC
(In reply to Bastián Díaz from comment #6)
> (In reply to Florian Müllner from comment #3)
> > 
> > It also uses a pressure barrier, so with enough intent the tray will open
> > without the extra click.
> > 
> 
> The idea is that work just the activities menu.
> 

It works the same. Just "push" more with your mouse or touchpad, it will open without clicking.

> > 
>  > 
> > > That's a separate bug that can be fixed within the current design.
> > 
> > Bug 747957, to be precise ...
> 
> That's exactly.
> 
> Thanks
Comment 8 l300lvl 2015-04-30 01:23:39 UTC
(In reply to Bastián Díaz from comment #5)
> (In reply to Allan Day from comment #2)
> > (In reply to Bastián Díaz from comment #0)
> > > The new style to display status icons is promising, however, to expand
> > > button is not very comfortable and intuitive. 
> > 
> > Can you expand on that? Is this just due to the jitter issue, or something
> > else?
> > 
> 
> The following bug is very close to my dissatisfaction with the functioning
> of the bar status icons. Bug 747957
> 
> > > It would be a good improvement
> > > to show and hide the status bar icons through a hot corner in addition to a
> > > keyboard shortcut.
> > 
> > It kind of is a hot corner, in the sense that it partially reveals on
> > hover...
> > 
> 
> Button to reveal itself, but to show the bar require additional click.It
> would be much easier to show the bar with a similar gesture to open the
> activity menu.
> 
> Moreover, I discovered that the keyboard shortcut Control+Alt+Tab , works
> with bar status icons, but I can not take any action with icons (dropbox,
> megasync, trasmageddon, etc) from the keyboard (that's a new bug?)
> 

a) Once you ctrl+alt+tab the Enter/Return key will open the app, and

b) if you just left/right arrow to the application you can use the Menu key aka xf86menu to open the applications right click menu, if it has one, then you can control it with up/down arrow.


> > > If you lay your cursor over the button to expand the status icon bar (near
> > > the corner), it begins to shiver and move quickly, which prevents work with
> > > a mouse click.
> > 
> > That's a separate bug that can be fixed within the current design.
> 
> This bug has already been reported.
> 
> Thanks
Comment 9 Bastián Díaz 2015-04-30 05:37:42 UTC
(In reply to l300lvl from comment #7)
> (In reply to Bastián Díaz from comment #6)
> > (In reply to Florian Müllner from comment #3)
> > > 
> > > It also uses a pressure barrier, so with enough intent the tray will open
> > > without the extra click.
> > > 
> > 
> > The idea is that work just the activities menu.
> > 
> 
> It works the same. Just "push" more with your mouse or touchpad, it will
> open without clicking.
> 

It is not the same. Also, if you do not mention it, I did not realize that I can do that, I think a very forceful action. At first glance, it seems to need two things drag, but only just a very long (unnatural) movement (compared with activities menu)

On the other hand I can not hide the status bar icons with the same action (same gesture).

Since the hot corner exists, should I change the title of the bug report?

Thanks
Comment 10 Bastián Díaz 2015-04-30 05:43:09 UTC
(In reply to l300lvl from comment #8)

> > 
> > Moreover, I discovered that the keyboard shortcut Control+Alt+Tab , works
> > with bar status icons, but I can not take any action with icons (dropbox,
> > megasync, trasmageddon, etc) from the keyboard (that's a new bug?)
> > 
> 
> a) Once you ctrl+alt+tab the Enter/Return key will open the app, and
> 
> b) if you just left/right arrow to the application you can use the Menu key
> aka xf86menu to open the applications right click menu, if it has one, then
> you can control it with up/down arrow.
> 

If I tried that. In my laptop I have a hardware button to open a context menu, but it does not work in most applications.

Really the only application that works is trasmission (tested with: dropbox, megasync, Antimicro, skype and libreoffice).Apparently it depends on the application.

Thanks
Comment 11 Florian Müllner 2015-04-30 08:15:30 UTC
(In reply to Bastián Díaz from comment #10)
> Really the only application that works is trasmission (tested with: dropbox,
> megasync, Antimicro, skype and libreoffice).Apparently it depends on the
> application.

Exactly. We pass on all events to the application, but whether it handles key events in addition to pointer events is completely up to the application. There's nothing we can do there, legacy status icons are simply crappy like this.
Comment 12 l300lvl 2015-04-30 11:43:57 UTC
(In reply to Bastián Díaz from comment #10)
> (In reply to l300lvl from comment #8)
> 
> > > 
> > > Moreover, I discovered that the keyboard shortcut Control+Alt+Tab , works
> > > with bar status icons, but I can not take any action with icons (dropbox,
> > > megasync, trasmageddon, etc) from the keyboard (that's a new bug?)
> > > 
> > 
> > a) Once you ctrl+alt+tab the Enter/Return key will open the app, and
> > 
> > b) if you just left/right arrow to the application you can use the Menu key
> > aka xf86menu to open the applications right click menu, if it has one, then
> > you can control it with up/down arrow.
> > 
> 
> If I tried that. In my laptop I have a hardware button to open a context
> menu, but it does not work in most applications.
> 
> Really the only application that works is trasmission (tested with: dropbox,
> megasync, Antimicro, skype and libreoffice).Apparently it depends on the
> application.
> 
> Thanks

Apologies. I expected this was implemented in a way that all apps *would* pick up on that key event.

Do they not listen to key events in other de's like Mate, XFCE, etc? I never tried, but if they do not, it isn't a gnome bug as Florian said. 

All apps should be doing this somewhere, or they are all buggy in this implementation, and probably have been all along in which I would totally point out somewhere to being a perfect use case example of WHY status icons should _go bye bye_
Comment 13 Florian Müllner 2015-04-30 12:16:49 UTC
(In reply to l300lvl from comment #12)
> Apologies. I expected this was implemented in a way that all apps *would*
> pick up on that key event.

No, that's not how status icons work. Even the behavior of showing the window on left-click and popping up a menu on right-click is just a convention, it is entirely up to the application (and to some extent the toolkit it uses) what it does in response to events.
Most GTK+ apps should use the GtkStatusIcon::activate/::popup-menu signals instead of the "raw" events, which behave correctly with both pointer and key events, while QT apps generally seem to not handle key events at all (at least the ones I encountered in testing). For apps that don't use either toolkit, it's safe to assume that not handling key events is the more likely behavior.
 

> Do they not listen to key events in other de's like Mate, XFCE, etc?

Yes, unless those do horrible hacks like synthesizing pointer events in response to certain key events - I don't think anyone does that, but the I haven't tried.
Comment 14 Florian Müllner 2015-04-30 12:19:14 UTC
(In reply to Bastián Díaz from comment #9)
> Since the hot corner exists, should I change the title of the bug report?

Yes please - I have to admit that at this point, I'm not sure what the bug is about.
Comment 15 Bastián Díaz 2015-05-01 03:33:00 UTC
(In reply to Florian Müllner from comment #14)
> (In reply to Bastián Díaz from comment #9)
> > Since the hot corner exists, should I change the title of the bug report?
> 
> Yes please - I have to admit that at this point, I'm not sure what the bug
> is about.

Update bug report:

Description of problem:
Hot corner of the status bar icons, works forcefully and very different from that implemented in the "menu of activities." This only opens the bar and need a long movement to be opened.

Version-Release number of selected component:
Fedora 22 Rawhide
Gnome 3.16.1

How reproducible:
Always

Steps to Reproduce:
1. Open an application that uses a legacy status bar icons (eg. Dropbox or Transmission)
2.Use the cursor to open the status bar icons across the bottom left hot corner. (Repeat to try to close)

Current results:
The hot corner only works to show the status bar icons, the same action is not permitted to hide.
The gesture is forced (need long movement, performing more pressure), and gives the feeling of needing two moves to show the status bar icons: a) show button (arrow) b) show bar.
Usability is very different from the hot corner "Activity menu" (less fluid).

Expected results:
The status bar icons shown / hidden through the use of the hot corner. (Similar usability to "Activity menu").

Additional info:
Related Bug: Bug 747 957
It gives the impression Image this strange movement on the button to expand the bar, reduces the usability of the hot corner.
Comment 16 Derek Moore 2015-10-13 15:06:47 UTC
Legacy Tray Handle obscures text in fullscreen terminal windows.

Legacy Tray should be in the top bar somewhere.

Stop hiding it. All of your ideas for hiding are not usable.
Comment 17 Bastián Díaz 2015-10-17 16:54:54 UTC
(In reply to Derek Moore from comment #16)
> Legacy Tray Handle obscures text in fullscreen terminal windows.

Hi, I guess like me, remains visible "panel status icons", however, at any time you can hide it.

> Legacy Tray should be in the top bar somewhere.

My personal experience, reading and comments from users/developers convince me that the system status icons should disappear. There is not even a common operation for this type of property and it seems that each application has its own implementation.

Unfortunately some older applications or platform applications [...] implement it and should do something about it.

I think the solution designers is the most successful so far.

Maybe I could add a setting in dconf/tweak-tool to move the system status icons to the bottom right corner.

> Stop hiding it. All of your ideas for hiding are not usable.

I disagree.
For these cases, you can always use an extension, see: https://extensions.gnome.org/extension/495/topicons/

Cheers
Comment 18 Bastián Díaz 2016-03-30 03:59:27 UTC
Hello, I think if you believe convenient, you can close this bug report. The functioning in gnome 3.20 is much better and to add function to close the icon legacy bar through a hot corner it can be written in a new bug report.

Thank you.
Comment 19 André Klapper 2017-08-12 22:11:39 UTC
Closing this ticket as WONTFIX as the legacy tray (introduced three years ago in 3.16) was meant as a temporary solution to encourage maintainers to move away from the concept of status icons and will not be included anymore in 3.26.

Users can install one of the existing extensions, either based on the still available XEmbed support or implementing the DBus-based StatusNotifier spec.