GNOME Bugzilla – Bug 151842
implement maximize to fill feature?
Last modified: 2020-11-07 12:35:49 UTC
While the rest of the world has moved to metacity, I find myself still using sawfish for a few advanced features I can't live without. One of these is a "maximize to fill" keybinding. Basically this is an available keybinding that expands a window until its edges hit other window edges, so the area is filled completely without overlapping other applications. This is very useful for opening text editors that don't cover terminals, or gimp canvases that don't cover the tool palettes. Along with features like edge resistance, this helps make windows feel less "loose" and more "solid" on the desktop. Because this is an advanced feature, it need only be accessible in gconf-editor. It doesn't have to clog the interface at all.
A patch that implements this would very likely be accepted. This is a hint.
I wish I could write a patch, but I'm totally unfamiliar with the implementation concepts of window managing and the gnome/metacity/libwnck codebase. Even if I spent a few weeks trying to figure out how window managing works, I'd probably come up with a boneheaded way of doing it. Hopefully someone familiar with the code wants this feature too.
This feature is fine with me as long as it's just a keybinding. I would not want to add it to any menus. It's basically the same thing as the existing "maximize_vertically" keybinding, since that just resizes, doesn't toggle any persistent state. You just have to call the search-for-nearest-edge edge snap functions to find the right edge to resize to.
Created attachment 31494 [details] [review] Preliminary patch for maximize to fill This is my first ever patch, so please be kind. This works for me, although gnome-terminal likes to resize itself based on the font so it never quite hits the adjoining window (unless the values divide perfectly).
Comment on attachment 31494 [details] [review] Preliminary patch for maximize to fill Right, the gnome-terminal behavior is expected. + if (window->has_resize_func) + meta_window_fill_avoid_horizontal (window); + meta_window_fill_avoid_vertical (window); Need braces there, the if() only covers the first line following. next_vertical_edge_resize( space before parens I think the naming fill_avoid_horizontal is a bit confusing; the root of this may be that the existing maximize_vertically is implemented by window_fill_vertical, and you add maximize_fill which is not implemented by window_fill. Suggest we have functions meta_window_fill_vertically_to_screen_edges(), meta_window_fill_vertically_to_next_edges() (or better suggestions welcome), and no plain fill_vertically. I would include the check_maximize_to_work_area in the new functions, since they could also happen to make a window fill the screen. What is the delta between find_next_horizontal_edge_resize() and the existing find_next_horizontal_edge()? Hopefully these functions can share more code... I think the _resize variant could also use a clearer name. Thanks for hacking on this!
Created attachment 31500 [details] [review] An updated version of my patch I renamed the old functions from meta_window_fill_X to meta_window_maximize_X since that's what they do. Then my functions become meta_window_fill_X. I'm not sure what the policy is on things like this, nothing else calls meta_window_fill so it shouldn't break anything... right? I also added a bunch of code to only bump up against edges facing the direction of expansion. Otherwise the window can bump up against the top border of a window it's already inside. There might be a much better way to do this, but I added a parameter to get_vertical_edges and get_horizontal_edges to specify whether we want to include top edges, bottom edges, or both.
You said yesterday it was ok to bump this bug. Biz-ump
I'm uploading an updated version of the patch that applies against current CVS. It seems to work well.
Created attachment 53017 [details] [review] Updated version of fit-to-fill patch
Dude, you deserve an award for patience. Sorry for making you wait so long for review. To add insult to injury, all the huge constraints changes causes approximately half the patch to fail to apply anymore. :-( Various comments on the patch: - You use a number of tabs as well as spaces, please replace all tabs with spaces. - Indentation needs to match the rest of the code style. E.g. + if (right) + get_vertical_edges (window, &edges, &n_edges, 1); + else + get_vertical_edges (window, &edges, &n_edges, -1); should be + if (right) + get_vertical_edges (window, &edges, &n_edges, 1); + else + get_vertical_edges (window, &edges, &n_edges, -1); - The old meta_window_fill functions have been removed since real vertical and horizontal maximization were implemented (bug 113601). So the name conflict shouldn't be an issue anymore. However, 'fill' seems rather vague to me and will puzzle a lot of people reading through the gconf keys. I'd suggest names more along the lines of maximize_horizontally_to_nearest_edge for the gconf keys, and similar naming for the functions.. - your gconf key descriptions have lines around 100 columns long or so; it'd be nicer if you broke it into multiple lines at about 75 characters or so like the rest of the file. - It seems odd to allow repeated maximization as this patch does. That is, if you maximize-to-fill once, wouldn't doing it again be a no-op? - you maximize to hidden edges, which is confusing. This was really due to the fact that you just use the edge finding functions in place.c but it's a drawback of those functions and I'd suggest not using them for this reason (which also means you won't need to tweak them to get just certain sides of the windows). - you implement the bidirectional maximize-to-nearest-edges stuff in terms of first maximizing horizontally and then vertically. That'd probably work just fine in most cases, but in some special cases it would give surprising results. In ASCII art, let's say the top half of your screen looks like this with two windows: --------------- | | | | --------------- --- | | | | | | | | --- and that the bottom half of the screen is empty. Your implementation would result in the top right window becoming very wide and somewhat short instead of filling almost the whole screen as most users would expect. The last three points above could be fixed with the new maximal/spanning rect stuff in boxes.c. You'd just need to pretend that all windows that don't overlap with the window you're modifying are extra panels (i.e. 'struts' as they're called in the code); then with meta_rectangle_get_minimal_spanning_set_for_region() you can generate a set of 'maximal' rectangles describing the region that doesn't overlap any of those *ahem* 'struts'. Then loop over the set, finding the largest such rectangle which already constains the window you're modifying. Given that, you just set that window's size to the rectangle. Let me know whether that makes sense or I need to try to explain it better. :)
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.