QtJolie and remote widgets

[Dario Freddi]

 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100827/aaf86486/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100827/aaf86486/attachment.sig