Re: [GSoC] Impress Remote and Bonjour

classic Classic list List threaded Threaded
11 messages Options
Michael Meeks-2 Michael Meeks-2
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour

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.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Siqi Liu Siqi Liu
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour

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.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Siqi Liu Siqi Liu
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour

Hello all again, 

I've just restored the old implementation and also keep the bonjour service available for Mac OSX as an extra. 

I've done several tests today and I've found that the old implementation indeed works under certain conditions, so I've restored it. However, it only seems to work when the LibreOffice instance is already launched on the PC and only then, when we start the android app, we can see that. And when we close the LibO instance, it doesn't disappear either. Anyway, I think it would be great to make android app compatible with the avahi/bonjour service (not really sure if that's possible) so that we can get it to work more reliably not the other way around... 

Also, I've had some troubles compiling DiscoveryService.cxx with avahi in it, it seems that I need to pass in some flags for this to work. I've tried to put this in the sd/Library_sd.mk

    sd/source/ui/remotecontrol/DiscoveryService, \
    -lavahi-common \
    -lavahi-client \
    -fpermissive \

but it doesn't seem to work ... any helps on how to pass flags in .mk files? 


Cheers, 
Siqi 


2013/7/20 Siqi Liu <[hidden email]>
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.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot




--
--------

Cordialement,
Siqi LIU

Étudiant Ingérieur, Université de Technologie de Compiègne
Vice-Président de l'association robotique UTCoupe
Responsable d'atelier de ClubChine

------
  Tel. +33 7 61 16 95 83
  email: [hidden email]
------

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Andrzej Hunt Andrzej Hunt
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour

On Sun, 2013-07-21 at 14:17 +0200, Siqi Liu wrote:
> Hello all again,

>
>
> I've done several tests today and I've found that the old
> implementation indeed works under certain conditions, so I've restored
> it. However, it only seems to work when the LibreOffice instance is
> already launched on the PC and only then, when we start the android
> app, we can see that. And when we close the LibO instance, it doesn't
> disappear either. Anyway, I think it would be great to make android
> app compatible with the avahi/bonjour service (not really sure if
> that's possible) so that we can get it to work more reliably not the
> other way around...
>
Would be interesting to see -- the reason I implemented the custom
discovery protocol was because mdns support on android is apparently
somewhat patchy -- things are supposed to have improved in newer
versions (4.0+ I believe), but I haven't tested recently, and there are
still plenty of devices with older versions of Android around.

No idea why the custom protocol is so patchy though -- is this using the
Android client? LO definitely has to be launched as it listens for
multicast packets from the client (which the client sends every 10s or
so) and responds to the client to let it know its existence -- might be
worth adding some code to the server side to
(1) Show the IP in the remote dialog.
(2) Show a message to the user if either of the remote ports
    is already in use?
If we could detect firewall issues as well that would be good but no
idea if that's even doable.

I've also noticed a possible bug to do with the timeout/search interval
in the android app, whereby a while loop could possibly be spinning
empty for 5 seconds at a time every 15 seconds (I didn't do much testing
of this at the time as I was trying to get Bluetooth working then and
after that never used the networked option again...) -- I'll try and fix
and test that during the course of this week.

However using Avahi/Bonjour is definitely preferable when available.

ATB,
        Andrzej



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-2 Michael Meeks-2
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour


On Sun, 2013-07-21 at 20:08 +0200, Andrzej J. R. Hunt wrote:
> No idea why the custom protocol is so patchy though -- is this using the

        I've never had any particularly deep joy with it myself :-) as long as
we're back-compat over bluetooth, I'd be inclined to abandon the old
WiFi stuff for Bonjour - if we can make it work nicely for Android too.

> However using Avahi/Bonjour is definitely preferable when available.

        Indeed :-)

        Thanks,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Artur Dryomov Artur Dryomov
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour

Hi All,

Siqi, the current implementation works fine with Android and commenting things or removing them is actually breaking existing clients. It would be great if you’ll do all protocol-related changes via Gerrit and always CC me and Michael. These changes shouldn’t be silent because there are thousands of active Android users using remote client. If you have any questions about the Android implementation — poke me and I’ll give you my opinion, it is highly welcome. The second thing is about the protocol itself — it would be great if you‘ll write down all known bugs and desired features to the wiki page so I can fix them or implement them. It is great that you post things to the mailing list but I just can forget to read some thread and then bug or feature will be missed, that’s why there is a wiki page for that (and Bugzilla as well). I hope that my words are reasonable and I’m sorry if they sound harsh — I didn’t mean that.

Andrzej, can you post the timeout bug to Bugzilla and CC me? I’ll try to test it on the NG version. Thanks for mentioning firewall issues — I saw a related comment at the Google Play page, I’m adding it to my TODO list.

And let me be the most pessimistic guy in the room about Zeroconf — it becomes a tradition, huh ;-)
Well, the Zeroconf conception is great. It worked perfectly since the first versions of OS X and it always was an example for me about how things should work in real world for people who doesn’t know what IP addresses are and what to do to connect to computers and share files. You don’t need that — just patch a cable or connect to WiFi and you are already set. So I’m not against it at all.
The point is that world is not ideal. I don’t really know how to make Bonjour work on Windows but I think it is tricky at least. What I know is Avahi sometimes is not installed on Linux stations — and if it is that doesn’t mean Avahi actually work because it just could be not active as a daemon. I’m not sure that an additional dependency for just discovering via remote clients for a very small (I think so and have no statistics) percentage of users is a great idea as well.
The network service discovery support is available only starting Android 4.1 [1] which is not acceptable because there are a lot of users using older Android versions [2]. There is an external library [3] but is seems not updated for a while. Also I don’t know is it a great idea to put an external dependency for the client — we had a talk with Michael about that already ;-)
Does that make sense?

