<div dir="ltr">Hi all,<div><div class="gmail_extra">I have implemented the neighborhood view using Avahi instead of telepathy.</div><div class="gmail_extra">Here, all the buddies that are connected to the same port are shown in neighborhood view.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Whenever buddy gets connected he adds a service to an EntryGroup which is discovered by all buddies(including the ones that are connected later) and hence buddy is added to neighborhood.</div><div class="gmail_extra"><br></div><div class="gmail_extra">And when buddy gets disconnected the service started by that buddy is stopped and hence removed from the ServiceBrowser this emits a signal "ItemRemove" which is received by other buddies and hence buddy disconnected is removed from the neighborhood view.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I have used profile.pub_key to overcome the issue of duplicate buddies.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">You could test my code[1] and review it and even a few suggestions that pops up in your mind :)</div><div class="gmail_extra">[1] <a href="https://goo.gl/PBWy08">https://goo.gl/PBWy08</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Abhijit</div><div class="gmail_extra"><div class="gmail_quote">On 27 July 2016 at 21:30, <span dir="ltr"><<a href="mailto:sugar-devel-request@lists.sugarlabs.org" target="_blank">sugar-devel-request@lists.sugarlabs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send Sugar-devel mailing list submissions to<br>
<a href="mailto:sugar-devel@lists.sugarlabs.org">sugar-devel@lists.sugarlabs.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:sugar-devel-request@lists.sugarlabs.org">sugar-devel-request@lists.sugarlabs.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:sugar-devel-owner@lists.sugarlabs.org">sugar-devel-owner@lists.sugarlabs.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Sugar-devel digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Thoughts on Collab (Dave Crossland)<br>
2. Re: Thoughts on Collab (Sebastian Silva)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 26 Jul 2016 19:16:30 -0400<br>
From: Dave Crossland <<a href="mailto:dave@lab6.com">dave@lab6.com</a>><br>
To: Sebastian Silva <<a href="mailto:sebastian@fuentelibre.org">sebastian@fuentelibre.org</a>><br>
Cc: sugar-devel <<a href="mailto:sugar-devel@lists.sugarlabs.org">sugar-devel@lists.sugarlabs.org</a>>, "Sam P."<br>
<<a href="mailto:sam.parkinson3@gmail.com">sam.parkinson3@gmail.com</a>><br>
Subject: Re: [Sugar-devel] Thoughts on Collab<br>
Message-ID:<br>
<CAEozd0zY5ve1YOnOdsV7fhkpWcyrD+h3mkL-xDE=YMUex8cT=<a href="mailto:w@mail.gmail.com">w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Jul 26, 2016 4:12 PM, "Sebastian Silva" <<a href="mailto:sebastian@fuentelibre.org">sebastian@fuentelibre.org</a>><br>
wrote:<br>
><br>
> El 26/07/16 a las 14:05, Dave Crossland escribió:<br>
>><br>
>><br>
>> On Jul 26, 2016 2:36 PM, "Sebastian Silva" <<a href="mailto:sebastian@fuentelibre.org">sebastian@fuentelibre.org</a>><br>
wrote:<br>
>> ><br>
>> > El 26/07/16 a las 13:08, Dave Crossland escribió:<br>
>> >><br>
>> >> Despite my suggestion to look at zeromq, I think we should be using<br>
the collaboration protocols that Lionel is using in Sugarizer, so that<br>
someone running Sugar desktop and someone using Sugarizer on a Chromebook<br>
(for example, 2 kids in a family at home who attend 2 different schools<br>
that have different hardware purchasing decisions ;) could collaborate.<br>
>> ><br>
>> > It's not a dichotomy.<br>
>> ><br>
>> > If two users use the same app [and it supports collaboration] - it<br>
should just work regardless of the environment where they are run.<br>
>> ><br>
>> > Much like running etherpad @ titanpad.<br>
>><br>
>> I mean to propose a requirement for any new collaboration system that is<br>
recommended to all sugar developers be that it support collaboration<br>
between a python paint application and a Javascript paint application.<br>
><br>
> That sounds challenging and not too useful.<br>
><br>
>> And therefore the system that meets that requirement is the one used by<br>
sugarizer today.<br>
<br>
Why could using the system on sugarizer from python be more challenging<br>
than writing a new system with zeromq or similar? :)<br>
<br>
>> >> However, I am eagerly awaiting Sameer's next installment of the<br>
vision quest process, because without the vision/mission/etc defined, we<br>
can't make informed technical decisions about what kind of collaboration<br>
protocols are best.<br>
>> ><br>
>> ><br>
>> > Maybe we shouldn't have to judge - they can all coexist.<br>
>><br>
>> An anti-design approach where no system is recommended and each activity<br>
developer can figure out their own system seems counter to the aims of a<br>
cohesive and consistent learning platform in which collaboration is<br>
promoted as a top tier feature :)<br>
><br>
> User facing features are at the application level. How they are<br>
implemented is only a detail. I'd rather have a paint app that<br>
collaborates, no matter how it is built. Currently we have none.<br>
<br>
The technology that Sugar platform offers to activity developers is what<br>
determines if they implement collaboration as a user facing feature. It<br>
seems to me that the current platform recommendation is for something that<br>
was experimental 10 years ago and has not matured in this time, so I am not<br>
surprised to hear central apps like paint don't implement features with it.<br>
<br>
> It is part of our philosophy to promote collaboration - at all levels -<br>
open organizations, user freedom, git, wiki, etc.<br>
<br>
Right - so I think its worth considering the strategic context of the<br>
implementation details: )<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160726/ee8fa789/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160726/ee8fa789/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 26 Jul 2016 19:27:29 -0500<br>
From: Sebastian Silva <<a href="mailto:sebastian@fuentelibre.org">sebastian@fuentelibre.org</a>><br>
To: Dave Crossland <<a href="mailto:dave@lab6.com">dave@lab6.com</a>><br>
Cc: sugar-devel <<a href="mailto:sugar-devel@lists.sugarlabs.org">sugar-devel@lists.sugarlabs.org</a>>, "Sam P."<br>
<<a href="mailto:sam.parkinson3@gmail.com">sam.parkinson3@gmail.com</a>><br>
Subject: Re: [Sugar-devel] Thoughts on Collab<br>
Message-ID: <<a href="mailto:a63ded9b-b26b-1249-6095-b1208b9bec4b@fuentelibre.org">a63ded9b-b26b-1249-6095-b1208b9bec4b@fuentelibre.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
El 26/07/16 a las 18:16, Dave Crossland escribió:<br>
<br>
> > User facing features are at the application level. How they are<br>
> implemented is only a detail. I'd rather have a paint app that<br>
> collaborates, no matter how it is built. Currently we have none.<br>
><br>
> The technology that Sugar platform offers to activity developers is<br>
> what determines if they implement collaboration as a user facing<br>
> feature. It seems to me that the current platform recommendation is<br>
> for something that was experimental 10 years ago and has not matured<br>
> in this time, so I am not surprised to hear central apps like paint<br>
> don't implement features with it.<br>
><br>
<br>
At the time perhaps a decision was required because the "platform"<br>
needed to fit into 1GB of the XO1 nand flash.<br>
<br>
In this case (because we are discussing Sugar/GTK), the "platform" is<br>
all of GNU/Linux.<br>
<br>
Perhaps the "official" recommendation should stay at the design / UI /<br>
philosophical level. After all, as you say, Sugarizer uses something<br>
different (that is...?).<br>
><br>
> > It is part of our philosophy to promote collaboration - at all<br>
> levels - open organizations, user freedom, git, wiki, etc.<br>
><br>
> Right - so I think its worth considering the strategic context of the<br>
> implementation details: )<br>
><br>
Only if you are planning on implementing (and maintaining!) "it"...<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Sugar-devel Digest, Vol 93, Issue 60<br>
*******************************************<br>
</blockquote></div><br></div></div></div>