=== duflu_ is now known as duflu | ||
=== Malsasa_ is now known as Malsasa | ||
=== Malsasa_ is now known as Malsasa | ||
tsdgeos | Cimi: ping | 09:17 |
---|---|---|
tsdgeos | Saviq: https://code.launchpad.net/~aacid/unity8/test_stubborn_flick/+merge/252407 for one of the tests that now suddenly fails | 09:28 |
tsdgeos | i'm having a look at the Dash ones | 09:29 |
tsdgeos | the TabletShell and WideView ones need mterry i'd say | 09:29 |
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 | 09:30 |
tsdgeos | Saviq: in https://code.launchpad.net/~aacid/unity8/scope-tool-dependencies/+merge/251573 you don't mean making them build time dependencies | 10:01 |
tsdgeos | since they are build time dependencies already | 10:02 |
tsdgeos | you mean changing the code, no? | 10:02 |
Saviq | tsdgeos, yes | 10:02 |
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:04 |
Saviq | blame doesn't help | 10:05 |
Cimi | tsdgeos, saw the review | 10:10 |
Cimi | tsdgeos, you propose to scroll the previewimagegallery? | 10:10 |
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:11 |
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:12 |
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:13 |
tsdgeos | Saviq: like? | 10:15 |
Saviq | tsdgeos, like explicit arguments to the tool ;) | 10:15 |
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:16 |
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:17 |
Saviq | tsdgeos, as there's nothing the tool links to to warrant rebuilds, we'd need a lib with those paths | 10:18 |
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:19 |
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:20 |
tsdgeos | ok | 10:21 |
tsdgeos | Saviq: added the comment | 10:45 |
Saviq | tsdgeos, tx | 10:45 |
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:24 |
Cimi | tsdgeos, I can add a comment with // there is a binding loop here | 12:25 |
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:27 |
Cimi | tsdgeos, yeah, that boolean | 12:28 |
Cimi | tsdgeos, xScale uses yScale and viceversa, but they both re evaluated when verticalScaling changes | 12:29 |
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:31 |
tsdgeos | but first good! | 12:33 |
tsdgeos | err | 12:33 |
tsdgeos | food :D | 12:33 |
Cimi | :) | 12:34 |
=== alan_g is now known as alan_g|lunch | ||
=== alan_g|lunch is now known as alan_g | ||
mterry | dandrader, can you merge your unifyShellTests branch from trunk? | 13:50 |
mterry | err, merge trunk into your branch that is | 13:51 |
dandrader | mterry, ok | 13:52 |
tsdgeos | Mirv: you back already or still on holidays? | 13:52 |
mterry | dandrader, thanks! :) | 13:53 |
dandrader | mterry, done | 13:53 |
mterry | dandrader, awesome | 13:54 |
tsdgeos | Cimi: why that implicitHeight to 1? | 13:59 |
tsdgeos | Cimi: that works much nicer :) | 14:17 |
Cimi | tsdgeos, to avoid a couple of divisions by 0 | 14:19 |
=== dandrader is now known as dandrader|afk | ||
Mirv | tsdgeos: back tomorrow | 14:22 |
tsdgeos | Mirv: oki, ping me then :) | 14:23 |
Cimi | tsdgeos, ? | 14:30 |
tsdgeos | Cimi: ? what? _D | 14:31 |
Cimi | tsdgeos, saw the binding issue? | 14:31 |
tsdgeos | yep | 14:31 |
Saviq | tsdgeos, you talking with Timo about backporting the dbus patches? | 14:33 |
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:34 |
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:35 |
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:36 |
Saviq | tsdgeos, QA is quite backed up, we've a silo for unity8 and qtmir already... | 14:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:43 |
=== dandrader|afk is now known as dandrader | ||
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:53 |
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 | 14:54 |
=== alan_g is now known as alan_g|afk | ||
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:23 |
ubot5 | 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:23 |
alecu | Cimi: yes, a click installation service is something that's needed to solve that bug. | 15:31 |
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:32 |
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:33 |
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:34 |
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:35 |
alecu | mzanetti: Cimi: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1350568 | 15:36 |
ubot5 | Ubuntu bug 1350568 in unity-scope-click (Ubuntu) "[launcher] [design] Apps are not pinned to the launcher" [High,Won't fix] | 15:36 |
mzanetti | Cimi, alecu: Design work for launcher on desktop has started now. That might change this again. | 15:37 |
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:38 |
mzanetti | yeah, I'm highlighting the convergence stuff all the time | 15:39 |
alecu | great | 15:39 |
=== alan_g|afk is now known as alan_g | ||
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:17 |
mterry | dandrader, but it should be trivial to rebase yours on mine | 16:18 |
dandrader | mterry, ok | 16:19 |
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:21 |
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:22 |
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:28 |
tsdgeos | i care that it fixes the bug bla bla | 16:29 |
Cimi | tsdgeos, done | 16:29 |
tsdgeos | thank | 16:29 |
tsdgeos | s | 16:29 |
=== dandrader is now known as dandrader|lunch | ||
=== alan_g is now known as alan_g|EOD | ||
=== dandrader|lunch is now known as dandrader | ||
dandrader | is anybody else having timeout issues with launchpad? | 18:19 |
dandrader | mzanetti, could you please re-approve this one? https://code.launchpad.net/~dandrader/unity8/controlTouchEmulationFromQML/+merge/252489 | 18:20 |
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:21 |
dandrader | hmm, got two "Launchpad internal error" e-mails... | 18:22 |
mzanetti | dandrader, the diff seems empty too | 18:41 |
dandrader | weird. let me see if I messed up somethign | 18:41 |
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:42 |
dandrader | mzanetti, it merges manually just fine | 18:44 |
dandrader | (locally) | 18:44 |
mzanetti | ok | 18:44 |
=== greyback__ is now known as greyback | ||
cheekoli | how might I add key bindings to increase/decrease the number of workspaces in unity on the fly? is that possible? | 20:59 |
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:00 |
=== seb128_ is now known as seb128 | ||
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:33 |
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:52 |
Saviq | cheekoli, it's under org.compiz.profiles | 21:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!