On Thu, 2007-01-11 at 15:31 +0100, Danny Baumann wrote:
Hi,
Wouldn't it be better to add this kind of functionality through
different interface than the current screen grab interface? We can
always expose the current screen grabs through a new interface if we
want that.
I'm not
Danny Baumann wrote:
Hi,
Wouldn't it be better to add this kind of functionality through
different interface than the current screen grab interface? We can
always expose the current screen grabs through a new interface if we
want that.
I'm not sure exactly how this interface should
Hi,
The same would happen for terminate bindings so other
plugins can keep an internal track of all other plugins (even
if the author didnt write their plugin specifically for them).
The problem is that this method (which also came to my mind
yesterday ;-) ) can't be used at all for replacing
Danny Baumann wrote:
The problem is that this method (which also came to my mind
yesterday ;-) ) can't be used at all for replacing otherScreenGrabExist
- given the fact that you don't want to have a string list of active
plugins in each plugin. Maybe I'm also misunderstanding you a bit - how
Hi,
I wouldn't want it to replace otherScreenGrabExist
because I feel that is for a slightly different purpose.
My approach was to try to add cooperation, but not
dependencies between plugins. My examples are:
1. 3D, Beryl uses IPCS for this which is not recommended.
I would like 3D
Danny Baumann wrote:
Yes, you are right to a certain degree - the root problem here is that
moveWindow is used for both window animations and viewport changes, what
makes it hard to distinguish both.
I have just had a quick look at moveScreenViewport and it
looks like you could tell a
On Fri, 2007-01-05 at 16:00 +0100, Danny Baumann wrote:
Hi,
I have a question regarding screengrabs:
At the moment, a lot of interaction between the plugins is done by
checking for screen grabs of other plugins with the function
otherScreenGrabExist. But pushing a screen grab means grabbing
