[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Straw-devel] a fleshed out todo list
From: |
Juri Pakaste |
Subject: |
[Straw-devel] a fleshed out todo list |
Date: |
Sat, 22 May 2004 11:12:40 +0300 |
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
- [Straw-devel] a fleshed out todo list,
Juri Pakaste <=