<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 23/08/2010 21:41, Aaron J. Seigo wrote:
<blockquote cite="mid:201008231241.42834.aseigo@kde.org" type="cite">
<pre wrap="">On Saturday, August 21, 2010, Dario Freddi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:201008231241.42834.aseigo@kde.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:201008231241.42834.aseigo@kde.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
Cool<br>
<br>
<blockquote cite="mid:201008231241.42834.aseigo@kde.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I also remember some people talking about abstracting dnssd
for using $something else, but I'll leave this for the discussion.
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:201008231241.42834.aseigo@kde.org" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Plasma-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/plasma-devel">https://mail.kde.org/mailman/listinfo/plasma-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>