[GSoC] Impress Remote Protocol

classic Classic list List threaded Threaded
13 messages Options
Artur Dryomov Artur Dryomov
Reply | Threaded
Open this post in threaded view
|

[GSoC] Impress Remote Protocol

Hi All,

I have created a wiki page where I moved some information from Git and placed some thoughts about the Impress remote protocol.


It would be really great if Andrzej could improve the information about the first version of protocol.
Probably there are other commands — like pairing ones — that are missed. But I can be wrong :-)

This page contains my proposal of the second version of protocol as well.
It would be interesting to see other proposals and hear thoughts and opinions.

Siqi is working on the iOS remote client and I am working on the Android remote.
I think it would be better for us to work on clients based on the first version of protocol and then move to the second version when it will be ready.

So let’s call this iteration “call for proposals” :-)

I’ll read Google Play reviews soon to find out new feature requests.
BTW — is it possible to get the access to the Android developer console?
Google Play shows reviews for a current language only, the developer console can show all reviews at once.

Regards,
Artur.
 


_______________________________________________
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 Protocol

Hi,
On 13/06/13 19:32, Artur Dryomov wrote:
Hi All,

I have created a wiki page where I moved some information from Git and placed some thoughts about the Impress remote protocol.


It would be really great if Andrzej could improve the information about the first version of protocol.
Probably there are other commands — like pairing ones — that are missed. But I can be wrong :-)
Looks correct, although I've not looked at this in a while so I might be forgetting some details. The definitive resources however are sd/source/ui/remotecontrol/Receiver.cxx & android/sdremote/src/org/libreoffice/impressremote/communication/Receiver.java which are both fairly small/simple.


This page contains my proposal of the second version of protocol as well.
It would be interesting to see other proposals and hear thoughts and opinions.
We actually did originally use JSON last year, but moved to a text based protocol to avoid having to deal with additional libraries and to reduce overhead, (although I'm not very well qualified to judge the relative merits of each). The main issue is making sure that the protocol is usable on all the necessary platforms. No idea how easy it is to use JSON or XML with iOS, Android seems to have good support for JSON but no idea about XML, Firefox OS (javascript) has great JSON support and shouldn't be too hard to use XML either -- in any case plaintext is still the easiest to parse. (I can't remember what library I used within LO for json anymore -- it might have been json-glib -- but any additional libraries mean extra work with integrating them into the LO since I was using an external library.)

I don't see any real need to switch from plain text though -- the commands are very simple (as most 3 parameters per command), i.e. easier to parse directly than through another layer. Extending the current protocol  avoids having to do any special work to keep backwards compatibility (e.g. any unrecognised commands will simply be ignored by older clients at the moment). Adding another layer looks like it'll just make the code more complicated without any benefit. It's even been suggested to go the other way and use a binary protocol (although that won't play well with the Firefox OS remote since Javascript doesn't like binary).

A versioning/handshake system would still be useful though so that clients and servers know what features are supported, especially w.r.t. to knowing whether the laser pointer can be used / slide previews & notes have to be actively fetched / etc.

I’ll read Google Play reviews soon to find out new feature requests.
BTW — is it possible to get the access to the Android developer console?
Google Play shows reviews for a current language only, the developer console can show all reviews at once.
No idea -- I'm not entirely certain who controls the TDF Play account.

I think the two main ideas being floated though were adding a "laser-pointer" and storage of presentations on the phone (i.e. as a usb-stick/web/etc. replacement).

Also one thing I did look at but didn't get very far with was sending fully formatted presentation notes -- at the moment they are unformatted (except for newlines) -- the necessary logic to output html notes is already in the export filters but would need adapting to output the notes for a single slide.

ATB,

    Andrzej

_______________________________________________
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 Protocol

Hi Andrzej,

> Looks correct, although I've not looked at this in a while so I might be forgetting some details. The definitive resources however are sd/source/ui/remotecontrol/Receiver.cxx & android/sdremote/src/org/libreoffice/impressremote/communication/Receiver.java which are both fairly small/simple.

Yep, I already read the code in the process of preparing the wiki page. I thought maybe something was wrong or not correct and you can fix it.

> We actually did originally use JSON last year, but moved to a text based protocol to avoid having to deal with additional libraries and to reduce overhead, (although I'm not very well qualified to judge the relative merits of each). The main issue is making sure that the protocol is usable on all the necessary platforms. No idea how easy it is to use JSON or XML with iOS, Android seems to have good support for JSON but no idea about XML, Firefox OS (javascript) has great JSON support and shouldn't be too hard to use XML either -- in     any case plaintext is still the easiest to parse. (I can't remember what library I used within LO for json anymore -- it might have been json-glib -- but any additional libraries mean extra work with integrating them into the LO since I was using an external library.)

I agree about JSON, an extra dependency is not a nice solution so I promoted XML as well.

> I don't see any real need to switch from plain text though -- the commands are very simple (as most 3 parameters per command), i.e. easier to parse directly than through another layer. Extending the current protocol  avoids having to do any special work to keep backwards compatibility (e.g. any unrecognised commands will simply be ignored by older clients at the moment). Adding another layer looks like it'll just make the code more complicated without any benefit. It's even been suggested to go the other way and use a binary protocol (although that won't play well with the Firefox OS remote since Javascript doesn't like binary).

The compatibility will be broken anyway even if there will be just extended protocol. I have plans to cut off sending information about all slides on presentations start and it will break the current Android client because it relies exactly on such behavior.

I cannot agree that plain text is the best solution as well. JSON or XML will allow us to use not positional arguments but named ones so instead of parsing, for example, second argument we could use a “coordinates” property and so on. Such high-level interface will allow client implementations to map structures directly to objects. It is scalable as well — it is easy to add a property to output when it has name, the current protocol relies on positions as parameters identifiers so when there will be, for example, ten parameters it will be hard to manage what position has parameter you actually need.

I can be too radical actually and it would be interesting to hear other opinions. That’s why I posted this message to the mailing list :-)

> Also one thing I did look at but didn't get very far with was sending fully formatted presentation notes -- at the moment they are unformatted (except for newlines) -- the necessary logic to output html notes is already in the export filters but would need adapting to output the notes for a single slide.

Hmm, notes look like HTML documents, don’t they have any formatting? :-? I haven’t try it yet.

Regards,
Artur.

_______________________________________________
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 Protocol


On Sat, 2013-06-15 at 19:14 +0300, Artur Dryomov wrote:
> Yep, I already read the code in the process of preparing the wiki
> page. I thought maybe something was wrong or not correct

        The protocol is deliberately simple; the problem space is also
reasonably simple - hopefully that makes a good match :-) a plain text
protocol is also hopefully readable and easy to debug. In addition -
while it is easy to update Android devices to the latest version - so
back-compat with old remote software is not a problem, the same is not
so true for the laptop end of the piece: 100Mb+ downloads plus (on
windows at least) horribly slow MSI processing to get a new version. So
- I'd like to keep the remote side compatible with old LibreOffice's if
possible.

> > We actually did originally use JSON last year, but moved to a text
> > based protocol to avoid having to deal with additional libraries and
>> to reduce overhead,

        Right :-)

> I agree about JSON, an extra dependency is not a nice solution so I
> promoted XML as well.

        :-)

