Plasma->Model/View->Nepomuk

[PierreL]

Answers/remarks to 2 messages:

 
> Message: 4
> Date: Tue, 6 Oct 2009 15:16:48 +0200
> From: Ivan ?uki? <ivan.cukic at gmail.com>
> Subject: Re: Plasma->Model/View->Nepomuk
> To: plasma-devel at kde.org
> Message-ID: <200910061516.48632.ivan.cukic at gmail.com>
> Content-Type: Text/Plain;  charset="us-ascii"
> 
> Hi,
> 
> what happens when you just restart plasma (kquitapp
> plasma-desktop; sleep 2; 
> plasma-desktop) - does it load the data then?

Yip if I understand your question correctly. 

Let me explain, when KDE is up and running, by removing and adding the plasmoid, then the RDF store (Nepomuk) is read. (As I said; only on KDE startup, when the plasmoid was added in a previous session, I get this problem) 


> 
> How do you access nepomuk? Via its classes or via d-bus?

Use of the Nepomuk API set http://api.kde.org/4.3-api/kdelibs-apidocs/nepomuk/html/classNepomuk_1_1Resource.html 

> 
> >  session, when KDE starts, it seems, plasma is
> started before Nepomuk
> You can check whether this is the case by checking whether
> you can connect to 
> org.kde.nepomuk.<something> via d-bus.

Will do.

> 
> > 1. Should the plasmoid do checks on the Nepomuk store
> service on start-up
> > and if so
> 
> > 2. why is this necessary from a plasmoid point of
> view
> > 3. shouldn't plasma do this internally on start-up?
> Plasma (and the rest of KDE) doesn't have a hard-dependency
> on Nepomuk at the 
> moment, so waiting for Nepomuk to start is not really
> needed.

Agree, but debatable from a "plasmoid that uses Nepomuk" point of view.

Thanx,

> 
> Cheerio,
> Ivan


> Message: 3
> Date: Tue, 6 Oct 2009 12:46:24 -0600
> From: "Aaron J. Seigo" <aseigo at kde.org>
> Subject: Re: Plasma->Model/View->Nepomuk
> To: plasma-devel at kde.org
> Message-ID: <200910061246.24432.aseigo at kde.org>
> Content-Type: text/plain; charset="us-ascii"
> 
> On October 6, 2009, PierreL wrote:
> > The thing is now, with this plasmoid already added in
> a previous KDE
> >  session, when KDE starts, it seems, plasma is
> started before Nepomuk
> >  service or maybe I'm wrong, but the plasmoid's
> model is empty (not
> >  populated with any Nepomuk data).
> 
> either individual plasmoids need to track the availability
> of services, or we 
> need to provide a way in libplasma to do this.
> 
> right now we have the following important services that can
> modify the 
> behaviour of Plasmoids:
> 
> * compositing (status available via Theme; Svg's are
> updated)
> * power (Applet::shouldConserverResources; but no status
> change notification)
> * network (each plasmoid must do it via Solid::Networking,
> which provides both 
> current info as well as change notification)
> * nepomuk (each plasmoid must do it by checking dbus
> connections)
> 
> if this collection continues to grow, it might be a good
> idea to have some 
> mechanism generally available to track them.
> 
> one way to do this without adding API to libplasma would be
> to write a 
> DataEngine that starts tracking a given resource when a
> source is requested by 
> that name. 
> 
> e.g. if the "nepomuk" source is requested, it would create
> a nepomuk source 
> with perhaps { "available" => bool } as the data and
> update the source 
> whenever the resources becomes available or not.

So to do a check, before accessing Nepomuk. I'm still not sure about the order in which services are started in KDE or in which order it should be started :-), which was one of my concerns here. 

I'm not a expert on the Nepomuk server architecture but I see it registered as a DBus service at org.kde.NepomukServer, the Nepomuk service manager does have "bool isServiceAutostarted(QString service) & bool isServiceInitialized(QString name)" 

"The Nepomuk Server is a daemon which hosts all Nepomuk service including the main Nepomuk data repository. In normal operation it is started through KDE's autostart feature when logging into KDE. Starting it manually is as simple as typing "nepomukserver". This will start the daemon and all services.

Services are started as separate processes via the service wrapper application "nepomukservicestub". This design descision has been taken to enhance the stability of the Nepomuk system. Services are implemented by subclassing Nepomuk::Service and exporting it like any other KDE plugin."

Maybe someone like Sebastain Trueg can give a few hints to do this elegantly for any plasmoids using Nepomuk?

Thanx,

> 
> -- 
> Aaron J. Seigo