App name in panel menu is truncated

Bug #619477 reported by Jono Bacon on 2010-08-17
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Fix Released
Neil J. Patel
unity (Ubuntu)

Bug Description

Binary package hint: unity

when an application is loaded in Unity the application name appears in bold in the panel menu bar, but the name is truncated. As an example, Gwibber shows as 'Gwibber S' whereas it should be something like 'Gwibber Social Media'.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: unity 0.2.26-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-15.21-generic
Uname: Linux 2.6.35-15-generic i686
Architecture: i386
Date: Tue Aug 17 14:11:24 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha i386 (20100630.2)
SourcePackage: unity

Related branches

Jono Bacon (jonobacon) wrote :

For the moment, this is deliberate. It's a quick solution to placing the
menu in a way that it doesn't need to move around between maximised and
non-maximised visuals. The design and implementation will get some
polish (will leave the bug open as a placeholder for that).


Changed in unity (Ubuntu):
status: New → Confirmed

This is an awkwardness that we need to refine. We want the menu position
to be constant, and we know that when windows are maximised we'll have
the window controls in there. As a temporary approach we're putting the
truncated first word of the app name in that space, we haven't done a
round of polish on that but renderings / concepts are welcome as
attachments to this bug :-)


Omer Akram (om26er) wrote :

this bug is fixed in maverick. if the appname is long like Movie Player it now only shows Movie.

Changed in unity (Ubuntu):
status: Confirmed → Fix Released
Mario Limonciello (superm1) wrote :

Per Mark's comments above, this is a temporary workaround to truncate the first word and put it there.

What about allowing apps to declare some sort of short title attribute to be shown in that area? Sure all existing apps would need to be modified to support this and new apps include it, but if you specify that the short title can only be say 15 characters long, you would be guaranteed not to need to truncate possibly in bad areas.

Then you can say if the app doesn't provide the short title attribute, you fall back to this behavior of truncating for that area.

Changed in unity (Ubuntu):
status: Fix Released → Confirmed
Erlan Sergaziev (sergeant) wrote :

I suggest that window controls are always in the panel regardless of their maximization state. The controls should then be removed from windows themselves.
In that case, we just need to make active window more prominent.
I am attaching a quick dirty rendering of my idea (actually not mine, but stolen from latest KDE :).

Mark Shuttleworth (sabdfl) wrote :

 Hi Mario

We could do that, but since it would require work on many apps, I'd
prefer to hold fire until we're absolutely certain it's needed. I
wouldn't be surprised if we find a creative solution that doesn't need it.


Vish (vish) wrote :

Attaching a mockup of 3 options i could think of...

Option 1 might work if we are sure the window placements can be done right. Making sure windows are placed from the top right makes it easier to have the buttons only on the top always. But we need to make sure that the windows placement is right. Else if unity is used anywhere else other than on netbooks it would be awkward.

Option 2 might be ok with no extra effort.. We would just need to replace the app name with the app icon from the dock tile..

The third option seems to be the most sensible to me.. Has a better visual hierarchy and creates a better visual workflow for a user systemwide. "exit" is always the last option everywhere, even in the unity's launcher...
But not sure everyone here likes that. ;-)

Erlan Sergaziev (sergeant) wrote :

No moving controls to the right again, please, everybody will laugh at Ubuntu.
I like the option 1 (obviously), but don't you think that the active window should stand out?
Especially when it's not the only one and somewhere in the bottom?
See also my mockup in comment 6.
It's a bit of stealing from KDE, but heck, we're friends after all.

Philipp Merkel (plippo) wrote :

I don’t think removing the buttons from the window title bar (like proposal 1) is a good idea. Users are used to having these buttons directly in the title bar, not on a probably far away menu bar. If the window is maximized, this is okay as the menu bar practically becomes the title bar, but if the window is not maximized the buttons are expected to be directly in the title bar. Also, many dialog windows don’t have menu bars, so the title buttons would be the only buttons in the menu bar making them even more hard to find.

Instead, I would also use the application icon, but maybe in a different way, as shown in the attachment.

Erlan Sergaziev (sergeant) wrote :

Although your mockups are nice, I'd like to argue the points you make:

1) Unity is by itself a new paradigm, so button location will be one of a dozen of new things users will have to get used to. Doesn't make a big difference.
2) Dialog windows should have their own buttons and it makes sense as they are child windows with local context. Makes it even easier to distinguish them from application windows.
3) Since Unity is designed for netbooks with small screen sizes users will rarely have unmaximized windows anyway.
4) The gap between Ubuntu logo and main menu has exactly enough space to put window buttons there, anything else will look awkward there however hard you try.

With buttons by the main menu the interface becomes more consistent and simple. It will be easier to train ones reflexes if all the major application wide controls are in the same place all the time.

This is also perhaps the easiest solution to implement as all the pieces are already in place.
Now that the release date is approaching fast this argument suddenly becomes important enough :)

Philipp Merkel (plippo) wrote :

Well, I agree with you that Unity is different, but anyway I think leaving the buttons in the menu bar is not the best idea, for the following reasons:

1) If you have dialog windows having the buttons in their title bar and application windows having them in the menu bar, this creates an inconsistency because for the user these windows often look the same. It’s difficult to draw the line: Are settings windows like the display properties or mouse properties dialogs or application windows? They are separate applications, but have “OK” and “Cancel” (or “Close”) buttons like dialogs. Where should their maximize/close buttons be? So instead of having the simple formula: “If window is maximized and thus has no title bar: buttons in menu; if it has a title bar: buttons in title bar”, the formula would be “Maximized windows and some non-maximized windows: buttons in menubar; Other non-maximized dialogs: Buttons in title bar”, which I don’t think is that easy to understand.

