Closed
Bug 900740
Opened 11 years ago
Closed 7 years ago
Hide titlebar on maximize
Categories
(Core :: Widget: Gtk, defect, P5)
Tracking
()
RESOLVED
DUPLICATE
of bug 1283299
People
(Reporter: marco, Unassigned)
References
Details
(Whiteboard: tpi:+)
Attachments
(2 files)
7.12 KB,
patch
|
karlt
:
feedback+
|
Details | Diff | Splinter Review |
13.47 KB,
patch
|
Details | Diff | Splinter Review |
It should be just a matter of setting the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property.
Comment 1•11 years ago
|
||
I was wondering why this would be a per-application property rather than a window manager configuration. [1] explains that an application may use the titlebar to convey useful information. We don't have to worry about that in Firefox because the information is duplicated in the tab. I wonder whether window managers will provide different UI for restore/minimize/close/window-menu, or if applications are expected to provide that. It seems [2] that chromium now only sets _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED when using its custom frame, which I guess provides some window controls. I skimmed that bug but didn't work out what "when the user explicitly wanted it" meant. Perhaps that was something to do with themes, or window manager configuration. [1] https://git.gnome.org/browse/gtk+/commit/gdk/x11?id=4f8f8fe828dbb5b1a2e54a26a58149e437cd5820 [2] http://code.google.com/p/chromium/issues/detail?id=137447
Reporter | ||
Comment 2•11 years ago
|
||
(In reply to Karl Tomlinson (:karlt) from comment #1) > I was wondering why this would be a per-application property rather than a > window manager configuration. [1] explains that an application may use the > titlebar to convey useful information. We don't have to worry about that in > Firefox because the information is duplicated in the tab. Yes, I agree. I've been using Firefox without a titlebar on GNOME Shell and I feel like nothing is missing. > I wonder whether window managers will provide different UI for > restore/minimize/close/window-menu, or if applications are expected to > provide that. I think that depends. For example on Unity you get the controls in the top-left corner, in GNOME Shell there are no controls when the window is maximized.
Reporter | ||
Comment 3•11 years ago
|
||
http://blogs.gnome.org/mclasen/files/2013/08/headerbar.png Looks like for some GNOME applications they've decided to use header bars for maximized windows: http://blogs.gnome.org/mclasen/2013/08/23/gnome-3-10-sightings/
Comment 4•11 years ago
|
||
Since gdk_x11_window_set_hide_titlebar_when_maximized is in gtk3 only, this can be depend on 627699.
Depends on: gtk3
Note that not all people who use GTK3 also use GNOME. GTK3 is not GNOME3! Some people will use Firefox with GTK3 on GNOME. Others will use it on Unity, Cinnamon, MATE, KDE, LXDE, Xfce, Openbox, etc.
Comment 6•11 years ago
|
||
(In reply to Eldmannen from comment #5) > Note that not all people who use GTK3 also use GNOME. > GTK3 is not GNOME3! > > Some people will use Firefox with GTK3 on GNOME. > Others will use it on Unity, Cinnamon, MATE, KDE, LXDE, Xfce, Openbox, etc. Sure. By documentation [1] the gdk_x11_window_set_hide_titlebar_when_maximized only set a hint for window manager to hide titlebar. It's up to window manager how it handles this request. At least I hope so. [1] https://developer.gnome.org/gdk3/3.4/gdk3-X-Window-System-Interaction.html#gdk-x11-window-set-hide-titlebar-when-maximized
Reporter | ||
Comment 7•11 years ago
|
||
(In reply to jhorak from comment #4) > Since gdk_x11_window_set_hide_titlebar_when_maximized is in gtk3 only, this > can be depend on 627699. Actually we could set the hint manually with GTK2.
No longer depends on: gtk3
Reporter | ||
Comment 9•10 years ago
|
||
Attachment #8415888 -
Flags: feedback?(karlt)
Comment 10•10 years ago
|
||
Comment on attachment 8415888 [details] [diff] [review] WIP This could be the best approach available, but it could have some awkward consequences. One difficult thing is that the _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED property has no corresponding way to detect whether the window manager will honour this, so it is hard to know whether to show a titlebar or not. This could lead to 2 titlebars being shown. I wondered about using MWM_DECOR_TITLE (aka GDK_DECOR_TITLE) instead as that is likely more widely supported, but GDK docs say "The hint must be set before mapping the window" and I don't know that it would be a good idea to unmap and re-map the window every time it is maximized or restored. If browser.tabs.drawInTitlebar is set then perhaps it is not a big problem if there are extra close/restore/minimize buttons, because the extra titlebar will still serve a purpose. However if drawInTitlebar is not set then there could end up being two mostly empty titlebars. Is this preference exposed in the UI? Perhaps window managers known to support _GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED can be detected individually and the client-side title bar only added there, or perhaps the preference can be used to decide whether to show a titlebar. Another difficulty is that this is removing the titlebar from all maximized windows (on some systems), but only adding buttons to the browser main window. There are other toplevel windows such as the "Library" (History) window, and other non-browser applications. It seems there should be a way to specify that the title bar is hidden, and only specify this on windows which will provide their own buttons. I don't know whether other platforms have an existing means to indicate which windows will have system-drawn title bars, or whether they are always client-drawn. Even if they have a means, I guess this may not depend on maximized state, so a new mechanism may be required. Or perhaps hidechrome/nsIWidget::HideWindowChrome() is suitable. There are many problems with client side decorations [1]. These may not matter so much if only applied to maximized windows because the user can at least restore the window to get all the functionality back. However, if some platforms don't have context menus on the decorations etc., perhaps an alternative to consider might be to use client side decorations only on these platforms so that this need not depend on whether the window is maximized. [1] http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/ > #ifdef CAN_DRAW_IN_TITLEBAR >-#ifdef XP_WIN >+#ifdef XP_MACOSX >+ chromemargin="0,-1,-1,-1" >+#else > chromemargin="0,2,2,2" >-#else >- chromemargin="0,-1,-1,-1" > #endif > tabsintitlebar="true" > #endif What is the purpose of the 2s here? >+#main-window[tabsintitlebar][sizemode="maximized"] > #titlebar { >+ -moz-appearance: -moz-window-titlebar; >+ min-height: calc(@tabMinHeight@ + 9px - @tabToolbarNavbarOverlap@); >+} >+ >+#main-window[tabsintitlebar][sizemode="normal"] > #titlebar { >+ display: none; >+} Is there a titlebar when tabsintitlebar is unset? What ensures that tabs are not in the hidden titlebar when not maximized? I don't know what the 9px here represents, but better to get a front end person to review these changes - perhaps Dão. >+ case NS_THEME_WINDOW_TITLEBAR: > return !IsWidgetStyled(aPresContext, aFrame, aWidgetType); DrawWidgetBackground() should support this drawing if ThemeSupportsWidget() can return true. I don't know that DrawWidgetBackground() knows what to do here. >+ guint32 hide = 1; "If the specified format is 32, the property data must be a _long_ array." That makes a difference on big endian systems with 64-bit longs. >+ (guchar*)&hide, Please use unsigned char* for Xlib parameters. This property should be set only on toplevel, non-popup windows.
Attachment #8415888 -
Flags: feedback?(karlt) → feedback+
Comment 11•10 years ago
|
||
What about adding "hidechromewhenmaximized" attribute to windows? It shouldn't broke anything, but it can help to add-ons authors. I just copy/pasted "hidechrome" attribute and added logic for setting "_GTK_HIDE_TITLEBAR_WHEN_MAXIMIZED" property to "nsWindow::HideWindowChromeWhenMaximized" method. I am not sure, that it works correctly with no-gtk builds. // Sorry for my bad English.
Comment 12•10 years ago
|
||
Any plan to continue this? I think adding a pref to switch this feature is enough to address the difficulity mentioned in comment 10. I guess most systems should work fine, and we can suggest the users who do use an odd system to switch off this pref themselves.
Flags: needinfo?(mar.castelluccio)
Reporter | ||
Comment 13•10 years ago
|
||
I don't have time to work on this right now.
Flags: needinfo?(mar.castelluccio)
Comment 14•9 years ago
|
||
Gtk3 provides gtk_window_set_hide_titlebar_when_maximized() and even gtk_window_set_titlebar/gtk_window_get_titlebar for this.
Updated•8 years ago
|
Priority: -- → P5
Whiteboard: tpi:+
Comment 15•7 years ago
|
||
Let's target his at Bug 1283299.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•