On Fri, May 18, 2007 at 11:06 AM, dragoran [EMAIL PROTECTED] wrote:
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 ControlSuper (which is the default)
Since I first tried nVidia's AIGLX with Compiz I've been seeing some pretty
consistent drawing problems on GWD's minimize and maximize buttons on hover.
It looks like part of the fill is drawn with low alpha. I haven't been able to
duplicate it when using Xgl... Here's a quick vid of what I'm
Here's a quick patch to have either horz or vert (instead of both) maximized
windows honor the ignore option:
--- src/window.c
+++ src/window.c
@@ -4012,7 +4012,7 @@ constrainNewWindowSize (CompWindow *w,
if (d-opt[COMP_DISPLAY_OPTION_IGNORE_HINTS_WHEN_MAXIMIZED].value.b)
{
- if
On Mon, Mar 5, 2007 at 6:08 AM, David Reveman wrote:
On Fri, 2007- 03- 02 at 13:14 - 0700, Mike Cook wrote:
Yes, that appears to render fine... As an update, I tried this update both
in SLED10 (with nVidia 9746 and Xgl) and openSUSE10.2 (with nVidia
9746 and their aiglx). I see
On Mon, 2007- 02- 26 at 17:23 +0100, David Reveman wrote:
I think the current state of the 0.4 branch is pretty good and I'd like
to just get the release out asap so we can focus on moving on. If anyone
got fixes or bugs that they like to see fixed let us know.
I've noticed that on a
On Tue, Feb 6, 2007 at 6:02 PM, David Reveman wrote:
Some additional options have been added to the decorators which allow
you to make any translucent decorations blur what's behind them.
Applications can also use the hint recognized by the blur plugin to
specify blurred regions.
Would it
On Mon, Dec 18, 2006 at 9:50 AM, David Reveman wrote:
-if (y1 pBox- y2 y2 pBox- y1)
+ /* consider strut if start/end overlaps box, size ends in box,
+ and edge is outside box or both edge size in same output
+ (in order to handle struts
On Mon, Dec 18, 2006 at 18:18, David Reveman wrote:
I have now pushed out some code to handle this properly. Here's what I
think is the correct way to include each strut:
(a window strut edge is valid if it's within the destination box)
1. left_strut = 0.
2. right_strut = box_max_x.
3.
On Fri, 2006-12-11 at 21:32 -0700, David Reveman wrote:
After looking at this I found the correct solution to be to just snap to
window struts instead of any workarea. I've pushed out changes that
should take care of this. I don't have access to a multi-head setup
right now so I can't verify
Here's a patch to wobbly.c to handle edge snapping with multiple outputs...
Also, I tweaked the window edge snapping to include dock window types, to
support the case where dock windows may be on the inner edges of multiple
monitors (and thus currently ignored as struts in the output workarea
Here's a patch to add the option of initiating scale on windows
only on the current output. With two or three monitors I often
want to scale only the few windows in a specific output, instead
of the current default of all the windows on all outputs.
Also, after experimenting I tried limiting the
On Nov 12, 2006 at 10:33, David Reveman wrote:
Thanks, I applied you're patch. I found one issue with the current code
though.. We shouldn't use the window position and size to determine if a
window should affect the workspace of a output or not. The
_NET_WM_STRUT_PARIAL hint contains
On Nov 08, 2006 at 1:20 PM, Shawn Starr wrote:
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
Hey, I'm thinking about the addition of the getWorkareaForOutput method,
and I'm wondering if it wouldn't make sense to define the workarea as part
of the CompOutput struct and set it up as part of (or replacing?) the
updateWorkareaForScreen call. Either that or make the call to
Hey, David, with the latest changes for output-specific zoom it wasn't focusing
properly for me with mixed resolutions. I think this patch corrects that.
(Oh, and on my previous comment I meant struts and not extents, if that was
confusing to anyone. It was to me when I re-read it, heh.)
...MC
15 matches
Mail list logo
