On Tue, 2007-02-27 at 12:15 +0100, David Reveman wrote:
> Yep, that made a lot of sense and I've now made changes that should fix
> it. The changes I've made affect which window that should get focus when
> you change viewport in other ways when using the switcher or scale too.
> Switching to a ne
David Reveman wrote:
OK, I still can't reproduce it. Does the attached patch help?
Yes, it does, thanks.
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
dragoran wrote:
can't reproduce
have you tryed generating a backtrace using gdb?
I'm not a developer. I don't know what gdb or a backtrace is :(
Can you point me what to do?
--
unwiredbrain
Proud GNU/Linux user #437712
___
compiz mailing list
compiz@l
On Sat, 2007-02-17 at 10:16 +0100, dragoran wrote:
> David Reveman wrote:
> > On Thu, 2007-02-15 at 20:39 +0100, dragoran wrote:
> >
> >> David Reveman wrote:
> >>
> >>> On Fri, 2007-02-09 at 13:35 +0100, dragoran wrote:
> >>>
> >>>
> I have configured compiz to use 1 workspa
On Tue, 2007-02-27 at 16:39 +, Mike Dransfield wrote:
> David Reveman wrote:
> >
> > PID can be in the core. Process name, host name.. and everything else
> > you can think of that are strings should be in the regex plugin.
> >
> > Window dimensions would be useful. '>', '<', '=' can be used wi
On Tue, 2007-02-27 at 11:35 -0700, Mike Cook wrote:
> >>> 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 the
On Tue, 2007-02-27 at 20:50 +, Mike Dransfield wrote:
> David Reveman wrote:
> > Can you reproduce it? if so, how?
> >
>
> OK, I can reproduce it now and point you in the right direction.
>
> I am 99.9% sure it is related to the decorators and their drawing
> of the title bar in the switch
On Tue, 2007-02-27 at 19:24 +, Mike Dransfield wrote:
> David Reveman wrote:
> > Yep, you should use the file watch interface instead of FAM. You should
> > call addFileWatch to add a watch for a specific file or directory.
> > addFileWatch will then call display->fileWatchAdded which is a wrap
David Reveman wrote:
Can you reproduce it? if so, how?
OK, I can reproduce it now and point you in the right direction.
I am 99.9% sure it is related to the decorators and their drawing
of the title bar in the switcher. If I quickly switch then the window
appears, if I wait for the switche
Hi guys!
Maybe I found a very annoying bug: by holding the ALT key and clicking
(anywhere) with the right mouse button, Compiz crashes.
I found this bug (or a **very**strange behavior?) by accident... ;)
I tried many times, and always Compiz to crashed.
Here's my machine configuration:
[start]
Travis Watkins wrote:
From the specification:
A DICT_ENTRY works exactly like a struct, but rather than parentheses
it uses curly braces, and it has more restrictions. The restrictions
are: it occurs only as an array element type; it has exactly two
single complete types inside the curly braces;
>>> On Tue, Feb 27, 2007 at 12:49 PM, Bellegarde Cedric wrote:
> Just find another thing...
>
> Blur alpha effect is present for every alpha effect in compiz: fade,
> minimize, scale...
Ah, that reminds me... I found that if you zoom in, you can see that
the blur effect stays at it's usual rad
It is working fine but there are a couple of problems.
1. It looks like I should use addFileWatch rather than
directly accessing FAM, is this correct? I notice dbus
uses addFileWatch rather than (*d->addFileWatch) is
this intentional, and does it get wrapped in the same
way?
Yep, you should us
Le mardi 27 février 2007, Bellegarde Cedric a écrit :
> I now use blur plugin thanx to window matching feature, thanx David ;)
Just find another thing...
Blur alpha effect is present for every alpha effect in compiz: fade, minimize,
scale...
For scale, it make sense to have blur under scaled wi
David Reveman wrote:
Is there any other debugging information I could get on this?
Can you reproduce it? if so, how?
I can reproduce it without trying. Unfortunately I do not know how
to reliably reproduce it. It just happens very often.
It's probably one of the input only windows
I now use blur plugin thanx to window matching feature, thanx David ;)
I have some bugs:
http://hibbert.univ-lille3.fr/~cbellegarde/blur_4xbilinear_bug.png
Here, i have some artefacts bugs with 4xbilinear. This blur mode is fast! May
be a Nvidia drivers bug...
http://hibbert.univ-lille3.fr/%7Ec
David Reveman wrote:
I'd like to get a 0.4 release out sometime soon. I created a compiz-0.4
branch some time ago and I've been cherry picking changes from master
that I think should go into the 0.4 release.
I think the current state of the 0.4 branch is pretty good and I'd like
to just get the
David Reveman wrote:
Yep, you should use the file watch interface instead of FAM. You should
call addFileWatch to add a watch for a specific file or directory.
addFileWatch will then call display->fileWatchAdded which is a wrapped
function that plugins that provide file watch functionality like t
On 2/27/07, David Reveman <[EMAIL PROTECTED]> wrote:
Incremental changes are always appreciated when possible. Having a
history of all changes is always good. You can do that locally or we can
get things into head in its current state and you can work on it there.
Whatever you prefer. If the chan
On 2/27/07, Mike Dransfield <[EMAIL PROTECTED]> wrote:
I am not sure if this is going to be ok with the introspection
data, I couldn't find any real documentation. Do you need to
specify each member of the dictionary or can you just say
a dictionary?
From the specification:
A DICT_ENTRY work
>>> 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 dua
On Tue, 2007-02-27 at 16:01 +, Ben Reeves wrote:
> >You shouldn't keep a small db of known plugins. The dbus plugin
> should
> >be able to give you the dependencies of any plugin so you can sort
> them
> >properly and generate proper error messages if some plugin can't
> >possibly be loaded du
On Tue, 2007-02-27 at 11:36 +0100, Jesper Andersen wrote:
> 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
Le mardi 27 février 2007, vous avez écrit :
> My point is that most of the window painting stuff is handled by
> core, so to really have an opacity/brightness/saturation plugin, you
> should remove either all the functionality or none of it.
Hmm, changeWindowOpacity(), increaseOpacity(), decreaseO
David Reveman wrote:
PID can be in the core. Process name, host name.. and everything else
you can think of that are strings should be in the regex plugin.
Window dimensions would be useful. '>', '<', '=' can be used without any
changes to match interface as those things are up to the expressio
Hi,
> obs does not appear to listen for the client messages, so I
> assume that there is a separate code path in core which does
> a very similar thing to your changeWindowOpacity function?
Indeed. This is done in core's event.c.
> Are you planning to pull all of that out into a plugin too?
Hmm
Danny Baumann wrote:
It's slightly different. Whenever a client wants to change an atom (such
as opacity), it sends a client message with the request to the WM which
then decides to modify the actual X property or to ignore it.
Whenever there is a client message requesting an
opacity/saturation/b
You shouldn't keep a small db of known plugins. The dbus plugin should
be able to give you the dependencies of any plugin so you can sort them
properly and generate proper error messages if some plugin can't
possibly be loaded due to some conflicts.
I haven't being following compiz development f
Bellegarde Cedric wrote:
On Tuesday 27 February 2007 15:03:02 Mike Dransfield wrote:
It just sets the atoms
which core responds to, so it is just a hack.
It's exactly what is doing compiz core with opacity...
Look at increaseSaturation() and inceaseOpacity(), the code is the same...
On Tue, 2007-02-27 at 14:11 +, Mike Dransfield wrote:
> There is a bug which I am seeing and a few people are reporting
> on the forum.
>
> The problem is a hidden window which is always rendered on
> top. It is always short and wide and appears near the
> bottom-center of the screen.
>
> He
On Tuesday 27 February 2007 15:03:02 Mike Dransfield wrote:
> It just sets the atoms
> which core responds to, so it is just a hack.
It's exactly what is doing compiz core with opacity...
Look at increaseSaturation() and inceaseOpacity(), the code is the same... So
bs code comes from compiz cor
Hi,
> If you changed beryl core to not respond to these atom changes then
> it means that no application outside can change its opacity. If you didn't
> remove this, then the obs plugin is doing more than it should and it
> is duplicating work done by core.
It's slightly different. Whenever a cl
On Sat, 2007-01-27 at 09:08 +0100, Stjepan Glavina wrote:
> On Fri, 2007-01-26 at 18:28 -0500, David Reveman wrote:
> > On Thu, 2007-01-25 at 10:32 +0100, Stjepan Glavina wrote:
> > > It would be great if switcher would rotate cube to the selected window
> > > when switching. Beryl has "autorotate"
On Tue, 2007-02-27 at 00:43 +, Mike Dransfield wrote:
> David Reveman wrote:
> > If you have
> > any window properties that you find useful for matching, please let me
> > know and I'll consider adding them. Whether they get added to the core
> > or not doesn't matter as you can always put the
Travis Watkins wrote:
The real problem is actions (ie activate/terminate)
because they can take a variable number of arguments
so would need to register somehow.
Perhaps it can take an array?
It would need to be a dictionary because they are named
parameters and they contain different datatyp
On Mon, 2007-02-26 at 16:49 -0600, Travis Watkins wrote:
> On 2/26/07, David Reveman <[EMAIL PROTECTED]> wrote:
> > Awesome, I've been hoping that someone would interested in doing this.
>
> The new dbus-python requires it so if I want to write python apps that
> use it this is needed. :)
>
> > I
Danny Baumann wrote:
The bso plugin should not exist because it does not actually
do the work of changing the paint values. It just sets the atoms
which core responds to, so it is just a hack.
I disagree. obs (as well as bs before) changes both paint values and the
atoms.
BTW, Beryl's obs
Hi,
> Or you could call it the obs plugin ;)
Yes, I did exactly that in Beryl ;)
> The bso plugin should not exist because it does not actually
> do the work of changing the paint values. It just sets the atoms
> which core responds to, so it is just a hack.
I disagree. obs (as well as bs befo
There is a bug which I am seeing and a few people are reporting
on the forum.
The problem is a hidden window which is always rendered on
top. It is always short and wide and appears near the
bottom-center of the screen.
Here is the output from xwininfo on that window, xprop produces
nothing.
x
Bellegarde Cedric wrote:
Another question, do we need a state plugin?
blur, switcher, ... now use "window matching" to enable/disable effect. With
your proposition, we should be able to specify blur type.
I think we will still need a state plugin, maybe other plugins
could take care of som
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 have a problem with focus und
41 matches
Mail list logo
