GNOME Bugzilla – Bug 662687
"tray" button issues
Last modified: 2013-02-14 16:35:38 UTC
The tray button in the on screen keyboard has a few issues. * It looks a bit funny in lowercase to me * It doesn't hide the tray when a bubble is up * It doesn't show the state
See bug 659744.
* It doesn't really work with translations (e.g. in French tray is « tiroir de messagerie » which is waaaaaay too long to be displayed correctly)
*** Bug 659744 has been marked as a duplicate of this bug. ***
Another issue: With multiple monitors, we need the osk to always appear on the monitor where the keyboard focus is. That may not be the monitor with the message tray. If the osk is on a non-primary monitor, the button does not make sense.
the 'pop up on the right monitor' issue mentioned in comment #4 is fixed.
would be nice to make some progress here - this seems like an easy fix. Here's a few proposals for what to use instead of the text: ✉ U+2709 ENVELOPE ☀ U+2600 BLACK SUN WITH RAYS ✆ U+2706 TELEPHONE LOCATION SIGN ❦ U+2766 FLORAL HEART
I wonder whether we really need to show the tray in this entirely different manner or whether we need to use a keyboard in the tray at all...
(In reply to comment #7) > I wonder whether we really [...] to use a keyboard in the tray at all... If we are OK with having chat notifications not work on touch I guess not.
Yeah I'd really like us to have the Chat app for that case. I don't think typing in the message tray is going to be that useful on a touch device...
so, what is the proposal, then ? just remove the tray button ?
I think that would have to be done in concert with an updated keyboard design that doesn't overlay. Perhaps we can use the same mechanism in the shell to display the OSK. Think of it as putting the keyboard in the tray... Need to mock this up probably.
Not 3.8 material then? Removing the button is perfectly doable til next week, implementing a completely new (and non-existent?) design for the OSK is not ...
Created attachment 235817 [details] [review] messageTray: Always hide while the OSK is up The message tray currently operates in three modes: in the overview, normal, and while the on-screen keyboard is up. The last case is particularly odd, and exclusively used for chat-notifications. As users can still use the Chat application directly on touch-only devices, the additional mode isn't really justified, so remove it.
Created attachment 235818 [details] [review] keyboard: Remove 'tray' button Now that message tray and keyboard are never shown together, the odd 'tray' button is pointless, kill it.
Created attachment 235819 [details] [review] layout: Remove obsolete message tray <=> OSK interaction code Message tray and on-screen keyboard are now exclusive, so remove all code that shuffles boxes around to make it possible to show both at the same time.
There was some discussion on #gnome-design regarding a short-term approach, which basically consists in removing the tray button altogether.
Review of attachment 235817 [details] [review]: ::: js/ui/messageTray.js @@ +2244,3 @@ this._desktopCloneState == State.SHOWN); let desktopCloneShouldBeVisible = (trayShouldBeVisible && + !this._overviewVisible); This can be on one line now. @@ +2249,3 @@ this._showDesktopClone(); } else if (desktopCloneIsVisible && !desktopCloneShouldBeVisible) { + this._hideDesktopClone (false); We always pass "false" here. Remove the parameter altogether (and fix the style nit)
Review of attachment 235818 [details] [review]: OK.
Review of attachment 235819 [details] [review]: OK.
Attachment 235817 [details] pushed as a534a6b - messageTray: Always hide while the OSK is up Attachment 235818 [details] pushed as a21e76c - keyboard: Remove 'tray' button Attachment 235819 [details] pushed as 2d9cf19 - layout: Remove obsolete message tray <=> OSK interaction code (In reply to comment #17) > This can be on one line now. It could, but I still try to not exceed the splinter/80-chars-terminal limit by too much (even though messageTray.js is pretty hopeless with regard to excessive line length ...) > @@ +2249,3 @@ > We always pass "false" here. Remove the parameter altogether Yeah, fixed.