[09:56] <tsdgeos> greyback: ping comment on https://code.launchpad.net/~gerboland/unity8/window-width-height-changes-acted-upon-always/+merge/286665
[09:59] <greyback> tsdgeos: thanks, will reply
[10:34] <cimi> pstolowski, hi! can we have again a silo with the filters?
[10:42] <pstolowski> cimi, we do have it. i need to rebuild due to doc updates in scopes-api, but it works anyway
[10:47] <cimi> pstolowski, # ?
[10:48] <pstolowski> cimi, 54
[11:09] <pstolowski> cimi, i'm testing silo 71 with a test scope but don't see social actions; they are supported by grid layout right?
[11:09] <cimi> pstolowski, they should
[11:09] <cimi> pstolowski, I will have a look
[11:11] <pstolowski> cimi, my scope is here: lp:~stolowski/+junk/scope-social_actions with click pkg included in click/
[12:47] <cimi> pstolowski, I haven't tried yet, but maybe we need to define them in the template like we do for attributes
[12:47] <cimi> pstolowski, query.cpp
[12:48] <pstolowski> cimi, ah, you might by right, i forgot that, let me check
[12:48] <pstolowski> * be
[13:13] <pstolowski> cimi, that didn't help. here is a dump of a sample result if that helps: http://pastebin.ubuntu.com/15327498/
[13:14] <pstolowski> cimi, and category renderer is http://pastebin.ubuntu.com/15327504/
[14:53] <cimi> pstolowski, can you try with "socialActions": { "max-count": 4 } ?
[14:56] <pstolowski> cimi, hmm ok
[14:57] <cimi> pstolowski, or in your case 2
[14:57] <pstolowski> cimi, these actions are supposed to be small buttons on top of the cards right? i don't think max-count should apply to them
[14:57] <cimi> or actually one
[14:57] <pstolowski> cimi, i only have 1 at a time
[14:57] <cimi> we need that
[14:58] <pstolowski> why?
[14:58] <cimi> all cards in a category need to have the same amount of items
[14:58] <cimi> and same style
[14:58] <cimi> so we need to define that
[14:58] <cimi> that's why we have max count
[14:59] <cimi> tsdgeos, can you confirm that what I said is correct please?
[14:59] <cimi> tsdgeos, "why we need max-count for socialActions"
[15:00] <tsdgeos> cimi: can the social actions ever wrap in two columns?
[15:00] <tsdgeos> err
[15:00] <tsdgeos> two rows
[15:00] <cimi> mmm not anymore I think
[15:00]  * cimi checks
[15:00] <cimi> tsdgeos, indeed not anymore
[15:01] <cimi> tsdgeos, so we probably dont need that anymore
[15:01] <tsdgeos> cimi: if they can't wrap we don't need the max-count since it's always there or not there
[15:01] <pstolowski> cimi, shall i try that still?
[15:01] <cimi> pstolowski, well, to see if that was the bug yes, put max-count 1
[15:01] <cimi> pstolowski, but I might be able to remove that and do a different check
[15:02] <pstolowski> ok
[15:02] <cimi> tsdgeos, that is the code for the model in cardTool
[15:02] <cimi>         onNumOfActionsChanged: {
[15:02] <cimi>             model = []
[15:02] <cimi>             for (var i = 0; i < numOfActions; i++) {
[15:02] <cimi>                 model.push( {"id":"text"+(i+1), "icon":"image://theme/ok" } );
[15:02] <cimi>             }
[15:02] <cimi>         }
[15:03] <cimi> ops sorry for the pasting thought were less lines
[15:03] <cimi> tsdgeos, shall we assume numOfActions is always 4 ?
[15:03] <tsdgeos> you don't need numOfActions anymore, no?
[15:03] <tsdgeos> you just need a bool "thereIsActions"
[15:03] <cimi> tsdgeos, mmm we need for the model no?
[15:04] <cimi> tsdgeos, fake model no?
[15:04] <cimi> cardtool mock
[15:04] <tsdgeos> that's a fake model, just add one
[15:04] <tsdgeos> if there is actions
[15:04] <cimi> ok
[15:05] <tsdgeos> cimi: pstolowski: there will still be a socialActions entry in components when there is social actions, no?
[15:06] <pstolowski> cimi, i did http://pastebin.ubuntu.com/15328150/ but still don't see them
[15:06] <cimi> tsdgeos, http://paste.ubuntu.com/15328157/
[15:06] <pstolowski> tsdgeos, yeah i think so, see the above pastebin; in the simple case i had just "social-actions":"social-actions"
[15:07] <tsdgeos> cimi: yeah something like that, you can probably make it readonly too
[15:07] <cimi> ok
[16:22] <Saviq> cimi, here's an interesting one: bug #1554602, it seems to stop processing scope comm until images are loaded ¿?
[16:22] <Saviq> tsdgeos, josharenson ↑ - not huge prio but just interesting
[16:23] <tsdgeos> i'd say that's the wrong bug :D
[16:23] <tsdgeos> the bug is the preview model is reset
[16:23] <tsdgeos> and it'd be great if we got an update
[16:24] <tsdgeos> but yes, meanwhile having them in a cache if possible would help i guess
[16:24] <tsdgeos> or i don't really understand what the bug means
[16:25] <tsdgeos> davmor2: which images you exactly mean in https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1554602 ? you mean the screenshots shown below the install button?
[16:26] <Saviq> tsdgeos, yes
[16:26] <Saviq> tsdgeos, a side effect of them taking long to load is that install progress isn't reported (it goes 0% → installed, for example for uTouch)
[16:27] <davmor2> tsdgeos: the screensots yes
[16:27] <tsdgeos> Saviq: i don't think that has any relation at all
[16:27] <Saviq> tsdgeos, it does seem like it
[16:27] <Saviq> tsdgeos, the thing changes as soon as all images load up
[16:28] <Saviq> tsdgeos, which is why I said it's interesting ;)
[16:28] <tsdgeos> Saviq: i would say that's coincidental on yout side, i pressed install, got all the images loaded, the thing stayed at 0% for a while after that and then went to 100%
[16:28] <davmor2> tsdgeos: and if the images are cached why do they take so long to load each time
[16:29] <josharenson> Saviq: gotcha.. also, whats the status on the greeter silo?
[16:29] <tsdgeos> davmor2: i don't understand that last sentence
[16:29] <davmor2> tsdgeos: and if you try on a larger app like dekko you with see the installer on 0% till the images load then it jumps up to 30%
[16:30] <Saviq> tsdgeos, may very well be
[16:30] <davmor2> tsdgeos: the screenshots are meant to be cached locally right? so why does it seem to re-download the images for each page
[16:30] <Saviq> josharenson, it's built, so I will try and test it out before tomorrow
[16:31] <josharenson> Saviq: cool thanks
[16:31] <tsdgeos> davmor2: who said the screenshots are mean to cached locally?
[16:31] <davmor2> tsdgeos: assumption and dobey and Saviq
[16:32] <Saviq> tsdgeos, they are cached by the network cacher at least (so network requests, not actual image requests)
[16:32] <Saviq> or well, should be
[16:33] <tsdgeos> Saviq: you mean CachingNetworkManagerFactory.cpp ?
[16:34] <Saviq> tsdgeos, yes
[16:34] <tsdgeos> Saviq: that is a noop
[16:34] <tsdgeos> Saviq: it only does things when you don't have internet
[16:34] <Saviq> tsdgeos, oh duh, really? we never got it to do the right thing? <facepalm/>
[16:34] <tsdgeos> i may be wrong
[16:35] <tsdgeos> but by looking at the code i think that it is what it does
[16:40] <tsdgeos> pstolowski: i guess making the previews be updated instead of reset is a bit of work?
[16:40] <Saviq> tsdgeos, and we're not using thumbnailer there, either? (we are for ZoomableImage, so should be able to use for screenshots, too/)
[16:41] <tsdgeos> Saviq: no we don't use the thumbnailer
[16:42] <tsdgeos> Saviq: what do you mean "we are for ZoomableImage"?
[16:42] <Saviq> tsdgeos, AFAIK we are using for ZoomableImage (since there was a bug about us requesting a lot of (-1, -1) images)
[16:42] <Saviq> or ones much bigger than the screen
[16:43] <pstolowski> tsdgeos, yes. i plan to do this in near future
[16:43] <tsdgeos> Saviq: we do not mangle urls from what i can see
[16:44] <tsdgeos> pstolowski: that'd be nice :)
[16:44] <Saviq> tsdgeos, ok well, we probably should :)
[16:45] <pstolowski> let me actually create a card for this
[16:45] <Saviq> tsdgeos, bug #1536814 fwiw
[16:46] <Saviq> tsdgeos, aah that's because this was image://thumbnailer/ already coming from the scope
[16:46] <tsdgeos> Saviq: yes, but that's because he gives us thimbnailer urls
[16:46] <tsdgeos> and why we should be veeeeeeeeeeery careful about mangling urls from the scope
[16:46] <tsdgeos> we could end up destroyign valid urls
[16:46] <Saviq> right, we should probably mangle them to be thumbnailer ones unless they are already thumbnailer :P
[16:46] <tsdgeos> but yeah i guess we can check for starts with http:// or something
[16:46] <Saviq> or maybe simply if they're not image://
[16:47] <Saviq> since that's the only thing thumbnailer won't be able to deal with
[16:47] <tsdgeos> not sure how smart the thumbnailer is with regards to remote images being updated if at all
[16:47] <Saviq> in theory
[16:47] <Saviq> tsdgeos, however smart it is, it *should* be at least as smart as Qt is (and I believe it is)
[16:48] <tsdgeos> well Qt doesn't save things on disk
[16:48] <tsdgeos> so at worst a reboot will for sure give you a new image
[16:49] <tsdgeos> but yes, worth checking
[16:49] <Saviq> well, yeah, in that sence thumbnailer should be smarter ;)
[16:49] <tsdgeos> a bit moot once pawel implements the model updating
[16:49] <Saviq> and then we can do away with BlahBlahBlahFactory
[16:49] <tsdgeos> but still would help with going to previews you've already been
[16:49] <Saviq> tsdgeos, not really, still first-time load would be improved
[16:49] <Saviq> tsdgeos, as you go out and back in to a preview
[16:50] <tsdgeos> yes, but mentally that's "less bad"
[16:50] <Saviq> sure, less of an improvement, not moot ;)
[16:50] <tsdgeos> yes
[16:50] <Saviq> but also - an easier one :)
[18:03] <cimi> Saviq, on that bug, I know you discussed with albert but the reason for the refresh is simple: the previewmodel gets reset on action
[18:03] <cimi> Saviq, so we basically reload the preview - pawel is aware
[18:03] <cimi> iirc
[18:25] <Saviq> cimi, yes, I know, but it's orthogonal to us not caching the images, or seemingly waiting for the images to load before updating the installation progress
[18:30] <cimi> Saviq, even if we cache the images, the components will still be recreated
[18:30] <cimi> sorry
[18:30] <cimi> if we unset the images from the model
[18:30] <cimi> anyway, Ill discuss with pawel tomorrow
[18:31] <cimi> my random statements afte 6pm dont make sense :)
[18:36] <Saviq> cimi, it doesn't matter if they're recreated, I mean not for the issue we're discussing here - sure, they're reloaded, but wouldn't it be better for them to be reloaded from the cache? and to not block the rest of the dash while they load? it affects first-time load just as well as the unnecessary reload
[18:37] <Saviq> cimi, and Paweł knows, he said he wants to work on that soon
[19:34] <josharenson> cimi: you still there?
[19:36] <Saviq> josharenson, can I help?
[19:37] <josharenson> Saviq: just some general dash architecture questions. I can send an e-mail
[19:37] <Saviq> kk
[19:37] <josharenson> I mean, I'll ask you too
[19:37] <josharenson> 1 min
[19:39] <josharenson> ... more like 5 min
[19:52] <josharenson> Saviq: e-mailed you something
[20:15] <Saviq> josharenson, replied, I hope I've not muddied the waters even more
[20:16] <josharenson> Saviq: reading.. ive figured a little more out in the meantime as well
[20:17] <josharenson> Saviq: ah, dashcontent is the one place albert told me not to look as its being redone? The engineer in me should have known that the place you are told _not_ to look is the first place you should look...
[20:17] <Saviq> josharenson, lol, yes, in the sense that the navigation model for this whole thing is going away soon
[20:17] <josharenson> ok
[20:18] <Saviq> josharenson, but to understand what it is today - yeah that's it
[20:18] <Saviq> josharenson, I won't link you to the new navigation docs just yet :)
[20:18] <josharenson> Saviq: gotcha, and your e-mail makes sense, thanks
[20:18] <josharenson> :-) ok
[20:19] <Saviq> josharenson, you need to get to terms with what it is now, so you can see what will actually change
[20:19] <josharenson> Saviq: good point
[22:29] <cimi> josharenson, here I am
[22:29] <josharenson> cimi: :-) saviq got most of my questions, no worries
[22:29] <josharenson> cimi: I sent an e-mail... feel free to wait until tomorrow to read it
[22:29] <cimi> josharenson, oki :) saviq is too fast :)
[22:29] <josharenson> hah yeah
[22:30] <cimi> can't even let me prepare dinner :)