> > I don't see any real need to switch from plain text though -- the
>> commands are very simple (as most 3 parameters per command), i.e.
>> easier to parse directly than through another layer.
...
>> Adding another layer looks like it'll just make the code more
>> complicated without any benefit. It's even been suggested to go the
>> other way and use a binary protocol (although that won't play well
>> with the Firefox OS remote since Javascript doesn't like binary).

        I tend to agree.

> The compatibility will be broken anyway even if there will be just
> extended protocol.

        Why ? It should be possible to accept being pushed slide thumbnails, as
well as being able to request specific slides' data as/when needed -
surely there is not a huge problem with that ?

> I have plans to cut off sending information about all slides on
> presentations start and it will break the current Android client

        Ideally we would assume that the android device can be easily updated,
but the C++ side much less so - and take care to continue working with
the old protocol - but of course, enable better modes of operation /
newer protocols if possible.

> Such high-level interface will allow client implementations to map
> structures directly to objects. It is scalable as well — it is easy to
> add a property to output when it has name, the current protocol relies
> on positions as parameters identifiers so when there will be, for
> example, ten parameters it will be hard to manage what position has
> parameter you actually need.

        Of course true; plain-text is not ideal with a highly complicated very
structured thing; on the other hand - we can easily add a:
"complicated_command" command (or somesuch) that takes an XML blob full
of impenetrable, hard to parse stuff ;-)

> I can be too radical actually and it would be interesting to hear
> other opinions. That’s why I posted this message to the mailing
> list :-)

        I am -very- suspicious of the second-system problem. What we have
works, it has some problems - but it is also rather minimal. I would
really prefer not to replace it with something that is over-engineered -
the best way (usually) to avoid that is to focus on the user-experience
and new features to drive the low-level extensions we want; rather than
the reverse :-)

        That's my 2 cents anyhow,

        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 Protocol

Hello all, 

