Merge lp:~gue5t/midori/window-state-event into lp:midori

Proposed by gue5t gue5t
Status: Merged
Approved by: Cris Dywan
Approved revision: 6741
Merged at revision: 6754
Proposed branch: lp:~gue5t/midori/window-state-event
Merge into: lp:midori
Diff against target: 21 lines (+3/-1)
1 file modified
midori/midori-browser.c (+3/-1)
To merge this branch: bzr merge lp:~gue5t/midori/window-state-event
Reviewer Review Type Date Requested Status
Cris Dywan Approve
Review via email: mp+226421@code.launchpad.net

Commit message

Use correct signature for window-state-event handler

Description of the change

Change the signal handler to return a gboolean as it should. This change results in correct maximize/unmaximize with GTK3 CSD.

To post a comment you must log in.
Revision history for this message
Danielle Foré (danrabbit) wrote :

Hm, for both Cody and I this branch makes decorations not show at all for maximized windows.

Revision history for this message
gue5t gue5t (gue5t) wrote :

> Hm, for both Cody and I this branch makes decorations not show at all for
> maximized windows.

I don't like it, personally, but that's what Midori has been doing all along, via midori-browser.c:5837: "gtk_window_set_hide_titlebar_when_maximized (GTK_WINDOW (browser), TRUE);"

Revision history for this message
Danielle Foré (danrabbit) wrote :

Do you know if there's a reasoning behind that? I feel like if the DE wanted to hide decorations for maximized windows that the WM would take care of that.

Revision history for this message
Cris Dywan (kalikiana) wrote :

The setting tells the WM that it's safe to hide the title and it doesn't contain vital pieces of information ie. wastes space by being there if it's maximized anyway.

I suppose the flaw here is that it's not just an indication but GTK+ itself does something in the backend.

Revision history for this message
Danielle Foré (danrabbit) wrote :

Yeah right now basically what we're looking at is that maximized decorations in elementary are either broken or not there at all, which isn't very ideal :p

What's the use case for this? Can we if/def this to whatever desktop environment it's supposed to support? I don't know of any other application that has this behavior.

Revision history for this message
Cris Dywan (kalikiana) wrote :

Correction, internally _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED will be set by GTK+ on X11, Gala and Mutter handle that property, not sure about WM's. So the bug is on the WM side.

Incidentally the patch is correct, it didn't add the behavior either.

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'midori/midori-browser.c'
2--- midori/midori-browser.c 2014-06-05 10:35:56 +0000
3+++ midori/midori-browser.c 2014-07-11 09:09:44 +0000
4@@ -5451,7 +5451,7 @@
5 }
6 }
7
8-static void
9+static gboolean
10 midori_browser_window_state_event_cb (MidoriBrowser* browser,
11 GdkEventWindowState* event)
12 {
13@@ -5463,6 +5463,8 @@
14 else if (event->new_window_state & GDK_WINDOW_STATE_FULLSCREEN)
15 window_state = MIDORI_WINDOW_FULLSCREEN;
16 g_object_set (browser->settings, "last-window-state", window_state, NULL);
17+
18+ return FALSE;
19 }
20
21 static gboolean

Subscribers

People subscribed via source and target branches

to all changes: