Skip to content

refactor Listeners to work as a library #63

Merged
merged 6 commits into from May 28, 2011

4 participants

@niklas
niklas commented May 15, 2011

I want to use the Listeners and the abstraction for different platforms in another project (vimmate). This patch allows to specify a directory to listen on. The user can choose whether to receive relative or absolute paths.

Additionally I refactored the listener specs to the extend that every platform-specific listener behaves similar to the others. I could only test the linux and polling version. The latter had to be patched to report moved and deleted files.

@thibaudgg
Guard member

Wow awesome refactoring! Thanks.
Actually the Darwin specs doesn't pass on Mac OS X, besides attr_reader :callback is missing in /listeners/darwin, rb-fsevents didn't support deleted & moved files (like rb-fchange on Windows). Right now, Guard didn't have any usages of deleted & moved (support of these on Linux, shouldn't be there either) so I think we should completely remove it.
What do you think about that?

@rymai, @yannlugrin, @netzpirat what your thought about that?

@niklas
niklas commented May 16, 2011

actually I though about adding events to the mix, so not only you get the (absolute/relative) path of a changed file, but the type of the change (:modify, :delete, :create etc) also. Maybe you'll need these later?

Would be nice to have a ruby library with (almost) platform independent fs notifications

@rymai
Guard member
rymai commented May 17, 2011

An agnostic FS events listener gem seems interesting indeed! And you've almost done it already with these commits. Moreover, for the moment deleted & moved events are not detected in Guard so that's one more reason to externalize this "listener" functionality into an external gem, in which all events could be detected and Guard could choose to listen only "modified" events (at the beginning, maybe later it'll be useful to detect other events)...

@thibaudgg
Guard member

There is already the fssm gem that is doing that (but without Windows support). If we add deleted & moved event, I'm little bit concerned about performance. That's why I have keep a more "keep it simple" approach in Guard without using fssm. @niklas did you known about fssm?

@niklas
niklas commented May 19, 2011

@thibaudgg I did not now fssm. And I looked for it for a while... Will have a look into it and will see if I can merge it with this code here.

@ttilley
Guard member
ttilley commented May 20, 2011

I'd rather stab myself in the face than work with a windows box long enough to add support (to FSSM), even though that was one of the original goals... Just helping people out when they see bugs via polling is painful enough. Did you know that the pathname code returns entirely different values in cygwin than one would receive using the one-click installer? So that simply checking if you're running on windows isn't enough to determine whether you're dealing with windows style paths?

@thibaudgg thibaudgg merged commit b12769d into guard:master May 28, 2011
@thibaudgg
Guard member

Merged & removed moved/deleted files support. Thanks for your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.