First, it's great to have a wiki page here, I will also add my ideas during the course of the development. :)

However, as said by Michael and Andrzej, I don't see any immediate need to switch from plain text protocol either. For now I would prefer to stick with plaintext protocol and extend the functionalities rather than switch to another format entirely. Also, the communication between remote and libO instance is relatively small since the most complicated command only have 3 parameters. Therefore the overhead caused by adding another layer will not be ignorable. The only command that might need some extra work is the slide_note command, maybe some simple markup that envelopes the html code will do the work.

I agree with you about the versioning, we can add a parameter during the handshake request so that we can keep the server-end backward compatible. 

That said, I would be willing to discuss with you more into details if you feel that JSON/XML format will improve user experience. Also, both of these two formats have native support on included in the SDK so there wouldn't be a great pain to switch to that. 

All the best! 

Siqi


2013/6/15 Michael Meeks <[hidden email]>

On Sat, 2013-06-15 at 19:14 +0300, Artur Dryomov wrote:
> Yep, I already read the code in the process of preparing the wiki
> page. I thought maybe something was wrong or not correct

        The protocol is deliberately simple; the problem space is also
reasonably simple - hopefully that makes a good match :-) a plain text
protocol is also hopefully readable and easy to debug. In addition -
while it is easy to update Android devices to the latest version - so
back-compat with old remote software is not a problem, the same is not
so true for the laptop end of the piece: 100Mb+ downloads plus (on
windows at least) horribly slow MSI processing to get a new version. So
- I'd like to keep the remote side compatible with old LibreOffice's if
possible.

> > We actually did originally use JSON last year, but moved to a text
> > based protocol to avoid having to deal with additional libraries and
>> to reduce overhead,

        Right :-)

> I agree about JSON, an extra dependency is not a nice solution so I
> promoted XML as well.

        :-)

> > I don't see any real need to switch from plain text though -- the
>> commands are very simple (as most 3 parameters per command), i.e.
>> easier to parse directly than through another layer.
...
>> Adding another layer looks like it'll just make the code more
>> complicated without any benefit. It's even been suggested to go the
>> other way and use a binary protocol (although that won't play well
>> with the Firefox OS remote since Javascript doesn't like binary).

        I tend to agree.

> The compatibility will be broken anyway even if there will be just
> extended protocol.

        Why ? It should be possible to accept being pushed slide thumbnails, as
well as being able to request specific slides' data as/when needed -
surely there is not a huge problem with that ?

> I have plans to cut off sending information about all slides on
> presentations start and it will break the current Android client

        Ideally we would assume that the android device can be easily updated,
but the C++ side much less so - and take care to continue working with
the old protocol - but of course, enable better modes of operation /
newer protocols if possible.

> Such high-level interface will allow client implementations to map
> structures directly to objects. It is scalable as well — it is easy to
> add a property to output when it has name, the current protocol relies
> on positions as parameters identifiers so when there will be, for
> example, ten parameters it will be hard to manage what position has
> parameter you actually need.

        Of course true; plain-text is not ideal with a highly complicated very
structured thing; on the other hand - we can easily add a:
"complicated_command" command (or somesuch) that takes an XML blob full
of impenetrable, hard to parse stuff ;-)

> I can be too radical actually and it would be interesting to hear
> other opinions. That’s why I posted this message to the mailing
> list :-)

        I am -very- suspicious of the second-system problem. What we have
works, it has some problems - but it is also rather minimal. I would
really prefer not to replace it with something that is over-engineered -
the best way (usually) to avoid that is to focus on the user-experience
and new features to drive the low-level extensions we want; rather than
the reverse :-)

        That's my 2 cents anyhow,

        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
Artur Dryomov Artur Dryomov
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote Protocol

In reply to this post by Michael Meeks-2
Hi All again,

If everybody is against the more high-level version of the protocol and you vote for the plain text one — so be it, then.

I read reviews at the Google Play page — only English and Russian ones because we still don’t know who rules the developer account. It seems like all features were mentioned at the wiki page. Other things are application-related.

Feel free to post messages with ideas or edit the wiki page anyway!

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 Protocol

Hello all, 

I've been working on the iOS app and I'm wondering if it's better for users to actually see the first slide before click on the "start presentation" button? 

Here is a screen shot of what I've implemented for now, that is, once paired, users will be brought to this page and on the top, users can have a quick preview (first slide for ex) of what will be displayed on the PC. That way users are sure about what will be displayed. 

Images intégrées 2

For now, the server end will not send previews until either the user hits the start presentation button, or the PC side starts it. 

