Max Liebkies | 21 Jul 13:57
Picon

Window listing on different workspaces

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.
(Continue reading)

Picon

An Invitation to Neuroscientists and Physicists: Singapore Citizen Mr. Teo En Ming (Zhang Enming) Reports First Hand Account of Mind Intrusion and Mind Reading

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,
(Continue reading)

vr@movingparts.net | 7 May 00:24
Favicon
Gravatar

Need help with auto-titlebar on unmaximized window with Compiz/Ubuntu 11.04/Unity

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!!!

--
 -[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
 -[ KDE PIM Developer         //  http://www.kde.org  ]-
 -[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-
_______________________________________________
compiz mailing list
compiz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Rune K. Svendsen | 1 May 20:41
Picon

I can't get access to the Compiz forums: 403 - Forbidden

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
Silvia Dobrota | 17 Feb 18:32
Picon

ccsm: Patch for autofocus on return to main page


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
Silvia Dobrota | 17 Feb 18:33
Picon

[PATCH] Focus filter entry on return to main page

From 5801cf0fbacde51ec60664efb1dd675a725b0f99 Mon Sep 17 00:00:00 2001
From: Silvia Dobrota <sd3209 <at> doc.ic.ac.uk>
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
@@ -96,6 +96,7 @@ class MainWin(gtk.Window):

     def BackToMain(self, widget):
         self.SetPage(self.MainPage)
+        self.MainPage.filterEntry.grab_focus()

     def RefreshPage(self, updatedPlugin):
         currentPage = self.CurrentPage
--

-- 
1.7.0.4
Martin Gräßlin | 16 Jan 17:07

Move KDE Plasma Integration to KDE Git Infrastructure

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 <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
okasion | 7 Dec 05:46
Picon

Re: compiz Digest, Vol 55, Issue 1

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, <compiz-request <at> lists.freedesktop.org> wrote:
Send compiz mailing list submissions to
       compiz <at> lists.freedesktop.org

To subscribe or unsubscribe via the World Wide Web, visit
       http://lists.freedesktop.org/mailman/listinfo/compiz
or, via email, send a message with subject or body 'help' to
       compiz-request <at> lists.freedesktop.org

You can reach the person managing the list at
       compiz-owner <at> lists.freedesktop.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of compiz digest..."


Today's Topics:

  1. Compiz Fusion and Linux Fusion (valent.turkovic <at> gmail.com)


----------------------------------------------------------------------

Message: 1
Date: Sun, 5 Dec 2010 21:00:58 +0100
From: "valent.turkovic <at> gmail.com" <valent.turkovic <at> gmail.com>
Subject: [compiz] Compiz Fusion and Linux Fusion
To: dev <at> lists.compiz.org, "compiz." <compiz <at> lists.freedesktop.org>,
       dx-team <at> lists.launchpad.net
Message-ID:
       <AANLkTim=eUu1Ou2+BhfVjSqd0Jsqe5oemg0Wo+t7nzc- <at> mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

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.

--
pratite me na twitteru - www.twitter.com/valentt
blog: http://kernelreloaded.blog385.com
linux, anime, spirituality, windsurf, wireless, ronjenje, pametne ku?e, zwave
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turkovic <at> hotmail.com


------------------------------

_______________________________________________
compiz mailing list
compiz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


End of compiz Digest, Vol 55, Issue 1
*************************************

_______________________________________________
compiz mailing list
compiz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Picon
Gravatar

Compiz Fusion and Linux Fusion

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.

--

-- 
pratite me na twitteru - www.twitter.com/valentt
blog: http://kernelreloaded.blog385.com
linux, anime, spirituality, windsurf, wireless, ronjenje, pametne kuće, zwave
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turkovic <at> hotmail.com
_______________________________________________
compiz mailing list
compiz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Sam Spilsbury | 13 Nov 11:35
Picon
Gravatar

Upcoming structural changes to compiz core - HEADS UP

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
--

-- 
Sam Spilsbury
Martin Gräßlin | 15 Aug 14:57

[RFC] Draft for a compositing manager specification

Resending as kwin and plasma mailinglists think that 200k is too large for a 
mail. The "attachment" can be found in [2]

Hi,

Pleas note: crossposting to kwin, compiz and plasma development lists. Please 
keep all lists CCed.

Attached you can find a very first draft for a compositing manager 
specification. It is currently based upon the KWin/Plasma interaction 
specified in the windoweffects namespace[1]. I basically just renamed all _KDE 
prefixes to _NET_CM. 

I want that in the end this becomes a new freedesktop.org specification to be 
used in addition to the EWMH specification. As I am not sure if all composited 
window managers are interested in such a specification I decided to discuss 
this idea first with kwin, compiz (as they implement our proprietary hints) 
and plasma, our most important stakeholder. The result of the discussion 
should be proposed as a joint draft from both compiz and kwin to 
freedesktop.org. I consider each and every of those hints as optional. So a 
window manager implementing none of the hints would be fully compliant.

Even if the attached draft is tainted to the current KWin naming and hints, it 
does not mean that this has to become the standard. I am very open to do 
changes to our code and also implement hints specified by compiz or other 
window managers.

I am aware that normally specifications are written in docbook. Unfortunately 
I don't know docbook at all, but I know LaTeX therefore I wrote the draft in 
LaTeX. Attached you find the tex document and a compiled pdf.

If someone has an idea how to collaborate on the document, please tell me. My 
only idea so far is to setup a special repository on gitorious.

Looking forward to your comments.

Regards
Martin Gräßlin

[1] 
http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.cpp?view=markup 
and http://websvn.kde.org/trunk/KDE/kdelibs/plasma/windoweffects.h?view=markup
[2] http://blog.martin-graesslin.com/blog/wp-
content/uploads/2010/08/compositing.pdf.tar.gz
_______________________________________________
compiz mailing list
compiz <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Gmane