[gpodder-devel] Hints for contributions (was: Re: Non-human readable dir[...])
- From: thp at perli.net (Thomas Perl)
- Date: Wed, 12 Dec 2007 17:07:30 +0100
Hello, Kaity!
Kaity G. B.->uberChicGeekChick(); wrote:
> Its only when running it through the command line. Adding its always fine,
> &right now it sems fine too. Nuking the sqlite dbs. BTW, they are sqlite
> dbs
> right?
Not at the moment (we use the "shelve" module). We might decide to
switch to SQLite when I got more familiar with it and decide it's easy
and fast, because using shelve has some drawbacks (db files get
corrupted easily when gPodder crashes, it seems).
> Then, I've really meant that I've been wanting to work on gPodder more.
> &This
> morning I'm ready to add it to my project list. LOL, I mean I'm sure gPodder
> isn't all you work on. *hopes not*. We all wok on tons of projects &as much
> work as I've spent writing an entire PHP program just as a helper app. Well
> its
> time I made the jump, even though I pretty much hate Python, but not enough
> not
> to use it. Now if gPodder were written in Java I'd be running the other way;
> no
> seriously.
Sure you'll be welcome to contribute to gPodder - anybody is. Just send
patches and maybe announce what you are going to work on here on the
list (except when it is a small, trivial patch) before you start working
on them, so no work is duplicated.
> But okay, how should I start? I'll prolly be intergrating syncing with
> command
> line option. I'm guessing I'll prolly have to write my own function, method,
> whatever(other wise you'd have implemented it already). Of course I'll start
> with checking out svn version, which I'm planning on developing and running
> as
> --local. Any coding conventions that you enforce?(those might make me run,
> LOL... just maybe). After some cli stuff I'll finish my barely started
> playlist
> manager(s)/creator. Well I hope I can help.
I'm currently rewriting the sync code to be more modular, which then
also means sync code can be trivially integrated into the CLI code, so
starting to integrate the sync code with the CLI code _now_ is probably
not a good idea, as the sync code will be replaced with the new one as
soon as I've finished re-organizing the code.
Always work on the current svn trunk head, see
http://gpodderwiki.jottit.com/running-from-svn for a guide how to get
the latest code. Also don't forget to read the section about how to pull
new changes after the initial checkout. Patches can easily be generated
with "svn diff" in the root of the working copy. Testing can be done
using "make test" in the root of the working copy.
As far as coding conventions go, I've started adhering to Python's PEP-8
some months ago, although much of the old code still has some other
style. If your patches have a bit different style, don't worry, I'll try
to fix that before merging it. Of course, the less work I have to do,
the more happy I am =) Just look at gPodder's code and you'll shortly
find out in which style to write the code. Or better yet: Read PEP-8 :)
> So just thnx &I hope no one'll hate that I like fun, pretty, &documented
> code.
Actually, documentation is a good thing we currently don't have much of.
It'd be most helpful if you add some documentation to the gPodder wiki
at gpodderwiki.jottit.com. Describing the whole GUI and how to use it
would fit perfectly on http://gpodderwiki.jottit.com/manual, which still
has to be started :)
Enjoy!
Thomas
Other related posts:
- » [gpodder-devel] Hints for contributions (was: Re: Non-human readable dir[...]) - Thomas Perl
