[Kde-pim] Re: Akonadi in a commandline tool

[Stephen Kelly]

Michael Schuerig wrote:

> On Friday 29 April 2011, Stephen Kelly wrote:
>> Michael Schuerig wrote:
>> > I'm trying to access Akonadi in a commandline tool, however there
>> > are still some crucial tasks I haven't found a way to achieve:
>> > 
>> > * Getting a list of the user-visible names of all (top level)
>> > collections.
>> > * Instantiating a Collection given its user-visible name.
>> > * Restricting a SPARQL query to a single collection.
>> > * Providing useful error messages for malformed SPARQL queries.
>> > 
>> > In GUI apps, the first two tasks are apparently handled by
>> > Akonadi::EntityTreeModel, but as that class is tied rather
>> > intimately to GUI functionality, I'm not sure if it is the right
>> > thing for my purpose.
>> 
>> The point of Akonadi::EntityTreeModel is to *not* be tied to gui
>> functionality at all, but allow gui functionality to rely intimately
>> on it.
> 
> Please correct me if I'm wrong. It is my understanding that models in
> Qt/KDE define a common SPI for anything that is supposed to be displayed
> in views.

Usually models are used with views, but as it is 'just' an interface, a 
command line tool could do something like 

QAbstractItemModel *model = getModel();

const int column = 0;
for (int i = 0; i < model->rowCount(); ++i) 
  cout << model->data(model(index(i, column)).toString();

Note though that as the EntityTreeModel (ETM) is populated dynamically and 
doesn't tell you what it is doing (such as if it is empty and will stay 
empty, or is running a fetch job that hasn't returned yet), you would have 
to somehow wait until the model is fully populated.

> As such, the model implementation itself preferably is just an
> adapter that moulds underlying functionality into that interface. 

Yes, this is a good description of what a model implementation is supposed 
to be.

> It is
> my impression that EntityTreeModel is a lot more than an adapter, it
> encompasses functionality that is not readily available elsewhere.

Such as? Mostly it just adapts Akonadi::Monitor into the QAbstractItemModel 
API. It allows some updating of items etc too though and handling of the 
akonadi server going up and down.

> 
>> It could be used in a command line tool just fine, but that's not to
>> say it's definitely right for the purpose. I might put together an
>> example application showing how it can be done/useful for the
>> purpose.
> 
> If using EntityTreeModel in non-GUI contexts such as commmandline tools
> and daemons is the accepted way then I go along. If all I want is read-
> only access to some data as it is right now, I get overwhelmed if I have
> to go through interfaces that confront me with, say, headers and change
> monitoring. 

Right, you don't need change monitoring. This is why I think the ETM is not 
really the right tool for you as it is right now. I think you should maybe 
start with using Jobs as Kevin suggested.

CollectionFetchJob *job = new CollectionFetchJob(Collection::root());

job->exec();

foreach (const Collection &collection, job->collections())
  printCollection(collection);

void printCollection(const Collection &collection)
{
  if (collection.hasAttribute<EntityDisplayAttribute>()) {
    EntityDisplayAttribute *eda = 
collection.attribute<EntityDisplayAttribute>();
    cout << eda->displayName();
    return;
  }
  cout << collection.name();
}

I didn't look up the API, so displayName might not be the right API there.

Replace Collection::root() with Collection(someId) above to list the sub 
collections of a collection with id someId.

> Obviously, I can achieve my purpose with such an interface,
> but as I'm still very much learning my way around the internals of KDE
> and Akonadi, I suspect I may have missed a way using a narrower
> interface.
> 
> Michael
> 

HTH, 

Steve.


_______________________________________________
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/