Besides, we can actually start sending these previews once we are paired can't we? At least for the first several slides, so that users don't need to wait for the previews transmission when they start the presentation. Did I miss something here?

Let me know what you think  ;)

Cheers,
Siqi


2013/6/16 Artur Dryomov <[hidden email]>
Hi All again,

If everybody is against the more high-level version of the protocol and you vote for the plain text one — so be it, then.

I read reviews at the Google Play page — only English and Russian ones because we still don’t know who rules the developer account. It seems like all features were mentioned at the wiki page. Other things are application-related.

Feel free to post messages with ideas or edit the wiki page anyway!

Regards,
Artur.



--
--------

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 Protocol

Hi Siqi,

On Fri, 2013-07-05 at 12:59 +0200, Siqi Liu wrote:
> I've been working on the iOS app and I'm wondering if it's better for
> users to actually see the first slide before click on the "start
> presentation" button?

        Certainly that would be much richer graphically :-)

> Here is a screen shot of what I've implemented for now, that is, once
> paired, users will be brought to this page and on the top, users can
> have a quick preview (first slide for ex) of what will be displayed on
> the PC. That way users are sure about what will be displayed.

        Sounds great to me.

> For now, the server end will not send previews until either the user
> hits the start presentation button, or the PC side starts it.

        IIRC this may be an artifact of the UNO interfaces involved - it was
prolly easier to code this way. Also - if you have multiple
presentations loaded concurrently, there might be some fun ergonomic
issues :-)

> Besides, we can actually start sending these previews once we are
> paired can't we? At least for the first several slides, so that users
> don't need to wait for the previews transmission when they start the
> presentation. Did I miss something here?

        It's a great idea; I'd love to see that. Prolly it intersects nicely
with Artur's work around protocol expansion - I imagine we'd want to
have new methods to query the open presentations, get notified when new
ones are opened, and render the first slide of each (?).

        I guess we would want to either have a special-case method to get all
previews of open slide-decks (and notification of when that changes).
Adding a new integer index (eg.) of "which presentation" to all 'get
preview' methods is likely to cause grief around re-numbering them /
sticking with the same presentation when others are loaded in the
background I imagine (?).

        Anyhow - nice work with the iOS remote ! :-)

        ATB,

                Michael.

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

_______________________________________________
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 Protocol


On 05/07/13 12:38, Michael Meeks wrote:

>
> > For now, the server end will not send previews until either the user
> > hits the start presentation button, or the PC side starts it.
> IIRC this may be an artifact of the UNO interfaces involved - it was
> prolly easier to code this way. Also - if you have multiple
> presentations loaded concurrently, there might be some fun ergonomic
> issues :-)

To create the previews XSlideShowController was used
( http://api.libreoffice.org/docs/common/ref/com/sun/star/presentation/XSlideShowController.html )
which is only available when a slideshow is running.

I've just discovered the existence of XSlidePreviewCache though --
 http://api.libreoffice.org/docs/common/ref/com/sun/star/drawing/XSlidePreviewCache.html --
maybe that would be useful for getting previews -- also when no slideshow is running (It
looks like this is used for showing the thumbnails which are shown when editing presentations
-- that would also be more efficient than generating them from scratch for the remote)?

ATB,

        Andrzej




_______________________________________________
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 Protocol

Hello Andrzej and all, 

That seems to be really promising ^^ I was pretty sure that there must be a way to generate slide previews since we do have those thumbnails. 

Now that I've implemented all functionalities on the client end, I'm looking to work on the server end in order to improve certain protocols and also add some new commands like the one used for pointer (by the way, any hints on how to do some drawing during the presentation? I'm totally new here :-P) etc. 

Also, @Artur any news on the current improvements made on the server-end? Have you merged your work to the master branch or a feature branch? If you like we can discuss on certains aspects over IRC (my id: siqi). ^^

All the best!
Siqi


2013/7/9 Andrzej J. R. Hunt <[hidden email]>

On 05/07/13 12:38, Michael Meeks wrote:

>
> > For now, the server end will not send previews until either the user
> > hits the start presentation button, or the PC side starts it.
>       IIRC this may be an artifact of the UNO interfaces involved - it was
> prolly easier to code this way. Also - if you have multiple
> presentations loaded concurrently, there might be some fun ergonomic
> issues :-)

To create the previews XSlideShowController was used
( http://api.libreoffice.org/docs/common/ref/com/sun/star/presentation/XSlideShowController.html )
which is only available when a slideshow is running.

I've just discovered the existence of XSlidePreviewCache though --
 http://api.libreoffice.org/docs/common/ref/com/sun/star/drawing/XSlidePreviewCache.html --
maybe that would be useful for getting previews -- also when no slideshow is running (It
looks like this is used for showing the thumbnails which are shown when editing presentations
-- that would also be more efficient than generating them from scratch for the remote)?

ATB,

        Andrzej







--
--------

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
Artur Dryomov Artur Dryomov
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Impress Remote Protocol

Hey Siqi,

Your progress is huge, you are working pretty fast ;-)

I haven’t worked on the server-side unfortunately. My plan was to implement the redesign of the client and then to work on the server. The idea was about implementing things with the current version of the protocol and only then move forward. That strategy gave me a better understanding of how the protocol works actually.

The work on the client is going not so fast as I expected — most of the work is done and I hope to finish it soon, but a lot of time gone for debugging and optimizing.

Protocol-related changes are part of my proposal actually. I have fears that if you’ll implement them I can fail the GSoC. Can you spend some more time on polishing, posting screenshots to the ux-advise list, QA, implementing iPad version, planning the Bonjour support? The design for the iOS 7 would be great as well — it is possibly coming this fall ;-) I’ll speed up and try to finish the redesign as fast as possible. Sorry for slowing things down — I just want to finish the GSoC successfully as much as you are ;-)

