It works totally fine for me. Probably highly depends on your screen size and resolution. Can you please provide more info?
Which distribution is this about?

Of course.

The distribution is Fedora 16.
My screen size is 15.4", with a resolution of 1680x1050.

I noticed that the problem is less severe on a screen with better contrast (on my colleagues laptop), so it might not be considered a problem with people with fancier machines.

Basically, the applications grid is barely readable when sitting normally in my chair with the laptop on the desk. I have to lean in so that my eyes are roughly above the edge of the laptop to get a comfortable reading distance.

It's true that icon name tooltips in the dash and window titles are smaller than most labels in the desktop. In particular, even if I can read them, I confirm that window titles are not very easy to read in a short glance (15" laptop screen).

Created attachment 201253 [details] [review]
increase font sizes

Suggested change to increase font sizes. This uses 10.5pt as that seems to be a common size in the rest of the theme.

There are a still a few elements that are <10pt, but I didn't touch those as they weren't part of common components.


One problem this causes is that application labels will often not fit. Ideally, they should be able to be multi-line. Unfortunately I'm unable to figure out the Javascript/gnome-shell/Clutter layers to accomplish this.

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

Some pointers on how to get multiline would be nice. I tried adding the following to iconGrid.js:

            this.label.line_wrap = true;
            this.label.line_wrap_mode = Pango.WrapMode.WORD_CHAR;
            this.label.ellipsize = Pango.EllipsizeMode.NONE;

No go though. It didn't even disable the ellipsing...

As plan B, I did this, which worked:

        this.tooltip = label;
        this.actor.has_tooltip = true;
        this.actor.tooltip_text = label;

Ok, I managed to figure it out. I forgot a ".clutter_text." in there:

            this.label.clutter_text.line_wrap = true;
            this.label.clutter_text.line_wrap_mode = Pango.WrapMode.WORD_CHAR;
            this.label.clutter_text.ellipsize = Pango.EllipsizeMode.NONE;

I also needed to get it properly restricted to the given width using:

            let [labelMinHeight, labelNatHeight] = this.label.get_preferred_height(availWidth);

Unfortunately, the bounding containers didn't resize dynamically as I would have hoped, so I had to change "-shell-grid-item-size" in the css. That got things mostly working for two line objects (although it got center aligned, instead of top aligned, which is probably preferred). It still looked funky for three line objects though.

So more work is needed to get thing more dynamic. Some help from the experts would be welcome. :)

Created attachment 201299 [details] [review]
increased font size and multiline support

Managed to figure it out. I have to say I'm very impressed by how easy it is to hack gnome-shell. :)

This patch improves the BaseIcon class so that it supports multiple lines. It will use the available space to fit as many lines as possible. That also means it should be completely backwards compatible as long as you don't increase the space given to it. I've changed the CSS to allow two lines of text with the new font size.

The remaining issue I have is that the "running" marker is misplaced. It seems like it is using the minimum width instead of the actual one. There's the same issue with the width, if a square look is deemed desirable.

> Managed to figure it out. I have to say I'm very impressed by how easy it is to
> hack gnome-shell. :)
That's one of the reasons JavaScript was chosen. ;-)

Care to attach a screenshot? Designers need to agree on the change, and they probably won't apply the patch to check the result. (The running indicator bug can be dealt with once/if they agree.)(In reply to comment #8)

I'd be in favor of this change ... the problem isn't really the font size though but the chosen font. Cantarel just looks bad at this small sizes. But as we are unlikely going to change the font increasing the size sound like a good way to solve it.

Created attachment 201323 [details] [review]
increased font size and multiline support (improved)

Improved version of the last patch. Better alignment of the label and icon when there is extra space, and makes things square to make it easier to fix the "running" marker.

Created attachment 201324 [details]
Comparison screenshot

Created attachment 201325 [details]
Comparison screenshot

(fixed image. bad pixel alignment in the first one)

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

