15:02 #startmeeting Docviewer meeting 15:02 Meeting started Fri Aug 21 15:02:27 2015 UTC. The chair is popey. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 15:02 15:02 Available commands: action commands idea info link nick 15:02 how is everyone? You feeling better sverzegnassi ? 15:03 hi popey! a bit tired, but i have no fever today \o/ 15:04 Yay! 15:04 So from my side this week I've been fighting Libreoffice on armhf 15:04 Turns out LO won't build in a chroot or qemu VM 15:04 So I has to request a special PPA which builds on native armhf hardware, not in a vm. 15:05 I then find out many of the unit tests don't work on armhf either 15:05 I've built it about 10 times now, and it takes ~9 hours each time. 15:05 I _think_ this one will succeed though :) 15:06 https://launchpad.net/~canonical-community/+archive/ubuntu/ppa/+builds?build_state=building 15:06 The idea is to grab that build, put it together with your libreoffice work and build a simple click 15:07 so, for the moment the idea is to ship a single big package, right? 15:07 for testing, yeah 15:07 but we can also break it up 15:08 and have a libreoffice deb preinstalled and a simple click for the viewer 15:08 or something else. 15:08 I don't yet have strong opinions on the way to do that. 15:09 Just updated my items on the blueprint https://blueprints.launchpad.net/ubuntu-docviewer-app/+spec/libreoffice-docviewer-integration 15:09 How is the zooming work going? 15:10 I've started it, but then I stopped because of my misadventure 15:11 okay :) 15:11 JMulholland: you around? 15:11 the zoom is nicely centered in the "desktop mode" (i.e. from the zoom selector in the bottom panel) 15:12 okay. 15:12 still working on the pinch-to-zoom gesture, but seems ok 15:12 My biggest worry right now is rendering performance on armhf. 15:12 because it's a bit of an unknown 15:12 ok 15:12 well, i had a play with the libreoffice viewer on android 15:13 it is a bit slow to load libreoffice on start-up 15:13 (around 10 seconds on my Nexus 5) 15:14 yeah, same here on nexus 7 2012 15:14 (which I appreciate is an old device) 15:15 rendering of simple text documents doesn't seem too slow though 15:16 Well, we'll see. Hopefully the forthcoming pocket desktop device will be powerful :) 15:16 :) 15:16 On a separate note, regarding "legacy" docviewer... 15:16 I've had more people tell me they don't like the fact that we don't auto-open documents when they are sent via content hub. 15:17 mmh... should we raise the priority for this? 15:17 Well, the problem is wider than docviewer. 15:17 When you download a pdf via the browser, you effectively have to press "open" up to 4 times 15:18 On the desktop, you tap a PDF in the browser and that's it, it opens in one click. 15:18 So we're somewhat less usable than the desktop 15:18 And part of that is not docviewers fault, but content hub and transfer indicator 15:20 huh, right... probably it would need a combo button with two actions: Open with and Open with... 15:20 Yeah, I know JMulholland (and others) are working on the browser side. 15:20 Just thinking if we could make it easier in docviewer side. 15:20 Was hoping JMulholland was around :) 15:22 in the wait we can discuss about the questions I submitted last week :P 15:22 sure. 15:23 Ok, so first was:_ 15:23 "Since our ultimate target is to get a DocViewer version, suitable for both PCs and devices, we'd need to have a up-to-date design pattern in order to know how to manage zooming with different input devices." 15:23 I spoke to JMulholland about this in our meeting just today. I asked for docviewer to be a higher priority. 15:24 I will discuss further with him next week when I'm in the office, but generally speaking, I agree, docviewer needs some design love as it is one of the apps that hasn't had any in the past. 15:24 Ok, great! 15:25 Next was "PDF plugin re-design" 15:25 Sry for afk, reading... 15:25 no mrqtros 15:25 Current implementation is a strange mix of QML, C++ and Qt's private imports 15:25 Right. 15:26 I'd like to get a "linear" implementation of the plugin, and now we can re-use part of work done for LibreOffice 15:27 Okay. 15:27 "Current implementation is a strange mix of QML" - any app for UP is a mix, but docviewer is really strange sometimes) 15:27 Is this something you have time to work on? 15:30 I'd like to have the LOK plugin completed first. We should be able to get a cleaner and equivalent (in performance) implementation by replacing tiles with PDF pages (consider this just a simple explanation) 15:30 I agree. 15:30 The code of PDF and LOK plugins looks almost similar 15:30 as in logic. 15:30 Right. 15:31 Third one was about UITK: "Is it worth to move directly from UITK 1.1 to UITK 1.3?" 15:31 We said to move to UITK 1.2 and we have a report on Launchpad for this. 15:32 As far as I saw UITK 1.3 seems to be already installed in the OTA-5 15:32 Right, and OTA-6 goes out next week (in theory) 15:33 So we can be confident that by the time we push a new docviewer + libreoffice in the store, all customers will be on a 1.3 image 15:33 Since the reboot branch will be released (ideally) in September, UITk 1.3 should be stable enough in the OTA-7 15:33 ii ubuntu-ui-toolkit-theme 1.3.1603+15.04.201 armhf Qt Components for Ubuntu - Ubuntu Theme 15:33 that's on my rc-proposed phone right now 15:34 agreed 15:34 The downside is the development on desktop. 15:34 on my PC I've added the vivid+overlay PPA, but it may be an uncomfortable addition- 15:35 s/addition/dependency 15:35 what release are you running? 15:35 yeah, we don't recommend the vivid overlay on PC :S 15:35 15.04... i know I'm brave :) 15:36 hah 15:36 would it be better to postpone the decision on this, then? 15:37 Hm. 15:37 This is a puzzle, yes. 15:37 15.10 comes out in october, it's quite stable here :) 15:39 I'm planning to switch to wily in a few weeks, probably as I get an SSD for my new desktop 15:39 but yes, I think we should postpone that, I agree 15:39 ooh, nice 15:39 balloons: you around? 15:39 * balloons floats in 15:39 Hey balloons ! 15:39 balloons: Did jenkins get enabled for https://code.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer ? 15:39 (if not, please can it) 15:40 I see on hold; https://code.launchpad.net/~ubuntu-docviewer-dev/ubuntu-docviewer-app/lo-viewer/+merge/262686 15:40 and some conflicts 15:40 sverzegnassi "by replacing tiles with PDF pages" do you mean that we should remove our tiled rendering and use pdf conversion? 15:41 mrqtros, could you remind me where I said that? :P 15:41 ok, found. 15:42 Just saying with a terrible explanation that we could consider a PDF page as a tile basically. A PDF plugin done so would run with the same performance of the current implementation 15:44 (just talking about reusing the LOK-plugin logic in the poppler-plugin. not talking about LOK) 15:45 balloons: is that a yes or no? :) 15:46 popey, jenkins will never run on an on-hold merge. Nor would it work as it has conflicts 15:46 we could force a run on it, but it has conflicts, so it will fail 15:47 No, I mean, is it pointed at the reboot series? 15:49 sverzegnassi: your final point in the mail was about an icon, and sadly no, no news, but I'll poke design when in the office next week :) 15:50 popey: hah, no problem. it was just a memo since we talked about that some months ago 15:50 yeah. 15:51 anything else to discuss? 15:52 well, nothing from me. since mrqtros is afk, I'll catch up with him later 15:53 Okay. 15:53 I'll try to fix the presentation support during the weekend 15:53 Awesome. 15:53 I hope you fully recover soon, and have a great weekend. 15:53 ty! have a nice weekend you too, popey! 15:54 Yes, sverzegnassi, I will keep in mind about pdf plugin while will be writing scene graph rendering for lok 15:54 Have a great weekend guys! 15:56 #endmeeting