What do you think?

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 Protocol

Hello Artur, 

No worry about that ^^ I was just thinking of implementing them so that I can see my pointer actually flying on the big  screen :-P. However, do let me know the what protocol you will adopt for this functionality and post it on your wiki page so that I can make the client conform to your design. (x, y in percentage relative to the width and height of the screen? And we take the left upper corner as the origin (0,0)? ) 

Otherwise, here are several functionalities that I'm looking to implement: 
1. The pointer feature support
2. Is it possible to send to client some basic informations like the current presentation filename, author, etc before the users hit "start presentation"? Since (as Michael Meeks pointed out) it's much harder to send previews before the beginning of the presentation, this would be a great alternative solution. 

I will leave the protocol improvements to you then, but do send me a message over IRC or by email should you need someone to work on that with you. I will keep you updated should I need some further server-end features. 

ATB and happy coding! 

Cheers, 
Siqi 


2013/7/13 Artur Dryomov <[hidden email]>
Hey Siqi,

Your progress is huge, you are working pretty fast ;-)

I haven’t worked on the server-side unfortunately. My plan was to implement the redesign of the client and then to work on the server. The idea was about implementing things with the current version of the protocol and only then move forward. That strategy gave me a better understanding of how the protocol works actually.

The work on the client is going not so fast as I expected — most of the work is done and I hope to finish it soon, but a lot of time gone for debugging and optimizing.

Protocol-related changes are part of my proposal actually. I have fears that if you’ll implement them I can fail the GSoC. Can you spend some more time on polishing, posting screenshots to the ux-advise list, QA, implementing iPad version, planning the Bonjour support? The design for the iOS 7 would be great as well — it is possibly coming this fall ;-) I’ll speed up and try to finish the redesign as fast as possible. Sorry for slowing things down — I just want to finish the GSoC successfully as much as you are ;-)

What do you think?

Regards,
Artur.



--
--------

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 Protocol

On Sat, 2013-07-13 at 17:20 +0200, Siqi Liu wrote:


> 1. The pointer feature support
> 2. Is it possible to send to client some basic informations like the
> current presentation filename, author, etc before the users hit "start
> presentation"? Since (as Michael Meeks pointed out) it's much harder
> to send previews before the beginning of the presentation, this would
> be a great alternative solution.
That should be possible: probably best to look at the start of
executeCommand in Receiver.cxx to see how to access the presentation
document, where we first get the active Frame (currently active window),
and then xFrame->getController()->getModel() to get the model of the
Presentation Document (you can find a list of some of the interfaces
that are implemented within sd/source/ui/inc/unomodel.hxx ). XModel's
getUrl method supplies the full path to the file that is open (although
there might be a better method elsewhere with just the document name).
You'll probably need to dig around a bit to find exactly what you need,
but it shouldn't be particularly difficult to do.

It should also be possible to implement the new pointer feature
independently of other protocol improvements: I don't know how you're
planning to implement it, but the only thing that would affect the rest
of the server would probably be adding the necessary code to
Receiver.cxx to parse pointer positions and pass them onto wherever you
actually deal with drawing the pointer -- it's probably worth adding a
versioning string to the protocol handshake (so that the client can
detect whether the server supports this and not offer a pointer unless
available), but it isn't entirely necessary given that the server should
just ignore any commands it doesn't understand -- although things may be
more complicated if the server has to get involved in calibration.

ATB,

        Andrzej





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