Watch Statuses Iceberg

[Jeff Fortin]

I was initially going to try applying the patch by Pascal from issue #181, but then I tried looking into why we were in this situation in the first place. And that's when I discovered a horrible monster.

We currently have *nine* watch statuses! Trying to understand them, especially since they are not well commented, induces headaches. I spent the last two hours trying to think of the logic process that happens in Specto globally, by making a flowchart, without looking at the code (in order to avoid bias). The results are attached to this message. I am not sure that I represented (or even understood) the process correctly. It's just that confusing for me. Now, actually, looking at this finished flowchart is pretty simple, but making it was quite complicated for my sleepy brain (I started over multiple times).

First, any corrections to this flowchart would be welcome. Among other things, this chart brings up another problem: is checking the saved state of the watches from the watch list on every refresh necessary, really?

Then, I'd like to have an idea if anything can be done to simplify the code as much as possible and make it crystal-clear in its logic, not just well-commented (though it would seriously needs that).

And if possible, if we feel courageous, we should make changes towards that, in a special bazaar branch (to avoid breaking the workflow of other features/bug fixes; and if it doesn't work out, we can just throw away the branch).

Basically, I'd like to apply the patch from issue #181, but, from my understanding, this would break other things. And it seems like this issue is in big part due to unclear terminology:

Jeff: I'll analyze pascal's patch now to try and figure out why we had this "clear" thing in the first place
Wout: if there are no unread mails in the gmail watch, it will call the "clear" status
Jeff: well, something's wrong I guess, because it doesn't seem very consistent. The only files that use "clear" are notifier.py, watch_mail_gmail.py, watch_web_greader.py. So it means that it happens only with gmail and google reader watches? Then why not other mail watches, facebook watches, etc? We might want to at least rename this to something clearer (pardon the pun): maybe "remotely-cleared"... In any case, there's something "unclear"/messed up with this whole status thing
Wout: yes maybe the whole code needs another review :s
Jeff: argh, "idle-clear" already exists, along "clear" and "idle"!

However, I'm thinking that this mess will not be trivial to clean up. As such, it should probably be part of the 0.4 series, and that would probably mean that issue #181 would not be fixed for 0.3 and be deferred to 0.4.

Thoughts?

[pascal...@gmail.com]

I was looking at the watch code... Why don't we subclass them from
gobject?
It would be easier to document them, we could add signals and
properties, and make them work directly with the gtk.Main loop.

And... did you see if my patch broke something?

[Jeff Fortin]

Wout did some cleanup recently, hopefully solving the problem, but it would need testing.

Subclassing from gobject: I guess you'd have to demonstrate how it is superior codewise :)

And... did you see if my patch broke something?

Yep, it broke mouse-activation of the add menu, as you already know by the time I have replied to this mail ;)