Hello all,
Sorry if I've broken something unexpectedly :P Actually I've commented the
current implementation out since it doesn't seem to work during my tests
with the android app... I mean, the auto discovery for Bluetooth
connections works well but the one with WiFi doesn't seem to work for me
(correct me here since I've done the tests before the gsoc actually, maybe
I've missed something :-P). Also need confirmation from Ahunt (I've cc
Ahunt also), since he has implemented this part I guess. Do let me know if
it works in your tests, in that case I will try to put them back to keep it
compatible with older implementation.
Concerning the backward compatibility, it doesn't seem to be an issue for
now because I've basically replaced some code that doesn't seem to work
(for me) with a new version backed by Bonjour/Avahi service, but in case it
prevents some functionalities to work, please let me know ^^.
On the server end, what I've done for now is:
1. Bonjour service publishing for Mac OSX
2. I've add some code to handle pointer feature, which follow the
protocol like this:
pointer_coordination\nx\ny\n\n, where x and y are in
percentage (0-1), taking upper left corner as the origin.
3. Try to correct the bug which gives the remote control false
currentSlideIndex in the "presentation_started" message
What I'm doing now:
1. Implement Avahi service publish for Linux and Bonjour for Windows
build. Still need a lot of research here :-P
What I've wanted to do but failed:
1. Draw a point on the running slideshow (like the pen feature), based
on the "pointer_coordination x y" command. I've tried to find out how to do
some drawing on the canvas but I didn't really understand the code there...
not sure if we can add a small red rectangle and move that to the position
corresponding to the "pointer_coordination", for now it just prints out the
coordination received.
2. The problem with currentSlideIndex seems to take place whenever we
connect the PC to an external display and we start a presentation for
middle. The remote app will always receive 0 instead of the real
"currentSlideIndex". The reasons, as far as I know, is related to the
UpdateCurrentSlide(0); in sdext/source/presenter/PresenterController.cxx.
Actually every time we launch the presentation, the thread which initiate
the presenter will reset currentSlide to 0 due to some reasons (don't know
why we need to UpdatecurrentSlide(0);) and the thread which sends
"presentation_started" to the remote will ask for the currentSlideIndex
after that, so it gets 0.
What would be great to improve on the server-end:
1. Add some version information during the hand-shake phase.
2. Add some screen size information (or just small, medium, big flags)
during the handshake, so that we can modify the preview size in the
ImagePreparer.cxx accordingly. In case when I build the iPad version of the
app, we will have some beautiful previews pictures instead of an
over-enlarged one...
On the android end, it seems that it's also possible to benefit from the
Bonjour Service discovery
http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html maybe
this can help ^^ But if the old implementation of WiFi auto-discovery works
already on your device, I will try to restore it so that we don't need to
change anything on the android app.
All the best! and Happy Coding!
Siqi
On Saturday, July 20, 2013, Michael Meeks wrote:
Hi guys,
On Sat, 2013-07-20 at 03:11 +0300, Artur Dryomov wrote:Hi guys,
I noticed your commit which comments the current discovery service and
replaces it with the Bonjour calls. Probably it is not a great idea —
I mean commenting the current version — because it will break all
Android applications which expect to get responses from server.
First - Siqi - just to say I've been really impressed with your
work :-) it's great to see the iOS remote looking so nice & making good
progress.
Or I just don’t understand the idea? I thought Bonjour could work for
OS X as an addition and not as a replacement.
I guess we would want to add Bonjour support for all platforms
(perhaps
via some cleanish platform abstraction ?) since the iOS remote really
has to use WiFi / Bonjour IIRC to work.
Siqi - clearly we want to keep back-wards compatibility; though my
greatest concern is only one-directional: IMHO it is trivial for people
to update their remote on their mobile: it's a tiny app and updates in a
few tens of seconds, also I think we can expect them to test that before
they present (at least after a LibreOffice upgrade). So - we should put
most effort into making sure that newer remotes talk to older
libreoffice's - rather than the other way around :-)
It would be great to hear Michael’s thoughts. Should we CC the devs
list ?
Yes of course; I've added that :-)
I also thought to place all protocol-related changes to Gerrit and
discuss them there because it is really easy to break things. Does it
sound reasonable?
Well - I'd hate to slow Siqi down - it's great to see the native
code
progressing there - but I guess agreeing the compatibility rules before
we get going is prolly a good idea.
HTH,
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.