similar to: Bug super key gets 'stuck'

Guys, Here is a little something to look at in the code. I have the following set: Run command 1: /opt/kde3/bin/ksnapshot <Super>Print Run command 2: /opt/kde3/bin/ksnapshot --current <Alt><Super><Sys_Req> The bug occurs when you choose 'Grab key combination' for <Alt><Super><Sys_Req>. When you enter the keystroke, the keystroke is clearly

I would like to get a better understanding as to why Quinn's patches have not been accepted into the compiz git tree. I feel Quinn's patches could greatly improve compiz. She has made quite a lot of progress wrt to enhancing compiz with her cgwd window decorator which allows users to write their own themes for window decorations. Also, many of the plugins that are in compiz.net are MIT

List, In checking ring switcher and shift switcher, it seems that the key bindings are off. For shift switcher, it still initiates with <Shift><Super>S, but no longer terminates with enter on the numeric keypad, only the normal enter key terminates it. For ring switcher, it is NOT initiated with <Super>Tab despite the key binding showing that it is. Instead,

I see no problem with your nvidia temps But, i have seen this exact behavior when 'indirect rendering' is enabled. On Wed, Aug 19, 2009 at 2: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 >

Hi David, With the recent opcode changes, does compiz need anything in order to use the newer X server? I updated glproto to 1.4.8, then built Mesa 6.5.1 release, then compiled Xserver from git then built compiz git and I get a white screen, but compiz cube shows all white/shaded when I attempt to drag the cube around. I have AIGLX used instead of Xgl. I'm testing out Xorg '7.2'

Hello, I noticed that the control+super key kombi no longer works with the rain plugin.. I went to check why and found out that its disabled in gconf. so I tryed to change it back to <Control><Super> (which is the default) but it changes itself back to disabled... any idea why?

Listmates, I installed 8.2 on opensuse 10.3 from the opensuse XGL repository to replace 7.6. Compiz works with the nvidia 8600 GT card (512M of GDDR3) on the box, but the ctrl+alt <- -> switching behavior is really bad. In 7.6, the ctrl+alt <- -> desktop switching changed desktops crisply with just the slightest hint of the cube detected during the very short and nice switch.

I've put a scheme plugin in users/racarr/compiz-scheme on gitweb.open-compositing.org. Essentially it allows the user to define a startup file (~/.compiz/startup.scm) and fill it with scheme code to do neat things and extend Beryl. On one hand it acts like a super powered state plugin, on the other it lets you define useful behavior specific to what you do with your Compiz and share these

Beyond the general work on compiz-scheme (new wrappings, hooks, code improvements, etc), I've added a few large new things: 1. Key bindings with modifiers. This lets you from any of your scheme files/interactive prompt bind an arbitrary key + modifier to an arbitrary scheme function. So you can define new Compiz behaviors and shortcuts on the fly. 2. An interactive prompt. This sets up a

I a rather dependent upon the Enhanched Zoom Desktop tool. It allows me to zoom into a part of the screen and see it clearly, with the zoomed part of the screen following the mouse. However, there are times when I need the screen to remain where it is (not to pan with the mouse), and the only way that I've found to do that is with the "Toggle zoom area lock" option. When this option

Hi David, When maximizing windows on a different resolution only 70% of the window is maximized. Ie: on my 1280x1024 screen a window maximized is correct (and does not clobber the desktop panel in KDE, kicker) On my 1600x1200 screen, with no kicker panel, the window is maximized about 70% of the screen only Is this known? Thanks, Shawn. ----- Original Message ---- From: David Reveman

hi there, a number of users of ubuntu gutsy with nvidia cards are experiencing a serious memory leak under compiz. This leak essentially renders compiz unusable for us. Gutsy ships with a compiz versioned at 0.6.0 +git20071008 , which I imagine isn't that different from the current compiz, and with the current 100.14.19 nvidia driver running under a 2.6.22 kernel. I'm just wondering

Hi, First of all, great job! :) I really like to organise my work on, former known "workspaces", now "viewports". I use currently use 9 so I have 3 for work, 3 for private applications and 3 for other projects. Using the viewports like this it happens to have 3 browser windows, 6 Document Viewers, 9 Terminals, 1 Evolution, 2 IDEs and >3 Gimp The number of Windows and

Here are a few plugins I wrote. The put plugins gives you bindings to move windows around. I set it up so the numeric keypad is like the area of the screen. So <Super>KP_Home will move the window to the top left, etc ... It also does viewport moves which is handy when used with the plane plugin. I like the plane plugin in a 3x3 matrix matching the keypad, so with the keypad and some

Hi, Suppose I have a compiz key-binding (let's say Ctrl and +) that performs a particular action (let's say maximization) and the current active application (say xterm) also does something with the same key-binding (zoom in xterm) - compiz handles the event and does not pass it on to the application. Is this desired behavior? Is the behavior configurable? Shouldn't compiz handle it

Hi Compiz Devs, as you might know I started about a year ago to implement a new theme engine for KWin called Aurorae. It is a SVG/Pixmap based engine. The theme format is SVG as soon as the SVG get's resized a pixmap is created and put into KDE's pixmap cache. This makes painting very fast while resizing kind of slow (not an issue with KWin as resizing is already slow ;-)), but at

Hey, David, for me the recent multihead changes had minor a problem with mixed resolutions (1600x1200 & 1280x1024). The viewport was getting set partially off screen. The following tweak fixed it for me: --- plugins/display.c +++ plugins/display.c @@ -2069,7 +2069,7 @@ eventLoop (void) { if (s->nOutputDev > 1)

Compiz Fusion Release 0.5.2 is out! This is the first development release of Compiz Fusion, the result of more than six months of work and polish. The first stable release, 0.6.0, will follow after the Compiz 0.6.0 release. Compiz Fusion is the result of a merge between the Compiz community plugin set "Compiz Extras" and the parts of the Beryl project that are independent of the

Hello! I noticed several problems in how Compiz handles full-screen windows*, and I hacked a bit around the source to try to find their source. (*: I use this pretty much as a replacement for full-screen, all the time.) I already mentioned two, here's another bigger one. In all descriptions below, full-screen windows are NOT un-redirected. * Problem: If the topmost window is a full-screen

As promised, here's a patch to switcher.c to add "Application window" switching to the switcher, default keybinding Super+Tab (and Shift+Super+Tab for reverse). Works (and fails to work*) in the same conditions Scale's "group" mode does. Also, two patches for doxygen-compatible comments for some of switcher, which I added while working out what was going on. It