Regards,
Artur.


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Siqi Liu Siqi Liu
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour




2013/7/22 Artur Dryomov <[hidden email]>
Hi All,

Siqi, the current implementation works fine with Android and commenting things or removing them is actually breaking existing clients. It would be great if you’ll do all protocol-related changes via Gerrit and always CC me and Michael. These changes shouldn’t be silent because there are thousands of active Android users using remote client. If you have any questions about the Android implementation — poke me and I’ll give you my opinion, it is highly welcome. The second thing is about the protocol itself — it would be great if you‘ll write down all known bugs and desired features to the wiki page so I can fix them or implement them. It is great that you post things to the mailing list but I just can forget to read some thread and then bug or feature will be missed, that’s why there is a wiki page for that (and Bugzilla as well). I hope that my words are reasonable and I’m sorry if they sound harsh — I didn’t mean that.

Hi Artur, I've already restored the old implementation a couple of days ago so it should work as before now. Sorry that I've commented that out since it seemed like it doesn't work on my device. You can pull the master branch and it should be working with the android app. However, as I said earlier, the current implementation is still less reliable than the Bonjour/Avahi service, but if that is too complicated to use on the android then it's fine to stick to the old implementation, that's up to you. 

I will try to remember to put what bugs that I've found on the wiki page so that you can find them easily. Just didn't have the time to organize them. Maybe you can create a filter (if you use gmail) which put all mails from Micheal, Andrzej and me together so that you don't miss them ^^ That's what I've done, maybe it can comes handy to you as well. There is absolutely no problem to stay direct with me :-P I mean we are all gsoc students so we both have a lot to learn. ^^ 
 
 
Andrzej, can you post the timeout bug to Bugzilla and CC me? I’ll try to test it on the NG version. Thanks for mentioning firewall issues — I saw a related comment at the Google Play page, I’m adding it to my TODO list.

And let me be the most pessimistic guy in the room about Zeroconf — it becomes a tradition, huh ;-)
Well, the Zeroconf conception is great. It worked perfectly since the first versions of OS X and it always was an example for me about how things should work in real world for people who doesn’t know what IP addresses are and what to do to connect to computers and share files. You don’t need that — just patch a cable or connect to WiFi and you are already set. So I’m not against it at all.
The point is that world is not ideal. I don’t really know how to make Bonjour work on Windows but I think it is tricky at least. What I know is Avahi sometimes is not installed on Linux stations — and if it is that doesn’t mean Avahi actually work because it just could be not active as a daemon. I’m not sure that an additional dependency for just discovering via remote clients for a very small (I think so and have no statistics) percentage of users is a great idea as well.

Actually Avahi comes with most of the modern Linux distro and Bonjour comes with Mac OSX. But yes, on Windows it can be tricky but it seems that a lot of widely used software needs that service as well, so we can probably find a way to handle that as well. For now, I've implemented the Mac OSX with bonjour and Avahi on Linux just needs some modifications to be able to build with some CFLAGS. I'm working on that. 
 
The network service discovery support is available only starting Android 4.1 [1] which is not acceptable because there are a lot of users using older Android versions [2]. There is an external library [3] but is seems not updated for a while. Also I don’t know is it a great idea to put an external dependency for the client — we had a talk with Michael about that already ;-)

Yep, on Android there is always a problem of fragmentation and maybe at least you can make it conditional on the android app? If (version>4.1) Bonjour resolution else ... Otherwise I suppose the IP resolution should be really easy as it's just several lines of code on iOS. 
 

Happy coding!

--
--------

Cordialement,
Siqi LIU

Étudiant Ingérieur, Université de Technologie de Compiègne
Vice-Président de l'association robotique UTCoupe
Responsable d'atelier de ClubChine

------
  Tel. +33 7 61 16 95 83
  email: [hidden email]
------

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-2 Michael Meeks-2
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour

In reply to this post by Siqi Liu
Hi Siqi,

On Sat, 2013-07-20 at 11:18 +0200, Siqi Liu wrote:
> 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.

        Has anyone managed to help you with some code pointers here yet ?
