Probably it could be easily implemented if we used GtkFlowBox. It is already used as the list of categories in the overview page, its main feature is that it automatically adapts the number of columns to the available space. Do you think it will be OK, Allan?

Some questions:

1. If we have a very very wide screen (such screens already exist) should we switch to 4 columns, then 5 etc., or should we stop at 3?
2. If we stop at 3 (or 4, or whatever limit you specify) and we still have more horizontal space, should the tiles grow or should the left/right margin grow?
3. Please specify the minimum and/or maximum width of a single tile. Please note that the maximum width must be roughly 150% of the minimum width, that's because there will be an edge value of the total width which will be distributed among 2 columns (this determines the maximum width of a tile) and then having one more pixel of the total width we will distribute it among 3 columns. You can specify the width in pixels, characters (of the label), etc. but also remember that the width of a single character in pixels depends on the font and even the user's language. Please note that the current algorithm always distributes all available space among 2 columns. The minimum width is probably much smaller. If we let the flow box choose the number of columns it will tend to allocate as many columns as possible and set the tiles as small as possible, that's why we will have to control the width of the tile.

I mark the bug 758036 as blocking because any solution to this bug could render the patch for bug 758036 not applicable.

(In reply to Rafal Luzynski from comment #1)
> Probably it could be easily implemented if we used GtkFlowBox. ...
> Do you think it will be OK, Allan?

I'm no expert on GTK+, but it seems like it is worth a shot!

> Some questions:
> 
> 1. If we have a very very wide screen (such screens already exist) should we
> switch to 4 columns, then 5 etc., or should we stop at 3?

I think we should stop at three - otherwise you will end up with very few rows, which could look strange.

> 2. If we stop at 3 (or 4, or whatever limit you specify) and we still have
> more horizontal space, should the tiles grow or should the left/right margin
> grow?

The margin should grow.

> 3. Please specify the minimum and/or maximum width of a single tile. Please
> note that the maximum width must be roughly 150% of the minimum width,
> that's because there will be an edge value of the total width which will be
> distributed among 2 columns (this determines the maximum width of a tile)
> and then having one more pixel of the total width we will distribute it
> among 3 columns. You can specify the width in pixels, characters (of the
> label), etc. but also remember that the width of a single character in
> pixels depends on the font and even the user's language. Please note that
> the current algorithm always distributes all available space among 2
> columns. The minimum width is probably much smaller. If we let the flow box
> choose the number of columns it will tend to allocate as many columns as
> possible and set the tiles as small as possible, that's why we will have to
> control the width of the tile.

For the mockups, I had 270px as the minimum width and 340px as the maximum width. You should only treat these as rough numbers though - it really depends on how it looks in real life, and the various other paddings and widths in the view. You could potentially go higher for the maximum width if that's necessary though.

Created attachment 319068 [details] [review]
Initial solution - please review but do not commit

This is a dirty and not yet finished but kinda working solution. I don't like this dirty trick with overriding the preferred width of GsAppTile but I'm afraid there is no other simple solution. I will appreciate your feedback, whether you accept this approach or if you can propose another one.

Even if you like this there are some other minor issues: the preferred width of GsAppTile should not be unconditionally hardcoded and the behaviour of the category page is not perfect if there are only 2 or only 1 app in the subcategory.

Allan, can you please apply and test this patch live? Although the source code looks ugly the user's look and feel probably will not change except the case of 2 apps and 1 app. Also I'll appreciate your hint how the category page should lay out its content if there are only 2 apps or only 1.

The patch in comment 4 seems great from a UI point of view. The only thing I'd change is to increase the maximum width of the tiles, possibly to around 420px.

Allan, a question to you. We want 3 columns if the window is wide enough and 2 columns if it is not. Now my question is: does the same rule apply if a category has only 2 or only 1 item? My ugly solution switches to 3 columns even if it displays only 2 or 1 item thus causing additional empty space which could be assigned to the app tiles. First I thought that I should find a solution not to switch to 3 columns if we have less than 3 apps. But now after few days I think that the current solution may be considered correct. If you browse categories and you reach a category having only 2 apps then these apps fit into the same grid (3 columns) as other categories. With the custom solution those 2 tiles would grow. The current experience is fine when a user browses the categories. The other solution (filling the available space) would be fine when a user resizes the window. Now the question is: are we going to provide good user experience for browsing categories and apps or for resizing the window?

Please use my patch again and please check if the new behaviour is good if we have at least 3 apps in a category or if it is also good if we have 1 or 2.

Review of attachment 319068 [details] [review]:

Just a tiny code style nit, otherwise I think it looks great! Thanks Rafal.

::: src/gs-app-tile.c
@@ +188,3 @@
+	GTK_WIDGET_CLASS (gs_app_tile_parent_class)->get_preferred_width (widget, &m, NULL);
+
+	if (min)

We use a style in gnome-software where you'd write 'if (min != NULL)'

@@ +190,3 @@
+	if (min)
+		*min = m;
+	if (nat)

likewise, "if (nat != NULL)"

Created attachment 319476 [details] [review]
Final (candidate) solution

Thanks for your review, Kalev. Please review this one and commit if you like.

Pushed to master, thanks!

Thanks, Richard. Can you please mark all pushed patches as pushed?

Allan, if you don't like the new look and feel of the category page (see my questions in comment 6) then feel free to reopen this bug or file a new one.

No can do Rafal, whenever I try to mark them as committed I get:

Failed to publish review: Undefined subroutine &Bugzilla::Extension::Splinter::WebService::ThrowCodeError called at /loader/0x7f2f9c3463b0/Bugzilla/Extension/Splinter/WebService.pm line 61.

Thanks for the fix Rafal! I've given master a try and it looks great.