This feature is already implemented for Installed, Updates, Extras and Search results, the maximum width is 860px - see bug 758662.

Details page - this feature would be highly desirable although I'm not sure that 860px is the best value. Currently there is a similar feature: the width_request property is set to 752px. Unfortunately, width_request is not a good choice because in fact it is the minimum width rather than maximum. Sometimes the window may be wider than 752px and it leads to bad results but never smaller. This is being reworked as bug 735994.

Category page - since bug 758669 is fixed the maximum width of the right panel only is set to 1338px. If it was smaller this would undo the effect of responsive scaling. The right panel must be at least 888px wide to switch to 3 columns. Note that it does not count the left panel (the list of subcategories), spacing, margins etc.

Overview page - setting the maximum width to 860px would undo the effect of fixing the bug 757986, the situation would be even worse because you can fit only 5 app tiles at 860px (the default width of an app tile is 152px). The fix for bug 757986 increases the maximum number of app tiles from 6 to 8.

I understand that a common fixed width for all pages would look good but it may be difficult or even impossible to achieve unless you sacrifice some of the most recent changes.

I wouldn't worry about the categories view here: that's got the sidebar and the content isn't centered, so it's a bit different. The relevant pages for me are:

 * Overview page
 * App details pages
 * List pages (installed, updates, search results)

The details and list pages seem a bit on the narrow side for me, and look like they could be expanded. 

I really like how the overview page expands to make use of available space. However, its maximimum width (looks about 1314px to me) might be too wide for the details pages.

I see two options therefore:

 1. Use a consistent width of around 1200px for all the relevant pages - this would reduce the overview page a bit
 2. Stick with the current width for the overview page, but try and make the details and list pages a bit closer: we could expand them to around 1100px wide or so

Thanks for answering, Allan. So again:

* Categories view: will be left unchanged.
* App details page: I agree that applying the maximum width would be good.
* List pages: this is already implemented and if you want to change the maximum width value you can experience it easily editing the code and building your local version from jhbuild or changing it live in the running process with GTK Inspector. You can even push the change yourself if you decide what value it should be.

