GNOME Bugzilla – Bug 678960
Make window size be limited by contents
Last modified: 2016-03-31 14:01:56 UTC
Right now the toplevel window size is not constrained at all, i.e. you can make its small enough to not even fit the toolbar. Clutter-gtk now has support for the use-layout-size property on the GtkClutterEmbed to fix this. However, just enabling leads to some issues with the current codebase. Boxes does almost all UI inside the main window (i.e. not in dialogs), which means that some pretty large UIs sometimes appear in the window, like the new box Wizard. This is problematic if the toplevel window currently is smaller than the new UI state. There are two solutions here, we can grow the window, or we can ensure that the window will never be smaller than needed for the largest UI needs in its minimal state (even if its currently not showing the largest UI). I've discussed this with the designers, and the least bad approach is the second, so that we don't unexpectedly change the size of the toplevel. We implement this by enabling use-layout-size, and ensuring that all clutter actors that affect the toplevel layout are always "visible", i.e. we hide them by setting opacity to 0 rather than hiding the actors. We also do some tweaking of the Wizard layout to make the minimal size smaller as that now affects the toplevel window minimal size.
Created attachment 217379 [details] [review] Make window size be limited by UI contents Right now the toplevel window size is not constrained at all, i.e. you can make its small enough to not even fit the toolbar. Clutter-gtk now has support for the use-layout-size property on the GtkClutterEmbed to fix this. However, just enabling leads to some issues with the current codebase. Boxes does almost all UI inside the main window (i.e. not in dialogs), which means that some pretty large UIs sometimes appear in the window, like the new box Wizard. This is problematic if the toplevel window currently is smaller than the new UI state. There are two solutions here, we can grow the window, or we can ensure that the window will never be smaller than needed for the largest UI needs in its minimal state (even if its currently not showing the largest UI). I've discussed this with the designers, and the least bad approach is the second, so that we don't unexpectedly change the size of the toplevel. We implement this by enabling use-layout-size, and ensuring that all clutter actors that affect the toplevel layout are always "visible", i.e. we hide them by setting opacity to 0 rather than hiding the actors. We also do some tweaking of the Wizard layout to make the minimal size smaller as that now affects the toplevel window minimal size.
for some reason, the OSD/selectionbar is not properly centered after the patch. I also noted that sometime, only the first row of the collection can be clicked, but I don't know if this is because of this patch yet. (could there be hidden actors above?)
Its because the selectionbar is packed inside the bin to the right of the sidebar needs to be in the same place as the collection view.
Ok, so reactive actors with opacity 0 will still be picked for mouse events. We need to make them transparent as well as non-reactive.
Created attachment 217396 [details] [review] Make window size be limited by UI contents Right now the toplevel window size is not constrained at all, i.e. you can make its small enough to not even fit the toolbar. Clutter-gtk now has support for the use-layout-size property on the GtkClutterEmbed to fix this. However, just enabling leads to some issues with the current codebase. Boxes does almost all UI inside the main window (i.e. not in dialogs), which means that some pretty large UIs sometimes appear in the window, like the new box Wizard. This is problematic if the toplevel window currently is smaller than the new UI state. There are two solutions here, we can grow the window, or we can ensure that the window will never be smaller than needed for the largest UI needs in its minimal state (even if its currently not showing the largest UI). I've discussed this with the designers, and the least bad approach is the second, so that we don't unexpectedly change the size of the toplevel. We implement this by enabling use-layout-size, and ensuring that all clutter actors that affect the toplevel layout are always "visible", i.e. we hide them by setting opacity to 0 and reactive to false rather than hiding the actors. We also do some tweaking of the Wizard layout to make the minimal size smaller as that now affects the toplevel window minimal size.
Created attachment 234299 [details] [review] Put selection toolbar in the right place in the UI The selection toolbar is over the CollectionView which is in below_bin, so put the toolbar there too. Without this the selection toolbar is centered over the area to the right of the sidebar, rather than over the whole icon view.
Created attachment 234300 [details] [review] Don't allow smaller window than the UI requires We activate the GtkClutter.Embed use-layout-size mode to ensure this. With this it may happen that the window size grows when you switch to a new mode, like the wizard. However, since the UI packing is pretty good these days this really only happens for really tiny window sizes which are not very common. And any way, its far better than just cutting off the UI.
Rebased the patch and dropped all the weird code that tried to allocate space always for all possible elements. It complicated the code quite a bit for something that in practice (at least with the current UI) almost never happens.
Review of attachment 234300 [details] [review]: If you have an ISO unknown to libosinfo with a very long name, this enlarges the window (needs to be ellipsized I guess)
Review of attachment 234300 [details] [review]: Same if you give a very long name to the VM in the properties
Review of attachment 234299 [details] [review]: ack
Comment on attachment 234299 [details] [review] Put selection toolbar in the right place in the UI Attachment 234299 [details] pushed as b986951 - Put selection toolbar in the right place in the UI
Created attachment 237152 [details] [review] Ensure all potentially long labels are ellipsized
With the last two patches i have no problem with overlong strings making the window wide.
Yeah works nicely for me too, ACK to the remaining patches in this bug. Potential bikeshedding on PANGO_ELLIPSIZE_MIDDLE vs PANGO_ELLIPSIZE_END as I tend to prefer the former, but _END is not bad either.
Attachment 234300 [details] pushed as 4bcdb19 - Don't allow smaller window than the UI requires Attachment 237152 [details] pushed as a529d83 - Ensure all potentially long labels are ellipsized