On Thu, 2007-04-05 at 19:50 +0100, Mike Dransfield wrote:
Diogo Ferreira wrote:
The current INI plugin seems to fail loading when there isn't a
~/.compiz dir. Since most users won't have it I believe it makes sense
to mkdir it before trying to mkdir the sub-options directory.
I would
Diogo Ferreira wrote:
The current INI plugin seems to fail loading when there isn't a
~/.compiz dir. Since most users won't have it I believe it makes sense
to mkdir it before trying to mkdir the sub-options directory.
I would have done it but since you use the get dir function a lot it
would
Gerd Kohlberger wrote:
The IN_MODIFY bit isn't really useful for text files.
If you watch the event sequence which get emited by inotify you'll see
something like:
1) MOVE compiz.conf - compiz.conf~
2) MOVE compiz.conf~ - compiz.conf
3) DELETE compiz.conf~
So if you watch compiz.conf
On Sun, 2007-03-04 at 22:47 +0100, Gerd Kohlberger wrote:
David Reveman schrieb:
hm, you're currently suppose to use different call-back functions for
this.
e.g. if you want to know the difference between move or delete do:
addFileWatch (d, path, NOTIFY_MOVE_MASK,
On Sun, 2007-03-04 at 23:06 +0100, Gerd Kohlberger wrote:
Mike Dransfield schrieb:
David Reveman wrote:
On Fri, 2007-03-02 at 13:35 +, Mike Dransfield wrote:
This seems roughly what I would need. I applied your patches and added
IN_MODIFY since I need that too.
Yes, we
Mike Dransfield schrieb:
David Reveman wrote:
On Fri, 2007-03-02 at 13:35 +, Mike Dransfield wrote:
This seems roughly what I would need. I applied your patches and added
IN_MODIFY since I need that too.
Yes, we need a MODIFY bit.
I am attaching a patch for that
I have also
David Reveman wrote:
On Fri, 2007-03-02 at 13:35 +, Mike Dransfield wrote:
This seems roughly what I would need. I applied your patches and added
IN_MODIFY since I need that too.
Yes, we need a MODIFY bit.
I am attaching a patch for that
I have also changed the notification
On Tue, 2007-02-27 at 20:58 +0100, Gerd Kohlberger wrote:
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
David Reveman wrote:
On Tue, 2007-02-27 at 19:24 +, Mike Dransfield wrote:
I will write a fam plugin as well and test if that works
correctly too. I think it will need extending a bit but I didn't
look too hard.
Do you get any benefit out of fam except that it provides polling
On Wed, 2007-02-28 at 15:28 +, Mike Dransfield wrote:
David Reveman wrote:
On Tue, 2007-02-27 at 19:24 +, Mike Dransfield wrote:
I will write a fam plugin as well and test if that works
correctly too. I think it will need extending a bit but I didn't
look too hard.
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
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 wrapped
On Thu, 2007-02-22 at 16:01 +, Mike Dransfield wrote:
I have written an initial flat file configuration
backend for Compiz. At the moment it is using
FAM for monitoring of files (it can be compiled
without monitoring support for now).
Great!
It is working fine but there are a couple
13 matches
Mail list logo
