15:01 <popey> #startmeeting [Doc|libreoffice]viewer meeting
15:01 <meetingology> Meeting started Fri Jun 26 15:01:13 2015 UTC.  The chair is popey. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:01 <meetingology> 
15:01 <meetingology> Available commands: action commands idea info link nick
15:01 <sverzegnassi> o/
15:01 <popey> hey hey
15:01 <popey> How did you get on playing with the code Sweet5hark1 provided sverzegnassi ?
15:02 <dpm> hey sverzegnassi o/
15:02 <dpm> seems Stefano had some feedback and questions on the last comment on https://code.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer/+merge/262686
15:02 <sverzegnassi> it was fine, I got a first prototype of qml plugin (not so good at the moment)
15:03 <sverzegnassi> here's the related branch: https://code.launchpad.net/~verzegnassi-stefano/ubuntu-docviewer-app/lo-plugin-prototype
15:03 <sverzegnassi> i have a few opened questions about the lo apis
15:03 <popey> ooh
15:03 * dpm tests the code while we're talking
15:04 <Sweet5hark1> shoot ;)
15:04 <sverzegnassi> the first one is about the way the document is rendered.
15:04 <sverzegnassi> i've seen that the render is about a whole document, while we may want to split it in pages (e.g. for lo writer documents)
15:06 <Sweet5hark1> sverzegnassi: so essentially you want to know "how do I learn where pagebreaks are from the API?"
15:06 <sverzegnassi> yes
15:07 <Sweet5hark1> sverzegnassi: havent looked at that yet, but IIRC the gnome docviewer renders pagewise, lemme have a quick look ..
15:07 <sverzegnassi> i didn't found any documentation about libreofficekit, so any reference would be great. thanks!
15:08 <dpm> Sweet5hark1, while you're doing that, other than the pagebreaks, is there a way to load a document in chunks? I could imagine that a really big doc might take a while to load while it's being converted
15:09 <mrqtros> hi guys
15:09 <mrqtros> I am here:)
15:09 <dpm> hey mrqtros o/
15:09 <popey> hi mrqtros
15:09 <Sweet5hark1> sverzegnassi: https://github.com/LibreOffice/core/tree/master/libreofficekit has some readme, and https://github.com/LibreOffice/core/blob/master/libreofficekit/source/gtk/lokdocview.cxx has a gnome docviewer that uses a lot more features (including pages IIRC)
15:10 <popey> for those who don't recognise, mrqtros is Roman, who worked on the Shorts a;p
15:10 * dpm adds documentation links to the MP with the rest of the info
15:10 <mrqtros> popey thanks!
15:10 <sverzegnassi> hey mrqtros!
15:11 <sverzegnassi> Sweet5hark1: ok, will have a look later
15:11 <Sweet5hark1> dpm: thats not really a question for the API, but a general libreoffice question. IIRC Lotus Symphony (forked from OOo) did try that (incremental document loading). But it is fundamentally a hard problem ...
15:12 <mrqtros> I have both C++ and QML knowledges, so I can participate both in plugin and ui development
15:12 <dpm> mrqtros, excellent
15:12 <popey> Sweet5hark1: does the android version of libreoffice render the entire document then? (and is that why it's painfully slow)?
15:12 <popey> (for me it was, anyway)
15:12 <sverzegnassi> mrqtros: great, an help is very appreciated! :)
15:14 <Sweet5hark1> dpm: in essence, when loading a doc you are parsing an XML stream inside an zip. The Symphony hacks gave some speedup, but in the end that is too flaky as you e.g. have stuff referencing around in the document etc. (say: table of contents, embedded images etc.)
15:14 <mrqtros> sverzegnassi I am planning to do a lot in that project)
15:15 <Sweet5hark1> popey: hangon, are we talking about loading/parsing or about rendering the document -- those are two different things.
15:15 <Sweet5hark1> ?
15:15 <popey> Well, both really.
15:15 <dpm> Sweet5hark1, I was talking about lok rendering the doc
15:16 <Sweet5hark1> so unless you rework all of libreoffice, you cant do much about the loading/parsing part. the rendering part is different:
15:18 <Sweet5hark1> once the doc is loaded, you can render any part of it with the API. The other clients of libreofficekit AFAIK did no offscreen rendering/double buffering yet (IIRC the gnome viewer is getting this implemented right now). of course, offscreen rendering makes things a lot smoother.
15:21 <popey> This sounds like way more work than we initial envisaged :S
15:22 <Sweet5hark1> with the same code you there are multiple things that take time: 1/ start and dynlink libreoffice 2/ read libreoffice's xml based general configuration files 3/ unzipping the ODF/OOXML to a stream 4/ parsing the stream 5/ rendering a part of the document. I assume 2/ and 4/ to take the majority of that for long documents.
15:23 <Sweet5hark1> popey: dont you do offscreen rendering for e.g. pdfs too? I assume you would. There is not much difference there.
15:24 <popey> Ok.
15:25 <Sweet5hark1> (offscreen rendering meaning e.g. rendering page 2 into a buffer while the user see page 1 etc.)
15:25 <popey> dpm: did you get it working?
15:25 <dpm> sverzegnassi, Sweet5hark1, mrqtros, popey: http://i.imgur.com/mVntSjN.png :-)
15:25 <sverzegnassi> in case you want some screenshot: https://imgur.com/UEPGpZV,Udyyq3W
15:25 <dpm> good work sverzegnassi!
15:25 <popey> oh!
15:26 <popey> so that's using your local install of libreoffice, right?
15:26 <dpm> yeah
15:26 <Sweet5hark1> as for the steps above: of course, e.g. some of the steps above would be faster if you are not using a fullblown TDF build coming with everything and the kitchen sink.
15:26 <dpm> lo 5 from the PPA, on my unity7 destkop, and I guess Stefano did the same to develop
15:26 <Sweet5hark1> dpm, sverzegnassi: \o/ nice!
15:27 <sverzegnassi> popey: since you have a parallel installation, you can edit line 35 before building: http://bazaar.launchpad.net/~verzegnassi-stefano/ubuntu-docviewer-app/lo-plugin-prototype/view/head:/src/plugin/libreofficetoolkit-qml-plugin/lodocument.cpp
15:27 <popey> ahah
15:28 <popey> Ship it!
15:28 <popey> Ok, so next steps, in the short term. Where do we go from here?
15:29 <dpm> sverzegnassi, I'm not sure you've had time to look at it yet in this little time, but do you think the links Sweet5hark1 gave you will answer your questions?
15:29 <popey> We need to figure out if we can bundle libreoffice into a click somehow, to prove that will work.
15:29 <dpm> sverzegnassi, and on your current prototype, are there any known caveats (other than not yet detecting pagebreaks)?
15:29 <popey> Sweet5hark1: I ran TDF version mainly to see if I could render using LO from a random (relocatable) directory, which would be a requirement for being a click.
15:30 <Sweet5hark1> ah, btw: TDF build vs. ppa packages: while the ppa packages come with the kitchen sink too right now, one thing the ppa packages have over the TDF ones: you can actually install libreoffice-dbg, have symbols and might see what is going on there without needing to do a build on your own installation.
15:30 <sverzegnassi> dpm, I had a look at the code, I think I'll have no  problem in finding how to split the document in pages, so i say yes.
15:31 <mrqtros> Guys, do we have blueprints or something like that? Can we parallel our work?
15:31 <dpm> awesome, so I guess that will be the next feature in the list
15:31 <dpm> mrqtros, good point
15:31 <mrqtros> Some time ago we tried to use Trello for that
15:31 <sverzegnassi> yep, as first thing I'd like to have a proper LO-writer view
15:31 <Sweet5hark1> popey: yeah, yeah: libreoffice is totally relocatable. I throw around binaries to the oddest locations (in fact we even have binaries in a git repository for regression hunting)
15:32 <dpm> sverzegnassi, popey, mrqtros, so perhaps we should start with documenting the tasks that we already know
15:32 <dpm> as meeting notes
15:32 <mrqtros> dpm yep
15:32 <sverzegnassi> +1
15:32 <popey> just making a blueprint.
15:33 <dpm> http://pad.ubuntu.com/loviewer for on-the-fly editing the meeting notes, which we can move to the BP
15:33 <mrqtros> I missed a lot because currently I am on my regular work) And I am teamlead, my whole team is asking me all the time, so I can't focus)
15:34 <popey> thanks dpm
15:35 <sverzegnassi> for the click packaging, a big issue may be the fat packaging. I think that we don't want to download around 100MB of libraries for a different arch.
15:35 <sverzegnassi> it would be nice to provide the lo support in a different click package, as a Document Viewer plugin
15:36 <dpm> yeah, I think this is something we'll have to look at very carefully
15:36 <sverzegnassi> so, basically, having a fat package for the docviewer itself (which should be around 5MB), and then 3 different click pkgs, one for any arch
15:37 <popey> Or maybe a docviewer app and a docviewer++ app which has the extra office bits
15:37 <popey> (The names can be worked out later)
15:37 <popey> But it's common on other platforms to have cut down apps and more featureful "HD" versions.
15:37 <mrqtros> BTW, are we want to create app which will only allow to read documents? No editing?
15:38 <dpm> sverzegnassi, Sweet5hark1, does the list of tasks in http://pad.ubuntu.com/loviewer look sensible to you for docviewer? I'm sure I've forgotten something
15:38 <popey> I also agree that we shouldn't make a giant fat package containing all 3 arch builds of LO.
15:38 <dpm> mrqtros, that's the initial goal, yeah, a viewer
15:38 <popey> mrqtros: only read, not edit for now.
15:39 * Sweet5hark1 is still fiddling with the u1 login
15:40 <sverzegnassi> it seems ok to me. for now i'd prefer to focus on a single document type (i have the feeling that text document and spreadsheet may require a "different" logic)
15:41 <dpm> sverzegnassi, makes sense, perhaps Sweet5hark1 has some insight on that too
15:41 <popey> I don't have any statistics for the types of documents people read on mobile devices.
15:42 <popey> But I'd expect more people parse documents and presentations than spreadsheets.
15:42 <popey> But that's a guess, I have no data :)
15:42 <Sweet5hark1> dpm, sverzegnassi: yes, focusing on e.g. writer docs for the start makes sense.
15:42 <popey> Only because a doc is much like a pdf and can just be scrolled through, and a presentation could be shown full screen.
15:42 <popey> +1
15:42 <sverzegnassi> i suppose that text document and presentations work pretty similar (both use pages)
15:42 <popey> yes
15:42 <popey> But I agree, focus on docs first.
15:43 <Sweet5hark1> writer is really WYSIWYG -- e.g. Calc you have a cell having both a formula and a value yadda yadda
15:44 <popey> Bear in mind the end goal of this is for it to run on a converged device, which will have a keyboard and mouse (typically, sometimes)
15:44 <popey> So it's not just for the mobile screen.
15:45 <popey> Sweet5hark1: how granular is the libreoffice build script? Is it possible to build "only doc support" for example?
15:45 <popey> and build-out base, presentation and spreadsheets?
15:45 <dpm> sverzegnassi, so from the list of tasks, which one were you thinking of picking next, so that we can spread the workload with mrqtros?
15:45 <dpm> adding page breaks?
15:46 <dpm> well, *detecting
15:46 <sverzegnassi> dpm, yes, page breaks
15:48 <Sweet5hark1> so, I looked a bit at the gnome docviewer code (as linked above) -- I didnt find pagebreaks yet, but it uses tiledrendering. that is: it splits the doc in tiles and renders only the visible ones, when you scroll it renders more. Thus if you e.g. open a 500 page doc, it would render the full width an as much height as visible until you start scrolling.
15:49 <dpm> Sweet5hark1, so independent from the rendering method, is there no way to jump to a particular page?
15:49 <Sweet5hark1> so looking at that -- and with the example, I would not go for the page break (will investigate that though), but simply go with "render document full width and as much height as is on screen etc."
15:50 <sverzegnassi> ok, that would require to rewrite the plugin, since it reuses the structure of the poppler plugin (get a page and render it)
15:51 <dpm> sverzegnassi, you're the person most familiar with the code. With which task do you think mrqtros could help?
15:52 <Sweet5hark1> dpm: can investigate that. FWIW, the API supports a lot more than we have covered right now. You can do selections (to go to full editing) and send UNO commands to the document. With that, ~anything should be possible, but I have to look into how exactly that is exposed.
15:53 <dpm> Sweet5hark1, do the 2 work items I've put for you on the etherpad look sensible in this regard?
15:53 <mrqtros> sverzegnassi I'm waiting for your command :)
15:53 <popey> :)
15:53 <sverzegnassi> dpm, having a look at the list on the pad, giving that the page break detecting may be not possible, i would say "error detection"
15:54 <sverzegnassi> the question is "do we want to go for the tile rendering?"
15:54 <mrqtros> We must think about it together
15:55 <mrqtros> But firstly I want to look at code, explore API and so on)
15:55 <Sweet5hark1> dpm: well as-is the second is could be an openended neverending story esp. since the API grows functionality as we speak ;) -- but yeah, look fine in general.
15:55 <dpm> yeah, I think that's a fair question. If full loading, despite the slowness for big docs, is good enough, then we might just want to implement that and no tile rendering
15:56 <popey> We need to try it and see really, on each device.
15:56 <sverzegnassi> mrqtros, it's okay to me... it's the first time that i play with lok too :)
15:58 <mrqtros> sverzegnassi Can you please write little introduction for me? Something like little guide  with build instructions and tips ( and send it to mrqtros@gmail.com)
15:58 <dpm> mrqtros, there is a README file on the docviewer code. The build should be the same as the rest of core apps,
15:59 <dpm> but we might want to put some extra instructions on how to install LO 5.0 from the PPA
15:59 <sverzegnassi> mrqtros, sure! did you already had a look at docviewer code? is there something in particular that i should focus on?
15:59 <Sweet5hark1> sverzegnassi: tile rendering vs. page-wise rendering you mean? FWIW, I think tile rendering is the better choice in the long run for two reasons: a/ everyone else (gnome viewer, android app, libreoffice online) will use it b/ when you have a calc document later, "pages" are not a well-fitting concept. spreadsheets are not paged in most peoples minds.
16:00 <sverzegnassi> Sweet5hark1: yes, that was my doubt. using a different logic for text-documents and presentation may make things a bit faster to be written, but we end having the double of the code to maintain...
16:00 <sverzegnassi> you suggest to go with the tile rendering, then?
16:00 <dpm> Sweet5hark1, is there LOK API for doing tile rendering?
16:01 <mrqtros> sverzegnassi yes I am... Some time ago I looked at DocViewer's code to find out details of "Night mode" implementation :)
16:01 <Sweet5hark1> dpm: we are using the API for tiled rendering already ...
16:01 <dpm> aha, so it's just that we're putting it in one big tile, right?
16:01 <mrqtros> sverzegnassi so I am worrying only about building and running
16:02 <sverzegnassi> dpm: yes, we are :P
16:02 <dpm> :-)
16:02 <sverzegnassi> mrqtros, the informations in the README file are enough then.
16:03 <dpm> mrqtros, and then just open the top CMakeLists.txt with the SDK and press Run
16:03 <Sweet5hark1> dpm: the api is "render me a part of the document (document coordinates) in this bitmap (bitmap size)". the sample code just was written by a lazy bum that always used (document coordinates = full document dimensions )
16:03 <dpm> :-)
16:03 <mrqtros> sverzegnassi so which branch I should use? It is not merged in trunk, am I right?
16:04 <sverzegnassi> the only thing I need to say if you use QtCreator to build the app, is to select the "docviewer" project instead of "com.ubuntu.docviewer" in the selector above the "run" button, on the left sidebar
16:04 <mrqtros> Wow, bitmap can waste a lot of memory
16:04 <dpm> ah, good point
16:04 <sverzegnassi> mrqtros, no, it's not in trunk. the branch is lp:~verzegnassi-stefano/ubuntu-docviewer-app/lo-plugin-prototype
16:05 <sverzegnassi> dpm, is it worth to merge my branch in lp:~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer?
16:05 <dpm> sverzegnassi, can it be merged or did you start the branch from scratch?
16:06 <dpm> sverzegnassi, if it's mergeable, I'd say yes, let's do it
16:06 <sverzegnassi> i've based it on the branch you started with the sample code
16:08 <dpm> sverzegnassi, done, pushed it to the team's branch
16:08 <popey> back in a bit...
16:09 <sverzegnassi> dpm, ok, thanks!
16:09 <dpm> ok, I need to leave, but feel free to continue the discussion. In summary, do the actions in http://pad.ubuntu.com/loviewer look good, and shall we talk during next week?
16:11 <mrqtros> I think that we should talk earlier, in monday, for example
16:11 <sverzegnassi> it seems to miss the tile rendering task
16:11 <Sweet5hark1> dpm: looks good for me, talking next week same time?
16:11 <mrqtros> I will be in business after code review
16:12 <dpm> sverzegnassi, mrqtros, is there a way you can perhaps look together at tile rendering? We can continue the talk next week on #ubuntu-app-devel
16:12 <dpm> sverzegnassi, for the moment I've put a task for yourself for tile rendering
16:13 <sverzegnassi> dpm, mrqtros, it would be okay to me
16:13 <dpm> Sweet5hark1, yeah, that will work in any case, thanks!
16:13 <Sweet5hark1> dpm: great, thx!
16:14 <sverzegnassi> about the next meeting, do we want to have it as "lo integration only" meeting?
16:14 <mrqtros> sverzegnassi dpm yes, for me too
16:15 <dpm> sverzegnassi, how do you mean?
16:15 <Sweet5hark1> mrqtros, sverzegnassi: no guarantees that I can respond quickly, but feel free to ping me if there are questions. Im lurking on IRC pretty much 24/7.
16:15 <mrqtros> Feel free to ping my Telegram +79875060361 and email mrqtros@gmail.com
16:15 <dpm> mrqtros, I've added some additional info on the build prerequisites on the description of https://code.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer/+merge/262686
16:15 <dpm> thanks mrqtros!
16:15 <sverzegnassi> Sweet5hark1, ok, thanks!
16:15 * dpm goes afk for a bit
16:16 <sverzegnassi> mrqtros, my nickname on telegram is "@sverzegnassi"
16:16 <mrqtros> Ok, I am hurry for now, nice start guys, looking forward!
16:16 <sverzegnassi> thank you all, cheers!
16:16 <mrqtros> sverzegnassi what is your real name? :) My name is Roman Shchekin
16:16 <sverzegnassi> Stefano Verzegnassi
16:17 <mrqtros> Ok, goodbye! :)
16:19 <sverzegnassi> dpm, i wanted to say that we already have a docviewer meeting on thursday, does we want to have a separate meeting for libreoffice?
16:39 * popey returns
16:40 <popey> sverzegnassi: The only reason for the meeting today at this time was because Sweet5hark1 couldn't make the thursday one.
16:42 <Sweet5hark1> yeah, I have a weekly meeting on thursdays. its a phone conf, so I could multichannel. but that might bring some latency :)
16:43 <popey> so shall we go for the same time again next week?
16:45 <Sweet5hark1> popey: works for me
16:46 <popey> \o/
16:46 <popey> ok, lets wrap up and continue the discussion elsewhere. Thanks everyone
16:46 <popey> #endmeeting