15:00 <popey> #startmeeting DocViewer meeting
15:00 <meetingology> Meeting started Thu Feb  5 15:00:19 2015 UTC.  The chair is popey. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:00 <meetingology> 
15:00 <meetingology> Available commands: action commands idea info link nick
15:00 <popey> I've been testing out your history branch.
15:00 <popey> works well!
15:01 <popey> One thing I noticed..
15:01 <sverzegnassi> Good to hear! There's some minor issue that needs to be fixed
15:01 <popey> I can press + and launch content hub -> file manager.
15:01 <popey> Then choose multiple files. If I do that, only one gets transferred.
15:01 <popey> Is that a content-hub limitation?
15:01 <popey> I think I should only be able to select one file?
15:02 <sverzegnassi> I think that depends on file manager
15:02 <popey> Ok, I'll make a note to file a bug there.
15:03 <popey> The viewer feels pretty quick at rendering large magazines.
15:04 <sverzegnassi> I was just checking code in the content-hub project. We use a ContentPeerPicker to choose the source
15:04 <sverzegnassi> There's no way to specify is single or multiple file mode (or I just missed that)
15:05 <popey> hmm
15:05 <popey> kenvandine: you about? Do you know if we can specify single vs multi when pulling files via content-hub?
15:05 <sverzegnassi> About, PDF rendering. Yes, there are huge improvements. I was trying to read some news on Linux Voice yesterday, I found that cacheBuffer needs some tweak
15:06 <sverzegnassi> It causes some lag because its value changes anytime zoom value changes.
15:07 <sverzegnassi> Just need to force the setting only when pinch gesture is finished
15:07 <popey> Ok.
15:08 <kenvandine> popey, yes
15:08 <popey> kenvandine: how? :)
15:08 <kenvandine> so the app with the picker knows if it can allow multi
15:08 <kenvandine> it's a property on the transfer, you can set selectionType
15:09 <kenvandine> http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Content.ContentTransfer/#selectionType-prop
15:09 <popey> excellent.
15:09 <sverzegnassi> kenvandine: thank you!
15:11 <kenvandine> np
15:12 <popey> Ok, so do you think we're closer to putting a version in the store?
15:12 <sverzegnassi> Yesterday, as I was using docviewer, I realized that we need some way to fast scroll to the top/bottom of the document
15:12 <sverzegnassi> As I fix autopilot test for toc-model, yes, we have something to put in the store
15:13 <sverzegnassi> (another nice thing to fix - if I change PDF document to open during the test, there's no failure)
15:14 <popey> could we use some bottom edge navigation?
15:14 <popey> Have you seen the bottom edge use in the email app, dekko?
15:14 <sverzegnassi> nope. is it similar to the concept for dialer-app?
15:14 <popey> no
15:14 <popey> let me get a screenshot
15:14 <sverzegnassi> ok
15:15 <popey> http://people.canonical.com/~alan/screenshots/device-2015-02-05-151501.png
15:15 <popey> see the little half-circle with dots inside at the bottom
15:15 <sverzegnassi> the radial bottom edge from nik90?
15:15 <popey> yes
15:15 <popey> http://people.canonical.com/~alan/screenshots/device-2015-02-05-151528.png
15:15 <popey> http://people.canonical.com/~alan/screenshots/device-2015-02-05-151535.png
15:15 <popey> maybe, just a thought.
15:15 <sverzegnassi> we already have toc on bottom edge
15:16 <popey> ahhh
15:16 <sverzegnassi> http://design.canonical.com/2014/03/loving-the-bottom-edge/
15:16 <sverzegnassi> I was thinking to something some similar to the dialer-app bottom edge
15:16 <sverzegnassi> *more
15:16 * popey checks the dialer
15:17 <popey> hmm, what would you put in there?
15:17 <popey> A set of buttons like
15:17 <popey> ...
15:18 <sverzegnassi> A set of actions (Go to top/ Go to bottom). If the user does a full swipe to the top, then the toc list is shown
15:19 <popey> http://paste.ubuntu.com/10074624/
15:19 <popey> like that?
15:19 <popey> with it highlighting each one as you pull them up?
15:20 <sverzegnassi> Yep, but if I'm not wrong, the actions should be max. 3
15:20 <popey> yes
15:20 <popey> so top/bottom/toc
15:20 <sverzegnassi> page up/down 10 are not necessary, the flickable is faster enough
15:22 <popey> ok.
15:22 <popey> Sounds great.
15:22 <sverzegnassi> About the rest of the app, there are a few thing which I don't like much
15:23 <sverzegnassi> 1) Does we need an image viewer? The gallery-app has more features and, using contentHub, we copy images in $HOME/Documents, since we cannot access $Home/Pictures
15:23 <popey> I don't think so, no.
15:24 <popey> I would rather it did text, pdf, (and later) office documents well
15:24 <popey> rather than throw every file at it, and turn it into "eye of gnome"
15:25 <sverzegnassi> I feel the same. Unless we offer more feature than gallery-app, that's a non-sense. And if we do it, docviewer becomes gimp
15:25 <sverzegnassi> :P
15:25 <sverzegnassi> 2) We need to re-think the whole content-hub story
15:26 <sverzegnassi> There are implications with also doc-history
15:26 <popey> Ok, so we agree on image files.
15:26 <popey> What's the issue?
15:27 <sverzegnassi> User may want to open documents from confined folders (e.g. system folders - file manager allows it) or from 3rd party app folder
15:27 <sverzegnassi> Should we really store a copy of the file in $HOME/Documents?
15:27 <sverzegnassi> And store its entry in the history list?
15:28 <popey> if the user has allowed (via file manager) us to copy the document then I see no problem keeping a copy in $HOME/Documents
15:28 <popey> if we have write access then we could manage that directory
15:29 <popey> Trash icon -> click -> Popup "Do you want to delete the file from disk as well as remove from history?"
15:29 <popey> and the fact that they have used the file manager means they have it installed.
15:29 <popey> if they have file manager installed tey can use it to manage their data in $HOME/Documents
15:29 <sverzegnassi> So we actually don't need an history in the Welcome screen, but a file manager
15:31 <sverzegnassi> Also because if user copies some file through MTP, docviewer requires anyway filemanager-app to open them
15:32 <popey> hmmm
15:32 <popey> I think I need to talk to design :)
15:33 <sverzegnassi> yep. using qt.labs.folderlistmodel shouldn't be eventually a problem.
15:33 <sverzegnassi> it already exposes fileAccessed rule, which is what we need
15:34 <sverzegnassi> and I have already the code for it (re-written 10 days ago for one of my app)
15:34 <sverzegnassi> *apps
15:34 <popey> :)
15:34 <popey> I'm in the office tomorrow. Will speak to design about it.
15:34 <sverzegnassi> Ok!
15:37 <popey> so are you thinking we should just access ~/Documents and not use file manager?
15:38 <sverzegnassi> At this point, I think that File Manager could be just use as a ContentPeer so that we can eventually open documents stored in some other folder
15:38 <sverzegnassi> But, yes, that's what a Document Hub should look like
15:38 <popey> I agree.
15:40 <popey> Ok, anything else?
15:41 <sverzegnassi> no, that's all!
15:42 <popey> Awesome.
15:43 <popey> thanks sverzegnassi !
15:44 <popey> #endmeeting