[15:39] <ltinkl> mterry, http://paste.ubuntu.com/23486028/
[15:39] <ltinkl> mterry, now the prob: ubuntu-keyboard-czech : Depends: myspell-cs but it is not going to be installed
[15:39] <mterry> ltinkl: what's wrong with myspell-cs?
[15:40] <ltinkl> mterry, if I installed it (or added to the *-packages), it would remove half of my system ;)
[15:40] <ltinkl> mterry, because I already have hunspell-cs installed (as part of the regular lang pack)
[15:40] <mterry> ltinkl: seems bad.  But that's not normal...  do you know why it conflicts?
[15:40] <ltinkl> mterry, and those 2 langpacks are in direct conflict
[15:41] <ltinkl> mterry, because those langpacks contain duplicated stuff
[15:41] <mterry> ltinkl: well then they shouldn't both be in stage-packages either, eh
[15:42] <ltinkl> mterry, I'm gonna add myspell-cs temporarily to show you what would happen
[15:42] <mterry> ltinkl: but I don't get these problems (on xenial).  Maybe zesty changed
[15:42] <ltinkl> mterry, I'm on xenial
[15:43] <ltinkl> mterry, this happens with "myspell-cs" added: http://paste.ubuntu.com/23486046/
[15:44] <mterry> sure...  but why does this only affect you?
[15:45] <mterry> Do you have some other packages installed that conflict?
[15:46] <ltinkl> mterry, nope, no conflicts at all
[15:46] <ltinkl> mterry, but isn't it obvious? ubuntu-keyboard-czech wants to install myspell-cs which in turn breaks hunspell-cs (which I do have installed)
[15:46] <mterry> ah so you do have other packages that conflict (hunspell-cs) -- I didn't gather than from before
[15:47] <mterry> You're saying hunspell-cs is from language-pack-cs, but language-pack-touch-cs wants myspell-cs
[15:47] <ltinkl> mterry, well they don't conflict atm, they _would_ if I were to install myspell-cs
[15:47] <ltinkl> mterry, ubuntu-keyboard-czech wants myspell-cs
[15:51] <mterry> ltinkl: sounds like a bug in our packaging, at the least -- we should settle on one of those?
[15:54] <mterry> ltinkl: but OK.  I get your problem now though.  I think I can workaround it by dropping all the packages from stage-packages again and just adding a bigger gross LD_LIBRARY_PATH in our wrapper.  Doesn't stop us from getting bit by this in the future, but should work for now
[15:55] <cimi> pstolowski, hello
[15:55] <pstolowski> cimi, hi!
[15:55] <cimi> pstolowski, how are you :)
[15:55] <pstolowski> cimi, i'm fine, thanks, what's up?
[15:58] <cimi> pstolowski, I'd like to start a conversation I started with design - basically dash/scopes look a bit empty on tablet/desktop when the window is big enough, because from what I have been told scopes don't provide all the results they have to the dash, but just a few... the reason was to avoid showing the "see more/see less" button on some categories
[15:58] <cimi> is that right?
[16:01] <pstolowski> cimi, kind of. netiher shell plugin nor scope knows what the "good" number of results is to fill a row etc. on given display
[16:02] <pstolowski> cimi, if shell knew if, it could give a hint to the scope about "good number"
[16:03] <pstolowski> cimi, and it would be up to the scope really to obey or ignore it
[16:03] <cimi> pstolowski, I was wondering if we could simply provide an API that basically tells the shell/dash "just fill one line then dont show the see more/less button"
[16:04] <pstolowski> cimi, also, i guess it depends on orientation and if you connect a monitor etc
[16:04] <cimi> pstolowski, you always give us all the results, but we only show the first required to fill a line
[16:05] <cimi> imagine you send us 10, on phone we show 2, on tablet 5, desktop 6
[16:05] <pstolowski> cimi, ah, you mean the shell ignores the rest and discards them?
[16:05] <cimi> pstolowski, yes, when you set the API to true
[16:06] <pstolowski> cimi, that could work probably. could a flag in category renderer definition?
[16:06] <cimi> pstolowski, yes something like that
[16:06] <pstolowski> s/could a /could be a/
[16:07] <cimi> pstolowski, that way you always send us all the results you have, and dash on desktop will look more appealing and not so empty :)
[16:07] <pstolowski> cimi, this makes sense as long as shell plugin is not required to physically do all that in the results models, i.e. if you can apply the limit in the model view
[16:08] <pstolowski> so when user rotates the device, you simply redraw with different limit
[16:09] <cimi> pstolowski, we can simply clip or set a maximum height for the grid when we see this new category rendered flag set to true
[16:09] <cimi> I think that would work easily
[16:09] <pstolowski> ok, if you say so ;)
[16:10] <tsdgeos> cimi: man never use the word "easily" :D
[16:10] <cimi> tsdgeos is right
[16:10] <cimi> pstolowski, I think that would work.
[16:10] <pstolowski> cimi, kyleN will be happy if you implement that.. he was struggling to get good-looking resultsets in his scopes on both the phone and tablet...
[16:11] <cimi> pstolowski, now we need to come up with a good name for that flag, tsdgeos pstolowski suggestions?
[16:11] <tsdgeos> noShowMore
[16:13] <pstolowski> tsdgeos, this would have to be used in conjunction with collapsed-rows i presume?
[16:14] <Saviq> pstolowski, cimi, we *do* have a way to do that already
[16:15] <Saviq> the scope can tell how many rows to show, even when it sends 100 items
[16:15] <cimi> Saviq, but showing the see more/see less button
[16:15] <Saviq> cimi, no, not showing
[16:15] <Saviq> expandable: false; collapsed-rows: 2; or some such
[16:15] <cimi> Saviq, WAT
[16:16] <cimi> Saviq, so basically it's years scopes give us less results because they didn't know they could do that?
[16:16] <Saviq> they know they can do that
[16:16] <pstolowski> hmmm i vaguely remember we had this discussion before...
[16:16] <Saviq> but they still send too little results
[16:17] <Saviq> we totally did
[16:17] <cimi> Saviq, read since my first message to pawel, if you have anything to add or we said something wrong
[16:19] <cimi> pstolowski, Saviq tsdgeos so why scopes only give us sometimes, TWO results? for example music scope, two albums then wide open spaces on the right on desktop/tablet
[16:19] <Saviq> cimi, because the scope is implemented like that
[16:19] <pstolowski> Saviq, I don't see 'expandable' in our category renderer docs, so looks like omission on our side
[16:20] <cimi> Saviq, mistake from scope author who didn't know expandable: false; collapsed-rows: 1?
[16:21] <tsdgeos> Saviq: are you sure there's an expandable property?
[16:21] <cimi> Saviq, I have been told by tsdgeos we received 2 results to avoid showing "see more" on the phone, basically
[16:21] <Saviq> there should've been
[16:21] <Saviq> there was something that was explicitly making this behaving like that
[16:21] <tsdgeos> i don't see it
[16:22] <Saviq> might very well be we lost it in the mean time
[16:22] <cimi> ok, so it's time to add it then
[16:23] <Saviq> we've reworked this thing so many times
[16:23] <pstolowski> cimi, scopes definately set arbitrary limit, e.g. Music aggregator scope forces 2 local results no matter what
[16:24] <pstolowski> 3 for local music files
[16:25] <cimi> pstolowski, yeah, I thought that was for the see more/less - maybe if we add this "expandable" property we can change scopes to send a dozen results
[16:25] <mterry> ltinkl: try buiding a snap now
[16:26] <ltinkl> mterry, kk
[16:26] <mterry> ltinkl: and let me know if it works and if you see pulseaudio (which you didn't use to I think, right?)
[16:26] <ltinkl> mterry, it used to work for me
[16:26] <mterry> ltinkl: oh ok.  Well let me just know if it builds then.  :)
[16:27] <Saviq>  this doc doesn't have it either https://docs.google.com/document/d/1NmiM4UCnJgf6IEawmfyTOHRNAA5ZGrqpyrPqPOibwc8/edit
[16:27] <Saviq>  but I distinctly remember discussing it and would've sworn we had it implemented...
[16:30] <pstolowski> Saviq, this doc is ancient ;), i don't expect it to match reality
[16:45] <ltinkl> mterry, looks like it's building fine so far :)
[16:45] <mterry> ltinkl: nice
[16:52] <cimi> pstolowski, Saviq so what's next?
[16:52] <cimi> can we work it out to add this flag?
[16:53] <cimi> then we can help to patch some of the scopes too
[17:08] <ltinkl> mterry, snap built fine
[17:18] <pstolowski> cimi, sounds good to me
[17:19] <cimi> pstolowski, so I guess "expandable" to add, in combo with collapsed-rows: 1
[17:19] <pstolowski> cimi, yep
[17:20] <pstolowski> eod.. cu
[18:00] <Saviq> cimi, yeah wfm
[23:16] <dmj_s76> Trevinho: Have you had a chance to look into the g-s-d hidpi code?