[Kde-pim] Akonadi Commandline Interface Project

[Kevin Krammer]

Hello Bhaskar,

On Friday, 2014-02-28, 17:17:23, Jonathan Marten wrote:
> Hello Bhaskar,
> 
> Bhaskar Kandiyal <bkandiyal at gmail.com> writes:
> > I've been working towards getting familiar with the existing code of
> > akonadiclient. I added a few commands to the existing client just to get
> > the hang of it. The commands are as follows:
> > 
> > * Clear - Clears all items of a collection
> > * Export - Export collection to an XML file
> > * Import - Import collection from an XML file
> 
> Looks good as a start.  I'm not familiar with the Akonadi XML
> interface, so I'll leave it to any others who may want to comment on
> that. 

I'll have a look at your repository over the weekend. But sounds very 
promising :)

> For the Clear command, just some things that I've noticed from
> a quick look though the code:
> 
> This is a dangerous command (extremely so!).  So as to avoid any user
> prompting for confirmation (which is not so useful for command line
> scripting), there is a check for such commands which needs a magic
> variable to be set in the environment in order to be able to execute
> such commands. 

I think we would rather go with a special commandline switch, e.g. like
--force

Maybe even requiring either that or --dry-run (or similar), like git clean 
does.

In kabcclieent I only had the dry-run/simulate option, i.e. in order to safely 
test commands, but without it would always execute unhindered.
But since this can do a lot more explicit force might work better.

Anyway.

> > For the Export functionality I used the Akonadi::XmlWriteJob, but
> >
> >since this class isn't available in pre-KDE 4.12 so to make it work
> >for me on KDE 4.11 I had to include the source for Akonadi::XmlReader
> >and Akonadi::XmlWriter in the akonadiclient. I don't know if it's the
> >best way to do this though.
> 
> If you eventually want your code to be in KDE (and we do, of course),
> then you will need to target the current version so there will be no
> need for the copy.  I don't know what distro you have or whether it is
> practical for you to compile KDE from source, but hopefully by the
> time summer comes you will be able to upgrade to a later base.

I think w can define the base line that we want for this work. When GSOC 
begins we will have 4.13 I think, so if we want to develop against the release 
this should be fine.

> > PS: I was wondering if there are any bug fixes I can do :)

One thing that came to my mind was a bit of refactoring of the current 
prototype.

When designing the first commands I fell into the trap of premature 
optimization, i.e. trying to delay construction of the application object 
until its event loop was really required.

That makes some of the command initialization stuff needlessly complicated, 
because it needs to delay translation, etc.

So if you think you would like to have a go at this, one task would be to make 
the program look more like typical Qt programs look like:
* main created the application object
* then creates the worker object, in this case the command
* then (on success of the previous step) runs app.exec()

Jonathan, what do you think?

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140228/bd97f246/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/