| kdub | could anyone take a look over? https://code.launchpad.net/~kdub/platform-api/mir-deb-bump-0.1.3/+merge/200430 | 00:00 |
|---|---|---|
| kdub | should be pretty simple, just bumping ABI | 00:00 |
| === duflu_ is now known as duflu | ||
| Akiva-Mobile | So I am thinking of contributing a feature to unity, patch and everything, about an idea that I just thought of. I'd like to pass the idea around here first | 03:05 |
| Akiva-Mobile | Its actually pretty mundane and simple, and has to do with moving windows with the mouse | 03:05 |
| Akiva-Mobile | When an application is full screen, and you go to the top screen bar, on the white space where no menu actions are currently situated, and then HoldLeftClick, you can move the window around | 03:08 |
| Akiva-Mobile | I basically want to extend this function to when windows are not full screen | 03:09 |
| Akiva-Mobile | One of the reasons why this is, is that I often find while using spaces, that my top menu bar is stuck on another virtual desktop | 03:10 |
| Akiva-Mobile | and I thus have to switch workspaces, or press alt+click the window to drag down. | 03:11 |
| RAOF | Hm. I was wondering where that was going; that's an actual use-case :) | 03:26 |
| RAOF | On the other hand, might this not be better solved by ensuring that the top bar is always visible? | 03:26 |
| Akiva-Mobile | RAOF: http://discourse.ubuntu.com/t/unity-five-suggestions-for-global-menu-bar-whitespace/1392 << sorry, library closed, and now im at the coffee shop :P. Anyways, I extended my suggestion to five | 05:51 |
| Akiva-Mobile | RAOF: The top bar being always visible... how would the logic work with vertical spaces? | 05:52 |
| RAOF | Akiva-Mobile: You'd just move the window down when you switched workspaces. | 05:52 |
| Akiva-Mobile | RAOF: wouldnt that be annoying if you were trying to escape that application, and it just happened to slightly be leaking into the next workspace? | 05:53 |
| Akiva-Mobile | RAOF: Gnome 3 doesnt have this issue though, does it...? | 05:54 |
| RAOF | Akiva-Mobile: Yeah, that would be awkward I guess. GNOME 3 gets around this by not having workspaces in a coherent space. | 05:55 |
| Akiva-Mobile | RAOF: If Gnome3 had HUD, I'd definitely consider using it. | 05:55 |
| Akiva-Mobile | RAOF: Sorry again :P | 06:02 |
| Akiva-Mobile | RAOF: I think my idea is reasonable, and it would be neat trying to get a patch accepted by the ubuntu project. Maybe then someone will hire me as a programmer once I have that on my mantle :) | 06:03 |
| RAOF | :) | 06:03 |
| RAOF | I'd give it a go. | 06:03 |
| Akiva-Mobile | RAOF: Any suggestion what file to start looking into? Save myself some time~ | 06:04 |
| RAOF | Sorry, no. | 06:04 |
| Akiva-Mobile | RAOF: I'll expose my ignorance here, but will I have to do this on mir? | 06:05 |
| Akiva-Mobile | or will the code be transferable? | 06:05 |
| RAOF | No; the Unity 8 codebase is entirely distinct. | 06:05 |
| RAOF | There's not currently any window management in Unity 8 anyway :) | 06:05 |
| Akiva-Mobile | RAOF: For mir, how much needs to be rewritten? | 06:05 |
| RAOF | We're rewriting everything; using Qt5 rather than compiz, etc. | 06:06 |
| Mirv | Saviq: FYI test failing https://bugs.launchpad.net/unity-scopes-shell/+bug/1267026 | 09:07 |
| ubot5 | Ubuntu bug 1267026 in unity-scopes-shell "1 test failing resulting in FTBFS" [Critical,New] | 09:07 |
| Saviq | mhr3, ↑ | 09:07 |
| Saviq | Mirv, the unity-api issue is tricky :/ in theory we've identified the commit where it got better, but that one commit wasn't enough | 09:08 |
| Saviq | Mirv, it's working fine on the stable branch, after https://bugreports.qt-project.org/browse/QTBUG-35721 has been fixed | 09:08 |
| tsdgeos | and the tabbar was merged, let's see all the complains :D | 09:09 |
| Mirv | Saviq: is stable = upcoming 5.2.1? please don't say 5.3 :) | 09:09 |
| tsdgeos | yes | 09:09 |
| Mirv | ok, yes I'd be planning to get qtbase and qtdeclarative snapshots (or maybe just qtdeclarative for starters) | 09:09 |
| tsdgeos | "Target for Qt 5.2.1 release is at the end of January \ early February." | 09:10 |
| tsdgeos | http://lists.qt-project.org/pipermail/releasing/2013-December/001557.html | 09:10 |
| Mirv | larsu: if you could check (or delegate) gsettings-qt bug #1259145 at some point, it would be nice. maybe some tests shouldn't be run under xvfb? SDK team might have encountered something similar earlier, also | 09:12 |
| ubot5 | bug 1259145 in gsettings-qt "gsettings-qt fails to build (run tests) against Qt 5.2" [Critical,New] https://launchpad.net/bugs/1259145 | 09:12 |
| tsdgeos | Mirv: as said i fixed that | 09:12 |
| tsdgeos | it's nothing about xvfb | 09:12 |
| tsdgeos | it's just that the test was failing | 09:12 |
| larsu | Mirv: I already did, it's fixed in qt | 09:12 |
| larsu | tsdgeos: thanks again for that :) | 09:13 |
| tsdgeos | Mirv: i.e. the x error we get we were getting before (afaics) | 09:13 |
| Mirv | tsdgeos: larsu: oh right I might be confused, there was the another bug report that was filed during RC1. the latest gsettings-qt build from 2012-12-19 failed still: https://launchpadlibrarian.net/160186213/buildlog_ubuntu-trusty-amd64.gsettings-qt_1%3A0.0%2B13.10.20130902.1-0~42.1~ubuntu14.04.1_FAILEDTOBUILD.txt.gz | 09:13 |
| tsdgeos | Mirv: a recent enough snapshot of qtdeclarative stable branch should fix it | 09:13 |
| Mirv | tsdgeos: aha, aha, so that's also one of those that needs newer qtdeclarative? | 09:14 |
| tsdgeos | yes | 09:14 |
| tsdgeos | they totally from QQmlPropertyMap in 5.2.0 | 09:14 |
| tsdgeos | it's far from salvageable | 09:14 |
| Mirv | right, in that case that's the first priority now (well aside from my ir testing) | 09:14 |
| tsdgeos | you need 5.2.1 | 09:14 |
| Mirv | Mir | 09:14 |
| Mirv | thanks. I'll skip qtbase updating for now until there's a known need for a snapshot. | 09:15 |
| Saviq | Mirv, so - we're targeting 5.2.1 then? | 09:16 |
| Mirv | Saviq: we're targeting anything that can get all FTBFS:s fixed and image results as good as with 5.0.x. preferably it would have been 5.2.0 already. | 09:17 |
| Saviq | Mirv, i.e. if stuff works with 5.2.1 but not 5.2.0, are we sad? | 09:17 |
| Saviq | Mirv, yeah, that isn't working apparently :/ | 09:17 |
| Mirv | Saviq: I think it doesn't matter what we use, as long as we can use it without regressions and the 100 source packages all compile neatly against it and everything is full of flowers :) | 09:17 |
| mhr3 | :/ seen that bug already | 09:18 |
| mhr3 | it's some kind of race | 09:18 |
| Mirv | I hope the qtdeclarative will resolve some of the build failures at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages (gsettings-qt is one pre-requirement to move forward) | 09:18 |
| Saviq | Mirv, so you're snapshotting qtdeclarative from the stable branch (5.2.1) now? awesome. | 09:18 |
| Saviq | elopio_, crap, sorry for yanking the bottom bar out from under your feet... :/ | 09:20 |
| Saviq | elopio_, didn't know you were working on that emulator | 09:20 |
| Saviq | elopio_, hopefully this new emulator will be able to use one from the sdk? is there an emulator for tabs in sdk already? | 09:20 |
| Mirv | Saviq: yes | 09:20 |
| Saviq | elopio_, ah, already done! ;) | 09:21 |
| mhr3 | Saviq, mind if we start the preview meeting 15minutes later? | 09:21 |
| Saviq | mhr3, sure | 09:22 |
| Saviq | mhr3, I don't | 09:22 |
| mhr3 | :) moving | 09:22 |
| mzanetti | Saviq: hey, did you come to a conclusion regarding the qml in cmake? | 09:24 |
| Saviq | mzanetti, I don't think I did ;) | 09:25 |
| Saviq | mzanetti, /me looks at the branch | 09:25 |
| mzanetti | Saviq: want me to summarize the possible options again? | 09:25 |
| Saviq | mzanetti, no, I think the only last beef I had was moving it into src/ or something | 09:26 |
| mhr3 | Mirv, you can try to just rebuild, it might just work | 09:26 |
| mzanetti | ah ok. yeah, gerry had the same opinion. I still think qml sources are sources too but I don't really mind as long as I don't have to open 2 project files all the time | 09:27 |
| Mirv | mhr3: well we don't allow flaky tests anyway, so it wouldn't change much even if it would work. but it seems to have failed every time on armhf: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+builds?build_text=unity-scopes-shell&build_state=all | 09:28 |
| Saviq | mzanetti, I think file(GLOB_RECURSE ../qml/*.qml ../qml/*.js) will do what you need | 09:30 |
| mhr3 | Mirv, seeing when it started happening actually helps, thx | 09:30 |
| mzanetti | Saviq: ok. I'll change it | 09:31 |
| Saviq | mzanetti, so leave qml/ be, and just do the GLOB again in src/ | 09:31 |
| mzanetti | Saviq: yep | 09:31 |
| Saviq | mzanetti, and drop .qmlproject then, I think? | 09:33 |
| mzanetti | yep | 09:33 |
| Saviq | mzanetti, http://paste.ubuntu.com/6713876/ | 09:34 |
| Saviq | mzanetti, that works for me | 09:34 |
| Saviq | mzanetti, might want to add .png / .svg etc. | 09:34 |
| Saviq | mzanetti, stuff that qmlproject itself does :/ | 09:35 |
| Mirv | mhr3: ok, great, indeed there is a certain point | 09:35 |
| mzanetti | Saviq: on a first thought I'd say that's not needed, given that we can't really do much with them in the IDE anyways. But I'm not opposed to it | 09:36 |
| Saviq | mzanetti, you can view them at least | 09:37 |
| Saviq | mzanetti, and see a list of them in the project explorer | 09:37 |
| Saviq | mzanetti, which is useful | 09:37 |
| mzanetti | ok | 09:37 |
| Saviq | mzanetti, .png, .svg, .sci | 09:38 |
| Saviq | mzanetti, and see if we have any other | 09:38 |
| mzanetti | ack | 09:38 |
| Saviq | mzanetti, http://paste.ubuntu.com/6713935/ is probably enough... after all we want all files from under qml/ to show up | 09:47 |
| mzanetti | Saviq: true... any idea how to make the importPaths statement work? | 09:48 |
| mzanetti | I tried this, but doesn't seem to work: add_definitions(-DQML_IMPORT_PATH=builddir/plugins:builddir/modules:builddir/tests/plugins:builddir/tests/utils/modules) | 09:48 |
| Saviq | mzanetti, do we actually need that? | 09:49 |
| mzanetti | its not totally essential. but for some plugins we'd get code completion | 09:49 |
| Saviq | mzanetti, that's *if* QtCreator would actually honor that | 09:49 |
| mzanetti | :D | 09:49 |
| Saviq | mzanetti, which I doubt it would | 09:50 |
| mzanetti | for qmake based projects apparently setting QML_IMPORT_PATH should work | 09:50 |
| Mirv | Saviq: would you have some time to test qtdeclarative stable head compilation? at least when combined with our packaging + patches, I'm getting http://pastebin.ubuntu.com/6713954/ (git hash used is there in the directory) | 09:52 |
| Saviq | Mirv, sure, sec | 09:53 |
| Mirv | this is with normal qt 5.2.0 otherwise (qtbase + qtxmlpatterns) | 09:54 |
| Saviq | Mirv, I imagine this says "you need newer qtbase" | 09:55 |
| Mirv | Saviq: I wish even stable branch would be safe from the interdependencies :) | 09:57 |
| Mirv | but sure, I wouldn't be surprised. the referrals failing are to qtdeclarative's own sources, but maybe something in qtbase changed about finding sources. | 09:58 |
| mzanetti | Saviq: https://code.launchpad.net/~mzanetti/unity8/qml-in-cmake-take2/+merge/200793 | 10:13 |
| mzanetti | thanks :) | 10:15 |
| Saviq | mzanetti, still not using colocated branches, btw? ;) | 10:16 |
| mzanetti | nope | 10:16 |
| mzanetti | but my disk space would appreciate it I guess | 10:17 |
| Saviq | Mirv, actually | 10:18 |
| Saviq | Mirv, qtdeclarative compiled fine here | 10:18 |
| Saviq | Mirv, clean chroot with qt5-beta2 | 10:18 |
| mzanetti | Saviq: where did you get the plugin from? | 10:20 |
| Saviq | mzanetti, lp:~fboucault/bzr-colo/colo-push/ for some reason | 10:20 |
| Saviq | mzanetti, but lp:bzr-colo is probably a better source | 10:21 |
| dandrader | tsdgeos, about the horizontalJournal Q_ASSERt | 10:22 |
| dandrader | tsdgeos, I thought that the signal would only be emitted if the operation was async | 10:22 |
| tsdgeos | nope | 10:22 |
| dandrader | therefore that slot would only be called in the async case | 10:22 |
| mhr3 | Saviq, you in a call already? | 10:22 |
| Saviq | mhr3, no | 10:22 |
| tsdgeos | dandrader: nope | 10:22 |
| tsdgeos | dandrader: which Q_ASSERT in horizontalJournal ? | 10:23 |
| tsdgeos | ignore me | 10:23 |
| tsdgeos | can't read | 10:23 |
| tsdgeos | ok | 10:23 |
| tsdgeos | :D | 10:23 |
| dednick | is s-jenkins down? | 10:28 |
| mzanetti | dednick: works for me | 10:29 |
| dednick | mh. | 10:29 |
| dandrader | tsdgeos, that one in itemCreated slot | 10:30 |
| tsdgeos | yes yes | 10:30 |
| dednick | stupid dns thing again... sigh | 10:31 |
| tsdgeos | dandrader: was lost in the way you built the sentence and how my brain read it | 10:31 |
| * mzanetti wishes we could wake up the screen by double tapping it | 10:49 | |
| Mirv | Saviq: hrm! | 11:11 |
| === daek_ is now known as Daekdroom | ||
| dednick | mzanetti: any idea? https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/832/console | 11:39 |
| mzanetti | dednick: I've seen the same in one of my branches. So far I hoped it's temporary woes... seems not :/ | 11:39 |
| mzanetti | Saviq: ^ ? | 11:40 |
| Saviq | hmmmpf | 11:41 |
| mhr3 | isn't that debian saying "you really need to bump the version"? | 11:41 |
| Saviq | mzanetti, why does qmluitests build the package at all? | 11:41 |
| Saviq | mhr3, yeah it kind of is | 11:41 |
| Saviq | mhr3, but why would it suddenly start now? | 11:42 |
| Saviq | TBH I never understood when dpkg starts complaining about that | 11:42 |
| mhr3 | error: ... binary file contents changed | 11:42 |
| mzanetti | Saviq: we've always built the package for qmltests | 11:43 |
| Saviq | mhr3, ah, so you're saying it doesn't care until you change a binary file? | 11:43 |
| === _salem is now known as salem_ | ||
| mhr3 | Saviq, i'm no debian pro, but seems that way | 11:43 |
| Saviq | interesting... | 11:44 |
| === dandrader is now known as dandrader|afk | ||
| dednick | wtf. my character map just changed, but it's still showing correct layout in region settings | 11:46 |
| Saviq | mzanetti, so what we're missing probably is bumping the version before building the package | 11:46 |
| Saviq | mzanetti, but why do we build the package at all? | 11:46 |
| mzanetti | Saviq: that was the most straight forward way to get it done in jenkins | 11:46 |
| dednick | funny thing is, i only have uk english installed... weird | 11:46 |
| Saviq | mzanetti, but that doesn't build the mocks etc. does it? | 11:47 |
| mzanetti | Saviq: sure it does. it's installed into the unity8-fake-env package | 11:47 |
| Saviq | mzanetti, I'm not sure that's true - not for *all* the mocks at least | 11:49 |
| Saviq | mzanetti, anyway | 11:49 |
| mzanetti | hmm, ok. I might miss something | 11:49 |
| Saviq | mzanetti, do you have access to the job? | 11:49 |
| mzanetti | yes, I do | 11:49 |
| Saviq | mzanetti, the pbuilderjenkins command | 11:50 |
| Saviq | mzanetti, doesn't use the hooks as defined in the job | 11:50 |
| Saviq | mzanetti, if that's on purpose, add H05set_package_version there and we should be good | 11:51 |
| mzanetti | Saviq: added | 11:51 |
| Saviq | mzanetti, dednick restarted the job, will be at http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-trusty/834 | 11:52 |
| mzanetti | dednick: I restarted your job. lets see what happens | 11:52 |
| mzanetti | oh | 11:52 |
| dednick | ta | 11:52 |
| === dandrader|afk is now known as dandrader | ||
| mzanetti | looks better, yes | 12:00 |
| mzanetti | Saviq: I've changed the job to inherit hooks from upstream jobs and just add the B09qmltests etc | 12:03 |
| Saviq | mzanetti, yup | 12:03 |
| mzanetti | lets hope I didn't break it. You'll know where to find me in that case | 12:03 |
| Saviq | mzanetti, I DO KNOW WHERE TO FIND YOU! | 12:04 |
| mzanetti | :D | 12:04 |
| * mzanetti hides | 12:04 | |
| Saviq | mzanetti, http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-trusty/834/console | 12:11 |
| Saviq | Started by user Saviq | 12:11 |
| Saviq | Started by user mzanetti | 12:11 |
| Saviq | interesting ;D | 12:11 |
| Saviq | must be we triggered the exact same configuration and jenkins combined that into one | 12:12 |
| mzanetti | heh | 12:13 |
| mzanetti | I'd rather bet on a bug in jenkins :D | 12:13 |
| Saviq | /food | 12:22 |
| Saviq | tsdgeos, hJournal ready for merging or are you searching for the assert? | 12:43 |
| tsdgeos | Saviq: ready for merging | 12:43 |
| tsdgeos | i forgot to check the failure and reapprove | 12:43 |
| Saviq | tsdgeos, k | 12:44 |
| tsdgeos | test_show_hud_button_appears ? | 12:44 |
| tsdgeos | weird | 12:44 |
| tsdgeos | let's see next run | 12:44 |
| Saviq | tsdgeos, yeah, it does fail sometimes | 12:45 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g|lunch | ||
| Mirv | Saviq: one of these days I learn to attribute all mysterious immediate failures to syncqt when snapshot builds don't work | 13:22 |
| mzanetti | deleting the hud-service binary wasn't such a good idea :/ | 13:24 |
| Saviq | Mirv, ;) | 13:25 |
| Saviq | mzanetti, btw, we've missed ../tests/*qml ../tests/*js :/ | 13:25 |
| mzanetti | Saviq: true. I'll fix | 13:26 |
| === alan_g|lunch is now known as alan_g | ||
| tsdgeos | kgunn: you increased the dependency of unity-mir to mir* 0.1.3 but that's still not out, no? | 14:02 |
| tsdgeos | greyback: ok, https://code.launchpad.net/~aacid/unity-mir/application_manager_tests/+merge/180898 should be ready | 14:07 |
| tsdgeos | CI is failing to compile because the ↑↑↑ change | 14:07 |
| greyback | tsdgeos: \o/ thanks!! | 14:07 |
| tsdgeos | if you want to try now in the phone | 14:08 |
| tsdgeos | just do | 14:08 |
| tsdgeos | - libmirserver-dev (>= 0.1.3), | 14:08 |
| tsdgeos | - libmirclient-dev (>= 0.1.3), | 14:08 |
| tsdgeos | + libmirserver-dev (>= 0.1.2), | 14:08 |
| tsdgeos | + libmirclient-dev (>= 0.1.2), | 14:08 |
| tsdgeos | on the control file | 14:08 |
| tsdgeos | it worked for me | 14:08 |
| greyback | tsdgeos: ok | 14:13 |
| elopio_ | Saviq: I was trying to use the tab bar from ubuntu ui toolkit, but it causes a couple of problems. The biggest is that when trying to open the files & folders scope, it tries to click on the right border of the screen and nothing happens there. | 14:17 |
| elopio_ | I need to make a workaround on the toolkit emulator before it's usable by unity. | 14:17 |
| === elopio_ is now known as elopio | ||
| kgunn | tsdgeos: yes...release team is testing new mir, so they had to approve and push the bump | 14:19 |
| kgunn | it should be over soon (and hopefully mir out soon) | 14:20 |
| tsdgeos | great | 14:20 |
| tsdgeos | ;) | 14:20 |
| Saviq | elopio, ack | 14:21 |
| elopio | Saviq: but I need help from my branch, on mako there are failures that don't seem related to my branch. I was hoping to find aacid here today. | 14:21 |
| Saviq | elopio, tsdgeos === aacid | 14:22 |
| Saviq | he's crypto, we know | 14:22 |
| Saviq | ;) | 14:22 |
| * tsdgeos hides behind his nicks | 14:22 | |
| tsdgeos | elopio: need help? | 14:22 |
| tsdgeos | Saviq: remember we talked about the "Please enter SIM PIN" text a while ago? | 14:22 |
| Saviq | tsdgeos, not really, wassup? | 14:23 |
| tsdgeos | Saviq: basically you said "it should come from the indicator" | 14:23 |
| tsdgeos | but it's still there | 14:23 |
| elopio | tsdgeos: \o/ I found you! | 14:23 |
| Saviq | tsdgeos, right | 14:23 |
| elopio | let me get something to drink and wake up a little, and I'll start bothering you :) | 14:23 |
| Saviq | tsdgeos, file a bug please? | 14:23 |
| tsdgeos | Saviq: shall i open a bug or something so someone maybe acts on it | 14:23 |
| Saviq | tsdgeos, ↑ that | 14:24 |
| tsdgeos | Saviq: against what? unity8? or? | 14:24 |
| Saviq | tsdgeos, affects unity8 and indicator-network | 14:24 |
| tsdgeos | okidoki | 14:24 |
| tsdgeos | man i ate too much of my fake chocolate cava bottle :D :( :-S | 14:26 |
| * mzanetti googles chocolate cava bottle | 14:29 | |
| tsdgeos | http://www.badamelos.com/1177-large_default/botellas-cava-benjamin-chocolate.jpg | 14:30 |
| tsdgeos | mzanetti: ↑↑ | 14:30 |
| mzanetti | lol | 14:30 |
| mzanetti | leftover from new years eve? | 14:30 |
| tsdgeos | yep | 14:31 |
| Saviq | greyback, mterry_, standup | 14:31 |
| greyback | mzanetti: thanks :) When I reboot, or suspend/resume, PA thinks sound is at the usual place, but is actually 0. If I wiggle the mic volume, it then works | 14:37 |
| mzanetti | greyback: yeah... try a "asoundctl store" with non-muted settings | 14:38 |
| === dandrader is now known as dandrader|lunch | ||
| tsdgeos | Saviq: https://bugs.launchpad.net/indicator-network/+bug/1267135 | 14:42 |
| ubot5 | Ubuntu bug 1267135 in Unity 8 "network-indicator should provide the "Please enter SIM PIN" text" [Undecided,New] | 14:42 |
| elopio | I'm back. tsdgeos, please let me know when you have some time, it seems I'll need more help than what I thought. | 14:44 |
| tsdgeos | elopio: now is a good moment | 14:45 |
| elopio | tsdgeos: the dashContentList has a currentIndex property. My problem is that the QQuickLoader and the GenericScopeViews don't have an index. | 14:47 |
| elopio | so I have no way to tell which is the currently selected scope. | 14:47 |
| elopio | I was assuming that the order of the list would give me the right index, but on mako where the music scope is to the left, my assumption breaks. | 14:47 |
| tsdgeos | elopio: the current scope is the one of the currentIndex? | 14:48 |
| tsdgeos | dashContent.model list the order of them | 14:49 |
| tsdgeos | which is actually the list of visible scopes | 14:50 |
| tsdgeos | as returned by Scopes | 14:50 |
| elopio | let me see if autopilot can access that. | 14:50 |
| tsdgeos | elopio: what do you want to find out actually? name? or something else? | 14:50 |
| elopio | tsdgeos: well, what I need is a way to know what's the index of a scope. On the toolkit tabs I had the same problem, and they fixed it adding the a new tabIndex property to every tab. | 14:51 |
| tsdgeos | elopio: as said the index of a scope is it's index in the list of visible scopes | 14:52 |
| tsdgeos | i.e. whatever is sorting scopes it's not the ui | 14:52 |
| elopio | tsdgeos: right. The problem seems to be that the list of scopes returned by autopilot is not on the same order. | 14:55 |
| elopio | (Pdb) p self.dash.dash_content_list.currentIndex | 14:55 |
| elopio | 1 | 14:55 |
| elopio | (Pdb) p self.scope_loaders[1].scopeId | 14:55 |
| elopio | u'music.scope' | 14:55 |
| elopio | there's the problem, because the selected scope at this moment is 'home.scope' | 14:56 |
| elopio | so we shouldn't rely on the order of elements that autopilot returns. | 14:56 |
| tsdgeos | what's scope_loaders ? | 14:57 |
| tsdgeos | i.e. who provides that info? | 14:57 |
| tsdgeos | and is self.scope_loaders[0] marked as visible or not? | 14:58 |
| elopio | tsdgeos: self.scope_loaders = self.dash.dash_content_list.select_many('QQuickLoader') | 14:58 |
| tsdgeos | ok | 14:59 |
| elopio | tsdgeos: and all of them always have visible=True, we can't rely on the visible property. | 14:59 |
| tsdgeos | so select_many is not giving you stuff in the corect order | 14:59 |
| elopio | (Pdb) p self.scope_loaders[1].visible | 14:59 |
| elopio | True | 14:59 |
| elopio | (Pdb) p self.scope_loaders[0].visible | 14:59 |
| elopio | True | 14:59 |
| tsdgeos | which given the name seems even reasonable | 14:59 |
| elopio | yes. But according to thomi, autopilot just returns the elements on the same order of the QML tree it sees. | 15:02 |
| elopio | as we have seen before, and now again, it seems a bad idea to rely on the order of the elements of the tree. | 15:02 |
| tsdgeos | so again, what do you need? | 15:02 |
| tsdgeos | know the current scope? | 15:02 |
| tsdgeos | maybe match it against the name of the selected tab? | 15:03 |
| tsdgeos | or that is what you're trying to test? | 15:03 |
| elopio | tsdgeos: not just know the current scope, I could use the isCurrent property for that. | 15:04 |
| elopio | I need to know the order of them, so I scroll to the left if the index I need is lower than the currently selected one, and scroll to the right if the index is higher. | 15:04 |
| tsdgeos | well then you can use the tabs? | 15:07 |
| tsdgeos | i think the tabs has getters | 15:07 |
| tsdgeos | let me see | 15:07 |
| tsdgeos | maybe not | 15:07 |
| elopio | tsdgeos: I found the bug and branch for the same problem on the toolkit: | 15:07 |
| elopio | https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1233402 | 15:07 |
| ubot5 | Ubuntu bug 1233402 in Ubuntu UI Toolkit "The Tab needs a tabIndex property" [Critical,Fix released] | 15:07 |
| tsdgeos | booo | 15:07 |
| tsdgeos | ok | 15:07 |
| tsdgeos | :D | 15:07 |
| elopio | tsdgeos: I could use the tabs instead of scrolling, but first I need to implement some changes on its emulator. | 15:07 |
| tsdgeos | elopio: so you want to do the change by swiping i guess, it's not ok that we add a switchToScope function | 15:08 |
| elopio | tsdgeos: sorry, I didn't get that last part. | 15:09 |
| tsdgeos | elopio: Dash.qml has a "function setCurrentScope" | 15:10 |
| tsdgeos | can you use that? | 15:10 |
| elopio | tsdgeos: no, with autopilot it all should be black box. | 15:10 |
| tsdgeos | or you want to trigger the change "emulating the user touch presses"? | 15:10 |
| tsdgeos | ok | 15:10 |
| elopio | I need to set the current scope only using the pointer. | 15:10 |
| tsdgeos | does autopilot know how to query models? | 15:11 |
| tsdgeos | if so i think that querying filteredScopes would be useful to get the order of things | 15:11 |
| tsdgeos | if not, someone should make autopilot able to introspect the models :D | 15:12 |
| elopio | tsdgeos: I think that's not possible. That's information that QML doesn't expose through the testability feature, that's what autopilot uses. | 15:14 |
| elopio | tsdgeos: but if you look at zsombi's branch: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/tab-index/+merge/188769 | 15:14 |
| elopio | it doesn't seem like a big change on the model | 15:14 |
| elopio | I don't know enough QML to do it myself on this case, though. | 15:14 |
| mzanetti | greyback: could we sort the appmanager model in a way that the focused one is at index 0? | 15:16 |
| tsdgeos | elopio: i'm understanding you can't access the attached properties of the listview deleagtes, no? | 15:16 |
| tsdgeos | elopio: i.e. i can use "index" inside a QML listview item | 15:16 |
| tsdgeos | and it'll give me the index | 15:16 |
| elopio | tsdgeos: I can access things like isCurrent and scopeId, but no, index doesn't seem to be available. | 15:18 |
| elopio | tsdgeos: have you used autopilot vis? | 15:18 |
| greyback | mzanetti: that should be the case already | 15:18 |
| tsdgeos | i used it once when all the stars aligned | 15:18 |
| elopio | it shows the QML tree as autopilot sees it. So those are the only things we can use. | 15:18 |
| mzanetti | greyback: seems not... | 15:18 |
| tsdgeos | errrrr, is everybody getting the tabs to show in unity8? | 15:18 |
| mzanetti | greyback: the first app I launch is always at 0 | 15:18 |
| greyback | mzanetti: but I don't see the code to do it either | 15:18 |
| tsdgeos | they don't show here :-S | 15:18 |
| * tsdgeos does a clean build | 15:18 | |
| greyback | mzanetti: suspect unity8 doing it | 15:19 |
| elopio | tsdgeos: I can see them. They work nicely here. | 15:19 |
| mzanetti | gnaaa | 15:19 |
| mzanetti | greyback: ok... I'll try to change it in my screenshotting-focusing branch | 15:19 |
| greyback | mzanetti: no objection here | 15:20 |
| tsdgeos | ok, tabs are here now, maybe needed a clean build | 15:21 |
| tsdgeos | elopio: let me try to run the visualizer | 15:21 |
| elopio | thanks tsdgeos. Take a look at the TabBar inside the PageHeader. It has a selectedIndex property. And then the AbstractButtons children of that TabBar have a buttonIndex property. | 15:22 |
| elopio | that's what I need. With those properties, I don't need to rely on the order of the children as autopilot sees them. | 15:23 |
| tsdgeos | sure | 15:25 |
| tsdgeos | adding the property is trivial | 15:25 |
| tsdgeos | it's just that i'd prefer not to add extra code just for the testing | 15:25 |
| tsdgeos | elopio: maybe you can use the "x" property of the loaders to sort them? | 15:25 |
| elopio | tsdgeos: I could use that. Let me try to see if it gets ugly. | 15:30 |
| === alan_g is now known as alan_g|tea | ||
| === rachelliu_ is now known as rachelliu | ||
| === alan_g|tea is now known as alan_g | ||
| elopio | tsdgeos: that will work nicely :) thank you. | 15:49 |
| elopio | when is your EOD? | 15:49 |
| tsdgeos | cool \o/ | 15:50 |
| tsdgeos | in 1:10h aprox | 15:50 |
| tsdgeos | 6pm spain time | 15:50 |
| elopio | tsdgeos: I have a meeting now, so I probably won't be able to finish my branch by then. Can you please take a look tomorrow? | 15:58 |
| elopio | https://code.launchpad.net/~elopio/unity8/open_scope/+merge/200426 | 15:59 |
| tsdgeos | sure | 16:00 |
| tsdgeos | Saviq: so i was thinking about the organic grid for the Dash vs the one in the gallery. Ours is always visible in full width and is designed to scrolls vertically while the one in the gallery is always full height and designed to scroll horizontally. That's not a radical problem, but introduces a few else/ifs here and there, want me to code directly for both or just catter our needs at first stage and improve later? | 16:05 |
| === dandrader|lunch is now known as dandrader | ||
| === boiko_ is now known as boiko | ||
| kgunn | mterry_: ping | 17:06 |
| mterry_ | kgunn, hello | 17:06 |
| kgunn | mterry_: hey hope you're feeling better.... | 17:06 |
| kgunn | got a question for you that i should already know :) | 17:06 |
| mterry_ | kgunn, OK | 17:06 |
| kgunn | so i was cleaning up some wiki stuff....for unity8 | 17:06 |
| kgunn | and greeter section referenced | 17:07 |
| kgunn | https://launchpad.net/unity-greeter | 17:08 |
| kgunn | but isn't the greeter in unity8 now ? | 17:08 |
| kgunn | mterry_: ^ | 17:08 |
| mterry_ | kgunn, yes. The phablet greeter is in unity8 | 17:08 |
| mterry_ | kgunn, unity-greeter is the old greeter | 17:08 |
| mterry_ | "old" | 17:08 |
| kgunn | mterry_: ok...that's what i tho | 17:09 |
| kgunn | t | 17:09 |
| kgunn | mterry_: so even after you land the split...it'll still be the phablet greeter in use right ? | 17:09 |
| mterry_ | kgunn, yes | 17:10 |
| kgunn | mterry_: thanks...i'll make it match | 17:11 |
| mterry_ | kgunn, same source package (unity8) but new binary package (unity8-greeter) | 17:11 |
| kgunn | ;) | 17:11 |
| kgunn | mterry_: curious...why is it delivered in a bin like that ? | 17:11 |
| kgunn | at least the unity-greeter | 17:11 |
| mterry_ | kgunn, I don't follow | 17:11 |
| kgunn | oh nvmd...i see... | 17:12 |
| kgunn | mterry_: ignore me | 17:12 |
| mhall119 | Saviq: has there been any progress on building Unity 8 on Saucy? | 17:18 |
| === jhodapp is now known as jhodapp|bbiab | ||
| === jasoncwarner__ is now known as jasoncwarner | ||
| Saviq | mhall119, there's more data on the failures, so hopefully it'll get better soon | 17:38 |
| greyback | fginther: hey, can I book some CI expert time for unity-mir. We've a branch that adds tests, which must run in an environment where Mir can execute. We need a hand to set up CI to deal with that | 18:06 |
| === alan_g is now known as alan_g|EOD | ||
| === jhodapp|bbiab is now known as jhodapp | ||
| fginther | greyback, I can help but I'll need to get back to you later, I have some fires to put out | 19:12 |
| greyback | fginther: sure, it's far from urgent | 19:13 |
| karni_ | Saviq: If there are any conventions on the team I didn't follow, just lemme know :) https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910 | 20:54 |
| === karni_ is now known as karni | ||
| Saviq | karni, cheers | 21:03 |
| Saviq | karni, jest już test "test_art_size_data" | 21:04 |
| Saviq | ooh english ;) | 21:04 |
| Saviq | karni, there's already test_art_size_data | 21:05 |
| * karni paczy ;D | 21:05 | |
| Saviq | karni, would make sense to build test_art_image_size into it | 21:05 |
| Saviq | karni, "card-size": "medium" is unsupported (and ignored, for that matter) in horizontal layout - not sure we should test that... or maybe we should, but add a "small" one, too | 21:06 |
| karni | Saviq: oh okay. I needed any size, I can replace that with small, as all sizes are covered in previous tests, right? | 21:07 |
| Saviq | karni, why did you need a size? | 21:07 |
| === salem_ is now known as _salem | ||
| Saviq | karni, what I mean is: in horizontal layout, the card-size setting is ignored - so we should either test that setting it doesn't matter, or not set it at all | 21:08 |
| karni | Saviq: I looked at the code, seems I could have gone with the default | 21:08 |
| karni | Saviq: I'll remove that, yes | 21:09 |
| Saviq | karni, for test_card_horizontal_layout, you're only checking for width, so integrating into test_card_size should work | 21:09 |
| karni | Saviq: I think I wanted it to test the width/height of the artImage, but we decided that need not to be tested | 21:09 |
| karni | Saviq: agreed on first and last comment, too. fixing. | 21:10 |
| Saviq | karni, I'd rename test_*_anchors into test_*_layout, as we're not actually checking the anchors | 21:11 |
| karni | Saviq: agree :) | 21:11 |
| Saviq | karni, and now... .left/right/top/bottom are anchor lines | 21:12 |
| Saviq | karni, not pixel values | 21:12 |
| Saviq | karni, so test_header_anchors should actually fail | 21:12 |
| * karni looks | 21:12 | |
| karni | Saviq: the last test? I'm not actually using anchors, the test name was confusing. | 21:13 |
| Saviq | karni, that's the thing - you are ;) | 21:13 |
| karni | let me do the art test refactor, and I'll push, so we're on the same page :) | 21:14 |
| Saviq | karni, header.top, header.left are anchor lines (not anchors, but something that can be attach to anchors) | 21:14 |
| Saviq | or something that anchors can attach to | 21:14 |
| * karni nods | 21:14 | |
| Saviq | karni, so in the last test you're comparing header.top to art.bottom, for example | 21:15 |
| karni | may have gone blindfolded a bit | 21:15 |
| karni | + top: template && template["card-layout"] === "horizontal" ? artShape.top : artShape.bottom | 21:16 |
| Saviq | karni, that's header.anchors.top, not header.top | 21:16 |
| Saviq | which are two distinct anchor lines - what I mean is that if you revert the changes to Card.qml, the test will still pass (assuming it passes now) | 21:16 |
| karni | ooooh right! | 21:16 |
| karni | Saviq: lemme fix that :) thanks for the super fast review :D | 21:16 |
| Saviq | karni, so yeah, you can't compare anchor lines of different objects | 21:16 |
| Saviq | karni, so you should look at x/y/width/height instead | 21:17 |
| Saviq | adding where necessary | 21:17 |
| karni | yes, all tests pass, but I obviously failed there with that anchor bit | 21:17 |
| Saviq | karni, shelve changes to qml/ and run your tests suite again - make sure that all tests that should fail - do | 21:18 |
| karni | Saviq: regarding your first/second comment about integrating test_art_image_size into test_art_size, I'd have to name properties like "imageWidth" and "imageHeight" because most of test_art_size concerns art, while I'm testing artImage | 21:19 |
| karni | So.. does it in fact make sense to pull this test into test_art_size? | 21:19 |
| karni | test_art_size tests width/height of testCase.art, while test_art_image_size tests width/height of testCase.artImage | 21:20 |
| karni | (FWIW, bit confusing terminology ;D) | 21:20 |
| karni | good suggestion. it did feel weird to write tests after the code ;D | 21:20 |
| Saviq | karni, I know, sorry for that ;) | 21:22 |
| Saviq | karni, was easier to write the code than tests ;D | 21:22 |
| karni | Saviq: no worries, I know how fun it is to improve/fix things :D | 21:22 |
| karni | haha, happy I can help (and learn!) | 21:22 |
| Saviq | karni, you shouldn't be testing artImage's size at all, as that component isn't even visible - the UbuntuShape around it is what we care for | 21:23 |
| karni | Saviq: may have gone overboard trying to cover every line of your code ;D | 21:24 |
| Saviq | karni, so yeah, there's only one additional entry to test_card_size_data that should be added | 21:25 |
| karni | Saviq: yes, fixed that | 21:25 |
| Saviq | karni, yeah, coverage for QML (or UI, for that matter) is unfortunately an arbitrary thing | 21:25 |
| karni | haven't pushed yet, want to fix those anchors/pixels thing you noticed | 21:25 |
| Saviq | karni, cheers | 21:25 |
| karni | :) | 21:25 |
| karni | Thank you! | 21:25 |
| Saviq | karni, aren't you past EOD yourself, btw? | 21:25 |
| karni | Saviq: You working from Poland? | 21:26 |
| Saviq | karni, we're not talking about me here, are we now :P | 21:26 |
| karni | Saviq: I wonder, why would you ask hahahahah | 21:26 |
| * karni laughs | 21:26 | |
| * Saviq → food | 21:26 | |
| Saviq | karni, just leave it here if you have more, will reply when around the keyboard later | 21:27 |
| karni | Saviq: thanks! :) | 21:27 |
| karni | Saviq: updated the MP. Left one 'XXX', can't get that line in test_header_layout to pass. I'll get something to eat and will try the shelves that you suggested to make sure stuff would fail where it should. | 21:52 |
| Saviq | karni, a) test_art_layout is bad, tryCompare takes three arguments: object, propertyName, timeout | 22:04 |
| Saviq | so tryCompare(testCase.header.x, data.headerLeft, data.value); is bad | 22:04 |
| Saviq | not to mention data.headerLeft and data.value are undefined | 22:05 |
| Saviq | karni, as for the other thing... the problem is that the card is laid out only when the test is executed, the _data() function is called before that, on the default layout, so art.width is 148 then, but when you select index 5, it becomes 80 | 22:06 |
| Saviq | but data.left is already evaluated with 148, so the test fails | 22:07 |
| Saviq | karni, http://paste.ubuntu.com/6717510/ fixes | 22:22 |
| Saviq | karni, actually make that http://paste.ubuntu.com/6717513/ | 22:23 |
| karni | Saviq: wow.. I'm surprized I wasn't thrown at that .headerLeft was not defined (I did change the name, missed that one). and tests still passed. not reassuring :( | 22:59 |
| karni | Saviq: fixed along your diff, appreciated https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910 | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
