[gpodder] Re: gPodder 3.1 development status update
- From: Thomas Perl <m@xxxxxx>
- To: gpodder@xxxxxxxxxxxxx
- Date: Mon, 5 Mar 2012 07:28:57 +0100
Hi Joseph,
On Fri, Mar 02, 2012 at 10:08:34AM -0800, Joseph Wickremasinghe wrote:
> I've actually been working on device sync for gPodder, but I'm a only
> a Python novice so it's been more of a learning project for me. I
> actually started by copying the sync.py code from 2.20 into the 3.01
> codebase, and figuring out how to get it working, which involved
> adding back in various settings, some object model tweaks, and making
> a couple of changes to the SQLlite db.
Which changes did you make exactly? Do you have a patch on top of our
"master" branch that I could have a look at?
> I've only been working on filesystem-based syncing, under GTK though,
> but from what I can tell, my changes wouldn't break other UIs, these
> other interfaces just wouldn't show any of the sync menus / commands
> in the interface.
That should be okay - ideally we would also have sync for the CLI
(doesn't make so much sense for the QML UI while it's mainly targetted
at the Nokia N9) but that can wait a bit more.
> Anyway, I've got it 95% working at present. My last issue is trying to
> get the episode published date to show up correctly in the custom sync
> rename.
Sounds promising. Have you uploaded your code somewhere?
> But, I still have a number of questions The first of course is even
> whether the approach to syncing used for 2.20 is even something you
> wanted to carry over into 3.x. Additionally, would it be ok for me to
> add in filesytem-based syncing into GTK only, since that's the
> platform I'm using?
> How do you handle changes to the SQLlite db structure (additional
> columns to the tables)? Is that even something you'd want to do?
That's taken care of by src/gpodder/schema.py - basically you would need
to introduce a new version, update the initial schema SQL and then
modify the "upgrade" function to upgrade the schema from the old version.
But let's have a look at your code - maybe the database changes aren't
needed at all? Also, in case we turn the sync into an extension (we
should), it could store its own data in a separate file/database below
$GPODDER_HOME (so it's even more flexible).
> Let me know your thoughts. I'm happy to rework the sync using JSON if
> that's your preferred approach - I imagine a lot of the settings & UI
> updates that I've made will be unaffected anyway.
I'd like to see the code and then we can start integrating from there :)
Thanks,
Thomas
Other related posts:
