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 > 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: m...@siqi.fr -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 > > 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: m...@siqi.fr -- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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. [image: 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 > 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: m...@siqi.fr -- <>___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [GSoC] Impress Remote Protocol
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 > > 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. > > -- > michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot > > -- Cordialement, Siqi LIU Étudiant Ingérieur, Université de Technologie de Compiègne Vice-Président de l'associat
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. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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. > > https://wiki.documentfoundation.org/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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[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. https://wiki.documentfoundation.org/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 LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
