GNOME Bugzilla – Bug 727414
Redundant text in titlebar
Last modified: 2016-06-30 17:33:54 UTC
Created attachment 273375 [details]
gtk3-demo 3.10.7 vs. 3.12.0
Starting with gtk+-3.11.5, the titlebar and the window content contain redundant data in dialog popups. This is *evidently* related to this documented change per:
- Dialogs have been modernized, can use a header bar now
- Built-in dialogs react to a setting, gtk-dialogs-use-header
for this, dialogs derived from GtkDialog: default to no headerbar
- GtkAssistant also respects the setting
The attached screenshot makes it clear, the left is gtk3-demo built with 3.10.7 and the other, with the duplicate text is from the latest 3.12.0 source. Also see this thread for examples of the dialog when closing GNU Emacs.
Those other examples are here:
Which windowmanager/desktop environment is this about?
Created attachment 273423 [details]
TWM and XFCE screenshots with gtk+3.12.0
The screenshot from the initial report of 2014-04-01 06:21:25 UTC was from KDE-4.12.3.
But since the issue is not dependent upon the windowing system, as proof, the attachment shows images, in top-to-bottom order of the following:
GNU Emacs-24.4 Find-File dialog
GNU Emacs-24.4 Find-File dialog
If need be, I can also submit similar screenshots from motif-2.3.4, trinity-14.R and KDE-3.5.10. In all cases, the result is the same as the four images in the composite image.
I'll also add the twiddling the Boolean values of these properties in settings.ini, either the global or per-user file, makes no difference:
Created attachment 273434 [details]
GNU emacs gtk+ 3.11.4 vs. 3.12.0
Also of possible assistance is that I can build (but elect not to install), for example, gtk+-3.11.4 and then symlink its libraries like this:
ln -sf libgdk-3.so.0.1104.0 libgdk-3.so.0
ln -sf libgtk-3.so.0.1104.0 libgtk-3.so.0
Upon doing so, applications such as GNU Emacs then return to the normal, expected behavior with dialog windows. The redundant text in the title then does not occur as evident from the screenshot, with the older library at the top and the current 3.12.0 library at the bottom.
Note that GNU Emacs was NOT rebuilt, only the linkages via the symlinks were altered,
Is there any additional information I can provide on this matter?
no additional information required
Bug 727414 - Redundant text in titlebar - UNCONFIRMED
1). Applied patch here to gtk/gtkwindow.c
The problem cited in the initial report remains.
2). Then I just cloned all of gtk+, and built, resulting in these news shared libs:
The problem remains with "double headers" to use Matthias Clasen's phrase.
Just to make sure I'm doing anything wrong, I tried this latest GIT version on different distros: Arch, Gentoo-2.2 and Slackware with KDE-4.12.X (my choice of a desktop environment) and, even with the latest version and the patch, the "double headers" are still present.
The configuration/make/install for GTK3 is:
./configure --prefix=/usr \
--enable-broadway-backend && make && make install
By the way, my quick fix for this matter is one of the following:
1). Ignore it since it's merely cosmetic and treat the "double header" as a feature. :)
2). Use KDE4's ability to suppress the titlebar and frame on a window-by-window basis. It's not too hard to disable this on the various dialogs that GNU Emacs uses.
Yes, I could always roll back to an earlier 3.10.X or 3.11.[1-4] version but I like to stay current.
(In reply to comment #8)
> Bug 727414 - Redundant text in titlebar - UNCONFIRMED
Overview of Changes in GTK+ 3.12.0 to 3.12.1
727414 Redundant text in titlebar
Stated in this thread and the URL cited above as FIXED. That's not the case. Just built gtk+-3-12.1 and the problem of "redundant text" (or "double header") remains in both KDE-4.12.4 and XFCE-4.10.1.
Created attachment 274213 [details]
KDE and XFCE screenshots (gtk+-3.12.1)
The remedy for both KDE4 and XFCE4 to eliminate what Matthias Clasen refers to as "double headers" is to enable compositing in those DEs. Here's a more detailed thread from the KDE perspective:
To clarify what came out of that KDE thread, the difference is:
Without a compositor: GTK+ asks for "border only"
With a compositor: GTK+ asks for "no decorations"
And what you are seeing is lack of support for "border only" in these environments.