[00:04] anybody know if there's a way to run Unity Next on my laptop, but then launch an SDK App inside of it? === salem_ is now known as _salem === jono is now known as Guest15458 [07:22] good morning [07:23] hey mzanetti! [07:23] hey didier [07:38] sil2100: hey, just on the autopilot failures - it was a local problem [07:38] sil2100: but probably something you should be aware of [07:38] I think gdk is doing the wrong thing in gdk_screen_get_n_monitors () [07:38] it returns the number of monitors currently plugged in, not the number of monitors the desktop actually spans [07:39] so there were some non-obvious failures coming from that [07:39] (I had a mirrored display FWIW) [07:39] but anyways, there were some failures like [07:39] smspillaz: ah! [07:39] it would detect 2 monitors, and then try and get the second launcher [07:39] and return None [07:39] and then tests would fail [07:40] or there would be asserts on the number of panels [07:40] etc [07:40] sil2100: anyways, I unplugged the other monitor and it works fine now [07:40] and added a note in the readme [07:40] smspillaz: I think I know about that one, but forgot filling out a bug - since indeed I saw those failures on my guest session when using mirrored displays, that's why I always disable that when testing [07:40] smspillaz: and guest session mirrors the displays by default when I have a monitor attached [07:40] sil2100: it might be better to ask unity how many monitors there are [07:41] sil2100: because for example, you can configure compiz to pretend to be multi-monitor when in fact there's only one [07:41] etc [07:43] sil2100: relevant https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1170013/+merge/159422 [08:07] didrocks, hi :) [08:07] hey MCR [08:08] didrocks, I would like to remove the quilt patch from EZoom xml. [08:08] MCR: is it upstream? [08:09] The ubuntu quilt patch just removes 4 shortcuts from EZoom. [08:09] MCR: right [08:09] No, it will affect Ubuntu [08:09] but not really [08:09] MCR: so no, this patch is there for a usability reason [08:09] as EZoom is turned off by default [08:09] MCR: usability testing showed that people hit that by mistake [08:09] then, they feel "stuck" [08:10] and reboot their machine [08:10] not a nice experience :/ [08:10] hence the patch [08:10] how can someone hit this by mistake ? [08:10] MCR: it seems it happens a lot [08:10] you have to enable EZoom manually first [08:10] especially super + scrollwheel [08:10] MCR: it's enabled by default [08:10] ah [08:10] my fault then [08:10] no worry :) [08:11] How about changing the upstream shortcuts to something else then ? [08:11] MCR: I think the shortcut makes default [08:11] I wonder if anyone could think whether there'd be some ~easy fix to https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/932520 on precise? [08:11] Launchpad bug 932520 in compiz (Ubuntu Precise) "Some windows on start up don't show full window" [High,Triaged] [08:11] MCR: what is missing a system settings option to enable them [08:12] Mirv: discussed at UDS, nobody tackled it [08:12] didrocks, it is completely useless to have an enabled EZoom without any shortcuts... [08:12] that compiz bug has a history of being marked erronously as fixed etc, but still there [08:12] why is it enabled in the first place ? [08:12] MCR: the idea is to avoid people enabling/disabling plugin (which is risky) [08:12] then, having an option to enable the shortcuts [08:12] MCR: want to tackle that? :) [08:12] didrocks, soon it won't be risky anymore [08:13] didrocks: oh ok. for me it's a bit unclear how big change in the "famous work branch" was the part that fixed that part. since it seems it could be something relatively easy related to coordinates after all, if one just understood what's going on. [08:13] sil2100: according to bug comments you also took a hard look at it a year ago :) [08:13] Mirv: sorry, wrong M[Tab], again :/ [08:14] Mirv: was talking to MCR [08:14] Mirv: I think I know what that was hang on [08:14] Mirv: is it still happening in precise ? [08:15] didrocks: :P [08:15] smspillaz: yes, it's still there with the Shotwell in particular [08:15] Mirv: ;) The problem was that it wasn't reproducible on my machine, so I was experimenting in the dark [08:15] I guess this was the commit that fixed it http://bazaar.launchpad.net/~compiz-team/compiz/0.9.8/revision/3110 in the 0.9.8 branch [08:16] sil2100: it may be you didn't try out shotwell, it seems that's the most trustworthy one (at least I experience it on fglrx machine, radeon machine and I think I had it on intel machine as well) [08:16] didrocks, I want to reduce Ubuntu-distro-patches against Compiz to a minimum... it makes changes to .xml.in files and code to a small horror-trip ;) [08:16] MCR: its pretty easy to test those patches [08:16] export QUILT_PATCHES=debian/patches; quilt push -fa [08:17] (fix failures) [08:17] quilt refresh [08:17] quilt op -fa [08:17] *pop [08:17] MCR: take them upstream is another solution ;) [08:17] smspillaz, it is not so easy if I change the whole .xml.in file upstream... [08:17] MCR: trust me, it used to be a massive PITA before we had inline packaging [08:17] smspillaz, I trust you, but [08:18] IT IS A HORROR TRIP [08:18] Mirv: not sure now [08:18] quilt apply and refresh them where appriate [08:18] *erm, just apply [08:18] it takes like [08:18] 2 minutes [08:18] didrocks: I jump out now for some errands again, buying insurance and such for the trip - be back soon [08:18] sil2100: ok [08:18] Mirv: hmm, did that revision ever go into precise ? [08:18] interestingly that patch (http://bazaar.launchpad.net/~compiz-team/compiz/0.9.8/diff/3110) applies just fine on top of 0.9.7, but it's a huge patch of course [08:18] (r3110)? [08:19] guess not [08:19] smspillaz: no, that's the thing, it was the work branch that became 0.9.8 [08:19] Mirv: you might also want a few other things too [08:19] smspillaz, could you do it then once successfully and print me the commands you used ? [08:19] smspillaz: yeah, I was fearing you might say that ;) there's that problem of SRUability [08:20] smspillaz, here it would be perfect: https://code.launchpad.net/~mc-return/compiz/compiz.merge-ezoom-cleanup/+merge/159991 [08:22] MCR: I already said how to do it? [08:22] cd into the root project directory [08:22] export QUILT_PATCHES=debian/patches [08:22] quilt push -fa [08:22] smspillaz, yes -> but it will not work correctly that way... [08:22] *find the .rej files, fix the original files as though the distro patches were applied* [08:22] ^^^ important step! [08:22] quilt refresh [08:23] quilt push -fa [08:23] quilt pop -fa [08:23] probably it was that step that was missing [08:23] *urgh* [08:24] I updated the bug report. I don't think the route of trying to apply both that and some other commits from 0.9.8 to 0.9.7 is going to work. it simply becomes too big. there would be a need of a simpler patch to 0.9.7 that only addresses that drawing problem and is more verifiably not causing regressions. [08:25] Mirv: I'll grab the bits you need hang on [08:25] its a small part of like 2 commits [08:27] smspillaz: ok, thank you, can you update those to the report? do you think all of that 3110 is needed to address #932520, or could some smaller subset of it address that bug alone (and not #862430, #892012, #923683)? [08:27] Mirv: I'd recommend taking all of 3110 if possible [08:28] there were just two other potential regressions I fixed later [08:28] smspillaz: yeah, if that's the only possibility then that's the only choice to evaluate. it might be too much. [08:28] I'm just trying to find the subcommits for them [08:28] Mirv: I'd say its worth putting out for testing at least [08:28] smspillaz: true, via a PPA [08:29] if only we could backport the testsuite :p [08:29] :) [08:29] (Wouldn't suggest it, its like 15000 lines) [08:38] ah man, this is why I don't like trunk reverts [08:38] * smspillaz had been looking at the wrong rev the whole time [08:45] smspillaz, I want to update showmouse and firepaint to use GL_TRIANGLE_FAN instead of GL_TRIANGLES -> it will then just need 4 vertices instead of 6 to make a quad, am I correct ? [08:46] MCR: prefer GL_TRIANGLE_STRIP if possible [08:46] GL_TRIANGLE_FAN is really only there for rendering spheres [08:46] GL_TRIANGLE_STRIP works like this: [08:46] 1----2 [08:46] / [08:46] / [08:47] / [08:47] 3 [08:47] -----4 [08:47] yeah okay, expressing ascii art over irc doesn't work very well [08:47] hehe [08:47] in any case, you need to be careful with both TRIANGLE_FAN and TRIANGLE_STRIP . They are both continuous primitives [08:48] so they only open at one and and close at another [08:48] as opposed to triangles which are always closed on each primitive [08:49] well -> you mentioned once (when the GLES port was made) that STRIP would be better and it would really be more efficient... [08:50] but FAN would imho be quite ideal for a quad also [08:50] well -> I will simply test it extensively [08:51] well, at least for four vertices TRIANGLE_STRIP and TRIANGLE_FAN work the same way [08:51] ah -> yes [08:51] the winding is just different that's all [08:51] okidoki [08:51] if you went tl, tr, bl, br it would go something like [08:51] 1,3,2,4 for STRIP [08:52] and 1,2,3,4 for FAN [08:52] its just easier if you emulate quads by doing STRIP as it makes more sense concentually [08:52] *conceptually [08:52] that GL stuff is quite mighty, but fun [08:52] OpenGL is like the worlds worst API [08:52] ok -> I take STRIP then [08:53] hehe [08:53] Mirv: yeah, now that I've looked into it pulling in any more revs looks complicated [08:53] smspillaz, I thought it is the world's most advanced 3d API ;) [08:53] Mirv: feel free to test 3110 . I don't think there wer e many regresisons from it [08:53] we must take what we get ;) [08:54] MCR: the whole implicit thread context is just the most annoying thing to work with [08:54] there's this whole idea that the pipeline is stateful but then that state is completely hidden from you [08:54] but then you shouldn't query that state as there's no guaruntee that the driver won't stall the pipeline or whatever [08:54] its *stupid* [08:55] anyways, time for me to get off IRC and do some study related things [08:56] c ya [08:57] smspillaz: ok, so those depend on some more new stuff et cetera. so "3110 only or nothing"? [08:57] I can make a test PPA out of that [08:58] Mirv: I could probably pull the relevant bits out - I'd just have to do it manually really [08:58] ( in terms of fixing "in theory" bugs in the ConfigureWindow handling bits ) [09:03] smspillaz: ok.. let's see with this. I need to modify the 3110 a bit anyway since it doesn't apply on top of the other patches, but probably nothing too big there [09:03] coolio [09:11] its the release day [09:12] om26er: \o/ [09:13] om26er: how is it going? [09:13] did you completely recover from being sick? [09:14] mzanetti, yeah, my stomach hurts other than that i am pretty much alive [09:14] mzanetti, ;) [09:15] mzanetti, overall i am pretty good now [09:15] ok. good [09:48] how do I know if an item is completed/loaded? [09:48] I'm trying to access x/width properties of delegates of a listview [09:49] but it complains on loading the app, because I think they are not completed yet [09:49] so I did listview.currentItem ? listview.currentItem.x for example [09:49] but it still doesn't work [09:50] mzanetti, tsdgeos ^ :) [09:50] Cimi: Loader.progress == 1.0 [09:50] mzanetti, it's not a Loader [09:50] mzanetti, is a listview [09:51] mzanetti, I want to see if the delegate exist [09:51] Cimi: hmm... its a bit tricky but I usually do this: [09:51] Cimi: tryCompare(listView.count, model.count) // Wait for listView to read the model [09:51] Cimi: wailt(0) spin event loop to let the listview create delegates [09:52] mzanetti, it's not in a test :P [09:52] Cimi: don't access the delage then [09:52] I'll do differently then, but I don't like it [09:52] onCurrentItemChanged: { } [09:53] Cimi: accessing delegates will crash sooner or later unless you really know whats happening inside the ListView [09:53] and set there, from the listview, the properties of the item I need [09:54] Cimi: ok... only to read x of currentItem should be ok... [09:54] mzanetti, indeed [09:55] I'm doing from the listview [09:55] onCurrentItemChanged: { highlightLine.width = currentItem.width [09:55] highlightLine.x = x + currentItem.x } [09:55] Cimi: listview.currentItem !== null ? listview.currentItem [09:55] mzanetti, did that [09:55] Cimi: your example didn't check for !== null [09:55] Cimi: err... might be !== undefined [09:55] mzanetti, isn't the same thing? [09:56] well, undefined is different [11:24] How would my app integrate with the sync menu? === MacSlow is now known as MacSlow|lunch === morphis|away is now known as morphis === commandoline_ is now known as commandoline === sil2100_ is now known as sil2100 [11:50] didrocks: can we re-run the unity tests, or are they already re-running themselves ;) ? === alan_g is now known as alan_g|lunch === mmrazik is now known as mmrazik|afk [12:39] tsdgeos: ping === _salem is now known as salem_ [12:41] sil2100: you mean, rebuild unity and rerunning, right? === MacSlow|lunch is now known as MacSlow === alan_g|lunch is now known as alan_g [12:55] mzanetti: yes? [12:55] tsdgeos: hey... seems we are blocked by the hud migration now [12:55] tsdgeos: I've updated the jenkins job to include the new ppa [12:55] hmmm [12:55] tsdgeos: sergiusens pointed me to your branch with the updates after I pinged you [12:56] is that new ppa landing on the devices? [12:56] tsdgeos: I've ran it through the updated job. still fails: [12:56] tsdgeos: http://s-jenkins:8080/job/unity-phablet-qmluitests/630/console [12:56] tsdgeos: I don't know... didrocks maybe know. [12:57] didrocks: mind spreading some information on the ppa you set up? [12:57] if it doesn't land into the devices we can't put it in our code [12:57] otherwise we'll have unusable devices [12:58] sergiusens: ^ [12:58] tsdgeos: yeah, from what I know it's this ppa + the phablet one [12:58] phablet one for things that we can't land yet in distro [12:58] mzanetti: ^ [12:58] ok [12:58] tsdgeos: so you will have the new HUD from the ppa on the device [12:59] good [12:59] tsdgeos: be careful, the HUD has a double build [12:59] ? [12:59] tsdgeos: i386 and amd64 is the "desktop with bamf" [12:59] amrhf is the phone with platform-api [12:59] sure [12:59] tsdgeos: this is temporarly, until ted can fix the issue :) [12:59] that doesn't matter to us [12:59] How would my app integrate with the sync menu? It is made in Java. Can I use D-Bus? [12:59] tsdgeos: just that if you test on i386/amd64, don't be surprised :) [12:59] the api that goes to our side is the same [13:00] mzanetti: this as well might interest you in case you are not aware of it ^ [13:00] didrocks: it's been that way all the time [13:00] tsdgeos: ok, not sure about HUD on i386, how you tested it :) [13:01] mzanetti: what failed was my branch or my branch + merge to trunk? [13:01] mzanetti: I see libhud-client2-dev in https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+packages [13:01] tsdgeos: +merge to trunk [13:01] why is it not finding libhudclient2-dev? [13:02] what does a virtual package mean?¿ [13:02] tsdgeos: sergiusens: the job uses those ppas: D08add_ppa-ubuntu-unity-daily-build D08add_ppa-qt5-proper D09add_ppa-phablet-team-ppa D09add_ppa-ubuntu-sdk-team-ppa [13:02] hell, the page Bug reporting etiquette after clicking "report a bug" is sooooo anoying [13:02] tsdgeos: my explanation may be crude, but it means it's refed somewhere but can't be found [13:03] sergiusens: i see [13:03] :D [13:03] mzanetti: daily-build vs daily-build-next ? [13:03] tsdgeos: ? [13:03] mzanetti: yeah, that's the issue [13:03] mzanetti: sholdn't it be D08add_ppa-ubuntu-unity-daily-build-next? [13:03] sohuldn't* [13:03] in those ppas [13:03] mzanetti: use the dynamic add ppa we have [13:03] omfg, do i really need to use "ubuntu-bug" to make a report?? [13:04] sergiusens: what is that? [13:05] given my ubuntu computer at work is not connected to the internet [13:05] mzanetti: I think he means that the wrong ppa is added [13:05] daily-build, not daily-build-next [13:05] didrocks: yeah... we don't have a hook for next as it seems [13:06] mzanetti: didrocks yeah, but I'm searching for the syntax ;-) [13:06] mzanetti: ping [13:06] kgunn: hey [13:06] * mzanetti waits in the hangout [13:06] mzanetti: D09add_ppa~ubuntu-unity~daily-build-next [13:07] morning [13:07] hey rsalveti [13:08] luv: Using ubuntu-bug is good in that it will attach many logs that could help in diagnosing the issue you have. However, if you can just put in a bug and provide enough info that developers can use to fix the bug, then it's not an absolute necessity. [13:09] ChrisTownsend: cool, how can i file a bug from a web browser then? Because when I click "report a bug" im redirecting to wiki [13:10] luv: Hmm, that doesn't sound right. Give me a sec and I'll post a link. [13:10] sergiusens: if you replace the dependency to what is described at https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603 it kind of works [13:10] luv: Are you wanting to file a bug against Unity? [13:10] sergiusens: well, hud will show up, but it'll be useless [13:11] but that might be a different issue [13:11] ChrisTownsend: for example https://bugs.launchpad.net/ubuntu and click "Report a bug". Nah, it's signond [13:12] rsalveti: that MR is going to land soonish ;-) [13:12] https://answers.launchpad.net/ubuntu/+source/indicator-sync/+question/227438 [13:12] sergiusens: great, then we need another MR to release it [13:13] sergiusens: since qml-phone-shell is still maintained by our ci at phablet-ppa [13:14] luv: We should probably move this conversation to #ubuntu since that is the support channel. But that link and Report a bug works for me. [13:15] ChrisTownsend: heh, that's very strange then, it behaves differently for you === mmrazik|afk is now known as mmrazik [13:28] tsdgeos, mzanetti how do I check if a model has finished loading? [13:29] what do you mean a model has finished loading? [13:31] tsdgeos, fully loaded [13:31] tsdgeos, Lenses have finished loading [13:31] populated [13:32] lenses.loaded ? [13:32] Cimi: but that's because it's a dee model, no? [13:32] Where do I need to ask questions related to he sync menu? [13:32] the* [13:36] Saviq, ping [13:38] tvoss: he's holidaying [13:38] tsdgeos, ah, thanks [13:54] tvoss: anything the rest of the shell team can help with? [13:54] tsdgeos, nope, but thanks for asking :) === dandrader is now known as dandrader|afk [14:04] sergiusens: anything blocking https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603 still? [14:05] rsalveti: nah... I think mzanetti has it covered [14:06] mzanetti: ^^ :-) [14:06] mzanetti, branch: https://code.launchpad.net/~nicolas-doffay/unity/infographics_transitions [14:06] rsalveti: we were talking in a different channel... be patient :-) [14:06] sergiusens: lol, ok [14:12] mzanetti, how can I use a tryCompare for a condition? [14:13] unless I do while (condition is false) (wait(0)) [14:14] mzanetti, can you pm me your email? [14:15] Sending the vid over now. [14:15] yep, works === dandrader|afk is now known as dandrader [14:20] Cimi: we have a tryCompareFunction or something like that [14:20] that is a bit better than while-ing [14:20] ah [14:20] well, it's the same [14:20] but looks less lame when reading the test :D [14:20] tsdgeos, where is it? [14:21] Cimi: ./tests/utils/modules/Unity/Test/UnityTestCase.qml [14:21] if you grep for it it's used in a few places [14:21] Cimi: sorry i didn't followup with the model thing, did you get what you wanted? [14:21] mzanetti: do you need anything from me in the hud thing [14:21] ? [14:22] tsdgeos, yes I did [14:22] cool [14:24] tsdgeos, js question [14:24] tsdgeos, how to embed a function as argument? [14:24] tsdgeos, I want tryCompareFunction (width > 0, true) [14:24] tsdgeos, syntax wise, replacing width > 0 with? [14:25] Cimi: afaik there's no lambdas, so just create a function [14:25] ok [14:26] actually it seems you can write the function code in there [14:26] but it's a bit weird :D [14:26] i.e. you could so something like tryCompareFunction (function(){return width > 0;}, true); [14:27] not really helping readability imho === alan_g is now known as alan_g|tea [14:30] mzanetti, could you help me? [14:31] ok... now... was in a meeting [14:31] Cimi: yes, let me just read all the scrollbacks in all channels first [14:31] mzanetti, not on that [14:31] mzanetti, a different thing [14:31] I'd like to move to the Launcher rewrite using Panel [14:31] but there is something wrong in the last test for the dashBar [14:32] sergiusens: rsalveti: tsdgeos: on it... I think the jenkins runs still failed... let me check [14:32] you need [14:32] lp:~tpeeters/ubuntu-ui-toolkit/panel [14:32] and [14:32] lp:~unity-team/unity/phablet.dashbar_panel [14:32] sergiusens: http://s-jenkins:8080/job/unity-phablet-qmluitests/633/console [14:35] mzanetti: arg... === alan_g|tea is now known as alan_g === mmrazik is now known as mmrazik|afk [14:40] Cimi: now... sorry [14:40] I was in a meeting for 1.5 hours and got pinged in all possible channels [14:41] Cimi: Launcher rewrite? [14:42] lol [14:42] grow (size=-39299359) at /home/tsdgeos/qt5/qtbase/src/corelib/tools/qlist.cpp:67 [14:42] grow! [14:42] not! [14:45] tsdgeos: you allright? [14:45] would like to know why qt wants to grow that list in -39299359 [14:46] other than that [14:46] not that bad [14:46] :D [14:48] Cimi: still here? [14:53] mzanetti, yep [14:53] mzanetti, was out for a walk with vesa [14:53] Cimi: ok. np [14:53] Cimi: you said something about Launcher rewrite? [14:53] mzanetti, I am rewriting the launcher to support the Panel SDK component [14:53] btw. hi vesar :) Long time no see [14:54] Cimi: oh... hm.. [14:54] Cimi: because I started working on the launcher and seems to me it needs to be changed A LOT [14:54] mzanetti, you can do it then :) [14:54] just use lp:~tpeeters/ubuntu-ui-toolkit/panel [14:55] Cimi: yours is only about the dragging in/out, right? [14:55] mzanetti, you can see how it works with lp:~unity-team/unity/phablet.dashbar_panel [14:55] mzanetti, hi man. how's it going. [14:55] vesar: very busy. but fine :) [14:55] mzanetti, the idea is to remove this part of the logic [14:55] vesar: thanks [14:55] mzanetti, and leave it to the panel [14:55] Cimi: thats the right information at the right time :) thanks! [14:56] Cimi: so we can get rid of all that timing stuff? [14:56] Cimi, mzanetti: So you guys are rewriting launcher component. Great! [14:59] mzanetti, mostly [14:59] mzanetti, watch out from the tooltips etc [15:00] Cimi: ok. thanks [15:01] vesar: yeah. well. I'm trying to reuse most of the existing stuff. but basic architecture will change. [15:03] mzanetti, ok. Just thinking that the whole launcher is quite of a mess at the moment. Just wonder if it would be better to start it pretty much from the scratch? [15:03] mzanetti, Cimi : though need to check that cimi's branch. [15:03] vesar: in terms of code... yes... its a mess... and I started from scratch. still hope to be able to reuse the delegates and tooltips and such stuff [15:03] vesar, this is for the dashBar [15:04] Cimi, oh ok then.. [15:04] mzanetti, ok good. that makes sense. === mmrazik|afk is now known as mmrazik [15:04] vesar: I'll implement the model in C++ and get rid of those 5 QML ListModels aggregated in some weird way [15:06] mzanetti, yes that was the most terrible part of it. They were created in the first place to enable the accordion pattern which is disabled anyway. [15:06] mzanetti, and sure it wouldn't need all those models to get it done anyway. [15:07] vesar: cool. so you know the internals if it... that might lead to me bugging you more often with questions [15:08] mzanetti, yes feel free to bug me. I can take responsibility of all weirdos in that code. unfortunately:) [15:08]