2) Another problem with the buttons in the menu bar: Imagine a user having Firefox open in the background, filling the whole screen, and then opens the sound preferences dialog from the sound menu. If this dialog’s close button is still in the menu bar, it will look for the user as it would be used to close Firefox, not the sound dialog.

3) I agree unmaximized application windows are not that common on netbooks, but you find a few of them: Take empathy, skype or other messaging software. And if you regard settings dialogs as application windows, there are even more. But you’re right, this probably is not the most important issue.

I also agree with you that the window buttons fit best in the space, but I think consistency is more important than looks. I also don’t think that removing the buttons from the title bars would be easier to implement than just filling the space with an icon instead of a string. Also, moving the buttons would change the usage concept while changing the text to icons would only change the look.

Erlan Sergaziev (sergeant) wrote :

I wish we had the luxury of playing around with both concepts for a while :(, because it's indeed hard to pick the right approach.

Anyhow, I have one more point to raise - accessibility.

I don't know which screen size you are using, but on my 14" display the top bar is so narrow that an application icon squeezed or cut into that place would hardly be recognizable. Imagine that on a 10" (or even 7" display).

Compare that with the icons in the system tray (e.g. envelope and sound volume). They are simple and monochromatic, i.e. specially crafted to look good in small sizes. The regular application icons are different - they are colorful and often have fine details.

Also, it wouldn't serve much purpose anyway, since the active application has an indicator in the dock.
Again, for accessibility reasons, it is not advisable to make system font too small, so freeing space in the title of unmaximized windows could help accommodate longer application titles.

Philipp Merkel (plippo) wrote :

Yes, this is a case where it is difficult to decide for one option.

Of course, adding the icon there is not an ideal solution. In fact, it doesn’t really have much purpose other than helping you to recognize to which window the menus belong. But that’s exactly what we need in that place, in my opinion: Some indicator for the user from which window the menus in the top menu bar come. The current approach, displaying the title, would work but is not ideal because the text has a variable width while the space is fixed. So using icons, which have a fixed size, in some way seems to be the logical consequence for me, even if I agree it is not ideal.

I am using a netbook with a 10” screen and 1024x600, and I can say that at least for me, the icon (at least the small, un-cut one) can be recognized easily. The 16px versions of the icons do not have that many details – in fact, they are used inside the title bars in other themes and also in the window switcher in Ubuntu desktop edition.

I don’t think the space in the title bars of the unmaximized windows is a problem; dialogs usually have quite short titles and for maximized windows, Unity doesn’t show any title.

Philipp Merkel (plippo) wrote :

Just a little test how the icons of different common applications would look if they were rendered at 48x48, with 50% opacity, vertically centered and cut to the size of the menu bar panel.

Erlan Sergaziev (sergeant) wrote :

They don't look too bad, I agree. Anyhow, we've both provided our points of view.
I hope our discussion will be helpful for the Unity Team to choose the right approach.

Vish (vish) wrote :

 Philipp Merkel , those mockups are pretty much what gnome-shell does.. Not sure unity folks want to copy that.. ;-)

Mark Shuttleworth (sabdfl) wrote :

If the Gnome Shell folks have a savvy approach we should embrace it, the
user experience is what matters most. Punishing the user because we
didn't think of the specific idea seems silly :-) I'm writing this
offline but will review the mockups when on the ground and make a
decision on which direction we'll go in Natty.


Mark Shuttleworth (sabdfl) wrote :

OK, have had a look now :-)

Both the concepts are interesting, thanks for the mockups. For the
moment, I'm going to ask we stick to the app name, with appropriate
ellipsis so that it fits in the room that the window controls will use.


Philipp Merkel (plippo) wrote :

Thank you, Mark! I think adding the ellipsis is already a big improvement over the current state, which just looks wrong for longer names.

Didier Roche (didrocks) on 2010-09-24
Changed in unity:
status: New → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
Iain Farrell (iain-farrell) wrote :

Tagging as Application name should be properly truncated bug from unity review session and tagging appropriately.

tags: added: natty sabdfl
levu (levu) wrote :

Some application's names such as "OpenOffice" are still too large for the title bar (see attached screenshot)

Neil J. Patel (njpatel) on 2010-12-01
Changed in unity:
assignee: nobody → Neil J. Patel (njpatel)
milestone: none → 3.2.10
importance: Undecided → Medium
Neil J. Patel (njpatel) on 2010-12-02
Changed in unity:
milestone: 3.2.10 → 3.2.6
Neil J. Patel (njpatel) on 2010-12-09
Changed in unity:
milestone: 3.2.6 → 3.2.8
Neil J. Patel (njpatel) on 2010-12-17
Changed in unity:
status: Triaged → Fix Released
Changed in unity (Ubuntu):
importance: Undecided → Low
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity - 3.2.8-0ubuntu1

unity (3.2.8-0ubuntu1) natty; urgency=low

  * New upstream release:
    - unity-panel-service should be autorestarted by unity when crashing
      (lp: #686591)
    - App name in panel menu is truncated (lp: #619477)
    - Removing the appmenu indicator left-aligns all other indicators
      (lp: #688764)
    - unity support for firefox menubar (lp: #690447)
    - the unityshell plugin has no icon in ccsm (lp: #688594)
    - the unityshell plugin has an "unknown category" in ccsm (lp: #688592)
  * debian/control:
    - updated the dee and nux requirement.
  * debian/libunity3.symbols:
    - updated to include the new symbols
  * debian/unity.install:
    - install the ccsm icons there
 -- Sebastien Bacher <email address hidden> Fri, 17 Dec 2010 19:18:58 +0100

Changed in unity (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers