On Thursday, January 20, 2011, Matthieu Gallien wrote: > I believe that some of the current solutions rely on encoding the address > in the name of a requested source.
it often is, yes. > I am not sure if a service could be used and how. you could, yes, by implement serviceForSource and returning a Service object from there that is (internally) associated with that source. it could offer operations like "connect" with a string for the hostname and an optional int for the port. when called, that operation would then set some internal properties. the way i usual recommend doing this is by subclassing DataContainer to do all the network stuff and when serviceForSource is called, passing the DataContainer subclass object to the Service subclass :) keeps everything nicely separated and clear in the code. you could, of course, do the entire thing as a Service and not use a DataEngine at all. it probably quite depends on what sort of communication happens with the server; if it's a stateless "make a request, the server returns an answer" like http then a plan Service might be more straightforward. if there is ongoing communication with the server and/or the data ought to be shared between multiple widgets, then a DataEngine probably makes more sense. > PS : by the way, I noticed that there is no techbase tutorial on writing > services in a data engine. If the way it is done in the task engine is > correct, I can try in the following month to make some text, but I will > need a review from somebody. yes, the task engine is a reasonable example :) a simple example in kdeexamples/plasma/c++/dataengines/ would be nice, too, if you felt like it. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
