With nwoki making really cool progress on the presence plasmoid the only outstanding task is file transfer \o/.<div><br></div><div>With this in mind I want the following.</div><div> - If there&#39;s any bug (not file transfer) and you think it&#39;s important make sure it&#39;s both on bugzilla and blocking the &quot;make a preview release of telepathy&quot; bug. </div>
<div><br></div><div>- Try and be in a pseudo-feature freeze and focus on fixing small UI issues. If you want to do any big changes, ask the ML first.</div><div><br></div><div>- Review any strings (bits of text) used throughout the apps, we don&#39;t want to change things /after/ it&#39;s been translated. </div>
<div><br></div><div>- Make sure everything all works nicely together with each other, look for inconsistencies between our components. Sensible defualts on first run etc. Fix anything if it comes up.</div><div><br></div><div>
 - Start thinking of what we want to do for the 0.2 release. </div><div><br></div><div>We&#39;re still maybe 2-4 weeks away, depending on how file transfer goes. May as well make the time to make the rest of it super awesome.</div>
<div><br></div><div><div><div><div class="gmail_quote">On Thu, May 12, 2011 at 10:13 PM, David Edmundson <span dir="ltr">&lt;<a href="mailto:david@davidedmundson.co.uk">david@davidedmundson.co.uk</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><br><div class="gmail_quote"><div class="im">On Wed, May 11, 2011 at 6:03 PM, Daniele E. Domenichelli <span dir="ltr">&lt;<a href="mailto:daniele.domenichelli@gmail.com" target="_blank">daniele.domenichelli@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/11/2011 06:09 PM, David Edmundson wrote:<br>
&gt; *270672: Channelhandler daemon for file transfers<br>
<div>&gt; *<br>
&gt; Dr Danz started this, hit some issues which means we&#39;ll only get working<br>
&gt; support in Jabber. Also requires a change in TpQt4. We can&#39;t ship until<br>
&gt; this change is merged into TpQt4 and they make a release. This is<br>
&gt; probably going to be the biggest hold-up.<br>
&gt;<br>
&gt; Could we try and make sure any work gets pushed to somewhere on kde git.<br>
<br>
</div>This is the blocking bug in TpQt4:<br>
<br>
   <a href="https://bugs.freedesktop.org/show_bug.cgi?id=37034" target="_blank">https</a><font color="#0000ee"><u>://<a href="http://bugs.freedesktop.org/show_bug.cgi?id=37034" target="_blank">bugs.freedesktop.org/show_bug.cgi?id=37034</a></u></font><br>



<br>
I can work on that bug, but I require some feedback from TpQt4 developers.<br>
oggis_, andrunko: ping ^ :D<br>
<br>
<br></blockquote></div><div>Caught Andrunko on IRC:</div><div><br></div><div><div>[22:01] &lt;andrunko&gt; d_ed, the approach seems ok, just add a new constructor and a setURI, etc as needed there and pass the info when requesting the FT channels</div>


<div>[22:01] &lt;andrunko&gt; and do not remove or deprecate current ones</div></div><div>[22:04] &lt;andrunko&gt; d_ed, also obviously add a FT::uri() accessor, so handlers can get the uri passed</div><div><br>
</div><div>As far as I understand it that&#39;s exactly what we wanted to hear (options 1&amp;2 of your bug report), but they&#39;re not allowing any changes which break binary computability (understandably).</div><div><div>
</div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Moreover the only connection managers that support the URI property at<br>
the moment seem to be gabble and salut therefore, file transfer will be<br>
supported only by those connection managers (unless we add some sort of<br>
ugly hack).<br>
<br>
<br>
<br>
Most of the handler is already written, therefore I believe that if<br>
TpQt4 bug is resolved we can ship it with the first release.<br>
<br>
By the way, as discussed on irc, I&#39;m implementing it as a one-shot file<br>
transfer handler (no daemon), therefore as soon as the channel is<br>
received it will unregister from D-Bus and start the file transfer and<br>
exit as soon as it finishes.<br>
If a new file transfer channel is received, a new instance of the file<br>
transfer handler will be started by MC.<br>
<br>
I believe that this is the best way to do it because:<br>
<br>
1) A crash in one process won&#39;t kill all the other file transfers.<br>
2) There is no daemon running all the time and no need to check if it<br>
   is possible to exit or if there are more transfers running.<br>
3) There shouldn&#39;t be racing condition with handler exiting/new file<br>
   transfers channel sent by MC (I&#39;m not sure if there could be a<br>
   racing condition with handler unregistering/new file transfer<br>
   channel sent by MC).<br>
<br>
If someone believes that this is wrong or has anything to tell about<br>
this issue, please speak now... :D<br>
<br>
<br>
&gt; *270673: Support FileTransfer channel types  [ in approver]<br>
<div>&gt; *<br>
&gt; I&#39;ve not heard of any work on this. Probably waiting on the<br>
&gt; channelhandler. I think it&#39;s pretty trivial though.<br>
<br>
</div>I started writing that, and I believe that also George K. started, but<br>
the main issue for this is that popup notifications can be hidden by the<br>
user...<br>
<br>
<br>
<br>
Cheers,<br>
 Daniele<br>
_______________________________________________<br>
KDE-Telepathy mailing list<br>
<a href="mailto:KDE-Telepathy@kde.org" target="_blank">KDE-Telepathy@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-telepathy" target="_blank">https://mail.kde.org/mailman/listinfo/kde-telepathy</a><br>
</blockquote></div></div></div><br>
</blockquote></div><br></div></div></div>