[Straw-devel] a fleshed out todo list

[Juri Pakaste]

Hey guys,

I sent a bit of a todo list to someone by email a couple of weeks ago,
and now that there was some new developer interest on #straw too
(welcome aboard, hope you stay :-) I thought I'd flesh out this a bit
here, if anyone's interested.

- Latency issues when polling.
        It's not nice it takes several seconds for the cogwheels to
        appear after the user has hit refresh. They really should come
        instantly, even if the polling didn't start quite as soon.

- Memory usage/startup time issues
        Straw is a memory hog and a slow starter. It helped that it
        doesn't keep all the images in memory any more, but it does keep
        all the articles. That's stupid. I have already structured the
        code so it should be relatively easy to use dynamic
        loading/unloading of articles; that's why there was the
        Feed/FeedItems split. It's probably against the principles of
        OO, but I thought it's easier to do the dynamic loading if the
        management of articles is separated into its own class.

- Code quality issues
        Two partially separate things are most important:   
                
                - Main.py/MainWindow.py separation of responsibilities
                is totally arbitrary. Also totally braindead. All that
                visible_* stuff simply does not belong into Main.py
                (it's not even used anywhere outside MainWindow!) I'm
                sure there's other things too that I just don't remember
                now and I'd rather not look. It hurts.
                
                - UI and logic are simply too strongly tied together.
                While the UI doesn't necessarily have to be a thin layer
                on top of program logic, there should be some more
                separation, at least. A decent first step: remove all
                internal data structure manipulation etc from gtk event
                handlers, put them into methods that can be called from
                other places too. That would also do wonders for
                testability. Maybe we should really completely separate
                the UI handling code into its own classes, so we could
                do dummies for testing.
        
        One other thing is that it would be really good to think, on a
        class by class basis, what parts of it are public and what
        private. Python's __private stuff is ugly and I don't think we
        should do that, but one underscore prefixing the internal names
        would be good. And then ensuring that no outsiders use those
        internal parts, at least not without a good reason.
        
        There are probably also places where we should use classmethods;
        the Feed constructor function comes to mind. If for no other
        reason, at least for namespace issues brought on by the possibly
        not very clever way __init__.py is done.
        
- Lack of unit tests.
        Yes test driven development would be good. The second best thing
        would probably be to at least add unit tests for what we already
        have. There's interesting UI testing issues here; that's why we
        should do more to separate the the UI from logic (see above) so
        that at least most of the non-ui parts could be tested better.
        If someone knows of a Gnome/Gtk+ project that's done with TDD,
        or that's at least properly unit tested, please tell me: I'd
        love to take a good look at it. I don't think there's anything
        like Abbot (http://abbot.sf.net/) for Gtk+? (No, I don't know if
        Abbot's any good, it's just something I've run across.)

- Lack of integration with the rest of the system
        Copying text to the clipboard from gtkhtml2 should be possible
        now. We should do more drag and drop things. We should have a
        notification area thing.

It's nowhere complete, but at least that's something. See also TODO in
straw sources, and the various stuff I've posted to the list in the
past. Feedback welcome, as well as what other people think should be
worked on.

signature.asc
Description: This is a digitally signed message part