[08:01] lol, it shows the CI is back [08:01] 170 emails :D [08:15] anyone knows what's the new s-jenkins ip? [08:16] ok 10.98.3.13 says Mirv [08:31] Saviq, Hi! [08:33] o/ [08:39] om26er, o/ [08:39] tsdgeos, don't use IPs [08:39] Saviq, I created a branch for phablet-tools to unlock screen before running tests, I was asked to get it reviewed by you. [08:39] tsdgeos, just set up the dns https://wiki.canonical.com/UbuntuEngineering/QA/VPN [08:40] Saviq, its using the unlock helpers from unity8 [08:40] https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529 [08:40] om26er, will do [08:40] Saviq: but that dns tech is black magic! a good hand written hosts file is the future! [08:44] Cimi, re: units.gu and no import - yeah, that's what we get for using context props - as long as you import it once somewhere, it's available for everyone everywhere [08:45] Cimi, not ideal, and yeah, we should have the import everywhere we are using units [08:50] Saviq: do you know if our autolander is really back? we had some autolanding failures due to some jenkins stuff, shall i re-approve them or wait? [08:50] tsdgeos, yeah it should be working now [08:50] ok, so i'll top-approve them [08:51] rotfl [08:51] https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/682/artifact/results/autopilot/artifacts/unity8.shell.tests.test_hud.TestHud.test_show_hud_button_appears%20%28Desktop%20Nexus%2010%29.ogv [08:51] :D [08:51] come on you can do it, type ubuntu in there! [08:52] but no, it never happens [08:52] that seems to be the most prevailing failure reason [08:53] i've seen a few with timed out scp [08:53] like https://jenkins.qa.ubuntu.com/job/unity8-trusty-armhf-autolanding/74/console [08:54] tsdgeos, https://code.launchpad.net/~aacid/unity8/killApplicationsFilterGrid.qml/+merge/194511 conflicted [08:54] booo [08:54] ok, tx [08:55] tsdgeos, scp should be fixed hopefully since then [08:56] :) [09:01] Saviq: reapprove https://code.launchpad.net/~aacid/unity8/killApplicationsFilterGrid.qml/+merge/194511 ? otherwise it'll complain it was approved in 515 but there's a 516 now, no? [09:01] tsdgeos, right, shouldn't have approved [09:01] tsdgeos, done [09:01] tx [09:08] om26er, here you go https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529/comments/451627 [09:16] mzanetti, Cimi, what's the status of https://code.launchpad.net/~cimi/unity8/carousel-music-video/+merge/192118 ? [09:18] Cimi, if you could reply to my comment as to what was fixed, would help progress on this [09:22] mzanetti, this should be ready, right? the last two things got fixed https://code.launchpad.net/~mzanetti/unity8/music-preview/+merge/193803 ? [09:23] mzanetti, filed a bug for SDK yet? could we link it in a FIXME there? [09:23] Saviq: re Cimi's branch: still no tests. do you think it would make sense to have some? [09:24] Saviq: re my branch: yes. last 2 things are fixed [09:24] Saviq: yes, bug is filed. can add a FIXME [09:25] mzanetti, re: Cimi's branch, what would you test there? it's mostly really layout changes, apart from maybe one or two "visible" checks [09:29] Saviq: yeah... ok. fine with me. do we have at least some test that loads up the loader once? to see if components actually compile [09:30] mzanetti, don't think we do, that'd be a simple test, though [09:31] mzanetti, thinking `source = data.source; tryCompare(loader, "status", Loader.Ready)` or so? [09:31] let me read it once more [09:33] tvoss_, https://code.launchpad.net/~thomas-voss/unity-mir/refactor-oom-score-adj-to-rely-on-process-cpp/+merge/194797/comments/451440 [09:33] tvoss_, https://code.launchpad.net/~thomas-voss/unity-mir/refactor-process-group-operations-to-rely-on-process-cpp/+merge/194804/comments/451441 [09:34] tvoss_, re: https://code.launchpad.net/~thomas-voss/unity-mir/replace_get_env_with_thread_safe_variant/+merge/195037 - do we have a corresponding set-env? as the actual thread-non-safeness wasn't from two threads getenv'ing, but from one of them getenv'ing while the other was setenv'ing [09:35] tvoss_, resolved by just moving the setenvs to execute earlier [09:35] Saviq: nah... I think its ok... [09:36] mzanetti, k [09:57] Saviq: do you know which designer I should contact regarding the expanding list items? [09:59] mzanetti, 'fraid not [09:59] Saviq: so maybe you can help me then. have a minute? [09:59] mzanetti, poke the usual suspects [09:59] mzanetti, sure [09:59] Saviq: I'm thinking how to make the API of it. I guess I start off with a ListItem.Base [10:00] Saviq: now, it sucks if I force the user to position stuff attached to the top. as he'd need to hardcode the collapsed size and he cannot vCenter the text in there for example [10:01] Saviq: also I'm a bit unsure what should happen on expansion. should the item just grow and with that reveal any previously clipped content? (/me not likes) [10:02] Saviq: or should it have some sort of "collapsedContent" and "expandedContent" properties which get exchanged on collapsed/epxanded (/me likes a bit more) [10:02] mzanetti, as said before, that last part should, IMO, be component-specific [10:02] Saviq: or should the expandedContent just be loaded additionally below the content (I think the nicest API and easy to use, but restricts it a bit on the looks&feel) [10:03] mzanetti, think OptionSelector - it shouldn't have its content replaced, as the content is just a ListView that's being expanded [10:03] Saviq: which is not really the case in a expanding list item [10:03] Saviq: as the epanded stuff is most likely not a list [10:04] but more like previewData [10:04] mzanetti, the OptionSelector *is* an example of expanding list item [10:04] where you have an OptionSelector in a ListItem, and it just grows when you "focus" it [10:04] Saviq: no. it's the other way round [10:04] mzanetti, no, it is not ;) [10:05] mzanetti, ok, let's put it another way [10:05] mzanetti, an OptionSelector is an example of the *content* of an expandable [10:05] where that content just grows to fill the expandable [10:06] mzanetti, we're not after a behavior like we have with the preview (OpenEffect) [10:06] mzanetti, but instead just an item growing in height when focused, revealing more content [10:07] so option one [10:07] ok [10:09] mzanetti, as for "sucks if I force the user to position stuff..." not sure I get what you mean [10:09] Saviq: I think most of the times the stuff in there will not be a list [10:10] Saviq: so you have the item that looks like a regular ListItem when collapsed [10:11] Saviq: but you can't vCenter text in there, as the actually size will change when expanded for example [10:11] so you need to anchor it to top/bottom with hardcoding margins etc [10:11] still, the most flexible [10:12] and that's what we need. so... [10:13] mzanetti, yeah, nothing better comes to mind [10:21] can I check in python or through bash if the screen is turned on or not? i.e. is there a powerd api for python or a commandline option without root access ? [10:35] om26er, I don't think there is, no, sforshee should know more === om26er_ is now known as om26er [10:46] Saviq, getting device not found errors in these jenkins reports, haven't seen those yet https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist [10:48] nic-doffay, it's in queue to run one more time - there were some configuration issues a few hours ago still [10:48] Saviq, kk [10:49] nic-doffay, but it's better now, we got two green ones already this morning http://s-jenkins:8080/job/unity8-autolanding/ [10:53] nic-doffay, https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/191145 fails due to "ListItem.ItemSelectorDelegate is not a type" [10:53] nic-doffay, did that get renamed or something? [10:53] Saviq, that's waiting on an sdk branch. [10:53] nic-doffay, ok [10:54] Saviq, I still need that icon from design, everything else has been seen to though. [10:54] Saviq, don't really know how to fix the carousel... [10:54] asin landscape [10:55] *in [10:56] because it scales.... [10:56] it's dynamic === _salem is now known as salem_ [10:57] it's bigger than when it's in portrait [10:57] so the assets and spacing/padding/margins are different [10:57] fonts too [11:01] Cimi, well it should just scale with them, should it not (i.e. margins and such should be a factor of the size) [11:01] Saviq, but they won't be pixel grid aligned? [11:01] Saviq, when it involves operations [11:01] Cimi, dednick had a "align-to-grid" function somewhere [11:02] Cimi, in indicators [11:02] Cimi, that would find the closest grid-aligned value for an arbitrary value [11:02] Saviq, but the asset is not aligned maybe [11:02] dunno [11:02] have to try [11:02] Cimi, font size should be good as-is, we don't want to scale fonts [11:02] Cimi, please do [11:02] Cimi, as this will break badly on the tablet, too [11:04] Saviq, I think we need better ubuntu shape [11:04] like when we can finally fill inside [11:04] Panel/Indicators/DefaultIndicatorWidget.qml::guRoundUp [11:04] Cimi: ^ [11:04] Cimi, please ping loicm on the status of it [11:04] Saviq, will land before january iirc [11:04] Saviq, in december [11:05] Cimi, if you can't find a ~simple "will-do" solution, we'll have to wait for that, then [11:05] Saviq, I'd wait [11:06] Saviq, can't think of something that will work now, unless asking for more assets [11:06] with a .sci file [11:06] Cimi, just ponder it, if you can't - mark the branch as WiP and comment on the bug accordingly [11:10] Cimi: can you do a review when you have some time? [11:10] Cimi: https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/fix-broken-calendar-tests [11:12] sil2100, seems like ci is working now, could you setup ci and autolanding for lp:unity-scopes-api? [11:12] sil2100, althought zmqpp seems to be stuck in proposed? [11:13] mhr3: releasing to distro is not ready yet though [11:14] didrocks, not needed to enable ci though, is it? [11:16] mhr3: well, for upstream merger, it still worth it I guess [11:23] mzanetti: you forgot to fix a typo in the same sentence :D re https://code.launchpad.net/~mzanetti/ubuntu-ui-toolkit/fix-listitems-empty-typo/+merge/195405 [11:24] tsdgeos: :D [11:25] typo overflow [11:28] Saviq, we have set_env, too [11:29] Saviq, working on a queue of mps right now, will get to that specific one shortly [11:29] tvoss_, cheers [11:46] dednick: aren't we better served by fixing that in Qt or glib or wherever the root cause is? [11:46] greyback, ping [11:46] Saviq: pong [11:47] greyback, icanhazchangelogbump on https://code.launchpad.net/~gerboland/unity-mir/listen-for-server-start-stop-ready/+merge/191224 ? [11:47] greyback, otherwise the ap tests I've just added to https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 will fail if we don't upgrade libunity-mir [11:47] okies [11:48] good we don't have .symbols files, 'cause that wouldn't help at that point, we'd need an explicit >= on libunity-mir1 [11:48] tsdgeos: yeah, well that would be great. But as far as I can tell, it's not actually bug. It's done that way on purpose. [11:49] didrocks, here's a question, unity8 build-deps on libunity-mir-dev, there's a behavioral change in unity-mir that unity8 wants to depend on, so we're bumping unity-mir's version and build-depending on >= $that_version [11:50] didrocks, shlibs will then make sure that there's a Depends on >= $that_version [11:50] didrocks, but if it was C, and there was a .symbols file, and we wouldn't have changed ABI, would that still work? [11:51] didrocks, or would shlibs find the lowest possible symbol set and use that for the Depends: unity-mir >= $version ? [11:51] /food [11:53] Saviq: done [11:53] greyback, cheers [11:54] greyback, cu2d would've taken care of the commit message (and the +foo in the version number) [11:54] greyback, just FYI [11:54] Saviq: didn't know that. Ta [11:55] dednick: really? [11:55] greyback, hmm why do we have an explicit Depends on libunity-mir1 for unity8? [11:56] greyback, wouldn't shlibs take care of that? [11:56] dednick: why would it be on purpose? [11:56] Saviq: it would. Not sure why. [11:56] greyback, k, will prep a branch [12:01] Saviq, fixed per suggestions: https://code.launchpad.net/~om26er/phablet-tools/unlock_screen/+merge/195529 [12:02] om26er, yup, saw that, will look/test soon [12:02] cool [12:03] tsdgeos: explanation given to me: [12:03] dednick: the loop level condition for deleteLater processing is to protect you from calling deleteLater and having it destroyed by a nested event loop while still in scope [12:04] dednick: and why should i care about internal stuff? [12:04] tsdgeos: what we're doing in glib callbacks bypasses the event system. [12:05] so bascially i can't use deleteLater and assume it'll delete stuff later? [12:05] that's a big bug, no? [12:07] tsdgeos: it will delete it. when the current event loop finsishes. Unfortunately that's when we shut the shell down. [12:07] dednick: :D not very helpful [12:08] tsdgeos: yes, I'm painfully aware. [12:09] tsdgeos: unfortunately that's what happens when you twist a framework. [12:12] dednick: so the problem is when we do stuff directly in a glib callback? [12:12] tsdgeos: yeah [12:12] can't we just detect the case where the callback is called outside of the qt system and deal with that inside deleteLater? [12:12] tsdgeos, dednick ^? [12:12] dednick: is it just deletelater or everything else that fails? [12:13] mhr3: it's what i was thinking, but i've had no look at the code at all [12:13] mhr3: detect? not that I know of. It's using the same mainloop. There is no difference between an event coming from keyboard and one coming from something we have initiated. [12:14] dednick, well one goes through some more qt :) [12:14] mhr3: because the keyboard event pushes it through the qt. Which is what we're supposed to do :) [12:15] dednick, in that case we could deal with it - set a flag when it gets into the qt event system, and unset when it leaves it [12:15] then inside deleteLater we'd look at that flag [12:16] problem solved [12:16] mhr3: ? when what goes into qt event system? [12:17] a qevent [12:18] mhr3: the qevent for the delete ? [12:19] or what caused the delete ? [12:19] tsdgeos: it's only deleteLater [12:20] dednick: i see [12:20] dednick: any idea why deelistmodeltest doesn't get built here? [12:20] tsdgeos: need to compile with -DWITHQT5=1 [12:20] ah right [12:21] mzanetti, got a quick one for you: https://code.launchpad.net/~dandrader/unity8/greeter_edge_hint/+merge/195591 [12:21] dednick: seen that CI failed? [12:21] actually fails here too [12:21] hmm [12:22] huh. odd [12:22] dednick, ok, from start 1) app receives key event (or any other) 2) there's a GSource that gets dispatched 3) that GSource usually sends a QEvent 4) stuff happens (q signals etc etc) [12:23] dandrader: what does this exactly do? [12:23] dednick, now somewhere inside the qt event system we'd set a flag (in sendEvent?), if deleteLater is called with that flag set, use the current behaviour, if not - which should mean that this was an direct glib dispatch - don't wait for the next event loop [12:23] mzanetti, adds a hinting animation when you press on the right edge of the greeter. try it [12:24] dednick, makes sense? [12:24] mzanetti, I think it fits nicely with the teasing animation that happens when you hit the body of the Greeter [12:24] dandrader: ah got it. when you press inside the drag area [12:25] mzanetti, exactly [12:25] dednick: somehow moc is not getting the -DWITHQT5 flag [12:25] maybe a regression somewhere [12:25] ? [12:25] tsdgeos: eh. it may be because i had compiled before i made changes [12:25] dandrader: shouldn't the DDA in that case reject the gesture and pass it on to any mousearea behind it? [12:27] mhr3: yeah, makes sense. could possibly work. [12:27] dednick: it's not your fault, the lp:dee-qt one doesn't build here either [12:27] dednick: are you on trusty? [12:27] tsdgeos: no [12:27] i am [12:27] so there you go [12:27] mzanetti, no. it's the same as what happens when you press on the indicator panel [12:27] i thought i had upgraded... [12:28] something changed in cmake probably [12:28] or somewhere else [12:28] dednick: can you do this for me plz [12:28] rm modules/Dee/moc_plugin.cpp [12:28] and then [12:28] dandrader: well, ok with me. I was just wondering. as my understanding was it would pass on the input to the next handler if it isn't a gesture. in which case the greeter teasing would already work [12:29] make VERBOSE=1 [12:29] dednick: and paste the moc line somewhere [12:29] /usr/lib/x86_64-linux-gnu/qt5/bin/moc bla bla [12:29] mzanetti, 1- the framework for having that forwarding scheme working is not in trunk yet [12:30] mzanetti, 2- hitting the border of the greeter is different than hitting its main body [12:30] because you cannot drag it from the main body [12:30] mzanetti, whereas you can when you hit its right edge [12:31] mzanetti, so it makes sense for those two animations to be like they are with this patch [12:32] dandrader: yes. I agree. was just curious. but if there is an app in foreground the right edge would pass non-recognized gestures on to the app once the required stuff is in trunk? [12:32] mzanetti, the fist animation says "hey, hit the border to drag me!" whereas the second tells "you can drag me if you start dragging your finger leftwards" [12:32] tsdgeos: http://pastebin.ubuntu.com/6437235/ [12:32] mzanetti, yes of course. in that case a DragHandle is not used. but a EdgeDragArea [12:33] dednick: so the -DWITHQT5 is there [12:33] not for me [12:33] :-/ [12:33] dandrader: ah, got it. yeah. thanks [12:34] tsdgeos: from builddir "cmake .. -DWITHQT5=1" [12:34] dednick: sure, but not propagating to moc [12:34] for me [12:34] weird [12:35] well cmake may have regressed [12:44] Merge branch 'fix-automoc-compile-definitions' into release [12:44] that looks like it :D [12:52] could be, could be :) === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|lunch === dandrader|afk is now known as dandrader [13:17] mhr3: trying a patch now. unfortunately it requires me to build qtbase. may take awhile :( [13:18] dednick, yea, i'll ask about it tomorrow ;) [14:03] dednick: ok, got the new cmake packaged and on prosoped, going to try if that fixes the build for me after rebasing for nth time my qt patch [14:05] * mzanetti celebrates jenkins-is-back-day :) === alan_g|lunch is now known as alan_g [14:13] dednick: yep, problem gone with cmake from trusty-proposed [14:14] mzanetti, if only it was jenkins-is-really-back-day and not jenkins-is-sometimes-back-day ;P [14:15] tsdgeos: cool [14:15] lol [14:15] mzanetti, too many things still not in their best shape [14:42] Saviq: https://code.launchpad.net/~mzanetti/ubuntu-ui-toolkit/expanding-listitem/+merge/195602 [14:43] dednick, standup? [14:45] MacSlow: we should get this reviewed in order to land your fullscreen branch: https://code.launchpad.net/~mzanetti/unity8/generic-lockscreen/+merge/191951 [14:48] kgunn: when is my scenegraph session? I can't find it... [14:48] mzanetti, yup [14:49] MacSlow: can you review this? I'll take your fullscreen branch then [14:49] greyback: mmm...let me check....i followed instructions....which may not have resulted in a "planned session" :) [14:49] mzanetti, ok [14:49] * greyback totally thought USD was next week [14:49] kgunn, you should also mark folks (me/ricmm) as essential where we're supposed to run them [14:49] kgunn: hey, just coming to the info from u-s-c not building :) [14:49] kgunn: also, it seems that platform-api doesn't have the bump build-dep merged? [14:50] Saviq: so picky...:).... i thot i had...sorry [14:50] kgunn, I just don't want to miss it, ya know ;) [14:50] Saviq: i know you were super pumped about it! ;) (...Borat _not_) [14:51] hmmm [14:51] argh, I saw a kgunn and was thinking it was the Mir channel, let's move there :) [14:51] should we delay our standup tomorrow given it is at the same time of vUDS opening so we can listen to Jono/Mark? [14:54] mzanetti, there should be only one expanded item per container (i.e. others collapse when you expand a new one) [14:54] mzanetti, that's not the case yet - that expected? [14:54] Saviq: ah right. sure. no forgot that. but its easy [14:54] Saviq: but the general approach seems ok, right? [14:54] mzanetti, just looking at the code - it behaved correctly, yeah [14:56] mzanetti, looking good, yeah [14:56] ok, cool [14:57] mzanetti, we'll need an ExpandingColumn, too, in case you don't want a ListView [14:57] yep [14:57] Saviq: altough that would be just setting height: contentHeight; interactive: false [14:58] mzanetti, nope [14:58] mzanetti, you'd have to use a Loader to get different delegates [14:58] mzanetti, there are three merge-conflicts with your generic-lockscreen branch atm [14:58] mzanetti, in a ListView [14:58] mzanetti, also, for naming I'd go Expandable, ExpandablesListView / ExpandablesColumn or so [14:59] MacSlow: oh... fixing asap [14:59] as ExpandingListView feels like it itself would be expandable [14:59] mzanetti, for ExpandablesColumn, think of: [14:59] yeah, I got it [15:00] no repeater [15:00] ExpandablesColumn { ExpandableFoo { } ExpandableBar { } ExpandableBaz {} } [15:00] yeah, no model [15:00] ack [15:00] so slightly trickier, but not a whole lot [15:01] MacSlow: I'm wondering why the SIM pin lock in trunk still is 4 digits only given that we merged this already: https://code.launchpad.net/~mzanetti/unity8/sim-pin-variable-length/+merge/191625 [15:01] mzanetti, one more thing, though, you need to limit expandedHeight [15:01] yep. [15:01] there's no fllickable in there yet [15:01] mzanetti, ok coll [15:01] that's what I'm waiting on design for [15:01] cool [15:02] Saviq: there are a few issues with closing it in that case [15:02] design-wise [15:02] mzanetti, yeah I know [15:02] mzanetti, progressing good :) [15:03] thanks [15:07] greyback: weird...the scenegraph session didn't get approved...don't know why [15:07] mzanetti, I can't trigger the pin-entry on my device (unlocked sim). [15:08] kgunn: ok. Bit late to add now? [15:08] mzanetti, I used the simentry-example from lp:unity-notifications [15:08] mzanetti, and there it works correctly. [15:08] MacSlow: not sure what you mean [15:09] tsdgeos, what motivated you to report https://bugs.launchpad.net/bugs/1250412 [15:09] Ubuntu bug 1250412 in Ubuntu UI Toolkit "InverseMouseArea does not work with TouchEvents" [Undecided,New] [15:10] tsdgeos, ie., what unity8 use case is affected by it [15:10] dednick: cimi's [15:10] Cimi: ↑↑ [15:10] hey guys, who's still developing on Unity 7 in here? I have some non-work-related questions [15:10] tsdgeos, you mean this? https://bugs.launchpad.net/unity8/+bug/1193414 [15:10] Ubuntu bug 1193414 in unity8 (Ubuntu) "[DASH] "quit" mode for 'recent apps' should be less persistent" [High,Triaged] [15:10] mhall119, Trevinho [15:10] tsdgeos: eh? [15:11] dednick: sorry, wrong d-autocompletion [15:11] ah [15:11] greyback: i think so... [15:11] Trevinho: ping when you're around [15:11] dandrader: well, the branch he's working on to fix that [15:11] mzanetti, what did you run to check what pinlength is used? [15:11] greyback: for sure...even it does get add late...no prep...just a review of where we're at [15:11] mhall119: pong [15:11] MacSlow: there is no such thing as a pinlength any more [15:12] kgunn: okies, keep me posted anyway [15:12] dandrader: i don't remember the branch exactly [15:12] dandrader: but basically anything that needs the topmostitem feature in IMA [15:13] s/enables/needs [15:13] damned qt private data exports... [15:13] Trevinho: hey, how hard would it be to build a new desktop session (an alternative to ubuntu-desktop) that uses Unity, without it's settings conflicting with ubuntu-desktop's Unity settings? [15:14] I tried to do this with Xfce years ago with moderate success [15:14] mzanetti, but in Greeter/PinLockscreen.qml there's still this property "pinLength"... I'm confused now. === dandrader is now known as dandrader|lunch [15:15] MacSlow: yeah. ignore that. just don't use it in the notification [15:15] mhall119: mhhm... well unity settings are stored all in gsettings, but some via comipz other directly... [15:15] didrocks, (how) can you mark people as essential for a session on UDS? [15:15] mhall119: so... for compiz side all you need is just to add a new compiz profile [15:15] didrocks, pinging you as you're marked as the person to ask for that on the session participation page [15:15] mhall119: for gsetttings side I think you need to force a different backend when starting the session [15:16] Saviq: only the meeting's creator (and possibly track lead) can mark people as essential [15:16] Saviq, just subscribe them to the bluepprint and tick the "presence required" box? [15:16] although, this last one would probably affect even compiz settings, so should apply to all [15:16] Trevinho: blegh, I was going to have to do that with Xfce too, which was hit-or-miss [15:17] seb128, hmm there seem to be sessions without blueprints (http://summit.ubuntu.com/uds-1311/meeting/22084/unity8-shell-discussion/) [15:17] which means in order to have separate Unity/Compiz settings, I also necessarily have to have different GEdit settings (and different settings for any app using gsettings) [15:17] Saviq, ok, so what mhall119 said then [15:17] seb128: the Launchpad "require" option is no longer strictly enforced in Summit [15:18] LP "required" = Summit "would really like to attend but not absolutely critical" [15:18] mhall119: I see... mh, well, I didn't check gsettings much, probably other guys are much more experienced with it than I am, but I don't know if it's possible to define a different profile for just a class of setings... it seems tha compiz is doing that in some way, but I didn't study that much [15:18] mhall119, oh? since when? what's the right way to make sure people don't have conflicts? [15:18] mzanetti, so there also is no "x-canonical-pin-length" anymore? [15:19] MacSlow: nope [15:19] MacSlow: that merge actually already removed that... I guess it came back somehow which is what it breaks again [15:19] Saviq, I can add participants I think ... who do you need? [15:20] Saviq: can do as well if needed [15:20] mzanetti, no idea what what merge might have reverted that [15:21] MacSlow: fixed the merge conflicts [15:21] * mzanetti -> food [15:21] seb128: for a while now, since before Copenhagen at least [15:22] seb128: Summit will warn about conflicts with "really would like to attend", but it won't block them [15:22] mhall119, ok, that's good enough I guess (if people schedule do take the warnings into accounts and tweak to resolve those) [15:23] mzanetti, ok [15:25] seb128: with auto-scheduling turned off for vUDS, it really doesn't make much of a difference either, it was mainly removed to make auto-scheduling/rescheduling less disruptive to the schedule [15:26] right [15:26] mhall119, thanks === alan_g is now known as alan_g|tea [15:27] Saviq, tsdgeos so I have API shared between carousel and filter grid, but when I use a loader to load those I guess I need to alias all those properties [15:27] is there a way to avoid that and duplicating code? [15:27] i don't think so [15:30] Cimi: do you have the branch where you need the topmostItem enabled IMA ? [15:30] i forgot the url [15:31] tsdgeos, it was a patch [15:31] * Cimi looks history [15:31] http://paste.ubuntu.com/6382346/ [15:31] dandrader|lunch: ↑↑↑ [15:32] dednick: ping [15:32] tsdgeos: plop [15:33] dednick: i was wondering why you went that weird QGlibCallbackEvent instead of just doing a QMetaObject::invokeMethod that my quick test shows it seems to work too [15:33] i think it's simpler (doesn't need a new class) === om26er is now known as om26er1 === om26er1 is now known as om26er [15:33] tsdgeos: you use queud connection? [15:33] yep [15:34] tsdgeos: because it goes onto the post queue. we don't want that [15:35]