http://blog.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 Liebkies </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, or even a few centuries before mind reading is finally brought to light before the general public. I would like to invite neuroscientists, engineers and physicists to speak on the scientific explanation behind mind intrusion and mind reading. Please remember what Singapore Citizen Mr. Teo En Ming (Zhang Enming) have said. Mark my words. You will know the truth in future. It is no longer a conspiracy theory. I can affirm that it (mind intrusion and mind reading) is indeed happening to me. Yours truly, Singapore Citizen Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics)(Singapore Polytechnic) BEng(Hons)(Mechanical Engineering)(National University of Singapore) Singapore Identity Card No/NRIC: S78*6*2*H Toa Payoh Lorong 5, Singapore Mobile Phone: +65-8369-2618 </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 Martin Gräßlin KWin Maintainer [1]: http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side- window-decorations/ [2]: http://mail.gnome.org/mailman/listinfo/wm-spec-list_______________________________________________ compiz mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz </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 Compiz is doing on its own or if it's Ubuntu's Unity stuff, and how I can keep this from happening? Thanks very much!!! </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 doing now with libappindicator and libdbusmenu + dee). Pretty much everyone is doing it differently now, and this fragmentation is probably going to become problematic soon I think. Cheers, Sam </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 mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz </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/compiz </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 decoration API as that causes KDE4-Window-Decorator to crash (this is the most often reported bug against KWin). This has let to a stagnation in our decoration API as we don't dare to touch the code again. Nevertheless I plan to change the API in 4.7 and our most prominent decorations (Oxygen and Aurorae) will move to it. Now with the git transition there might be a solution for these kind of problems: Compiz's KDE Plasma integration is moved to KDE's infrastructure and could be released in sync with the rest of Plasma. This means you don't have to care about the release (done by KDE's release team). Additionally you get the advantages of the KDE community like the Krazy checks [1] and developers going through the code and fix common issues. Translation would be provided by KDE's translation infrastructure ensuring that the code is translated into all the languages KDE supports and providing a consistend translation. Concerning better support for changes in Plasma/KWin integration and decoration API, there is the chance that KWin developers will directly port changes to Compiz if it is in the same repository. Especially the decoration API is that small that we can add support to Compiz directly. Nevertheless there are a few things you should be aware of: * Everybody with commit rights to KDE would be allowed to commit to it. * You would need a KDE commit account to be able to commit to the repository (though KDE hands out commit rights rather easily and you are all proven members of the community) * You would probably need to go through a two weeks Review Process which requires that there are no reported Krazy issues. Last time I looked into the Compiz KDE integration part the code was not in a state to get through review directly (As you are also using C++ I can only recommend to run KRazy checks on your main repository, too. It should also find generic options and KDE specific checks can be disabled.). Depending on where the repo will me moved that step might be omitted. The last point gets me directly to where to move the code. There are several options: 1. Own repository either in extragear or as part of KDE SC. KDE SC would mean releases synced with rest of KDE. 2. Part of workspace repo. Same as option 1 with SC, but you get also access to the private libs of workspace. This means you could add support for KDE's activities, use Kephal for screen handling and could in general add more integration for Plasma. Disadvantage: KDE does not use submodules so the code needs to be imported, which means the code really has to move to KDE infrastructure. 3. Part of KWin. That is same as option 2, plus you could use KWin internal code. E.g. no need to duplicate decoration code any more, make use of KWin parts separated from core (e.g. Alt+Tab). This is probably the best integration you could get. Personally I would prefer option 3 from an integration point of view. My current plans are to modulize KWin which would allow to make use of more KWin features. If there is interest from your side for going such a step, I would contact KDE's sysadmins to evaluate a possible merge path. Cheers Martin Gräßlin KWin Maintainer P.S. We will probably have another Plasma developer sprint in Europe around April. It would be nice to have some Compiz developers around to discuss possible future integration and collaboration. [1]: http://quality.kde.org _______________________________________________ compiz mailing list compiz&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz </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 Compiz features that enhance desktop usability and productivity, so please send any links you have to that kind of videos. Thank you in advance, Valent. </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 ============================================== Again, same reasons as above. Also, stuff for gnome-control-center doesn't belong in a desktop agnostic core and even though you can disable it by default. And it makes packaging easier. 3rd Change: Moving the following plugins into plugins main ================================================ * cube / rotate (one of the more well known ones, but still an effect) * wobbly The above reasons and also the semi-obvious ones listed next to the plugins. 4th Change: Moving the following plugins in to plugins extra ================================================ * annotate (it's for drawing on the screen, not managing windows) * blur (it's an effect) * ini / inotify (we recommend people to use compizconfig now, but ini/inotify should still be available in case people don't want to use it) * screenshot * water Same reasons as above 5th Change: GConf Schema Generation moved out of core ================================================ Currently we generate GConf schemas for all the plugins in the CompizPlugin.cmake buildsystem. Even though you can turn it off, I still think that keeping this in core as a matter of principle is wrong. Also, the rest of GNOME is moving from GConf to GSettings and we will need to write a GSettings backend and GSettings schema generation. I don't think that we should have both in core when that happens. I propose that we move the GConf schema generation into compizconfig-backend-gconf's buildsystem and out of CompizPlugin. I have already created a simple way to add build hooks to plugins [1] so we will install a CompizGenGconfSchemas.cmake into ${PREFIX}/share/cmake/plugin_extensions, which when installed, will automatically be processed any time a plugin is built (so that schemas can be built for the plugin). Of course, this leaves the problem that core needs to be built first and then compizconfig-backend-gconf and then core again if you want to get the schemas, but I have also found a solution for this as well, which allows the compizconfig-backend-gconf to automatically generate schema files for every single plugin which has already been installed. 6th Change: Split gtk-window-decorator into two decorators ================================================ As everyone probably knows, gtk-window-decorator is really two window decorators in one - a simple window decorator which uses cairo to draw a decoration which changes color based on the current highlight_color of your gtk theme and also a window decorator which uses libmetacity-private to render the decoration based on your current metacity theme. If you don't want to build the metacity section, you can just disable USE_METACITY on build. This of course, is a mess. I think that we should split these into two decorators, a cairo one and a metacity one and have a shared libgdkcompizdecorator.so. This probably won't happen until the next release though. I'll do this in about 4 days, so please give me some feedback before I do. Kind Regards, Sam [1] http://git.compiz.org/compiz/core/commit/?id=b45a3a77866e037c90f13f45537187bd8bb30f0f </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