http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3147 <pre>Hello everyone, what I am trying to achieve seems rather simple. I would like to enumerate all open windows with respect to their current workspace. The problem seems to be that Compiz does not differentiate between workspaces as other (EWMH compliant?) window managers do. I'm not even sure whether this is a bug or a design decision. Let me explain this with an example: Running Compiz gives me this: $ wmctrl -l 0x02a00001 0 N/A N/A 0x02a00002 0 N/A launcher 0x01a00005 0 max-station Kontaktliste [...] But I think it should rather be like this: $ wmctrl -l 0x02a00001 0 N/A N/A 0x02a00002 0 N/A launcher 0x01a00005 1 max-station Kontaktliste [...] So. Is there any way to achieve this? I need this to get a Python tiling script working. Without the differentiation between workspaces all windows will be tiled when using something similar to PyTyle, stiler, etc. I'm currently running Compiz 0.9.4.0 (unmodified) on Ubuntu 11.04 with Unity. Cheers and thanks in advance, Max</pre> Max Liebkies 2011-07-21T11:57:29 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3146 <pre>16 May 2011 Monday 7:28 P.M. Singapore Time For Immediate Release SINGAPORE, SINGAPORE - Singapore Citizen Mr. Teo En Ming (Zhang Enming) would like to report first hand account of mind intrusion and mind reading. I have been hearing voices for quite some time now but I have not been able to identify the persons physically. A number of un-identified persons have intruded into my mind and they are able to read my thoughts. I could not explain the mechanism by which these un-identified persons have been reading my mind at the moment but there is definitely a scientific explanation for it. I know very clearly that I am not suffering from schizophrenia at all. I am fully aware that no common man would believe me except the select few scientific researchers working in top secret government projects and the human guinea pigs who are being experimented on. One of the possibilities is that I have a microchip implanted into my brain, possibly when I was an infant. It may take a few years, a few decades,</pre> Singapore Citizen Mr. Teo En Ming (Zhang Enming 2011-05-17T12:38:23 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3145 <pre>I dare to answer even if I am not a Compiz dev :-) While the Compiz/Unity behavior is most likely a bug, the real issue in the cases of Wine, Chromium and now Vmware is that they are using Client Side Windowdecorations (CSD). CSD is a broken concept and there is no way to guarantee that the window managers do not add a window decoration. A window manager is always allowed to reparent the window and for some window managers it is even required (e.g. some tiling window managers). In fact I have been thinking about deliberately breaking KWin's support for the legacy support of requesting no decoration (as used by Chromium). You can find an extensive summary about all the issues with CSD on [1]. My recommendation to you is to rethink the approach and work together with the window manager developers on what your requirements really are (e.g. why do you need no decoration) and how you can get what you need. A proper place for such a discussion is most likely the wm-spec mailing list [2]. Kind Regards M</pre> Martin Gräßlin 2011-05-07T06:35:12 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3144 <pre>re, all. Here's a bug filed against Google Chrome for the same problem: http://code.google.com/p/chromium/issues/detail?id=80856 and here's some forum users complaining about the same problem, and regrettably their solution is to stop using Ubuntu's Unity mode: http://ubuntuforums.org/showthread.php?t=1742354. I work for VMware and for our Unity mode (which has the unfortunate name as Ubuntu's new Unity mode), where we show individual guest Virtual Machine windows in the Linux host environment as individual windows, we use undecorated windows, similar to how Wine shows Windows applications in X without having to be inside the full Windows desktop container. The problem I'm trying to figure out a solution for is that when our user maximizes the guest window and then unmaximizes it in Ubuntu 11.04's default Unity desktop environment, Compiz is putting a titlebar onto our window just like it puts one on Google Chrome. Can you guys please help me understand why Compiz is doing this, if it's something that Com</pre> vr< at >movingparts.net 2011-05-06T22:24:37 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3143 <pre>Hi list I'm trying to get access to the Compiz forums, but I am greeted with a "403 - Forbidden"-page. Is this a known issue? Regards, Rune </pre> Rune K. Svendsen 2011-05-01T18:41:48 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3142 <pre>On Fri, Feb 18, 2011 at 1:33 AM, Silvia Dobrota &lt;silvia.dobrota09&lt; at &gt;imperial.ac.uk&gt; wrote: Looks great! Applied. Thanks, Sam </pre> Sam Spilsbury 2011-02-24T04:25:39 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3141 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys! This is my first patch for compiz. I found it very annoying that when you filter for some plug-ins, click on one of them and later come back to the main page, the filter entry is not focused anymore so you have to click on it with your mouse, in order to search for other plug-ins. Thank you, Silvia -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNXVuWAAoJEPYkGph0x7WujUcH/jl+FTSrJYO0EPe5LeLBKy05 Xm3w8WlGrlK7HY+ZpNghrlL4PuDUJfkyCUwmKlIRg4EqinmzagBQcjhDZv7d7bIF 9Zahrqmcbn6ZLT7z4J6+CN2ZJNzk+E/fYYOiXOEdRCfsYO6QqSP6X/ojq2wnm6QN AqkkvDF9XEjQXle7rBtD7CjA96quOp4EHVtFPheTe+OP4eQ4+0ghP9fEBVOUco+i 7egk9PbUHn04DBWIfSX+olvbujMEQOODcpNWgxqg/k0l0Y0dwpCDIcVFu0aGR52U usttwS2Upen1iaVW4wWwSjyh9O/i2ABOf50MnxtT65u25IjK3GH1cU84zwD68FA= =Zu8s -----END PGP SIGNATURE----- </pre> Silvia Dobrota 2011-02-17T17:32:06 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3140 <pre>From 5801cf0fbacde51ec60664efb1dd675a725b0f99 Mon Sep 17 00:00:00 2001 From: Silvia Dobrota &lt;sd3209&lt; at &gt;doc.ic.ac.uk&gt; Date: Thu, 17 Feb 2011 17:19:19 +0000 Subject: [PATCH] Focus filter entry on return to main page --- ccm/Window.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/ccm/Window.py b/ccm/Window.py index 9478f34..1b57fcf 100644 --- a/ccm/Window.py +++ b/ccm/Window.py &lt; at &gt;&lt; at &gt; -96,6 +96,7 &lt; at &gt;&lt; at &gt; class MainWin(gtk.Window): def BackToMain(self, widget): self.SetPage(self.MainPage) + self.MainPage.filterEntry.grab_focus() def RefreshPage(self, updatedPlugin): currentPage = self.CurrentPage </pre> Silvia Dobrota 2011-02-17T17:33:26 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3139 <pre>For when is 0.9.4 planned? That sounds as a good solution Apart from GNOME blocking the status notifier standardization and having implemented something different for GNOME Shell which would require patching all apps :-( Given the current activity on wm-spec I doubt that's useful at all. To your last thread nobody except me replied. On that basis it does not look like it's possible to standardize anything anymore. I have great hopes in Desktop Summit to get the standardization body set up again. But maybe it needs a complete restart as it's not about WMs anymore. Cheers Martin _______________________________________________ compiz mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz </pre> Martin Gräßlin 2011-01-23T14:13:55 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3138 <pre>yes not sure if 0.8 is really required to be supported and even if the Sam's idea to have both in one sounds better. If distri's continue to ship 0.8 together with recent versions of KDE, it would be better to tell them to drop KWD (quite pointless to include something what crashes in all cases). With git that should not be a problem ;-) Martin _______________________________________________ compiz mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz </pre> Martin Gräßlin 2011-01-23T14:08:45 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3137 <pre>Hi All, Sorry I haven't gotten into this earlier, I have been busy fixing bugs and doing other things. Most points have been covered though, so I'll just add some things which could be interesting to consider. I agree with the general premise of where the discussion is going, and think that the best time to look into this is after 0.9.4 when I start to look at the modularization of compiz code again. As a small aside, I think it should be possible to merge the 0.8 and 0.9 decorators and change functionality depending on which decoration API is supported (we announce it in the property). I'll look into this once I get back to looking at further modularization of git components. I have a working version of this in fact, but nobody really looked at it so it never got merged in. I think it would be interesting to discuss at the Desktop Summit and beforehand on wm-spec a standard for pushing UI componentry into the compositing manager (with wayland and such in mind here), in a standard way (like Ayatana is </pre> Sam Spilsbury 2011-01-21T11:12:49 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3134 <pre>That would be the first solution: own repository in KDE. But it still has some problems which would need to be solved. E.g. to push a commit to KDE's git repo, the committer must have an account. But we have awesome sysadmins to help on that if we agree on going such a way. Which rules out the option to have it in workspace as AFAIK KDE's git infrastructure does not support submodules. But it would be something to revalidate with sysadmins. Well for Compiz I see there a better integration into Plasma, the "official blessing" from a competitive project and of course the chance for improving the existing integration (there are several things I would like to see improved, e.g. swap KWin's configuration modules against Compiz's when Compiz is used) and more collaboration (in that regard the refactoring work might become handy). thanks, I just picked the first one in my inbox - both are too low traffic to know which one is the real ;-) Martin _______________________________________________ compiz mail</pre> Martin Gräßlin 2011-01-20T22:02:54 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3132 <pre>The question is whether Compiz can provide BC. KWin provides BC for the decoration API, but the problem is that KWD is not a decoration, but "plays KWin" ;-) From a release point of view it seems easier to just also release the KDE integration when Compiz does a release. From what we have seen KDE has more releases with significant changes to API than Compiz has. True but it is a difference whether it's part of our product or your product. I forgot to mention that I was talking about the "classic" tabbox and not one of our effects. Our classic Tabbox is more like a framework to create tabboxes ;-) I want to split up Workspace into small pieces which make it easier to maintain and to test. Ultimate goal is to have Workspace in a state that we can easily add Wayland support and drop X support ;-) Or so to say turn KWin into a libwindowmanager. Regards Martin _______________________________________________ compiz mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/</pre> Martin Gräßlin 2011-01-20T18:42:53 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3131 <pre>Hi, Agreed. Indeed, that's a problem. I don't agree with this conclusion, though: Releasing KWD with KDE just moves the code-is-broken-due-to-unsynced-release problem from 'KWD is broken when KDE code is changed' to 'KWD is broken when Compiz code is changed'. I'm not sure how that improves things, especially given that Compiz 0.8 (which is still widely used) and Compiz 0.9 have different decoration APIs (to accomodate non-composited rendering and reparenting in 0.9). With the current state of things you could provide a patch and we could do our best to do a new release ;-) Taking aside the point that Alt+Tab is implemented in the plugins, not the decorator (which only renders the tabbox frame), I must say that personally the look of Kwin's Alt+Tab implementation is one of the things that makes me use compiz on KDE ;-) What is your ultimate goal/plan here? What parts of Kwin do you want to modularize? Regards, Danny </pre> Danny Baumann 2011-01-20T10:55:28 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3130 <pre>Hi Compiz developers, as you might know KDE will transition to git somewhen next week. This gives some new possibilities for the Compiz community, too. Let me first describe the current situation and the problems with it: Compiz and KDE releases are out of sync. We are currently more and more integrating features from the desktop shell into the window manager. In difference to other desktop shells (GNOME Shell, Unity) Plasma still allows to use a different window manager and has not removed any legacy code. This is a hughe advantage and although it does not look like other shells care about supporting different window managers I do not want to lose the possiblity to switch the window manager. Up to now Compiz has done a great job of supporting our additions, so that Compiz users get the same level of integration as KWin users. Nevertheless due to the fact that releases are out of sync Compiz users do not get new features when KDE has a release. This gets to a real problem when KWin changes the </pre> Martin Gräßlin 2011-01-16T16:07:46 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3129 <pre>I'm not expert at all, but I would never recommend enabling Compiz by default on a Live CD/DVD at the stage Compiz/X11 it's right now. At least ask the user at boot stage. On Mon, Dec 6, 2010 at 5:00 PM, &lt;compiz-request&lt; at &gt;lists.freedesktop.org&gt;wrote: _______________________________________________ compiz mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz </pre> okasion 2010-12-07T04:46:00 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3128 <pre>Hi guys, let me first introduce myself, I'm Fusion Linux (www.fusionlinux.org) project leader. Fusion Linux is a Fedora Remix that includes all the best software that is available for Linux. Fusion uses a combination of free and open-source, non-free and non-open-source firmware and software, to bring the user the most advanced experience on the Linux platform. Fusion Linux is 100% compatible with Fedora. A Fedora Remix including packages from Fedora and RPM Fusion software repositories plus some custom packages. We would like to enable Compiz by default in our next release. From what I have seen there are few Compiz configuration tools, right? Which one do you recommend we include by default for non-advanced users? We would like to enable Compiz by default for our Live DVD and Live USB versions automatically, which way is best to enable Compiz? Do we need to edit some gconf options or just start compiz via terminal? I would also like to include some great Compiz video that show of some of the best Com</pre> valent.turkovic< at >gmail.com 2010-12-05T20:00:58 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3127 <pre>Hi Everyone, I'm going to make some big structural cleanups to core which is likely to affect everyone here, but I believe is for the better, so I am posting this mail now to get some feedback and make sure that we don't tread on anyone's toes when I merge all of this stuff. 1st Change: Decorators are going in their own repo ========================================= The decorators are going to be taken out of core and put into individual git repositories (/compiz/decorators/kde4-window-decorator /compiz/decorators/gtk-window-decorator) so that we can work on them individually. Making commits to core when working on these decorators is annoying when it comes to bisecting other problems in core and in the decorators themselves too, so we should just move them to separate repos. This also helps package maintainers in the long run, since they no longer need to do 3 separate builds of compiz in order to get a compiz-kde or compiz-gnome package 2nd Change: GNOME Integration stuff into it's own repo ==========</pre> Sam Spilsbury 2010-11-13T10:35:17 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3122 <pre>_______________________________________________ compiz mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz </pre> Martin Gräßlin 2010-08-18T19:25:30 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3121 <pre>_______________________________________________ compiz mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz </pre> Martin Gräßlin 2010-08-18T19:16:04 http://permalink.gmane.org/gmane.comp.video.opengl.compiz.general/3118 <pre> The key enlightenment developer has been CC'd in. </pre> Sam Spilsbury 2010-08-17T00:49:28 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.opengl.compiz.general