I should have mentioned: this could also apply to the installed list, unless bug 757647 is fixed first.

Created attachment 316455 [details]
Preview screenshot

Allan, is this what you would like?

I have set the default list size to 752 pixels. In this solution the width will be smaller if a user resizes the window but not below the minimum required by the widgets inside the list. Two smallest screenshots show the minimum width 644 pixels. You may not like that the column with the app names is wider than the description column but this is caused by the OpenJDK version number 1.8.0.31-3.b13.fc21.x86_64 which is (IMHO incorrectly but we can't change it) included in the app name and which is a single word and cannot be broken. This long "word" determines the minimum width of the column. We can settle other layout rules if you think that we should.

(In reply to Rafal Luzynski from comment #2)
> Created attachment 316455 [details]
> Preview screenshot
> 
> Allan, is this what you would like?
...

Hi Rafal! This looks great! The default list width could probably be higher (I used 860px in the mockups, for what it's worth). 

I agree that the application name column needs to be smaller in your screenshots. Is it not possible to ellipsize extremely long names?

Created attachment 316632 [details]
Preview screenshot (v2)

Thanks, Allan. Your information is very helpful and here are the new screenshots at 860px. Note that the window still can be smaller than 860px if a user resizes it or if the screen is smaller.

The long application names issue has been easily worked around with PANGO_WRAP_WORD_CHAR mode (wrap lines at word boundaries, but fall back to character boundaries if there is not enough space for a full word.) This also helps with ellipsizing.

Here is a summary of some properties of the labels.

Application name label:
* default width: 20 characters (turns out to be 173 pixels)
* wrapping: yes
* wrapping mode: at word boundary, break the words if they are too long (previously was strictly at word boundary)
* maximum lines: 3 (previously was unlimited)
* ellipsizing: yes, at the end (previously was no ellipsizing)

Application description label:
* default width: not set, will use all available space
* wrapping: yes
* wrapping mode: at word boundary, break the words if they are too long (previously was strictly at word boundary, I suggest this change to handle the descriptions which may contain veryveryverylong words while having less horizontal space)
* maximum lines: 3
* ellipsizing: yes, at the end

You may notice a large space between the description and the Install or Remove button. This is because the button is placed inside a box which has a fixed width 180 pixels. As far as I know the space is reserved for the Pending label (for the apps which are enqueued for install but not yet installed) and for the spinner (now used to indicate that the app is being removed, previously also being installed.) I think it could be smaller but then the description label would jump if a space is needed for the Pending label or for the spinner.

Allan, would you like to allow more lines for the application description? Would you like other changes? You can use GTK Inspector to make some experiments live in your running GNOME Software.

Created attachment 316634 [details]
Screenshot of the fixed width search results (preview)

The search results list uses the same application row widget as the list of updates and the list of the installed apps. Would you like this list to follow the same design? Please see the screenshot which is a preview of a trivial implementation of your design. Please note the grey area around the list. That's because the search results list is a separate page rather than an overlay on top of the overview page. You may request it to be the overlay instead but this change would not be trivial.

Created attachment 316712 [details] [review]
Implements all changes except the search results

Here is the patch which implements all changes according to the mockups and screenshots above *except* the change in the search results (comment 5) because I am not sure if you like it. If you want the same change for the search results now it is easy to implement.

Your comments and review will be appreciated.

Where do the scrollbars appear with this? To the far right at the window border, right? Should they instead be at the content area? Allan?

Also, I wonder if there's any chance to get this in GtkBox in gtk+ instead of having to do custom containers in gnome-software?

Review of attachment 316712 [details] [review]:

Some code style nitpicks:

::: src/gs-app-row.ui
@@ +48,3 @@
+                <property name="ellipsize">end</property>
+                <property name="lines">3</property>
+                <property name="wrap-mode">PANGO_WRAP_WORD_CHAR</property>

<property name="wrap-mode">word-char</property>

@@ +112,3 @@
             <property name="yalign">0.5</property>
             <property name="wrap">True</property>
+            <property name="wrap-mode">PANGO_WRAP_WORD_CHAR</property>

<property name="wrap-mode">word-char</property>

::: src/gs-box.c
@@ +112,3 @@
+	if (box->preferred_width >= 0
+			&& box->preferred_width >= box->min_width
+			&& allocation->width > box->preferred_width)

&& should be at the end of the lines and individual statements aligned, so that it reads:

if (box->preferred_width >= 0 &&
    box->preferred_width >= box->min_width &&
    allocation->width > box->preferred_width)

@@ +120,3 @@
+	if (box->preferred_height >= 0
+			&& box->preferred_height >= box->min_height
+			&& allocation->height > box->preferred_height)

Same here.

Created attachment 316784 [details] [review]
Implements all changes except the search results (corrected)

Thanks, Kalev. Here is a corrected patch.

(In reply to Kalev Lember from comment #7)
> Where do the scrollbars appear with this? To the far right at the window
> border, right? Should they instead be at the content area? Allan?

Yes, at the right window border. I thought it should be that. Allan?

> Also, I wonder if there's any chance to get this in GtkBox in gtk+ instead
> of having to do custom containers in gnome-software?

As I said (I write it here for the record) I'm afraid it is impossible with the standard GTK+ widgets/containers. "width-request" property seems to be inviting but in fact it defines the minimum size rather than maximum.

In fact probably we are breaking some GTK+ rules but probably this time we can say that we know what we are doing. Also there is a fallback code in this patch which ensures that this hacking solution does not break more rules than required (the child widgets will receive their required size, the box will not be larger than its parent container).

See also: bug 745317.

(In reply to Rafal Luzynski from comment #4)
> You may notice a large space between the description and the Install or
> Remove button. This is because the button is placed inside a box which has a
> fixed width 180 pixels. As far as I know the space is reserved for the
> Pending label (for the apps which are enqueued for install but not yet
> installed) and for the spinner (now used to indicate that the app is being
> removed, previously also being installed.) [...]

What about this design:

* let the Pending label be an overlay over the application row, the same as the Installed badge over some other application tiles,
* no spinner for the apps being removed: let the progress be shown in the Install/Remove button, the same as while installing (may be difficult because AFAIK there is no percentage feedback from the app being removed, we would have to show indeterminate progress or some fake percentage value),
* there would be no additional space reserved and unused for most of the time.

(In reply to Kalev Lember from comment #7)
> Where do the scrollbars appear with this? To the far right at the window
> border, right? Should they instead be at the content area? Allan?

One more thought here. I think that the scrollbar at the right border of the window has its advantage: it's always there, on all pages.

(In reply to Rafal Luzynski from comment #9)
> Created attachment 316784 [details] [review] [review]
> Implements all changes except the search results (corrected)
> 
> Thanks, Kalev. Here is a corrected patch.
> 
> (In reply to Kalev Lember from comment #7)
> > Where do the scrollbars appear with this? To the far right at the window
> > border, right? Should they instead be at the content area? Allan?
> 
> Yes, at the right window border. I thought it should be that. Allan?

That seems correct. As you've said, it is consistent with other views. It also means you can use the screen edge for scrolling.

(In reply to Rafal Luzynski from comment #10)
...
> > You may notice a large space between the description and the Install or
> > Remove button. This is because the button is placed inside a box which has a
> > fixed width 180 pixels. As far as I know the space is reserved for the
> > Pending label (for the apps which are enqueued for install but not yet
> > installed) and for the spinner (now used to indicate that the app is being
> > removed, previously also being installed.) [...]
> 
> What about this design:
> 
> * let the Pending label be an overlay over the application row, the same as
> the Installed badge over some other application tiles,
> * no spinner for the apps being removed: let the progress be shown in the
> Install/Remove button, the same as while installing (may be difficult
> because AFAIK there is no percentage feedback from the app being removed, we
> would have to show indeterminate progress or some fake percentage value),
> * there would be no additional space reserved and unused for most of the
> time.

Sounds good to me. Another alternative would be to change the button label to "Pending".

Note that we should only use progress bars when we know how long the task will take. If we have indefinite periods of time will have to wait, a spinner might still be necessary. "Pending" is wider than a spinner though, so maybe the spinner isn't so much of an issue?

Allan, thank you for your answers. Please answer more questions so we'll be able to solve this problem.

Please answer my question from the comment 5: would you like the same design for the search results page?

(In reply to Allan Day from comment #12)
> (In reply to Rafal Luzynski from comment #10)
> ...
> > ...
> > What about this design:
> > 
> > * let the Pending label be an overlay over the application row, the same as
> > the Installed badge over some other application tiles,
> > * no spinner for the apps being removed: let the progress be shown in the
> > Install/Remove button, the same as while installing (may be difficult
> > because AFAIK there is no percentage feedback from the app being removed, we
> > would have to show indeterminate progress or some fake percentage value),
> > * there would be no additional space reserved and unused for most of the
> > time.
> 
> Sounds good to me.

Please provide some hints where the Pending label should be placed. A mockup would be helpful but not obligatory. By the way, don't you think that this label should have a similar appearance like the Installed label on other widgets, white text on the blue background? Now it has the default appearance.

> Another alternative would be to change the button label
> to "Pending".

No, this is impossible because when an application is "pending" the button label changes to "Cancel": it is intended to undo pending (remove the application from the install queue). The "Pending" label instead probably wouldn't be a clear information to the user that this button can be used to undo pending.

If you want to experience the Pending label it is pretty easy: turn off networking in your computer and then try to install something with GNOME Software. An app of course won't be installed but instead it will be enqueued for the installation (will be "pending") and you will be able to cancel.

> Note that we should only use progress bars when we know how long the task
> will take. If we have indefinite periods of time will have to wait, a
> spinner might still be necessary. "Pending" is wider than a spinner though,
> so maybe the spinner isn't so much of an issue?

I am pretty sure you have seen the indefinite progress bars many times: this is the progress bar which bounces back and forth many times until it stops. This is not (yet) implemented in the g-s progress button but this is roughly the idea which I mean. Also it would be consistent with the progress button when an app is being installed. Although you may consider this is not a good idea and retain the spinner instead. Indeed, the spinner is not so wide.

Created attachment 317091 [details] [review]
Implements all changes except the search results (corrected + rebased)

I'm afraid we are drifting too far from the original aim of this bug report. Placing and styling of the Pending label and whether we need the spinner or some kind of animation effect on the Install/Remove button is beyond the scope of this patch, maybe even beyond the scope of this ticket.

Simple questions. Allan:

1. Do you want the same design for the search results? See the comment 5 for the preview.

2. Can we leave this large space before the Install/Remove button as is for now? I've checked this and we can make it smaller by 16 pixels only. The rest must be reserved for the spinner. If the Pending label appears it will increase the box width and it will have its place.

Created attachment 317095 [details]
Pending label (preview)

This is my proposition of the Pending label, when we decide to rework it.

Some notes when trying out the patch:

1) I can't scroll to the bottom in the Installed list any more, it cuts off several rows in the bottom when I've scrolled all the way down

2) I don't think it's right to break up app names in several lines. I'd much rather ellipzise the names so that it doesn't break the layout, and also so that it forces apps to stay below a limit when choosing names. Your example with the OpenJDK name is particularly bad. I don't want to encourage names like that.

3) I think it needs some borders: https://kalev.fedorapeople.org/gnome-software-updates-needs-borders.png looks a little bit sad right now

Ţhanks for your review, Kalev.

(In reply to Kalev Lember from comment #16)
> 1) I can't scroll to the bottom in the Installed list any more, it cuts off
> several rows in the bottom when I've scrolled all the way down

Sound like a bug, I'll have to check it later.

> 2) I don't think it's right to break up app names in several lines. I'd much
> rather ellipzise the names so that it doesn't break the layout, and also so
> that it forces apps to stay below a limit when choosing names. Your example
> with the OpenJDK name is particularly bad. I don't want to encourage names
> like that.

I'd disagree because the app names which don't fit into one line are pretty common, I think. Please note that translations into non-English are often longer than in English. You will end up explaining the users that "JBoss Studio 8.5.6. Uninstaller" is not the same app as "JBoss Studio 8.5.6". :-) Allan?

> 3) I think it needs some borders:
> https://kalev.fedorapeople.org/gnome-software-updates-needs-borders.png
> looks a little bit sad right now

I'd agree here. Allan?

I've just tried the patches and discussed it with Jakub. One thing he suggested is using the same background colour on the margins, so the whole background is white. I agree that this will probably look better. 

(In reply to Rafal Luzynski from comment #13)
...
> Please answer my question from the comment 5: would you like the same design
> for the search results page?

Yes, that sounds great! We should be doing this wherever there is a list.

...
> Please provide some hints where the Pending label should be placed. A mockup
> would be helpful but not obligatory. By the way, don't you think that this
> label should have a similar appearance like the Installed label on other
> widgets, white text on the blue background? Now it has the default
> appearance.

My suggestion would be to show a spinner instead of "pending". It carries the correct meaning and is a lot smaller.

I would also suggest ensuring that there is even padding on either side of the description text, taking into account the space that is reserved for the spinner - this will make the layout more balanced.

...
> you have seen the indefinite progress bars many times: this
> is the progress bar which bounces back and forth many times until it stops.
> This is not (yet) implemented in the g-s progress button but this is roughly
> the idea which I mean. Also it would be consistent with the progress button
> when an app is being installed. Although you may consider this is not a good
> idea and retain the spinner instead. Indeed, the spinner is not so wide.

Generally speaking indefinite progress bars are not recommended, and a spinner is preferred to indicate indefinite progress. Also, I don't see a problem with showing a spinner next to the button.

Thanks for keeping going with this, Rafal! It's going to be a big improvement.

Created attachment 317258 [details] [review]
Implements all changes including the search results and extras + bugfixes

I've found one more list of applications: extras. I have no idea where it appears in the live application so I couldn't test. I have corrected this page only because it is almost identical with the updates page.

(In reply to Kalev Lember from comment #16)
> 1) I can't scroll to the bottom in the Installed list any more, it cuts off
> several rows in the bottom when I've scrolled all the way down

Thanks for spotting this, Kalev! It's fixed now. The bug was caused by missing height-for-width implementation.

> ...
> 3) I think it needs some borders:
> https://kalev.fedorapeople.org/gnome-software-updates-needs-borders.png
> looks a little bit sad right now

Done. I have removed the top border because it was double.

(In reply to Allan Day from comment #18)
> I've just tried the patches and discussed it with Jakub. One thing he
> suggested is using the same background colour on the margins, so the whole
> background is white. I agree that this will probably look better. 

Thanks for your hard work testing this, Allan. I've done the white background. It's implemented by replacing the (nonexisting) "main-scrolled-software" style class of the scrolled windows with the basic "view" class. I hope it is correct and portable across multiple themes. Please notify me if it's not.

> (In reply to Rafal Luzynski from comment #13)
> ...
> > Please answer my question from the comment 5: would you like the same design
> > for the search results page?
> 
> Yes, that sounds great! We should be doing this wherever there is a list.

Done, as well as another page: extras.

There are some features not yet implemented and some comments I should reply but that's not a task for today. If you like this patch and you accept that the missing changes will be discussed and implemented later then I think it's safe to commit it. It's also fine not to commit, if you prefer.

(In reply to Kalev Lember from comment #16)
...
> 2) I don't think it's right to break up app names in several lines. I'd much
> rather ellipzise the names so that it doesn't break the layout, and also so
> that it forces apps to stay below a limit when choosing names. Your example
> with the OpenJDK name is particularly bad. I don't want to encourage names
> like that.

Trying Rafal's latest patch, wrapping the names over several lines doesn't seem to have an adverse effect on the page layout. I see what you're saying about not encouraging terrible app names, but I'm not sure this change will have much effect there.

> 3) I think it needs some borders:
> https://kalev.fedorapeople.org/gnome-software-updates-needs-borders.png
> looks a little bit sad right now

I'm not entirely sure where we are going with the visual design, to be honest.

Jakub recommended that the background should be all white - which is implemented in the latest patch. This looks better for the list views, but results in a jarring transition from the other views that use a grey background (this is particularly apparent with search).

I would imagine that a border would be more to denote a column down the centre of the view, rather than being a box around list rows (for cases where the rows don't fill the view).

Given the uncertainty, I'd sooner wait and get more comprehensive visual guidance from Jakub or Lapo before we continue with the styling.

Created attachment 317616 [details] [review]
GsBox: introduce "preferred-width" and "preferred-height"

This is the first of the series of patches made by splitting the patch from comment 19. You will be able to apply or reject individual patches depending on whether you want the features or not.

This patch introduces the "preferred-width" and "preferred-height" properties of GsBox. It does not introduce any visual changes but this new feature will be needed to limit the width of any application list.

Created attachment 317617 [details] [review]
Limit the width of all app list boxes to 860px

This patch applies the limited width feature to all application lists: extras, installed apps, search result, updates. Requires the patch from the comment 21 to be applied first.

Created attachment 317618 [details] [review]
Minor tweaks to make the app row look better

You may like to introduce these changes to make the application lists look better at the limited width and deal better with some weird application names which may be too long or may contain too long words.

This patch does not depend on other patches from this series. You may even consider backporting it.

Created attachment 317619 [details] [review]
Add frames around the app list boxes

One should be able to add the frames independently on adding any other changes but this patch assumes that you have also applied the patch from the comment 22 and may not apply cleanly if you have not. But probably adding frames around the list box which already fills entire window would not make any sense.

Created attachment 317620 [details] [review]
Add white background around the app list boxes

One should be able to add the white background independently on adding any other changes but this patch assumes that you have also applied the patch from the comment 22 and may not apply cleanly if you have not. But probably adding the white background around the list box which already fills entire window would not make any sense.

Note that the white background and the frame are independent on each other and you may choose to apply one or another or both.

This is the last patch of this series.

I spoke to Jakub about the styling yesterday. His view is that we shouldn't use a border. About the background colour, there are two options:

 1. For the list views, use a white background for the list and grey along the sides.
 2. Use a white background everywhere instead of grey.

Jakub expressed a preference for option two, and I'd be interested to give it a go.

From irc discussion:

It turns out that the sole feature gsbox was introduced for (fixed ratio of children) is not used anymore. Therefore, I'd rather see gsbox be removed, and a new simple container for limiting the width of a child be introduced

Created attachment 318606 [details] [review]
Introduce GsFixedSizeBin featuring "preferred-width" and "preferred-height"

I've thought about it again and finally I agree with you, Matthias. Here is the new container GsFixedSizeBin. The GsBox is reverted to the master version (to be removed in future).

Created attachment 318607 [details] [review]
Limit the width of all app list boxes to 860px

The same as the one from comment 22 but this time using the new GsFixedSizeBin.

Note: after this patch you can apply the patch from the comment 24, it still applies smoothly.

Created attachment 318608 [details] [review]
Add white background around the app list boxes

The patch from the comment 25 rebased.

Note again: you can apply the patch from the comment 24 before, after, or instead of this patch, it should apply smoothly.

(FWIW, I'd prefer grey background and a frame.)

This looks great to me! I would maybe leave the third patch for now (Add white background around the app list boxes) and spin that out into a separate bug - since it will require updating the background for the other views and is not strictly needed for this issue.

I definitely prefer it without the frame, as do our visual designers. (Sorry Rafal!)

Looks great Rafal, I've committed those three patches. Okay to close this bug now?

Comment on attachment 317619 [details] [review]
Add frames around the app list boxes

Actually, aday said I should revert this, sorry for the confusion.

I've filed bug 760475 for the white background.

Bug 760171 requests a fixed width list for music, like the one here. It would be great to be able to transfer the lessons learnt in this case.

(In reply to Richard Hughes from comment #32)
> [...] Okay to close this bug now?

Yes, I think it's OK. Thank you everybody for your support.

Allan, we had a short discussion about the Pending label and the spinner. Please file another bug report or feel free to reopen this one if you want it to be reworked.