Trying to use the XCanvas for rendering is ... in my experience deeply
problematic. Something as simple as 'draw a rectangle' is ... acutely
non-obvious in my experience ;-)

        In the absence of better advice (and I'm no impress expert) I'd
personally try hooking off the existing 'scribble on slides' code -
which if you right click during a presentation allows you to draw over
the current slide:

        git grep -10 CM_PEN_MODE

        This disappears into a set of UNO properties set on the slideshow code
eg.

            // for Pen Mode
            beans::PropertyValue aPenPropSwitchPenMode;
            aPenPropSwitchPenMode.Name = "SwitchPenMode";
            aPenPropSwitchPenMode.Value <<= sal_True;
            mxShow->setProperty( aPenPropSwitchPenMode );

        Which lives in slideshow/

source/engine/slideshowimpl.cxx:    if ( rProperty.Name == "SwitchPenMode" )
source/engine/slideshowimpl.cxx-    {
source/engine/slideshowimpl.cxx:        bool nSwitchPenMode(false);
source/engine/slideshowimpl.cxx:        if (rProperty.Value >>= nSwitchPenMode)
source/engine/slideshowimpl.cxx-        {

        Presumably the mouse event code there goes down a different path that
builds out some goodness to render on top of the slides in this mode
that we could hook / use a different event for.

        Does that make sense ?

        Personally I'd be inclined to load a bitmap that has a nice central
point & alpha pattern around it and composite it on top and let the
artists go wild with that :-)

        Hope that's helpful, Thorsten is really the expert here :-)

        ATB,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour

Michael Meeks wrote:
> Has anyone managed to help you with some code pointers here yet ?
>
Was talking that over with Siqi on irc already - for something that
moves on screen, XSprite is the thing to use. ;)

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (853 bytes) Download Attachment
Michael Meeks-2 Michael Meeks-2
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour


On Thu, 2013-07-25 at 10:51 +0200, Thorsten Behrens wrote:
> Michael Meeks wrote:
> > Has anyone managed to help you with some code pointers here yet ?
>
> Was talking that over with Siqi on irc already - for something that
> moves on screen, XSprite is the thing to use. ;)

        Thanks - sorry for duplicating that ;-) Siqi - do you have the
structural overview of what you need and/or how to couple that into the
remote code ? :-) I guess the nominally thread-safe UNO API for
slideshow might be a help here, though I'd be rather tempted to do idle
rendering / dispatch of anything graphical in the main UI thread and not
trust the thread-safety: it already caused significant problems around
thumbnailing IIRC.

        Anyhow - looking forward to seeing this feature ;-) IMHO it's a really
neat one.

        ATB,

                Michael.

--
michael .[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Siqi Liu Siqi Liu
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote and Bonjour

Hello Michael and Thorsten, 

I'm now working on refactoring the Avahi/Bonjour integration to get a platform independent abstraction for publishing zeroconf service. And I will move on to continue with the pointer functionality once I've finished the Avahi/Bonjour one.

I've already attempted to follow the example of engine/slideshow/waitsymbol.cxx as pointed out by Thorsten but I am a bit lost here when it comes to calling the setPointerVisble and setPointerPosition methods that I've defined in ui/source/slideshow/slideshowImpl, from within the Receiver.cxx class in source/remotecontrol.

The problem is that I only have access to XPresentation2 and XSlideShowController interface and I don't know how can we call those methods defined in the slideshowImpl...I've git grep for other methods defined in the slideshowImp but it seems that they are called from no where outside the class itself... maybe I've made some silly mistakes by defining those methods in the slideshowImpl in the first place? 

It has become much more complicated when it comes to coding on the LibreOffice code base itself than coding in my little corner for the iOS ^^ But I'll try to get up to speed here. 

Siqi


2013/7/25 Michael Meeks <[hidden email]>

On Thu, 2013-07-25 at 10:51 +0200, Thorsten Behrens wrote:
> Michael Meeks wrote:
> >     Has anyone managed to help you with some code pointers here yet ?
>
> Was talking that over with Siqi on irc already - for something that
> moves on screen, XSprite is the thing to use. ;)

        Thanks - sorry for duplicating that ;-) Siqi - do you have the
structural overview of what you need and/or how to couple that into the
remote code ? :-) I guess the nominally thread-safe UNO API for
slideshow might be a help here, though I'd be rather tempted to do idle
rendering / dispatch of anything graphical in the main UI thread and not
trust the thread-safety: it already caused significant problems around
thumbnailing IIRC.

        Anyhow - looking forward to seeing this feature ;-) IMHO it's a really
neat one.

        ATB,

                Michael.

--
michael .[hidden email]  <><, Pseudo Engineer, itinerant idiot




--
--------

Cordialement,
Siqi LIU

Étudiant Ingérieur, Université de Technologie de Compiègne
Vice-Président de l'association robotique UTCoupe
Responsable d'atelier de ClubChine

------
  Tel. +33 7 61 16 95 83
  email: [hidden email]
------

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice