[09:17] <tsdgeos> Cimi: ping
[09:28] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/test_stubborn_flick/+merge/252407 for one of the tests that now suddenly fails
[09:29] <tsdgeos> i'm having a look at the Dash ones
[09:29] <tsdgeos> the TabletShell and WideView ones need mterry i'd say
[09:30] <tsdgeos> seem real flackyness since i can have them fail here too sometimes and not depending on what sdk version i have
[09:30] <tsdgeos> maybe we got slower/faster CI now
[09:30] <Saviq> tsdgeos, ktx
[09:30] <tsdgeos> and it exposes them
[10:01] <tsdgeos> Saviq: in https://code.launchpad.net/~aacid/unity8/scope-tool-dependencies/+merge/251573 you don't mean making them build time dependencies
[10:02] <tsdgeos> since they are build time dependencies already
[10:02] <tsdgeos> you mean changing the code, no?
[10:02] <Saviq> tsdgeos, yes
[10:04] <Saviq> tsdgeos, obviously unless you can understand the reason if it can't be build-time, when I'd like a comment near the code, so we don't have to go through that exercise again
[10:05] <Saviq> blame doesn't help
[10:10] <Cimi> tsdgeos, saw the review
[10:10] <Cimi> tsdgeos, you propose to scroll the previewimagegallery?
[10:11] <tsdgeos> Cimi: it is scrolled already, isn't it?
[10:11] <tsdgeos> i just proposed to do it immediately
[10:11] <tsdgeos> and that closing gives you the nice animation instead of the non nice one
[10:12] <tsdgeos> Saviq: yeah, my only guess is if you want to run a different regisyty, etc by modyfing the PKG_CONFIG_PATH
[10:12] <tsdgeos> that i guess at some point can be interesting
[10:12] <Cimi> tsdgeos, there is the overlay and the listview in the preview
[10:13] <Saviq> tsdgeos, if you wanted to allow overriding the scope path, there's probably better ways than to change PKG_CONFIG_PATH...
[10:13] <Cimi> tsdgeos, if you scroll the overlay to an image that in the original listview is outside the view, it still goes there (out of screen)
[10:13] <Cimi> tsdgeos, how do you propose to fix it?
[10:15] <tsdgeos> Saviq: like?
[10:15] <Saviq> tsdgeos, like explicit arguments to the tool ;)
[10:16] <Saviq> not hidden functionality through pkg-config
[10:16] <tsdgeos> Saviq: it's not better if you already have it coded :D
[10:16] <tsdgeos> Cimi: i don't propose to fix it, since it is already doing it
[10:16] <tsdgeos> Cimi: have you done what i say on my comment?
[10:17] <Saviq> tsdgeos, so the only problem I can see with making it build-time is that the tool could get outdated in case the paths changed
[10:18] <Saviq> tsdgeos, as there's nothing the tool links to to warrant rebuilds, we'd need a lib with those paths
[10:19] <Saviq> tsdgeos, so yeah, let's leave it run-time for now, and once we make libs in unity-api is when we'd move
[10:19] <tsdgeos> yeah, i mean it's not like it's a huge problem anyway given that it's a "devel" tool
[10:20] <tsdgeos> Saviq: want me to comment on the MR?
[10:20] <tsdgeos> saying "let's leave it as it is for now"? or you do?
[10:20] <Saviq> tsdgeos, rather add a comment in code where it's calling pkg-config
[10:20] <Saviq> tsdgeos, saying why we're doing it runtime
[10:21] <tsdgeos> ok
[10:45] <tsdgeos> Saviq: added the comment
[10:45] <Saviq> tsdgeos, tx
[12:24] <Cimi> tsdgeos, I fixed that, however there's a binding loop for loader xScale/yScale first when you open it
[12:24] <Cimi> tsdgeos, but cannot see anything wrong though
[12:24] <tsdgeos> i'll check, tx
[12:25] <Cimi> tsdgeos, I can add a comment with // there is a binding loop here
[12:27] <tsdgeos> Cimi: i'd prefer no unless we know why exactly and why it's unfixable
[12:27] <tsdgeos> or do you know?
[12:27] <Cimi> tsdgeos, I don't
[12:27] <Cimi> tsdgeos, unless is due to the verticalScaling boolean
[12:28] <Cimi> tsdgeos, yeah, that boolean
[12:29] <Cimi> tsdgeos, xScale uses yScale and viceversa, but they both re evaluated when verticalScaling changes
[12:31] <tsdgeos> hmmmm
[12:31] <tsdgeos> ok, let me first check it works nicely and then we cna have a look at the code to see if there's a way to fix that or not
[12:33] <tsdgeos> but first good!
[12:33] <tsdgeos> err
[12:33] <tsdgeos> food :D
[12:34] <Cimi> :)
[13:50] <mterry> dandrader, can you merge your unifyShellTests branch from trunk?
[13:51] <mterry> err, merge trunk into your branch that is
[13:52] <dandrader> mterry, ok
[13:52] <tsdgeos> Mirv: you back already or still on holidays?
[13:53] <mterry> dandrader, thanks!  :)
[13:53] <dandrader> mterry, done
[13:54] <mterry> dandrader, awesome
[13:59] <tsdgeos> Cimi: why that implicitHeight to 1?
[14:17] <tsdgeos> Cimi: that works much nicer :)
[14:19] <Cimi> tsdgeos, to avoid a couple of divisions by 0
[14:22] <Mirv> tsdgeos: back tomorrow
[14:23] <tsdgeos> Mirv: oki, ping me then :)
[14:30] <Cimi> tsdgeos, ?
[14:31] <tsdgeos> Cimi: ? what? _D
[14:31] <Cimi> tsdgeos, saw the binding issue?
[14:31] <tsdgeos> yep
[14:33] <Saviq> tsdgeos, you talking with Timo about backporting the dbus patches?
[14:34] <tsdgeos> Saviq: do we want them backported already even if not landed upstream?
[14:34] <tsdgeos> Cimi: i guess we can live with those
[14:34] <tsdgeos> should be possible to fix some of them
[14:34] <Cimi> it is just 2
[14:34] <tsdgeos> but probably making the code harder to read
[14:34] <tsdgeos> so not sure worth it
[14:34] <Saviq> tsdgeos, no, thought that was what you were pinging him about, wanted to let you know that mzanetti has another thing to backport for pixel ratio
[14:35] <tsdgeos> Saviq: it was a fix for a crash greyback_ found that is fixed for 5.4.2
[14:35] <tsdgeos> and to tell him that we can probably land 5.4.1 now that we found the keyboard crash was because the cache wasn't cleared properly
[14:36] <tsdgeos> Saviq: speaking of which any chance of landing https://code.launchpad.net/~aacid/qtmir/load_generic_sensors_test_5_4_1 soon?
[14:36] <mzanetti> https://bugreports.qt.io/browse/QTBUG-38127
[14:37] <Saviq> tsdgeos, QA is quite backed up, we've a silo for unity8 and qtmir already...
[14:38] <Saviq> tsdgeos, so yeah, in the next landing, wherever it might be...
[14:38] <tsdgeos> mzanetti: is that something you need to fix in the provider side? yesterday i came across https://git.reviewboard.kde.org/r/122869/diff/#index_header
[14:38] <tsdgeos> Saviq: ok
[14:38] <tsdgeos> mzanetti: which according to David is the right thing to do
[14:39] <Saviq> tsdgeos, having providers know about pixel ratio sounds wrong, doesn't it?
[14:39] <mzanetti> tsdgeos, no, I don't think the provider should need to care
[14:39] <tsdgeos> it does to me
[14:39] <mzanetti> tsdgeos, also, it can't in all cases
[14:39] <tsdgeos> but i won't claim i understand it
[14:40] <mzanetti> tsdgeos, the image provider should already get transformed sizes, which is what happens in 5.5
[14:40] <mzanetti> tsdgeos, also because QML will read the returned image's size and if the provider just returns double the requested size, it'll confuse qml a lot in some cases
[14:41] <tsdgeos> mzanetti: well you can set the devicepixels thing in the qimage
[14:41] <tsdgeos> but as said, i won't claim i am up to date on how that thing works
[14:41] <mzanetti> yeah, at least 5.4 doesn't seem to care about that at all
[14:43] <mzanetti> tsdgeos, with that kimageprovider patch, if one sets "sourceSize.width: width" and no width it'll end up generating bigger and bigger images in an endless loop
[14:53] <mterry> Ugh, there is a failing qmluitest in trunk, in TabletShell
[14:53] <mterry> I'm guessing it's my fault
[14:53] <tsdgeos> mterry: wideSomething too
[14:53] <tsdgeos> i had a look
[14:53] <tsdgeos> and seems like a timing issue
[14:53] <tsdgeos> mterry: it'd be great if you could have a look yes
[14:54] <mterry> tsdgeos, hrm
[14:54] <tsdgeos> mterry: i.e if i add a few wait() in places
[14:54] <tsdgeos> i can make it pass some more and fails somewhere else :D
[15:23] <Cimi> thostr_, kgunn alecu in order to fix https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1267184 someone will probably have to write a click installation service that unity8 and click store will use
[15:31] <alecu> Cimi: yes, a click installation service is something that's needed to solve that bug.
[15:32] <alecu> Cimi: it's not a trivial amount of work, so I'd like to understand better where this will be shown, to make it worth the effort.
[15:32] <alecu> Cimi: since we are not adding the just installed apps automatically to the launcher, the progress will only be shown on scopes
[15:33] <Cimi> alecu, we won't?
[15:33] <Cimi> alecu, that's what we currently do on the desktop
[15:33] <alecu> Cimi: we had an open bug to add the app to the launcher that was closed as won't fix, iirc
[15:34] <Cimi> mzanetti, ping
[15:34] <alecu> Cimi: I think that the problem is when you install a few apps the launcher gets too crowded.
[15:34] <mzanetti> Cimi, hey
[15:34] <alecu> *the launcher would get too crowded, that is.
[15:34] <Cimi> mzanetti, read le last lines
[15:34] <Cimi> mzanetti, what will happen with newly installed apps on the launcher?
[15:35] <mzanetti> Cimi, dunno... haven't ever gotten a definite answer from design. Last statement was they don't want to pin new apps automatically... but there are conflicting specs
[15:36] <alecu> mzanetti: Cimi: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1350568
[15:37] <mzanetti> Cimi, alecu: Design work for launcher on desktop has started now. That might change this again.
[15:38] <alecu> I hope that includes the convergence use case.
[15:38] <Cimi> in that bug they said that we want to pin apps on the desktop
[15:39] <mzanetti> yeah, I'm highlighting the convergence stuff all the time
[15:39] <alecu> great
[16:17] <mterry> dandrader, I just filed an MP for lp:~mterry/unity8/fix-two-qmluitests which will conflict with your unifyTestShell
[16:17] <mterry> dandrader, I didn't want to base it on yours, since mine felt closer to trunk, and could easily land without yours
[16:18] <mterry> dandrader, but it should be trivial to rebase yours on mine
[16:19] <dandrader> mterry, ok
[16:21] <tsdgeos> Cimi: there?
[16:21] <Cimi> tsdgeos, yes
[16:21] <tsdgeos> Cimi: one last thing in https://code.launchpad.net/~cimi/unity8/fix-previewoverlay/+merge/251728
[16:22] <tsdgeos> do we really need the change in https://code.launchpad.net/~cimi/unity8/fix-previewoverlay/+merge/251728 ?
[16:22] <tsdgeos> er
[16:22] <tsdgeos> in tests/qmltests/Dash/Previews/tst_PreviewImageGallery.qml
[16:22] <tsdgeos> i mean
[16:22] <Cimi> tsdgeos, it makes the window not squared
[16:22] <tsdgeos> ah good
[16:22] <Cimi> tsdgeos, so it tests the squared image zoomed on a not-squared screen
[16:28] <tsdgeos> Cimi: ah, and really last thing
[16:28] <tsdgeos> Cimi: can you give it a better commit message?
[16:28] <Cimi> hah
[16:28] <tsdgeos> it's not really a "Refactor"
[16:28] <tsdgeos> well it is
[16:28] <tsdgeos> but i don't care
[16:29] <tsdgeos> i care that it fixes the bug bla bla
[16:29] <Cimi> tsdgeos, done
[16:29] <tsdgeos> thank
[16:29] <tsdgeos> s
[18:19] <dandrader> is anybody else having timeout issues with launchpad?
[18:20] <dandrader> mzanetti, could you please re-approve this one? https://code.launchpad.net/~dandrader/unity8/controlTouchEmulationFromQML/+merge/252489
[18:21] <dandrader> mzanetti, I had to resubmit it to add lp:~dandrader/unity8/unifyShellTests as a prerequisite
[18:21] <dandrader> mzanetti, to solve a merge conflict between them
[18:22] <dandrader> hmm, got two "Launchpad internal error" e-mails...
[18:41] <mzanetti> dandrader, the diff seems empty too
[18:41] <dandrader> weird. let me see if I messed up somethign
[18:42] <dandrader> mzanetti, ah... I got two "Launchpad internal error" e-mails telling me that they could not produce a diff. maybe that's it
[18:44] <dandrader> mzanetti, it merges manually just fine
[18:44] <dandrader> (locally)
[18:44] <mzanetti> ok
[20:59] <cheekoli> how might I add key bindings to increase/decrease the number of workspaces in unity on the fly? is that possible?
[21:00] <cheekoli> i can currently go through compizconfig to edit them manually, but i'd like to be able to add a workspace and push a window to it with keyboard shortcuts
[21:33] <Saviq> cheekoli, I don't think that's possible with compiz directly, but it should be possible to script it
[21:33] <Saviq> and then have a script run on a keybinding
[21:52] <cheekoli> Saviq, yea--I can probably probably hack together something using any number of languages.. any idea where those values are stored??  in config files in ~ or gconf or something?
[21:52] <Saviq> cheekoli, gsettings
[21:52] <cheekoli> thanks, that should give me enough to dig in
[21:53] <Saviq> cheekoli, it's under org.compiz.profiles