Hi, > Looking at the GtkHeaderBar source code, it does not appear to be the > case that Gtk is "forcing client side decorations". 3.12 did for > GtkDialog under at least some circumstances, but 3.14 does not appear to > use CSD for GtkDialog under non-GNOME.
Yes, the subject of this bug report isn't correct anymore. But as I said in my previous letter (to Tsu Jan), the inability to resize any windows that _have_ CSD is still present in 3.14. Since this is basically the same issue that has been reported originally, I think this bug should be kept open. Just the title needs to be changed. > One possibility would be to detect GNOME Shell (or some "we like CSDs" > GSetting that GNOME Shell could set), use CSD in Shell, and use WM > decorations / no title in the GtkHeaderBar on non-Shell Yes, that's what I'm thinking about. GTK+ 3.14 already has the logic that enables or disables CSD in dialog windows, depending on the current environment. Similar logic might be used to use either WM decorations or CSD. That would solve this bug for good (you would be able to resize the windows normally with a mouse). > So, it is likely that someone who advocates this > change will have to do the research, propose a solution/design that > makes sense and is implementable, and implement it. We've already seen > in this bug's discussion that attempts to patch in design changes via a > GtkModule are not sufficiently robust to be a good solution. Yes, our experiments so far led to two results, both not acceptable as a good solution yet: - the headerbar is removed completely, taking any app-specific buttons with it, making the app completely or partially unusable. The only control that's not removed is the "fallback" app menu which is converted to the "classic" menu. Not a good solution. - the headerbar is not removed, therefore some apps have duplicated window title (in WM decorations and in the headerbar). This doesn't break the functionality but doesn't _look_ good either. Since at least one headerbar item (the app menu) can be converted to the conventional menu, I was hoping to find a way to do the same for the other headerbar buttons (excluding WM controls of course) and therefore get rid of the headerbar in the end. Of course, this would be also paired with the aforementioned logic (leave the headerbars alone in Gnome Shell, convert them in other environments). That would not only solve this bug with window resizing, but also make Gnome apps look less out-of-place in the environments other than Gnome Shell. > The fact that GNOME 3.14 adds the gtk-dialogs-use-header GSetting and > the gtk_application_prefers_app_menu() function (and hence GtkDialog no > longer uses CSD, and some apps' menu structures go back to being more > traditional, under non-GNOME) indicates that there is upstream interest > in this sort of thing. Oh, that's interesting, I didn't know about gtk_application_prefers_app_menu(). In regard to what had been said above, it would certainly be nice to have some kind of gtk_application_prefers_headerbar() function as well. :) As for now, I don't know whether someone comes up with a reasonable solution, but I'm already afraid we might run out of time due to the coming freeze of Jessie.
