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