GNOME Bugzilla – Bug 746787
new tray tab hides a whole character out of gnome-terminal
Last modified: 2015-05-20 15:04:14 UTC
When using gnome terminal at full/half-left screen, the new tray hides a whole character horizontally for at least two rows on my typical font size. Same happens for Vim where I'm not even sure if I'm searching or in command mode (:,/). I know we've crossed the rubicon wrt the release but I find that we're going to piss off quite a lot of people if we don't find a solution.
Created attachment 300327 [details] example of the problem
Here's my suggestion: https://bugzilla.gnome.org/show_bug.cgi?id=746025#c13
*** Bug 746952 has been marked as a duplicate of this bug. ***
Agreed with Clément Guérin, this extension is nice. But i think what systray icons can be hidden in the menu of time on the panel, where notifications hide. Above notifications.
(In reply to Alberto Ruiz from comment #0) > When using gnome terminal at full/half-left screen, the new tray hides a > whole character horizontally for at least two rows on my typical font size. What font settings are you using? What is the resolution of your display?
(In reply to Egor Zaharov from comment #4) > Agreed with Clément Guérin, this extension is nice. But i think what systray > icons can be hidden in the menu of time on the panel, where notifications > hide. Above notifications. We can't do that, due to limitations in X11.
"Liberation Mono Regular 9" and 1960x1200 & 1600x900
I must note that using the system's default monospaced font I still get the same problem.
(In reply to Alberto Ruiz from comment #8) > I must note that using the system's default monospaced font I still get the > same problem. Hrm, OK. The obvious thing to do as a short term fix would be to reduce the size and visibility of the tray when it is retracted. This would need to be done in conjunction with a fix to bug 746025. Any thoughts, Jakub?
Why just not merge https://extensions.gnome.org/extension/495/topicons/ and maintain it while needed (until no application use "legacy tray") You will solve multiple issues, tray icons should be always visible, because some applications can just have simple notifications like changing systray icon to show some event, but not send regular system notification and take your attention, but you can see that something has changed by looking at the icon in tray. (I use this for hexchat for example, some type of notifications are set like this, more important send regular notifications which pop-up). Or they can show different icon for different status like IM clients, away, busy ..., so user don't need to click to open tray to see what is his IM client status ..., also any action on tray icon will take less steps.
(In reply to (bitlord) from comment #10) > Why just not merge https://extensions.gnome.org/extension/495/topicons/ and > maintain it while needed (until no application use "legacy tray") ... Please file a separate bug if you want to discuss that.
(In reply to Allan Day from comment #9) > e obvious thing to do as a short term fix would be to reduce the size and > visibility of the tray when it is retracted. This would need to be done in > conjunction with a fix to bug 746025. > > Any thoughts, Jakub? Sure. 3px wide should do it.
(In reply to Allan Day from comment #11) > (In reply to (bitlord) from comment #10) > > Why just not merge https://extensions.gnome.org/extension/495/topicons/ and > > maintain it while needed (until no application use "legacy tray") > ... > > Please file a separate bug if you want to discuss that. No I don't want to file 50 bugs for same thing, legacy tray never worked in >=gnome3, and every time you redo it, and it is always broken, current design is not fixable, same as any other before it, there is no way to fix it. I understand that developers and designers consider it a legacy ugly hack, but other application developers used that hack, and people liked it, and people still use it. (I for example want some applications running, but "hidden", don't want them in atl+tab ... when I don't need them) Just leave it as it was before, simple, accessible and not interfering with things, when no application use it, then just remove it, until then you need it. How many cycles (release cycles) "you" are trying to fix this? Do we need to wait another cycle to try new design? What if new design is broken again? Just count how many stable releases + 6months have been since 3.0? When we will have usable desktop? In 15 years? I don't want to spend my life filing bugs about same things every cycle, and live with broken desktop 6 months, and again and again, ignoring it until you redesing it again. I don't care how many hours developers and designers spent on the project, but I see most of it as a wasted time, it is yours time, do whatever you want. People have solution for this, it is maybe not revolutionary, but it is simple, works and everyone understands it, you just don't want to take it :( Please ban my bugzilla account, thanks!
Please try to stay constructive, ok ?
I filed a new bug to discuss it: https://bugzilla.gnome.org/show_bug.cgi?id=747034 bitlord, although I feel the same way I still think it's not a good idea to rant at developers. Let's fix this in a civilized manner.
(In reply to (bitlord) from comment #13) > (In reply to Allan Day from comment #11) > > (In reply to (bitlord) from comment #10) > > > Why just not merge https://extensions.gnome.org/extension/495/topicons/ and > > > maintain it while needed (until no application use "legacy tray") > > ... > > > > Please file a separate bug if you want to discuss that. > > No I don't want to file 50 bugs for same thing, legacy tray never worked in > >=gnome3, and every time you redo it, and it is always broken, current > design is not fixable, same as any other before it, there is no way to fix > it. I filed this bug and I am telling you, this is a different topic. Fixing problems the current design is not the same as proposing a different one. 3.16 is out and your proposal only makes sense for 3.18 now (if it makes sense at all). I think you want to discuss your views on #747034 Thank you very much.
(In reply to Alberto Ruiz from comment #16) > (In reply to (bitlord) from comment #13) > > (In reply to Allan Day from comment #11) > > > (In reply to (bitlord) from comment #10) > > > > Why just not merge https://extensions.gnome.org/extension/495/topicons/ and > > > > maintain it while needed (until no application use "legacy tray") > > > ... > > > > > > Please file a separate bug if you want to discuss that. > > > > No I don't want to file 50 bugs for same thing, legacy tray never worked in > > >=gnome3, and every time you redo it, and it is always broken, current > > design is not fixable, same as any other before it, there is no way to fix > > it. > > I filed this bug and I am telling you, this is a different topic. Fixing > problems the current design is not the same as proposing a different one. > 3.16 is out and your proposal only makes sense for 3.18 now (if it makes > sense at all). > > I think you want to discuss your views on #747034 > > Thank you very much. I was initially here for the exact same problem you reported, but <rant> ... </rant>, because I don't see this as fixable I wanted to suggest something that worked before and all people understand, and don't get in a way. And this lasts so long that forcing changes to new releases only is bad. https://bugzilla.gnome.org/show_bug.cgi?id=745162#c9 https://bugzilla.gnome.org/show_bug.cgi?id=745162#c10 https://bugzilla.gnome.org/show_bug.cgi?id=745162#c11 I'm not interested anymore in this, and in gnome in general, just wanted to tell you that I didn't come here to troll on your bug report.
*** Bug 747313 has been marked as a duplicate of this bug. ***
*** Bug 747828 has been marked as a duplicate of this bug. ***
As an additional problem, the lower left corner seems to be considered a "hot corner" that blocks the mouse even when the tray is not displayed.
An obvious fix for this is to provide an option that hides the tray altogether. It's a completely useless feature for the vast majority of users. Disabled by default is a great solution for non-features.
Created attachment 301563 [details] [review] legacyTray: Decrease visible width when concealed Now that the tray is shown temporarily when a tray icon appears, we can decrease its visible width when concealed to interfere less with window content without hurting discoverability.
(In reply to Jan Alexander Steffens (heftig) from comment #20) > As an additional problem, the lower left corner seems to be considered a > "hot corner" that blocks the mouse even when the tray is not displayed. That's a separate issue, namely bug 746579.
Review of attachment 301563 [details] [review]: Didn't test it but "<fmuellner> but they pass the vim test" sounds good enough to me ;) Code looks fine.
Attachment 301563 [details] pushed as da3e5f9 - legacyTray: Decrease visible width when concealed
*** Bug 747883 has been marked as a duplicate of this bug. ***
If the width is decreased further then it'll appear as a display artifact even more so than it already does. It's a poor design that just serves as a distraction. Removing it is the only sensible thing to do. Please do the right thing.
(In reply to Malthe Borch from comment #27) > If the width is decreased further then it'll appear as a display artifact > even more so than it already does. It's a poor design that just serves as a > distraction. Removing it is the only sensible thing to do. Please do the > right thing. I'm sorry, but there's nothing in this comment that is remotely useful. Please cut the emotional appeals, and stick to the practical issues. What are you proposing, exactly? Bear in mind that UI freeze is in effect for the 3.16.x series, so only minor changes are possible at this stage.
Add a setting that toggles its visibility and set the default visibility to hidden. Then users that want to have the tray shown can easily enable it.
(In reply to Malthe Borch from comment #29) > Add a setting that toggles its visibility and set the default visibility to > hidden. Then users that want to have the tray shown can easily enable it. How would a user know that the setting exists? What happens when they install dropbox and there's no way to interact with it? Where would the setting go?
Can't they just open the application? But okay, that's a fair consideration. What's more important than having it hidden by default is simply to be able to hide it in the first place. The setting for that could go into the gnome tweak tool perhaps.
(In reply to Malthe Borch from comment #31) > Can't they just open the application? Dropbox doesn't have a window. Neither do other status icon apps, like Sparkleshare or Google Music Manager. Other apps rely on a status icon to quit the app (such as Skype or Steam) - without the status icon, there is no way to know that it is running in the background. > But okay, that's a fair consideration. What's more important than having it > hidden by default is simply to be able to hide it in the first place. The > setting for that could go into the gnome tweak tool perhaps. But then, most users wouldn't know about the setting.
Then perhaps it can be moved up in the top bar? Either left or right. Anything to not have it overlap normal windows. Or alternatively, must it take up any space at all? Maybe it can activated just be moving the mouse to the lower left corner. I don't mean to be emotional about this, but I think the idea of having a recangular little box that looks like a terminal cursor overlap the location that often inhabits a terminal cursor is just not working out. Let's defrost the UI freeze just a little bit and move this tray up where it belongs: in the top bar somewhere.
(In reply to Malthe Borch from comment #33) > Let's defrost the UI freeze just a little bit and move this tray up where it > belongs: in the top bar somewhere. Violate GNOME release policy just because the new system tray covers 3 pixels from bottom left corner, it is so *right*. Why you just don't install TopIcons extension for some time and let GNOME developers think about what system tray should be in the future 3.18 release.
(In reply to Malthe Borch from comment #33) > Then perhaps it can be moved up in the top bar? Either left or right. > Anything to not have it overlap normal windows. Moving to the top bar seems like too big a change now that we are in UI freeze. > Or alternatively, must it take up any space at all? Maybe it can activated > just be moving the mouse to the lower left corner. That's a possibility.
Since this is marked as "Resolved Fixed", is it being tracked somewhere else, post-freeze? I'd like to suggest to consider moving these icons inside the new combined calendar/world clocks/notifications panel that pops up when clicking the date.
(In reply to Pavlos Touboulidis from comment #36) > Since this is marked as "Resolved Fixed", is it being tracked somewhere > else, post-freeze? There's bug 747034 (see comment #15). > I'd like to suggest to consider moving these icons inside the new combined > calendar/world clocks/notifications panel that pops up when clicking the > date. ... which has already been suggested in comment #4, and the answer is still the same as in comment #6: that's not possible (unless we are OK with breaking the icons' right-click menus).
Post fix comment: What about moving it to the right bottom corner? I didn't read all the comments :-), so I don't know what is the actual solution. It still persist in gnome-shell 3.16.2, what version contains the fix?
(In reply to Tomas Rohovsky from comment #38) > Post fix comment: What about moving it to the right bottom corner? That was what the original mockups used, but the design was changed because it would interfere with more applications (for instance all maximized windows with scrolled content). > It still persist in gnome-shell 3.16.2, what version contains the fix? 3.16.1. Note that there was no radical change that eradicates any overlap, we simply reduced the visible width of the hidden tray significantly - it's now just 3 pixels, which no longer interferes with the vim status lines of a maximized terminal (at least using gnome-terminal and default font settings).
Ok, I see. Another idea: what about to hide it completely and show if you hover to the left(/right) bottom corner? Similarly like 'Activities' works. 3px are no big deal, but 0px is IMO better. I noticed a small bug. If you hover to the left bottom corner pixel the rolled try will hop.