Or:
- allow date and time to move to the left as needed
(might be bit crowded, though ;-)

What is that keyboard looking one?

We could start with reducing the spacing between icons when space limited. I'd like to see at least twice the space between date and leftmost icon than we have between icons.

(In reply to comment #2)
> What is that keyboard looking one?

Input selector (ibus).

(In reply to comment #2)
> What is that keyboard looking one?
> 
> We could start with reducing the spacing between icons when space limited. I'd
> like to see at least twice the space between date and leftmost icon than we
> have between icons.

We still need to have wide enough targets for us to be able to click the menu items though. As long as the top edge of the panel is clickable, it should still be big enough though.

Created attachment 189560 [details] [review]
panel: remove legacy tray icons

Simplify the panel layout by removing the legacy trayicon container
and exiling the remaining trayicons to the message tray. Any remaining
trayicon icons that are supposed to be in the panel will need to be
ported to status icons for 3.2.

Created attachment 189561 [details] [review]
panel: allow padding around panel buttons to shrink

for narrow screens (eg, portrait orientation)

The big problem is that the name on the user menu gets ellipsized, which looks really bad. Should we just drop the name part (keeping only the icon) when there's not enough room? Or switching from name to username would save some space... Or alternatively, we could just not let it ellipsize, and force everything else to shrink together even more.

At some point we might want to give up on centering the date as well, since there's a lot more extra space on the left than on the right. (We could just have it appear immediately to the left of the status icons if the status icons would otherwise crash into it.)

Hiding the text part of the user menu when it ellipsizes probably makes sense.

(In reply to comment #7)
> The big problem is that the name on the user menu gets ellipsized, which looks
> really bad. Should we just drop the name part (keeping only the icon) when
> there's not enough room?

(In reply to comment #8)
> Hiding the text part of the user menu when it ellipsizes probably makes sense.

cc:ing gnome-user-docs-maint as a heads up / chance to object, since the user menu is currently referred to as just "your name on the top bar" in the docs.

I've filed docs bug #653487. We'll discuss it. Thanks for the heads-up.

Would it be possible to fall back to just the first word in the user name, rather than ellipsizing the full string?

Dropping the day from the panel might also help. It would save a bit of space and could also help ground the layout by having the clock indicate the middle of the panel.

(In reply to comment #11)
> Would it be possible to fall back to just the first word in the user name,
> rather than ellipsizing the full string?

It's technically possible, but any attempt to automatically abbreviate people's names will fail for some names. (Eg, Chinese given names are generally two words long.)

*** Bug 655349 has been marked as a duplicate of this bug. ***

Just to add my suggestions from the duplicate bug:

1.  Do something on the lines of how windows does it.   Have the icons which aren't used much, hide when space is needed into a drop down menu or bubble.

2.  reduce the space between the icons when space is cramped.

Review of attachment 189560 [details] [review]:

This is going to make jhbuild-ing hell for me unless I can figure out why I get a legacy NM applet, but go for it :)

::: js/ui/notificationDaemon.js
@@ +99,3 @@
         this._busProxy = new Bus();
 
+        this._statusIconDispatcher = new StatusIconDispatcher.StatusIconDispatcher(Main.messageTray.actor);

Since StatusIconDispatcher is now an implementation detail, and it's an incredibly short file, just move it in here.

Review of attachment 189561 [details] [review]:

I may be crazy, but I think that doing this across the entire status menu would be a better approach than trying to do it per-button, where the spacing between the menu items can shrink to 0.

Review of attachment 189561 [details] [review]:

I may be crazy, but I think that doing this across the entire status menu would be a better approach than trying to do it per-button, where the spacing between the menu items can shrink to 0.

Comment on attachment 189560 [details] [review]
panel: remove legacy tray icons

ibus didn't get ported, so we can't remove the legacy icons yet

Well, ibus patches are available. They are just not getting picked up :-(

Created attachment 195903 [details] [review]
panel: fix part of the panel-corner-highlighting hack

The underline highlights on the panel menu items normally have a 100ms
transition between highlighted and unhighlighted, but the panel corner
graphics can't do that, so we hacked the Activities button and user
menu to have no transition. But in gdm mode, the user menu isn't the
rightmost item any more. Fix this by modifying the CSS from the code
instead.

Created attachment 195904 [details] [review]
userMenu: belatedly rename CSS to match the new filename

Created attachment 195905 [details] [review]
panel: remove legacyBox, mix legacy icons in with regular

Legacy trayicons are mostly gone, so remove some of the special-casing
for them to simplify things.

Also, fix panel.addToStatusArea() to interpret its "position" relative
to tray_icon_order, not relative to the existing contents of
statusBox, so that the order that extension icons appear in does not
depend on the order they are loaded in.

Created attachment 195906 [details] [review]
panel: merge statusBox into rightBox

Simplify the layout in rightBox by getting rid of statusBox, and just
putting everything into rightBox directly.

Simplify the handling of the user menu by adding it like it was a
status icon rather than special-casing it. Rename the "tray_icon"
variables to "status_area" to reflect this better.

Created attachment 195907 [details] [review]
panel: allow padding around panel buttons to shrink

for narrow screens (eg, portrait orientation)

===

This changes the user menu title to be Pango.EllipsizeMode.NONE.
But truncating it doesn't look any better than ellipsizing it...

I'm assuming it's too late to remove the name and use just the icon at
this point? (UI freeze, documentation issues, etc)

Another possibility: switch to username instead of name?

Review of attachment 195903 [details] [review]:

This patch looks fine and it fixes a visual glitch  in the login screen, so I don't see why it shouldn't go in.  I'm not even sure it's the kind of thing subject to UI freeze since it's only slightly changing the timing of an intermediate state of a minor, localized animation.   I just asked on #release-team for confirmation and the response was "our release notes only contain screenshots, not videos".

More generally, though, I don't like the (pre-existing) special treatment. I struggle to see a difference between a transition-duration: 0 and transition-duration: 100 for these items (except for the corner item).  And, really, if there is supposed to be a noticeable difference we wouldn't want inconsistency from one item to the next, just because one item is in the corner would we?  So, if there is no practical, discernable difference then the transition doesn't matter, and if there is a discernable difference then we shouldn't have the inconsistency. As a test, i changed the transition from 100 to 3000.  That revealed the transition feature isn't working 100%.  Sometimes I would get a 3 second fade, but just as often I would get 3 seconds of inactivity followed by it jumping to the end state.  So personally, I think we should either fix the various issues or drop the transition for all the panel items (with a preference for the latter atm).  In either case we wouldn't need the special treatment.

(In reply to comment #25)
> Review of attachment 195903 [details] [review]:

...

> That revealed the transition feature isn't working 100%.  Sometimes I
> would get a 3 second fade, but just as often I would get 3 seconds of
> inactivity followed by it jumping to the end state.

Part of this was a Cogl bug, but not everything was fixed by the Cogl patch there. See #658092

Review of attachment 195904 [details] [review]:

Clearly, makes sense.  You might consider renaming the actor name in the same commit, too.  Maybe not worth it, though, since you drop it in later commits anyway.

This may have implications for third party themes, but if it does, they'll adapt I'm sure.

Review of attachment 195905 [details] [review]:

probably okay.  changes the spacing somewhat (for the better) i believe.

::: js/ui/panel.js
@@ +1066,3 @@
+        for (i = children.length - 1; i >= 0; i--) {
+            let rolePosition = children[i]._rolePosition;
+            if (!rolePosition || position > rolePosition) {

I don't think this !rolePosition is right.  Afaict, rolePosition will never be undefined (indexOf returns -1 for "not found") and this means icons that don't have a defined position will always get put after the icon in defined position 0, right?

Review of attachment 195906 [details] [review]:

This patch misses one occurance of tray_icon so it shows an exception when trying it.

::: js/ui/panel.js
@@ -957,3 @@
-            this._userMenu = new UserMenu.UserMenuButton();
-            this._userMenu.actor.name = 'panelStatus';
-            this._rightBox.add(this._userMenu.actor);

I like that you were able to get rid of this global.session_type check. he less ofthose that we have peppered through the code, the better.

Review of attachment 195907 [details] [review]:

This patch makes the app menu icon spill past the panel and makes the keyboard status icon radial gradient not meet its highlight line.

::: js/ui/userMenu.js
@@ +419,2 @@
         this._name = new St.Label();
+        this._name.clutter_text.ellipsize = Pango.EllipsizeMode.NONE;

This should really be a separate commit i think.

(In reply to comment #24)
> This changes the user menu title to be Pango.EllipsizeMode.NONE.
> But truncating it doesn't look any better than ellipsizing it...
Yea, we should really shorten it in a more structured way. imo (and not everyone agrees with me) ellipsizing is almost always a bug.  It means the UI is showing information it wasn't designed to show, but it can't, so the computer is arbitrarily throwing out bits of it without much context to help figure out what parts are important.  The same goes for truncating.

> I'm assuming it's too late to remove the name and use just the icon at
> this point? (UI freeze, documentation issues, etc)
I think the name has traditonally been used for that thing (and its predecessor f-u-s-a) to make it clear who's session is active in fast user switching.    Of course, user switching is increasingly less important these days, and even more so on small form factor screens.

> Another possibility: switch to username instead of name?
My vote would be to try full name, fall back to username, and fallback again to just icon.

as far as ui freeze goes, it doesn't hurt to ask.

pushed everything but the last patch, with the changes you suggested

Attachment 195903 [details] pushed as f2f2898 - panel: fix part of the panel-corner-highlighting hack
Attachment 195904 [details] pushed as 0febcbf - userMenu: belatedly rename CSS to match the new filename
Attachment 195905 [details] pushed as 6d89d0b - panel: remove legacyBox, mix legacy icons in with regular
Attachment 195906 [details] pushed as 9fbd793 - panel: merge statusBox into rightBox

ah great, thanks. I was going to take a look at making the changes today and went here and noticed you already took care of them :-)

Created attachment 196812 [details] [review]
panel: drop dead code

The _userMenu variable never gets initialized anymore,
so remove some code that only gets run when it's defined.

Review of attachment 196812 [details] [review]:

Sure.

Comment on attachment 196812 [details] [review]
panel: drop dead code

Attachment 196812 [details] pushed as 33718ef - panel: drop dead code

Created attachment 196933 [details] [review]
status/keyboard: fix function naming style

Created attachment 196934 [details] [review]
status/keyboard: use correct style class name to fix menu highlight

The keyboard status item doesn't derive from SystemStatusButton, since
it doesn't use an icon. But this meant it wasn't getting the right
class name, and so was using the full-width menu title highlight
rather than the small one. Fix that.

Created attachment 196935 [details] [review]
panel: allow padding around panel buttons to shrink

for narrow screens (eg, portrait orientation)

====

fixed PanelMenu.ButtonBox allocation to clamp height to availHeight,
so that the app icon menu won't draw outside the panel

Review of attachment 196934 [details] [review]:

Makes sense.

Review of attachment 196933 [details] [review]:

seems like a good idea

::: js/ui/status/keyboard.js
@@ +122,3 @@
             this._labelActors[i].destroy();
 
+        let short_names = this._adjustGroupNames(this._config.get_short_group_names());

this says short_names instead of shortNames

Review of attachment 196935 [details] [review]:

I don't have any awesome review comments to add. Code looks reasonable enough to me.  It could probably use a comment somewhere saying that the buttonbox reverts to using minimum horizontal padding instead of natural padding when constrained.

The concept of min-padding seems more generally useful and might make sense to add to St directly, but we can cross the bridge later if we end up needing it in other places.

::: js/ui/panel.js
@@ +1104,3 @@
         icon.height = PANEL_ICON_SIZE;
+        let box = new PanelMenu.ButtonBox();
+        let bin = box.actor;

This isn't a bin anymore so maybe give it a new name? (or maybe rename ButtonBox to ButtonBin since it can't only have one child anyway)

::: js/ui/panelMenu.js
@@ +75,3 @@
+
+        let childBox = new Clutter.ActorBox();
+        if (natWidth + 2 * this._natHPadding > availWidth) {

I think this would 'read better' if you flipped the > to <= and then swapped the two blocks. Also it would be more consistent with your availHeight handling below.  I realize that's subjective, though, so do whatever.

pushed with suggested changes

should have left this open; we still have to do something about the user menu

(In reply to comment #12)
> (In reply to comment #11)
> > Would it be possible to fall back to just the first word in the user name,
> > rather than ellipsizing the full string?
> 
> It's technically possible, but any attempt to automatically abbreviate people's
> names will fail for some names. (Eg, Chinese given names are generally two
> words long.)

evolution-data-server has some utility functions that try to split a full string into name/surname/... here [1] we could reuse if we decide to do this.

[1] http://git.gnome.org/browse/evolution-data-server/tree/addressbook/libebook/e-name-western.c

not going to happen for 3.2 anymore

The new system menu designs should help with this.