15:04 <popey> #startmeeting Docviewer / Libreoffice view meeting
15:04 <meetingology> Meeting started Fri Jul  3 15:04:16 2015 UTC.  The chair is popey. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:04 <meetingology> 
15:04 <meetingology> Available commands: action commands idea info link nick
15:04 <popey> https://blueprints.launchpad.net/ubuntu-phone-commons/+spec/libreoffice-docviewer-integration
15:04 <popey> ^ Blueprint we created last week.
15:04 <mrqtros> sverzegnassi it's great - summer, weekend, hot weather
15:05 <popey> http://pad.ubuntu.com/loviewer
15:05 <popey> ^ scratch notepad
15:05 <sverzegnassi> mrqtros, haha... not when you're trying to study at home :P
15:05 <dpm> yeah, not the best weather to study :-)
15:06 <popey> So, any progress this week?
15:06 <sverzegnassi> talking about the lo-viewer, I've started to have a play with the tile rendering
15:07 <sverzegnassi> still a WIP
15:07 <dpm> sverzegnassi, are you finding any blockers or perhaps you have any questions for Sweet5hark?
15:07 <mrqtros> Ok, my results - reviewed code (very bad approaches used, can't live in production, only in demo) and studied a little about libreofficekit (little bit frustrated that it's new library and tiled rendering has only experimental support)
15:08 <dpm> mrqtros, can you be a bit more specific on which code you reviewed and which approaches you are not finding good?
15:09 <sverzegnassi> dpm, ATM I'm bothered by making the rendering asynchronous, but I just started half an hour ago
15:09 <sverzegnassi> I didn't found anything the page breaks though
15:09 <mrqtros> dpm yes, of course - we shouldn't render whole document in one (!) bitmap, it can be huge even on docs with few pages
15:09 <dpm> sverzegnassi, no pressure, you've still got 20 minutes to finish it until the end of the meeting? :P
15:09 <sverzegnassi> dpm, haha :-)
15:10 <mrqtros> dpm nice joke :D
15:10 <dpm> :-)
15:10 <dpm> mrqtros, yeah, I think we all agree on that
15:11 <dpm> it was just the initial proof of concept to demonstrate that integrating LibreOffice Toolkit with docviewer could work at all
15:11 <dpm> Sweet5hark, did you have the chance to look into your work items on the blueprint?
15:12 <mrqtros> dpm ok ok, then we should change our approach) Someone is already working on that as I can see
15:12 <Sweet5hark> dpm: hang on
15:12 <Sweet5hark> - page splits: there doesnt seem to be an obvious way to have that in current API
15:12 <Sweet5hark> -- I could hack something up inside LibreOffice, wonder however how to deploy that etc.
15:12 <Sweet5hark> -- As the GNOME docviewer has a page control already and there is a good GSoC on that, currently would see if there is a solution there. If not, would need to coordinate with them
15:12 <Sweet5hark> - discussed consolidation "phabletplatform" in upstream build system, upstream is not blocking -- actually encouraging: http://nabble.documentfoundation.org/minutes-of-ESC-call-td4153457.html
15:12 <Sweet5hark> - would like to blog a bit about this: does anyone else want to?
15:14 <Sweet5hark> - Ubuntu Touch will likely get namedropped in LibreOffice 5.0 announce -- details still pending.
15:14 <popey> I would welcome blog posts about this.
15:14 <popey> Especially if they include a call for help :)
15:15 <dpm> Sweet5hark, that's awesome. Might be worth dropping "Touch", though. Perhaps Ubuntu for mobile devices, or something like that?
15:15 <Sweet5hark> dpm: wording is still in flux. I will keep it in mind and get back to you once it stabilizes.
15:15 <dpm> sounds great
15:17 <Sweet5hark> sverzegnassi: if you dont want to blog about this, I'd love to use your screenshot. But if you want to blog about this, I dont want to steal your thunder ;)
15:17 <sverzegnassi> Sweet5hark, np. I still have to complete the setup of my blog :-P
15:18 <dpm> awesome
15:18 <Sweet5hark> sverzegnassi: do you have that link again? Me forgot to save the pic and lost the window :P
15:20 <sverzegnassi> https://imgur.com/UEPGpZV,Udyyq3W#0
15:20 <Sweet5hark> to extend a bit on the above the "consolidate phalet builds" in upstream build system is aiming towards reusing as much of the Android config stuff -- esp. the stuff to minimize the size -- for us too.
15:20 <sverzegnassi> Sweet5hark: are those? ^^
15:21 <dpm> Sweet5hark, so that'd mean we could put the LO build insice the click (or snap moving forward), right?
15:22 <Sweet5hark> sverzegnassi: thx, great. any screenshot will do for the start mostly: a post with a pic works a lot better always.
15:23 <sverzegnassi> BTW, before I forget again about it, may be a good idea to use a ODF to PDF converter, just temporarily? I've seen that GNOME Documents is currently using this approach in the stable release
15:23 <Sweet5hark> dpm: well, at minimum it would mean we would need a separate build. from a technical perspective, moving libreoffice around isnt an issue, its completely relocatable.
15:25 <dpm> yeah, popey did some testing in that regard, IIRC
15:26 <dpm> Sweet5hark, but what I mean is that we could use the output of the separate build to ship it alongside docviewer without having to rely on a full LO installation, right?
15:26 <Sweet5hark> I have no idea how that "shipping the source as per license"-stuff would work with click/snappy packages. but I assume there has to generic solution for all stuff ...
15:27 <dpm> "shippig the source as per license"?
15:28 <dpm> sverzegnassi, you mean converting as an external file and then loading the .pdf via content hub? Which converter could be used for that?
15:29 <popey> dpm: lo would do that bit.
15:29 <popey> surely?
15:29 <sverzegnassi> dpm, i mean we could convert the file internally in docviewer in a temp folder, and then load it through the PDF plugin
15:30 <sverzegnassi> lok provides a function to save a file in a different format, or we could start a "unoconv" process (which is the approach used by GNOME documents)
15:31 <Sweet5hark> sverzegnassi: yes, and unoconv is just converted to use lok in the future ;)
15:32 <dpm> Sweet5hark, sverzegnassi, so do you guys think this is the better approach rather than lok's bitmap/buffer conversion?
15:32 <sverzegnassi> Sweet5hark, so it looks safe to use lok directly... good!
15:33 <sverzegnassi> dpm, well, if we want to have page breaks for text documents, I'd say that ATM it's better to convert to PDF
15:33 <sverzegnassi> which provides also a ToC
15:33 <dpm> ack
15:33 <dpm> so how does docviewer access the PDF converter?
15:34 <sverzegnassi> http://bazaar.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/trunk/view/head:/src/app/qml/common/loadComponent.js
15:34 <sverzegnassi> All the supported types are processed with this JS code, by the mimetype of the given document
15:35 <sverzegnassi> we could check for the specific mimetype of the word/ODT document, and then create a LibreOffice.Document object that converts the file to PDF
15:35 <dpm> sverzegnassi, I think you already answered my question, I just re-read the log. So essentially, we'd still be using lok, but we'd be saving to an external file instead of loading the bitmap in a buffer
15:35 <sverzegnassi> and push the related QML view
15:35 <sverzegnassi> dpm, yes
15:36 <dpm> Sweet5hark, what are your thoughts? Pros/cons?
15:36 <Sweet5hark> dpm: converting to pdf would be a quick initial solution, I guess if that works out with temp storage (and also solve the "goto page X" stuff). In the long run, using tiledrendering is the better thing as it allows all the other sexy stuff (much of which is admittedly WiP right now). Also I assume e.g. spreadsheets as PDF are underwhelming.
15:37 <dpm> I guess docviewer can just store the PDF in its cache
15:37 <popey> makes no sense to convert twice
15:37 <popey> so yeah, I'd rather we cache it somewhere
15:37 <sverzegnassi> We could cache the PDF on disk, so that it's immidiately available the second time a user ask for that file
15:38 <dpm> I think the downside would be again for big documents, the first conversion might take a long time
15:38 <Sweet5hark> (the stuff that tiledrendering would bring later would be navigation also in spreadsheets, seeing formulas in spreadsheets, better copy paste and ultimately editing capabilities)
15:39 <sverzegnassi> mmh... we'd need to check. if we have a huge file, that would anyway require much time to be rendered, since it's probably full of images
15:40 <popey> We'd need to test this to find out the limits
15:40 <dpm> sverzegnassi, yeah, but I meant vs tile rendering, in which case we'd do it e.g. a page at a time
15:40 <dpm> so from what you guys are saying, it seems we should approach this in two phases?
15:40 <Sweet5hark> dpm: hmm, indeed. if the file is bigger you parse it once completely, render it to pdf completely, parse it again ...
15:40 <dpm> 1) PDF converter
15:40 <sverzegnassi> dpm, got the tiled rendering working. now i should manage better what happens off-screen https://imgur.com/1PTVBqt
15:40 <dpm> 2) Tile renderer on buffer
15:41 <dpm> sverzegnassi, so it wasn't a joke having the tile rendering ready by the end of the meeting? :-D
15:41 * dpm hugs sverzegnassi
15:42 <sverzegnassi> dpm, haha.. no! it's not working perfectly, but at least it's rendering tiles asynchronously :P
15:42 <dpm> :-)
15:42 <popey> wow
15:43 <Sweet5hark> dpm: sounds sensible to me: the pdf stuff is quick and very low risk, the tiled rendering has more potential, but also is a moving target (that comes with the territory: we are not following Android years later here, but are somewhat trailblazing just along with them -- which is awesome)
15:43 <dpm> sounds good
15:44 <Sweet5hark> but kudos to sverzegnassi, if tiledrendering is there by the end of this meeting, we dont need the pdf stuff ;)
15:44 <popey> haha
15:45 <dpm> sverzegnassi, or do you think we could split the work between PDF conversion and tile rendering? I.e. perhaps mrqtros wants to have a go at PDF conversion and you continue with the tile rendering branch?
15:47 <sverzegnassi> dpm, I think that the PDF conversion comes mostly at no cost, since it's not difficult to implement. I'd anyway prefer mrqtros to help with the tile rendering, since he has a stronger Qt knowledge than me :)
15:47 <sverzegnassi> (qt and c++)
15:47 <dpm> cool
15:48 <dpm> sounds sensible to me
15:49 <dpm> sverzegnassi, after your experience with the API, do you have a good idea of where you might need help?
15:51 <sverzegnassi> dpm: well, tiled rendering is something totally new for me. if it's okay to mrqtros, I'd like him to give an help with writing/debugging/improving performance of the tiled rendering code
15:52 <sverzegnassi> don't know anyway how much time he's got to dedicate at this task, so i'm just proposing
15:53 <dpm> sverzegnassi, cool. I think that's helpful to have a concrete task. He said he'd be back in ~30, so perhaps we can have a chat with him then if we're all still around
15:54 <sverzegnassi> ok
15:57 <dpm> ok, we've got a few minutes left, shall we recap on work items for next week?
15:59 <dpm> Do these sound sensible?
15:59 <dpm> [verzegnassi-stefano] Continue prototyping tile rendering approach: TODO
15:59 <dpm> [mrqtros] Provide support to Stefano on writing/debugging/imroving performance of the tiled rendering code: TODO
16:00 <dpm> Sweet5hark, anything we should add for you for next week? ^
16:00 <popey> blog post?
16:00 <sverzegnassi> we said that page breaks detection is currently blocked, IIRC?
16:00 * dpm checks scrollback
16:00 <Sweet5hark> blog post is easy -- so sure.
16:01 <Sweet5hark> page breaks: yeah.
16:02 <sverzegnassi> so, basically, we have the tiled rendering and the PDF converter (which should be just some C++ lines, and a few, mostly about storage management, in QML)
16:02 <dpm> sverzegnassi, do you think the PDF converter is something we should add in the work items for next week?
16:02 <dpm> just want to make sure it's a sizable workload, and not too much
16:03 <sverzegnassi> the implementation in the LibreOffice QML plugin would not require much work, IMHO it's worth to add
16:03 <dpm> Sweet5hark, so I've added [bjoern-michaelsen] Publish blog post on the mobile LibreOffice viewer work: TODO - anything else you'd want me to add for you next week?
16:04 <sverzegnassi> eventually we can split it up into two parts: 1) Add conversion support in LOK plugin; 2) Implement conversion in DocViewer QML code
16:05 <Sweet5hark> dpm: not right now -- TBH I still also have enough to do with finalizing plain old libreoffice packages and stuff.
16:06 <dpm> thanks Sweet5hark
16:06 <dpm> sverzegnassi, do the work items sound sensible to you?
16:06 <dpm> on the etherpad, I mean
16:09 <sverzegnassi> dpm, that's ok to me. just the second part of PDF conversion (implement in QML code) could be postponed to the next week (#29)
16:09 <dpm> sverzegnassi, done, thanks!
16:10 <dpm> all right then, I think we can then close another very productive meeting :-)
16:10 <sverzegnassi> thank you all!
16:10 <dpm> good work everyone, seems the viewer is becoming something real :)
16:11 <Sweet5hark> thanks guys!
16:14 <popey> \o/
16:14 <popey> #endmeeting