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. > 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. > 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. > 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). -- 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
