On 23/08/2010 21:41, Aaron J. Seigo wrote: > On Saturday, August 21, 2010, Dario Freddi wrote: >> However, I'd really like to remove that code from kdelibs as it definitely >> does not belong there. However, after a quick look at the code, I found out >> that such a thing would mean having a hard dependency on QtJolie in >> kdelibs. > right now, yes, but that would be easily resolved by making those code paths > conditional. that could be achieved through ifdef's or by abstracting out the > backend more if needed.
Yes, I'd probably go for ifdefs to get the job done quickly, although in the long term I'd surely like to see the backend being abstracted. > >> So, basically I'd like to know if anybody is planning to maintain remote >> widgets actively to plan what I should do. I am surely fond to learn Jolie >> as I'm interested in it, so I can volunteer for at least having a better >> situation than now. > awesome :) go head, imho. there was one GSoC student working with QtTelepathy > who was hoping to make remote widgets work over telepathy tubes. other than > that, i think it's a wide-open area for work to be done. Ok, that's cool :) I'll start with posting a review when I'll get KDELibs to compile without QtJolie, and then abstract things out from there. >> What I'd like to do is abstract the Jolie stack to let kdelibs compile >> without QtJolie itself (even if this would mean remote widgets won't >> really work). > yes, that would be fine; it would just mean that Applet wouldn't show the > share dialog and widgets announced on the network wouldn't show up in such a > build. it should be pretty much completely transparent to the outside world > without anything looking too ugly. Cool >> I also remember some people talking about abstracting dnssd >> for using $something else, but I'll leave this for the discussion. > yes, that would also be nice (though a different topic), and is what the GSoC > student would have needed to work on. i don't think he actually got that far, > however? anyways, abstracting that out was something that was taken into > consideration in the original design (which is why it is a bit more complex > than it probably really needs to be a couple of places internally). Hmm, I see. From what I saw it should be no monster work, but I can try to find out something about the former work with Telepathy - I hope it got at least started somehow, otherwise I'll try taking charge of this. > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