(In reply to comment #11)
> Created an attachment (id=201323) [details] [review]
> increased font size and multiline support (improved)
> 
> Improved version of the last patch. Better alignment of the label and icon when
> there is extra space, and makes things square to make it easier to fix the
> "running" marker.

Can you reattach this as a proper git patch? i.e with commit message and subject (using git format-patch or git-bz).

(In reply to comment #13)
> Created an attachment (id=201325) [details]
> Comparison screenshot
> 
> (fixed image. bad pixel alignment in the first one)

Thanks for the patch and the screenshot! I've having trouble with my build today so I'm unable to test. Can you post a full screen shot for me to see?

The main thing that I can see is that items in the grid are misaligned. The way you would fix that is with the y_align property, so that the icons in the grid are always at the top of the item.

A full screenshot would help to see if it's noticable, though.

Created attachment 201387 [details]
Full screenshot

(In reply to comment #17)
> The main thing that I can see is that items in the grid are misaligned. The way
> you would fix that is with the y_align property, so that the icons in the grid
> are always at the top of the item.
> 
> A full screenshot would help to see if it's noticable, though.

I'm afraid I'm still too new to this to understand what you mean. Could you elaborate a bit? Things should be aligned AFAICT :)

Look at the bottom of the ABRT icon compared to the icons to the left of it. The full label pushes the icon up. We want to not do that.

Created attachment 201388 [details] [review]
0001-Improve-icon-grid-layout.patch

Created attachment 201389 [details] [review]
0002-Avoid-small-font-sizes-in-common-ui-elements.patch

(In reply to comment #20)
> Look at the bottom of the ABRT icon compared to the icons to the left of it.
> The full label pushes the icon up. We want to not do that.

Ah. Suggestions on how the logic should be here? Just have BaseIcon top align everything?

Jimmac (one of the designers) approves of the general approach here.

It's been suggested that we impose a two line limit on the size of the labels.

Created attachment 201472 [details]
Full screenshot, icons top aligned

Here's a screenshot with the icons aligned at the top instead. This puts them all at the same height, regardless of how big the label is.

I'm not so sure about this model though. As you can see, this results in uneven space around the application when it is selected. To me, this looks worse than the fact that the icons aren't on a perfectly straight line.

Hm, why does the running prelight go around the label, not around the full box? See if you can tweak the CSS so that it goes around the box instead.

I have no idea, and that was the portion I need some help with. The CSS for it is just this:

.app-well-app.running > .overview-icon {
    text-shadow: black 0px 2px 2px;
    background-image: url("running-indicator.svg");
}

I'm afraid I have no idea on how gnome-shell handles backgrounds. What's the default position? Scaling? Repeat?

It looks to me like the answer is, centered, no scaling, no repeat. OTOH, the favourites list on the left seem to have a scaled version of the running indicator.

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

For window title labels, see bug 201829.

That doesn't seem to have been a correct bug number. :)

Yeah, that was bug 664486. Wonder where I found the weird bug number... Too many mistakes in a few days, I guess I need to learn how to copy and paste. ;-)

Looks quite good to me, I think you could try to reduce just a little bit the space between the two lines of text and center the text vertically, so the running app hilight (is that fixed now?) would look better in case of just one line, not sure tho need to see it first.

Also the space between grid cells could be reduced quite a bit.

I'm afraid I haven't looked very much more at this (damn skyrim), but it's not off my radar. I'll try to get a new version for you soon.

(In reply to comment #34)
> I'm afraid I haven't looked very much more at this (damn skyrim), but it's not
> off my radar. I'll try to get a new version for you soon.

What's the status on this? Do you have an upcoming patch or should I take a look? Multiple lines shove the icons up so you align them to the top but then hovering them look bad, right?

Maybe try do a little less css-fixes and more coded resizing of the labels? I think css-fixes are too general to work. Some dynamic Pango resize may work.

If you are not working on anything upcoming that fixes this I could try to fix it. This would improve the icon grid a lot.

Forget about the css being too general stuff I might misunderstood that but what's the status on this?

Feel free to hack away. I don't have any more work right now that isn't attached to this bug.

Created attachment 205263 [details]
design

Is this what we are aiming at?

Created attachment 205266 [details]
design

-||-

Wouldn't it be better to let the icon labels remain single-line and use tooltips for those cases where the text is truncated by an ellipsis?

(In reply to comment #40)
> Wouldn't it be better to let the icon labels remain single-line and use
> tooltips for those cases where the text is truncated by an ellipsis?

No makes reading harder and does not really work on touch.

Created attachment 208407 [details] [review]
0001-Increase-size-of-background-image-to-handle-larger-g.patch

I managed to figure out the problem with the background. It seems things will be scaled down if the background is too large, but just centered if it is too small. So the solution is simply to increase the size of the background to something larger than the icon grid.

I'm trying to get the proposed design to work, but it is difficult for three reasons:

 - There is no value provided for suitable padding. Currently the padding is simply what's left after the icon and label have taken their areas, so there is no need to specify it.

 - I can't get the allocation code to behave properly. It will never allocate more than the minimum height needed, even if there is room. It seems like _getPreferredHeight()/_getPreferredWidth() is never called with anything except -1 as the argument.

 - Icon boxes tend to become rectangular, causing the "running" indicator to either have an offset from the bottom, or not be wide enough.


Is the proposed design a hard requirement? Or can forced square containers with varying amounts of padding be acceptable for now? I'd really like to see these changes get in 3.4.

(In reply to comment #43)
>  - I can't get the allocation code to behave properly. It will never allocate
> more than the minimum height needed, even if there is room. It seems like
> _getPreferredHeight()/_getPreferredWidth() is never called with anything except
> -1 as the argument.

That's a common bug all throughout the Shell code. The fix should be in iconGrid.js. I wonder if we should just scrap a lot of that code and replace it with a ClutterFlowLayout or ClutterGridLayout.

Looking further at this, I'm not sure how the current request/allocation methods can resolve this properly. Either there are more methods, or the proposed design is impossible in the current architecture.

Basically I reimplemented clutter_actor_allocate_align_fill() in iconGrid.js. This method fails to handle text wrapping correctly:

 a) The actor is asked for a natural width, given a limited height. It will compute a layout without line breaks, given that available width is infinite.

 b) The actor is asked for a natural height, given a limited width. It will now be forced to wrap the lines to compute a multi-line height.

 c) Width would now have to be recomputed, given that the line wrapping will most likely not require the full available width. Failure to do so adds extra padding to these icons.

As far as I can tell, there is no way to do c). Basically the layout system would need a way to ask for BOTH width and height at the same time, not independently.

So I see two options here:

 1. Abandon the proposed design because it cannot be implemented in the current structure.

 2. Reorganise the widget hierarchy. The highlighted area needs to be owned by BaseIcon, as it is the only part of the code which can compute its dimensions correctly.

I'm not paying enough attention. It seems the highlighted area is already owned by BaseIcon. I'll see if I can get this working...

Crap... doesn't look like that helped me. The final dimensions seems to be nicely hidden away from BaseIcon as well.

Ideas?

Created attachment 208441 [details]
Fixed width, varying height

Compromise suggestion. The width is fixed for icon entries, but the height varies depending on the size of the label.

(In reply to comment #48)
> Created an attachment (id=208441) [details]
> Fixed width, varying height
> 
> Compromise suggestion. The width is fixed for icon entries, but the height
> varies depending on the size of the label.

Hey Pierre, do you have an updated patch to go along with this?

Created attachment 209050 [details] [review]
working copy diff

I just did a quick hack to get that screen shot. But here's a diff for my working copy if you want to test it.

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

Could somebody review Pierre's patch? It's too bad it wasn't included in 3.4...

It looks like the proposed patch would fix my problem that different versions of the same app (like Netbeans 7.1.1 and Netbeans 7.2 RC1) with the same icons, only discernible by their titles, are ellipsized identically so that I don't know which is which?

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

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

Pierre, I think it's pretty crucial here to keep the icon + text cell a square whatever the label lengh is, with that fixed I think the patch should go in.

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

Changed version to 3.7.x.

It would be great someone could review the patches sent and commit/approve them. The fix should not depend on screen size/resolution... maybe having a higer padding between elements or showing the tile hovering the mouse would be enough.

Any progress on this? If patches are ok, please commit them so we can close this issue.

Thanks!

I haven't had time to look at what was requested in comment #56.

This bug has mostly come to be about line wrapping for the application names. The more I think about it, the less I'm sure that wrapping will work with the current prelight effect that we use for running apps.

A better solution seems to be to make the app names wider, as is described in bug 694699.

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

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

Reassigning to overview.

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

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

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

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

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

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

Created attachment 329534 [details]
Text wrapping

Today i want to try Google unstable, if something is wrong i want google beta ...

How to know what is what if those icons change positions as you use them?

@kolorafa, Just as a temporary solution I would suggest that you edit the .desktop files for them to make the names shorter and fit properly.

Just use this extension: https://extensions.gnome.org/extension/1071/applications-overview-tooltip/

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

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

This is ridiculous! A bug which breaks the most central thing in the whole UI, and it goes unfixed for over half a decade. And even after patches have been provided years ago.
If there was no patches I'd have a look at it myself, but clearly nobody is interested in even reviewing patches so what's the point?

(In reply to Marcus Sundman from comment #76)
> This is ridiculous! A bug which breaks the most central thing in the whole
> UI, and it goes unfixed for over half a decade. And even after patches have
> been provided years ago.
> If there was no patches I'd have a look at it myself, but clearly nobody is
> interested in even reviewing patches so what's the point?

Please cut out the emotional hyperbole. The fact that there are comments here from shell developers clearly shows that people are interested.

What I said in comment 61 still stands. If you have a suggested for how to resolve the issue we'd love to hear it.

(In reply to Allan Day from comment #77)
> What I said in comment 61 still stands. If you have a suggested for how to
> resolve the issue we'd love to hear it.

I am not who you are talking to, but I am annoyed by this bug too.

In my opinion the ugliness caused by wrapped text is, by far, less annoying than not being able to read the application's name in the overview. 

Taking into account the fact that this bug has been open for close to 6 years and that there are patches available that partially fix it, it seems like a good decision to commit those patches and schedule a design review of the overview's effects.

These are my honest thoughts on this matter.

Cheers.

I agree, this really needs to be sorted out. What's the point in working on new features if the existing ones don't work well enough already?

(In reply to Nicolás Bértolo from comment #78)
...
> I am not who you are talking to, but I am annoyed by this bug too.

My comment was marked as a reply to comment 76.

> In my opinion the ugliness caused by wrapped text is, by far, less annoying
> than not being able to read the application's name in the overview. 

Nobody's talking about "ugliness" from wrapping. The issue is that multi-line names will interfere with the positioning of the running indicator below the application name - either making it appear too far below the name, or leaving it positioned at different heights.

One way to fix it would be to drop the running indicators from the application grid.

> Taking into account the fact that this bug has been open for close to 6
> years and that there are patches available that partially fix it, it seems
> like a good decision to commit those patches and schedule a design review of
> the overview's effects.

That's not how this works. We come up with a design first, then commit patches. Not the other way round.

By the way, Ubuntu 17.10 Alpha currently defaults to GNOME Shell with the Ubuntu font which means there are even fewer characters there (about 13-14) before the labels start ellipsizing. I posted a screenshot at comment #5 of https://launchpad.net/bugs/968213

Created attachment 355056 [details]
current Ubuntu example of confusing layout

One other example of very confusing user experience, that's on a stock current Ubuntu installation looking for libreoffice, you better know the icon to be able to start the right component...

Just showing the full name (even more important for files) on mouse-over would solve the problem, at least for non-touch interface.

Ubuntu 17.10 was released with this issue. Please, find a way to add at least second line for long program names. Activity indicator could be moved to the left, like in Ubuntu dash.

A fix is pending:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/90

And another fix is pending:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/58

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

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

And another fix is pending:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/109

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

GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.