[Gpe-list] Rationalising tasks databases

[Florian Boor]

Hi,

i am catching up slowly...

Matthew Palmer schrieb:
> I've just loaded GPE onto my Zaurus SL-C3200 (via OpenZaurus 3.5.4.1), and
> one of the first things I noticed was that the tasks in gpe-timesheet and
> gpe-todo aren't shared.  I want to fix this.

That's a very good idea - the structure should be quite similar.

> The first thing to do is to rationalise the databases, so that the timesheet
> tasks can be stored in the tododb.  As far as I can tell, the only database
> field that's missing from the tododb when compared to the timesheet db is
> the parent task ID.  This seems like a fairly simple change to make to
> libtododb.

That's good - another thing we get for free with this is a proper database
abstraction for gpe-timesheet so that the database backend isn't part of
application itself any more once it uses libtododb.

> My intent is to make this change in the libtododb code.  However, to do this
> I'll need to change the todo_item struct.  It's been a while since I've
> hacked much C, but I'm fairly certain that changing this struct will
> incompatibly change the library ABI -- which, if I'm not mistaken, requires
> a SONAME change.  Except I can't see anywhere to change the SONAME.  Could
> someone point out what I'm missing here?

You can get the SONAME version information to the linker in this way:
libtododb_la_LDFLAGS = ... -version-info 1:0:0
So its just a small modification in Makefile.am. It might be worth to think
about defining a variable for this.

> Once the tododb handles hierarchical tasks, I'll need to modify the
> timesheet app to use the tododb, and migrate the timesheet tasks to the
> tododb and fix the task IDs in the log.  Does anyone have any suggestions
> for how to do the data migration -- not so much the mechanics of the actual
> transformation (which I'll work out in code), but the mechanics of the
> higher-level stuff -- *when* to do the translation (automatically,
> click-a-button, at package upgrade time, or what?).

I'd do this automatically on application startup. You just need to store some
database version information or another flag that indicates that you migrated
the data already and check this on application start.

> Modifying the timesheet app seems... trickier than I first thought. There
> appears to be some support for linking timesheet tasks with todo tasks, but
> it seems mostly hidden behind '#ifdef HILDON' stuff.  Am I right in thinking
> that Hildon is something for the Nokia 770?  At any rate, I think that some
> of that stuff needs rethinking -- either to merge the Hildon and regular UI
> stuff, or just get rid of the distinction between todo tasks and timesheet
> tasks.  I'm not about to start making UI decisions, though, so I'd
> appreciate some guidance from people who know as to which way to rewrite
> this thing.

I think i can help with this a little bit. In theory the features of the UI in
Hildon should be the same like with plain GTK - no idea where the difference
comes from. The code specific for Hildon should be quite limited and is mostly
related to using some special widgets or following different UI guidelines.
Using one database we get this feature for free anyway.

> Finally, how should I go about getting these changes back into the main
> tree?  Just log a bug, with patch, in bugs.linuxtogo.org?

Yes you can do this - or just send a patch to the mailinglist.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-14
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor at kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76