After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 675242 - odd behavior on maximize
odd behavior on maximize
Status: RESOLVED OBSOLETE
Product: mutter
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2012-05-01 14:05 UTC by William Jon McCann
Modified: 2021-07-05 13:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot (83.50 KB, image/png)
2012-05-01 14:06 UTC, William Jon McCann
  Details
window: Recalc features on size/position change (945 bytes, patch)
2012-05-01 18:19 UTC, drago01
rejected Details | Review

Description William Jon McCann 2012-05-01 14:05:18 UTC
I'm testing out the patches on https://bugzilla.gnome.org/show_bug.cgi?id=673869
and noticing some odd behavior.

* We ask the window to remove the titlebar on maximize and most of the time that isn't happening.
* We ask for the window to be maximized and most of the time that isn't happening

The behavior isn't always the same.
Comment 1 William Jon McCann 2012-05-01 14:06:53 UTC
Created attachment 213209 [details]
screenshot
Comment 2 William Jon McCann 2012-05-01 16:44:45 UTC
Part of the problem seems related to when we set has_maximize_func.

I started the same app twice in a row and got these two different results:

VERBOSE: Request to change _NET_WM_STATE action 1 atom1: _NET_WM_STATE_MAXIMIZED_VERT atom2: _NET_WM_STATE_MAXIMIZED_HORZ
VERBOSE: Request to maximize 0x1c0000b (System Set) horizontally max:1 has-max-func:0

VERBOSE: Request to change _NET_WM_STATE action 1 atom1: _NET_WM_STATE_MAXIMIZED_VERT atom2: _NET_WM_STATE_MAXIMIZED_HORZ
VERBOSE: Request to maximize 0x1c0000b (System Set) horizontally max:1 has-max-func:1

The first didn't work. The second did.

It seems that has_maximize_func is being disabled due to this:
VERBOSE: Disabling maximize since larger than workarea w: 740 >= 800 h: 628 >= 600

But it seems that when the size changes the has_maximize_func is not being updated or something.
Comment 3 William Jon McCann 2012-05-01 16:57:48 UTC
So I think this occurs in this case:

gtk_scrolled_window_set_min_content_height (GTK_SCROLLED_WINDOW (scrolled_window), LARGE_HEIGHT);
gtk_window_present(window);
gtk_scrolled_window_set_min_content_height (GTK_SCROLLED_WINDOW (scrolled_window), SMALL_HEIGHT);
gtk_window_maximize(window);


The part about the titlebar showing when maximized... it still has a titlebar when maximized if I launch the app from the command line, but it correctly hides the titlebar on maximize if I launch from the shell.
Comment 4 drago01 2012-05-01 18:19:18 UTC
Created attachment 213227 [details] [review]
window: Recalc features on size/position change

Recalculate the window features when the window's position or size changes
to make sure that features that depend on the are up2date.
Comment 5 Jasper St. Pierre (not reading bugmail) 2012-05-01 18:31:19 UTC
Review of attachment 213227 [details] [review]:

"up to date", but yeah.
Comment 6 Florian Müllner 2012-05-01 19:55:25 UTC
(In reply to comment #3)
> The part about the titlebar showing when maximized... it still has a titlebar
> when maximized if I launch the app from the command line, but it correctly
> hides the titlebar on maximize if I launch from the shell.

It works from the command line as well if you launch it as "gnome-control-center --overview" - otherwise, the call to gtk_window_set_hide_titlebar_when_maximized() is not in the code path, so the corresponding x property is not set. Also note the odd behavior when launching a specific panel - there is a titlebar until switching to the overview, then the titlebar remains hidden when switching back to the previous panel.
Comment 7 Jasper St. Pierre (not reading bugmail) 2012-05-02 18:03:07 UTC
Review of attachment 213227 [details] [review]:

After discussion on IRC, this isn't the best way to go about this.
Comment 8 GNOME Infrastructure Team 2021-07-05 13:52:03 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/mutter/-/issues/

Thank you for your understanding and your help.