The only concern is the overview page. I also like how it expands on wide screens and I think there is already some value where it stops expanding (you said 1314px, probably that's the value), probably it could be a little smaller but not so small to lose its nice appearance on large screens. I think we could apply some limit and see how it looks.

Whatever change we apply please keep in mind that the application should also handle correctly both much wider and much smaller screens, including the screens in vertical orientation.

OK, so it sounds like the way forward is to try a larger maximum width for the lists and the app details pages, and a smaller maximum width for the overview page. If we don't manage to meet in the middle, that's OK: I'd be OK with having a different width for the overview page.

One concern I have though: what about the screenshots on the app details pages? I understand that the screenshots are generally only 752px wide: if we expand the width of the details pages, the screenshots won't be big enough to span the width.

(In reply to Allan Day from comment #4)
> [...] I understand that the screenshots are generally only 752px wide: if
> we expand the width of the details pages, the screenshots won't be big
> enough to span the width.

That's true, so the screenshots box must be centered or start aligned. I hope it is OK. Another option is to scale the main screenshot but it would cause some loss of image quality. I think we should avoid this.

Created attachment 320838 [details] [review]
Applies max-width=860 to the app details page

This patch looks huge but the only relevant changes are:

* put almost everything inside the GsFixedSizeBin with preferred-width=860;
* set the box_details halign=fill to let it actually fill the new maximum width;
* decrease its margins from 64 to 24 pixels to match the app lists (Installed, Search, etc.)

Other changes are just formatting, I recommend viewing it in space-ignoring mode.

Since the patch is actually huge and other developers are also working on the same file I'd like to get your review quickly. If you like this patch please commit it ASAP, if the only concern is the width value then please note that it can be changed easily in future. If you don't like it please just say it. Otherwise soon we may face conflicts and the patch will become unmergeable.

Thanks for the patch, Rafal. I've experimented with different widths for the app pages and for the lists. To me it looks like the lists would be better even wider, somewhere in the 1000-1200px range. The app details pages could also be wider, although 1200 is a bit too wide: around 1000px seems OK there.

As expected, the screenshots are an issue, since they don't span the full width of the app pages.

Tanks, Allan. Do you think we should ask Richard to push it to master now and only change the value 860 later? I'm asking this because I'm afraid of the git conflicts. If you think that applying a max width to the app details is a good idea but only not yet sure what the value should be then IMHO it's better to push it.

The app details width 860 pixels minus margins actually does not look much different than the current 752. The screebshots box is start (left) aligned, it's OK for now because all texts all also start aligned and seldom actually reach the right end. Centered would look too much shifted right. Of course this may be different if we change the width to 1000px or more.

I think I'd rather merge such an invasive patch after we branch.

Created attachment 325140 [details] [review]
Applies max-width=860 to the app details page (V2)

Second attempt - rebased, appliable.

Created attachment 325142 [details]
what i see

Looks good in code, but looking at the screenshot I see the stars no longer align with the right side of the thumbnails -- is that intentional?

OK, I think I know what you mean. Indeed, I have not noticed this. This is a consequence of applying a fixed width to this page. The current fixed width is 752px, this is also an actual width of the screenshots box. TL;DR answer is: if you don't want this appearance to be changed then let's use the "preferred-width"=800.

Here is a longer explanation. What this patch does is:

* use the GsFixedSizeBin to control the fixed width (in fact this is the maximum width so in future it will allow to collapse the window and fit in small screens, the current version uses the minimum width),
* increase the width value to 860px.

If you change the "preferred-width" value of GsFixedSizeBin to 800px, with 24px margins it will result with the content being 752px wide and make it look as it looks now. Note that in comment 7 Allan was thinking about 1000px. If you apply a larger width it will make the box_details_header expand and move the stars to the right, also it will expand the app description and the details at the bottom. The screenshots box will not expand.

You can use GtkInspector to play with different values of "preferred-width" property of gs_fixed_bin, also with "halign" property of box_details_screenshot.

If you want the stars and probably whole box_details_header to be aligned with the screenshots box we can use a GtkSizeGroup. But then please answer: what should happen if an app does not have screenshots or if it a component (e.g. an input method) which will never have screenshots?

Allan, what's your opinion?

Instead of left-aligning the screenshots, why not expand the width of the main screenshot background? I think this would look better, since it would reinforce the left and right margin of the page content.

Created attachment 325611 [details]
Example of the expanded main screenshot widget

Is that what you mean, Allan? Please note that my next step will be placing the thumbnails horizontally under the main screenshot on very small screens. Soon we will face the problem "ok, we have too little space to put the thumbnails at the right side of the main screenshot so fine to put them below but now we have too much horizontal space for just the screenshot." This would be the solution.

Other options I think of are:

- center the screenshots box;
- add two vertical lines marking the margins;
- add two horizontal lines above and below the screenshots marking the full width of the central area.

(In reply to Rafal Luzynski from comment #14)
> Created attachment 325611 [details]
> Example of the expanded main screenshot widget
> 
> Is that what you mean, Allan?

Yes, that's right.

> Please note that my next step will be placing
> the thumbnails horizontally under the main screenshot on very small screens.

Sounds good to me!

I like the screenshot/thumbnail arrangement discussion. I would add to span the whole width of the block in case there is only one screenshot and no switcher is necessary (rather than keeping the space for mini thumbnails allocated as it is in the table version right now).

Thanks, Allan, I think we will finish this patch soon.

(In reply to Jakub Steiner from comment #16)
> [...] I would add to span
> the whole width of the block in case there is only one screenshot and no
> switcher is necessary (rather than keeping the space for mini thumbnails
> allocated as it is in the table version right now).

I think this is how it works now and I'm (we are) not going to change it.

My bad, the current 3.20 version actually spans full width for single screenshots. We're good :)

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups-software/master/wireframes/app-page-grid.png

Created attachment 326295 [details] [review]
Expand the width of the main screenshot background

I'm sorry for being absent for so long.

Here is the second patch which does exactly what Allan asked for in a comment 13. Please apply it after applying the first patch.

Please note that these patches set the preferred width of the Details page to 860px. Feel free to set it to a different value if you prefer.

Created attachment 326666 [details] [review]
Applies max-width=860 to the app details page (V3)

Just rebased to reflect the recent changes.

Review of attachment 326295 [details] [review]:

Looks good, thanks.

Review of attachment 326666 [details] [review]:

Looks good, thanks.

Thank you, Richard, for pushing and I'm sorry for responding late. Now we have the following views (children of stack_main) with the following state:

* Installed,
* Updates,
* Extras,
* Search - max width of these four set to 860px in the fix for bug 758662.
* Moderate - newer view but copied from the above so also has max width = 860px
* Details - this fix sets the max width of the outer box to 860px, the inner box to 812px, the difference comes from the margins 2x24px
* Category - max width of the right panel is 1338px and should not be much smaller (fixed as bug 758669); left panel - minimum (!) width 220px and one can expect it won't be much wider.
* Loading - does not matter, this view is 480px wide and probably won't be wider.
* Overview - no maximum width set explicitly but the children force it to be 1338px, actually 1314px due to the margins 2x12px. It should not be smaller because this is also the minimum width to display 8 recommended application tiles.

Jakub, Allan, is there anything we can do here? If you want different max width values for these pages you can set them now. For other pages I suggest doing nothing. Can we close this bug report?

(In reply to Rafal Luzynski from comment #23)
> Can we close this bug report?

I think so. Thanks all!