GNOME Bugzilla – Bug 387809
Using compiz means window decorators to be missing.
Last modified: 2015-11-14 16:47:06 UTC
Originally reported at https://bugs.launchpad.net/distros/ubuntu/+source/compiz/+bug/74008 After filing https://bugs.freedesktop.org/show_bug.cgi?id=9357 determined that this is a screenshot bug. As David R says: "That's because gnome-screenshot assumes that the window manager is reparenting client windows into frame windows. Compiz doesn't do that. This is not a compiz bug. gnome-screenshot and other screenshot utilities that make the same assumption should be fixed."
same happens here (gnome-utils-2.16.0-1.fc6)
gnome-screenshot does not assume anything: the window border are included only if the "include-border" GConf key is set to TRUE, or command line argument is given. the problem is that the common path used by the include-border option doesn't seem to work with compiz, so "include-border" is not honoured. gnome-screenshot tries to find the current window using the _NET_ACTIVE_WINDOW X property and then, if 'include-border' is set to TRUE, it walks back the window chain until it finds the window frame. I don't know why compiz doesn't do the reparenting, and neither understand why it can't behave like every other window manager; if compiz authors wish to share how to fix this misbehaviour, I'm all ears.
Emmanuele, can you hash it out with Davidr on that freedesktop bug I first posted?
(In reply to comment #3) > Emmanuele, can you hash it out with Davidr on that freedesktop bug I first > posted? sure.
The freedesktop bugs had some comments about the bug, looks like there is no need for extra information
still problem in gnome 2.20
anyone is working on this?
According to http://live.gnome.org/RoadMap (see the Screenshot section) someone is going to work on making the screenshot program work with Compiz. So, I suppose the answer to this question will be yes. But then again, I am not an official developer.
Please update version to 2.22.0. This bug STILL appears.
Still affects 2.24.1. I also believe that this bug should receive some priority, since there are a lot of distributions that are enabling compiz by default.
I'm actually closing this bug as WONTFIX. gnome-screenshot is GNOME's screenshot utility, and GNOME ships with Metacity - which is a reparenting window manager. Compiz is a non-reparenting window manager, and as such it has its own screenshot utility because there is *no way* for any third party tool outside the window manager to actually extract the frame and composite it correctly. I'm not convinced implementing an IPC to extract the window manager frame is a good solution, and surely it would take time to be implemented "client"-side (screenshot utilities) and "server"-side (window managers) - let alone in a standard (even "freedesktop.org standard") way. (In reply to comment #10) > Still affects 2.24.1. I also believe that this bug should receive some > priority, since there are a lot of distributions that are enabling compiz by > default. those distributions should then update the applications menu and the key shortcuts for taking a screenshot to use Compiz tools, not gnome-screenshot. please, file a bug to the distribution bug tracking system.
This is a great disappointment. GIMP can do it, GScrot can do it. From what I see, this issue was one of the most desired when using Compiz (and let's be clear, very soon the very majority of Gnome users will use Compiz instead of Metacity, if not already). Compiz does not have a serious screenshot tool itself.
(In reply to comment #12) > This is a great disappointment. GIMP can do it, GScrot can do it. all of these just take the _NET_WM_FRAME_EXTENTS area and get the corresponding area of the screen; this will hardly work with non-square frames, and will create the wrong screenshot. > From what I > see, this issue was one of the most desired when using Compiz (and let's be > clear, very soon the very majority of Gnome users will use Compiz instead of > Metacity, if not already). it may be so (even though I don't think it's even remotely true), in which case all of these users should just use Compiz screenshot tool. anyway, GNOME does not ship Compiz as part of the desktop. > Compiz does not have a serious screenshot tool itself. then open a bug in Compiz BTS to improve their tool.
I don't want to argue in any sense. I can see that from a developer perspective you may be right. I am a developer myself and I know that often users just demand something in a completely wrong way. Compiz should provide it's own tool to capture screenshots. All of this may be true. But from a user perspective, we currently (and for quite some time) don't have a tool to capture nice screenshots. Sad. I was really looking forward for gnome-screenshot to improve its behaviour also because of Gnome 2.24 roadmap: http://live.gnome.org/RoadMap/Archive "# Rewrite the capture logic and make it work properly under Compiz" I just wanted to explain the incentives. Of course thanks for your work. Some more suggestions: >all of these just take the _NET_WM_FRAME_EXTENTS area and get the corresponding >area of the screen; this will hardly work with non-square frames, and will >create the wrong screenshot. I dare to say that it is certainly better than what gnome-screenshot is currently doing. At least this change could be incorporated. If it is not possible, the relevant checkboxes (include border etc.) should be disabled under Compiz not to mislead people and report bugs, but to show that this functionality is not available.
I must say that I also think that this would deserve to be reopened as I think that it's still a valid bug as gnome-screenshot has a illogical behavior here. It's true that this bug is related to components that are not GNOME related and while many users would like gnome-screensaver to work with compiz in the same way that it does with metacity, it's also true that it might be considered as a feature request. However, the bug is still a bug and it can probably be fixed with the implementation of the feature or by disabling the option when compiz is enabled if gnome-screensaver is not about to support compiz.
@Emmanuele Bassi, after reading DavidR's reponse comment here: https://bugs.freedesktop.org/show_bug.cgi?id=9357#c4 Could you please consider re-opening this bug just to break the stalemate? Lots of people are having a poor experience with GNOME because of this bug. Even though I completely understand if you don't have time to work on this personally, can you at least undo the WONTFIX. I'm thinking if the bug is re-opened that at least that signals that GNOME might accept a patch if someone writes a good one.
(In reply to comment #16) > @Emmanuele Bassi, after reading DavidR's reponse comment here: > https://bugs.freedesktop.org/show_bug.cgi?id=9357#c4 > > Could you please consider re-opening this bug just to break the stalemate? Lots > of people are having a poor experience with GNOME because of this bug. > > Even though I completely understand if you don't have time to work on this > personally, can you at least undo the WONTFIX. I'm thinking if the bug is > re-opened that at least that signals that GNOME might accept a patch if someone > writes a good one. having it resolved doesn't mean that the bug is removed from bugzilla. if somebody wants to come up with a patch for gnome-screenshot to make it work with non-reparenting window managers then he or she is free to do so, attach it here and reopen the bug - or open a new one, and I'll mark this as a duplicate. I'll then proceed to review such patch. up until that day I don't believe this is a bug in gnome-screenshot, and the changes that should be done to support this are so many and so pervasive that I don't think they will ever be implemented. another thing to note is that non-reparenting window managers will be able to turn on client-side decorations for gtk+ applications, as soon as the support lands in gtk+ itself. it won't help with other applications, though. seriously: if your window manager does not reparent then it should provide its own screenshot tools. gnome-screenshot caters to Metacity (and Mutter, for GNOME 3.0) not to every window manager that can possibly be written that doesn't honour any of the conventions on X11.
Hello! I found this page while looking for information on a problem with gnome-screenshot I've encountered after finally switching to Compiz. Now, the discussion here explains the problem quite well and I can see why you'd not rewrite the program around it. What I disagree with, however, is the current solution. A proper fix for this problem, I think, is disabling the "Include the window border" checkbox if the user is running Compiz (or a non-reparenting window manager in general, if you can reliably detect that). Just leaving it there as it is may lead users unfamiliar with such behaviour to think it's a bug. A hint or even a help entry explaining why it cannot be done would also help. Consider reopening the bug and implementing such behaviour in order avoid further user confusion and/or this being reported once again. Thank you.
*** Bug 610926 has been marked as a duplicate of this bug. ***
@ebassi, do you know any bug number / branch / wikipage or similar for this "client-side decorations for gtk+ applications" work?
(In reply to comment #20) > @ebassi, do you know any bug number / branch / wikipage or similar for this > "client-side decorations for gtk+ applications" work? there is a branch in the gtk+ repository: http://git.gnome.org/browse/gtk+/log/?h=client-side-decorations by the way, Compiz developers told me that the unstable branch now brings back reparenting of the window inside a frame. much rejoicing.
ah great news. thanks for the update ebassi.
*** Bug 635109 has been marked as a duplicate of this bug. ***