#ubuntu-unity 2012-12-10
<didrocks> hey Mirv, sil2100 :)
<didrocks> how was your week-end?
<didrocks> mmrazik: hey, how are you?
<mmrazik> didrocks: morning
<mmrazik> didrocks: whats up?
<didrocks> mmrazik: do you have a minute for a quick call with jibel? We have some autopilot-env requests
<mmrazik> sure
<didrocks> (also, let's check if jibel is available :))
<Mirv> didrocks: hello, pretty fine, some family visiting etc
<Mirv> didrocks: how was yours?
<didrocks> Mirv: oh nice! :) Mine was excellent! It was the "fÃªtes des lumiÃ¨res" (light festival) in Lyon, so a lot of people (4 millions approx.) on the street and a lot of walking :)
<didrocks> but nice shows like http://www.youtube.com/watch?v=51G-Ewf4B2M&list=UUwsuhgq2VBY54f8Lez8wGEQ&index=3 and http://www.youtube.com/watch?v=a8hboL4N4yc&list=UUwsuhgq2VBY54f8Lez8wGEQ&index=1
<didrocks> even if the videos don't reflect how beautiful and impressive this is :)
<didrocks> Mirv: I wanted to ask you about the compiz fullsceen opengl fix, where are we with this?
<Mirv> nice looking stuff, surely awesome seen live
<didrocks> oh yeah, it really is :)
<didrocks> mmrazik: starting a hangout and inviting you
<Mirv> didrocks: about 10 minutes of giving the quantal branch to you or so, so pretty good, all tested
<didrocks> Mirv: \o/
<didrocks> Mirv: for precise, it will be disabled by default for now, right?
<didrocks> for the xorg guys to look it, isn't it?
<Mirv> we just have a habit of getting final ack from another team member, so waiting sil2100 to ack it
<didrocks> (in quantal, it's enabled by default)
<didrocks> great :)
<Mirv> didrocks: yes, like that, sil2100 is probably finalizing the phase-1 of precise compiz this week
<didrocks> Mirv: for precise, maybe we can push that to a ppa rather?
<didrocks> rather than going to the long SRU queue
<didrocks> what do you think?
<didrocks> and then, the xorg team can play with it
<Mirv> didrocks: it looks it's already there since Friday (similar to quantal that was there for good time)
<didrocks> oh good, can you ensure you/sil2100 speaks with the xorg guys then?
<Mirv> some arm build problem though, so needs tinkering
<didrocks> let's only push final work
<Mirv> didrocks: yes, will do
<didrocks> ok :)
<didrocks> thanks a lot!
<Mirv> np
<mmrazik> didrocks: is the invite out?
 * mmrazik still doesn't have anything
<didrocks> mmrazik: it seems you are unknown on my tablet :p
<didrocks> I just added you to my circlesâ¦
<didrocks> ah here you are :)
<didrocks> mmrazik: won't it be more flexible that we give you dynamically a list of tests to run (with all tests for unity) and a list of packages to install from the ppa?
<didrocks> mmrazik: so that we don't bother you when the list changes
<didrocks> and you just generate from those list, it sounds easier for you?
<mmrazik> didrocks: it probably would but I'm not sure how exactly to do it. This is all controlled by UTAH so its in utah config. Thomi/Chris started to write some scripts that generate it but I just checked and they don't use it yet.
<mmrazik> and still have e.g. different preseed for the trunk and the release job
<didrocks> mmrazik: ok, so we'll probably need some more jobs, I'll detail everything by email :)
<mmrazik> ok
<mmrazik> if its more then it definitely makes the generation more urgent
<didrocks> yeah, because I thought of one thing
<didrocks> I'll detail your everything :)
<mmrazik> ok
<didrocks> in the email, it's easier
<apw> didrocks, i have just upgraded in quantal and my unity settings were reset again
<didrocks> apw: hum, I think you are suffering from bug #1063617, with a fix that was merged into compiz trunk 6 hours ago
<ubot5> Launchpad bug 1063617 in compiz (Ubuntu) "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,In progress] https://launchpad.net/bugs/1063617
<didrocks> https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1063617.8/+merge/138801
<didrocks> but maybe you can check with duflu ^
<apw> ok ta
<didrocks> apw: I can only see that, I hope it's the same issue
<freedomrun> gsettings set org.gnome.nautilus.window-state start-with-status-bar true is impossible in 13.04 ??!
<duflu> apw, didrocks: By smspillaz' last estimate it would require 9 merge proposals to fix. Only 8 have landed so far ... !? :)
<didrocks> duflu: oh, I didn't the count right :)
<didrocks> isn't the last one about the migration key with integrated one?
<duflu> didrocks: Yes, Sam said so but I don't know the details
<didrocks> so the specific case of apw "should" be fixed (hopefully)
<apw> didrocks, thanks ...
<mmrazik> didrocks: I assume "unity.tests.test_hud.HudAlternativeKeybindingTests.test_super_h" is not interesting for indicators and it is only in the list because "bindings" have the "indi" substring...
<didrocks> mmrazik: no, it's more because it has the HUD in it (and the hud is part of the indicator stack), but I thought it would be easier to include them all than doing one after another
<mmrazik> didrocks: ok
<didrocks> mmrazik: this also enables to ensure that by default, the hud backend doesn't give back wrong result making the frontend crashing (we never know what can happen)
<hyperair> so the other day i read about this newfangled unity version with fixed unredirect fullscreen windows
<hyperair> how do you know if it's working?
<hyperair> (also team fortress 2 doesn't redraw for ~2 minutes when trying to unredirect
<davmor2> Hey guys the Legal notice link in the home dash should it be missing from R?
<popey> ah, didrocks was that distropatched in?
<didrocks> it's not distro-patched, I see it here
<didrocks> oh indeed, no
<didrocks> hum, interesting
<seb128> the path changed with the version?
<didrocks> no, the version wasn't bumped
<didrocks> let me check
<didrocks> I remember to bzr merge the branch
<didrocks> maybe nobody never acked itâ¦
<didrocks> https://code.launchpad.net/~gordallott/unity/dash-legal-link/+merge/129235
 * didrocks grrr
<didrocks> thanks for the notice davmor2, we'll get it fixed :)
<davmor2> didrocks: no probs
<sil2100> Ah, right
<sil2100> Since hm, it was supposed to be worked on for R I think?
<didrocks> yep
<didrocks> sil2100: do you have the time to get it merged?
<didrocks> I think retaking the branch, merging trunk back and repropose/approve
<sil2100> didrocks: ok, I'll make it mergable for trunk
<didrocks> sil2100: thanks, please feel free to get it reviewed/approve yourself
<sil2100> Yea, since Gord probably won't be working on it anymore ;/
<didrocks> yep
<didrocks> thanks sil2100 ;)
<didrocks> hey mterry, how was your week-end?
<mterry> didrocks, hi!  good
<didrocks> sweet ;) Sorry to bother you on Monday but I have a tasklist to hang over to you :)
<didrocks> FYI I asked sil2100 to take care of https://code.launchpad.net/~gordallott/unity/dash-legal-link/+merge/129235 so that it's finally merged into trunk (we lost the legal notice with latest release)
<didrocks> * I didn't see the nux fix .pc file -> build-dep added to the -dev package, did I miss anything?
<didrocks> * We forgot in the stack libunity-misc: https://code.launchpad.net/~unity-team/libunity-misc/trunk
<didrocks> so I guess this one needs bootstrap/inline, and so onâ¦ :)
<didrocks> * finally, I guess that the new hud package (already inlined by ted) would be great to have a double check that it's similar to our packaging standard + bootstrap :)
<didrocks> I think cyphermox is still fighting on the test for the 4 packages that are failing on tests for the indicator stack, not sure how busy you are, but maybe you can give a hand
<didrocks> I guess that's more than enough for a Monday :p
<mterry> didrocks, no you didn't miss the nux fix.  I just didn't put it high on my todo, I can get to it today
<mterry> didrocks, ACK on libunity-misc
<didrocks> mterry: not very high compared to the rest TBH, good to know that my filters still work though! ;)
<didrocks> thanks mterry ;)
<mterry> didrocks, I came back from vacation for a few days last week and then had another day off.  Having these short days on, short days off means it's hard to recover from email
<mterry> didrocks, did get VPN access though!  Haven't set it up, but IS did
<didrocks> mterry: yeah, no worry at all (that's why I didn't spam you the first days ;)) and good luck on emails! :-)
<didrocks> excellent for the VPN access!
<didrocks> I'll probably discuss more with you on autolanding how it works later this week
<didrocks> one a quieter time for both you and I :)
<fginther> bregma, any idea why autolanding failed? https://code.launchpad.net/~bregma/unity/fix-standalone-shorts-startup-crash/+merge/139010
<bschaefer> fginther, yeah, Ill have a fix in a second
<fginther> bregma, looks like a possible compiz api change?
<fginther> bregma, thanks
<bschaefer> fginther, compiz pushed new changes, and unity didn't reflect it
<bregma> fginther, is Jenkins not supposed to try to build Unity of Compiz changes, or is that a later-stage Jenkins that does that?
<fginther> bregma, jenkins will rebuild unity if compiz changes
<fginther> it will always try to build a merge proposal if it is approved
<bregma> did it pick up the compiz-caused unity build failure or did I miss the message?
<fginther> bregma, let me look at the logs
<fginther> bregma, jenkins didn't catch this one on the unity rebuild.  There is an optimization to not rebuild unity if another merge proposal is pending.
<fginther> which appears to have happened here
<fginther> bregma, also, the jenkins jobs are not smart enough to determine that a change to compiz caused unity to failed to build.
<bregma> sure, but a rebuild of unity that was kicked off by a changed dependency like compiz failed, the person looking at the logs would know
<bregma> then, if there was some way to delay pending builds until that was resolved, we'd have fewer manual remarking merges as approved, but I don't think it's worth the effort to make that work
<fginther> bregma, yes, that is correct. We're lacking builders and other resources to make this work, but hopefully we'll get there this cycle.
<bregma> mterry, could you clarify what versions need bumping to remedy all the current compiz/unity build problems?
<mterry> bregma, I'm not familiar with the specific build problems.  Let me look at the staging PPA
<mterry> Nope, the staging is fine.  You're talking about some jenkins failures?  Related to the compiz abi bump?
<mterry> bregma, ^
<bregma> yes, you made a comment in bschaefer's MP to fix it
<mterry> bregma, ok, so you're talking about the unity package.  Let me check versions
<bregma> well, I'd like to see the compiz version bumped because of the non-backwards-compatible API change that cause all this breakage, but it's unclear how that happens with this continuous packaging stuff
<mterry> bregma, such packaging changes should have been a part of the branch that bumped API
<mterry> that changed API rather
<mterry> bregma, so since we didn't bump the compiz version, unity needs to add a build dep in debian/control on something hideous like 1:0.9.9~daily12.12.05bzr3521pkg0raring0
<bregma> mm-hmm
<mterry> bregma, but ideally we'd actually fix compiz's version
<mterry> and then change unity's dep to be 1:1.0.0 or something clean
<bregma> yes
<bregma> so I approved bschaefer's MP so we can get build backlog cleared on the premise we could work out the version bumps
<bregma> I figure we need to talk to duflu about details
<mterry> bregma, so I don't know what the proper compiz version should be.  1.0.0 or 0.9.10.  But either way, do a normal everyday version bump in the code and add a debian/changelog entry with the new version
<mterry> bregma, did the SONAME change?
<mterry> bregma, we broke ABI or API?
<bregma> mterry, I don;t think the SONAME changed, either
<bregma> it's an ABI break because symbols have disappeared
<bregma> someone is going to get spanked
<mterry> bregma, Oh...   that should cause a SONAME bump then, eh?
<mterry> I thought we were just adding symbols
<mterry> Do the symbols need to disappear?  i.e. was this an accident?
<bregma> hmm, it looks like the SONAME may have changed, I am confused by the way compiz reinvented SONAME versioning
<mterry> bregma, I'm surprised jenkins took it if the SONAME changed (I would expect a build failure due to packaging)
<bregma> there was a change that made some functions const -- that causes the symbols to change their mangled names, so in effect they've disappeared and now ones have appeared
<mterry> I see, right
 * mterry isn't super familiar with C++
<mterry> bregma, OK, so that was presumably an expected change and we have to do the whole soname bumping dance.  Which involves changing the package name in debian/control and all that
<mterry> bregma, how much help do you need with that?  i.e. do you want me to do a branch or do you just want a review from me?
<bregma> it definitely needs discussion with duflu
<mterry> OK.  I'm not super familiar with IRC nicks yet.
<bregma> the packaging would never break woth compiz due to a SONAME change because the SONAME isn;t tracked by the .so file name or any of the other stuff the packaging knows about
<bregma> it's weird
<mterry> bregma, the SONAME isn't part of the .so file name??!
<mterry> Seems odd
<bregma> nope -- liek I say, they reinvented how this stuff works
<mterry> Alright
<bregma> if someone installed the binary deb as an upgrade they'd be in for a nasty surprise
#ubuntu-unity 2012-12-11
<bschaefer> fginther, ping
<fginther> bschaefer, pong?
<bschaefer> fginther, hey, its late for you! Umm I was running into jenkins failing to merge nux branches
 * bschaefer goes to dig up the error
<bschaefer> fginther, https://code.launchpad.net/~nick-dedekind/nux/remove-animation-on-tick/+merge/136069
<bschaefer> it doesn't seem like its the branches fault...
<bschaefer> fginther, looks like a lib is not being found
<fginther> bschaefer, I'll take a quick look
<bschaefer> fginther, thank you, I could poke martin when he gets on
<fginther> bschaefer, I enable code-coverage collection on this job, I might have missed something when I did so
<bschaefer> fginther, hm interesting, as it worked locally
<fginther> bschaefer, It's my fault. I used the wrong hook script to collect the test data. I've updated the jenkins job and re-approved the MP
<bschaefer> fginther, alright, thanks!
<fginther> bschaefer, https://code.launchpad.net/~smspillaz/nux/nux.fix_1086701/+merge/138070 will also fail for the same reason.
<fginther> I'll kill the job and restart it
<bschaefer> alright, I could have also waited :)
<bschaefer> and re-did
<bschaefer> re-approve it
<fginther> bschaefer, they should be good now, but I'll check in on them later to make sure
<bschaefer> fginther, thank you! Ill try to keep an eye out as well
<didrocks> mmrazik: https://jenkins.qa.ubuntu.com/job/unico-autolanding/build=pbuilder,distribution=coverity-raring,flavor=amd64/2/console seems an internal builder issue?
<didrocks> hey sil2100
<didrocks> sil2100: did you see that unity is FTBFS on armhf?
<didrocks> bregma: FYI ^
<didrocks> not sure if it's an archive mismatch or intended
<didrocks> like the -dev package not being published right
<didrocks> will worth a shot looking at it/launching a rebuild if you can :)
<sil2100> didrocks: for armhf?
<sil2100> Og
<sil2100> Oh
<didrocks> yep yep :)
<didrocks> possible it's just a publisher skew
<didrocks> but worth confirming :)
<sil2100> Didn't see that one, thanks for pointing out - I was just looking at the armel failure from earlier
<sil2100> But I saw an issue like that before, and it might really be just a publisher problem
<didrocks> just relaunch a build manually once nux armfh is published
<didrocks> the closer we are to a possible faulty rev, the better :)
<MCR1> smspillaz: Hi. Bad news. I think Compiz r3512 broke window selection quite heavily... Sometimes you can click through windows on the desktop now, docks like Docky, Plank or glx-dock are not able to restore minimized windows anymore - Are you running Compiz trunk ?
<MCR1> @all: Can anyone confirm this regression ^^ ?
<smspillaz> MCR1: not at the moment
<smspillaz> MCR1: you sure it was 3512 ?
<smspillaz> MCR1: 3512 didn't touch the shape code
<MCR1> smspillaz: No, I am not 100% sure that it was r3512...
<smspillaz> MCR1: more likely would be 3513
<MCR1> smspillaz: Maybe r3513...
<smspillaz> MCR1: though, I wouldn't say "3513 broke it"
<MCR1> yes
<smspillaz> more likely is that 3513 is triggering a bug that was already there
<MCR1> I just know that working with windows and Compiz is quite complicated at the moment
<seb128> andyrock, ^
<smspillaz> MCR1: I'm a bit busy atm, but you can debug this yourself - check with xwininfo -all (and xwininfo -id (the parent window)) to make sure that the right window shape is applied up the chain
<smspillaz> seb128: leave andyrock alone :)
<seb128> smspillaz, he /query me 15 min ago asking if I was running compiz trunk and if I had issues that look like the one MCR1 is describing, he was looking for confirmation of whether there is a bug or if he has a local issue
<smspillaz> seb128: coolio :)
<seb128> ;-)
<MCR1> The most easy way to reproduce the problem is to install any Dock and try to minimize/restore windows with it...
<seb128> smspillaz, hey btw, how are you? ;-)
<smspillaz> mmmm okay
<smspillaz> I haven't been able to get that startup thing I was meant to be doing off the ground
<smspillaz> probably procrastinating it
 * smspillaz should probably get on to that
<smspillaz> seb128: how about yourself ?
<seb128> smspillaz, I'm good thanks ;-)
<MCR1> smspillaz: I would not nerve you, but this seems quite serious as it makes working with windows hard (sometimes you click through them or they become fully unresponsive)
<andyrock> seb128, smspillaz what's up?
<seb128> andyrock, I though the issue from MCR1 was similar to yours
<seb128> you were looking for confirmation
<smspillaz> MCR1: patience :)
<smspillaz> we are mere mortals
<MCR1> I do not like to bring the bad news, but I think it is better to identify such problems fast, until they get lost in the timespace and will be harder to find many revisions later...
<smspillaz> MCR1: of course, what I'm saying is, we'll get on to it soon
<smspillaz> but not right now
<MCR1> ok - you have been informed about the problem now ;)... thanks in advance
<andyrock> MCR1, [Fatal 13:09:00.015] DBus could not be found and is required by Docky. Exiting.
<MCR1> oh strange, Docky works here - but I got it from the ppa, maybe the version in the repo is not up-to-date
<MCR1> andyrock: docky-core/ppa
<MCR1> andyrock: You can also use any other dock, like cairo-dock or plank to reproduce
<andyrock> i'm installing docky ppa
<andyrock> still get that issue
<MCR1> andyrock: It seems to be Compiz r3513 causing the problem...
<MCR1> andyrock: btw, thanks 4 fixing the Place issue...
<MCR1> andyrock: I got it working here by changing the load order - Do all the Place plugin settings work now ? Like open window where the mousepointer is ?
<smspillaz> I wonder if the unity plugin is forwarding the ::place wrap function call
 * MCR1 is also wondering...
<andyrock> smspillaz, yes if the window was not maximized
<smspillaz> ... is that intentional ?
<smspillaz> because that's almost certainly broken behaviour
<andyrock> smspillaz, for what I see yes
<smspillaz> andyrock: can we see if it would be possible for forward the call ?
<smspillaz> the place plugins has lots of logic to ensure that windows end up in the right place, skipping it for all restored windows surely doesn't make any sense
<smspillaz> andyrock: or was it for maximized window sthat we skip it
<andyrock> i need to study unity history to see why it does not forward the call if the window was maximized
<smspillaz> ah
<smspillaz> it makes sense if it doesn't forward the call when the window is maximized
<MCR1> I just know that all different Place-plugin settings work perfectly if it is started after unityshell, so the fix should make all options in the Pace plugin fully functional...
<smspillaz> (eg, automaximization logic)
<smspillaz> MCR1: indeed, loading if after unityshell will cause the place logic to be called first
<smspillaz> however, I'd like to make sure that we don't load plugins after unityshell
<MCR1> yes, I know...
<MCR1> ;)
<smspillaz> having it at the end means we can make certain assumptions
<andyrock> MCR1, btw if you can still reprdouce the bug using compiz trunk (loading unityshell after the place plugin) ping me
<MCR1> andyrock: ok, I will restore original load order, test the new fix and report soonish...
<andyrock> danke
<MCR1> bitte
<smspillaz> heh
<smspillaz> "thanks please" is not often a phrase I hear used in english that much :)
<MCR1> smspillaz, it can be even better - like dankeschÃ¶n, bitteschÃ¶n - which would mean thanksbeautiful, pleasebeautiful...
<smspillaz> einshuldegen sie!
<smspillaz> (that is, about the extent of my german)
<MCR1> hehe
<Zhenech>  /wi3
<didrocks> sil2100: compiz is FTBFS as well, can you look at what's wrong? (eventually reverting if we cant' find the fix)
<sil2100> didrocks: ACK!
<didrocks> thanks :)
<sil2100> didrocks: the problem is not in compiz sadly
<sil2100> didrocks: it seems python2.7-minimal version 2.7.3-11ubuntu1 in raring is broken ;/
<sil2100> didrocks: or maybe something changed organization-wise maybe
<sil2100> didrocks: i.e. in the past python2.7-minimal was supposed to provide the pyconfig.h file, but version 2.7.3-11ubuntu1 doesn't provide it - although 2.7.3-5ubuntu5 still does, but the -11 one not
<didrocks> sil2100: do you have time to investigate a little bit? indeed, there has been an new python2.7 yesterday
<didrocks> sil2100: like pinging doko about I?
<didrocks> it?
<sil2100> didrocks: ok, I'll dig further
<sil2100> Maybe they moved it into another package
<didrocks> sil2100: there is a long changelog to look at :)
<didrocks> thanks again sil2100 :)
<sil2100> ;) Looking and pinging
<sil2100> np!
<katie> ivanka: https://plus.google.com/hangouts/_/812365a2aeff04c3d674ae01b47a680dd6d0090f?authuser=0&hl=en#
<sil2100> didrocks: ok, so, doko doesn't seem to be around to answer my questions, but from what I saw, the latest changes he made simply removed the pyconfig.h installation rules from debian/rules - and didn't really re-add/re-enable it anywhere else
<didrocks> sil2100: that's weird, he just uploaded a gcc though
<sil2100> didrocks: pyconfig.h is generated, but not installed
<didrocks> interesting
<didrocks> nothing in the changelog for that?
<sil2100> didrocks: so I would guess it's a packaging error on Ubuntu side - but to be sure I would have to poke doko
<sil2100> Nothing
<sil2100> http://bazaar.launchpad.net/~doko/python/pkg2.7-debian/revision/93
<sil2100> Here is the revision that removed the installation in debian/rules
<sil2100> I poked him on the channel and priv, so I guess he would answer if he was around
<didrocks> sil2100: I'm poking barry right now
<sil2100> didrocks: thanks! I'm guessing this got removed by accident during the debian/rules cleanup
<sil2100> Since I'm pretty sure that pyconfig.h is still as important as it was
<didrocks> yeah, possibly, I'll let you answering once barry is around :)
<didrocks> thanks for digging in!
<didrocks> sil2100: excellent work again! :)
<sil2100> didrocks: thanks :)!
<didrocks> sil2100: can you track that until the python fix is landing?
<didrocks> (maybe pinging people again if not by tomorrow morning ;))
<sil2100> didrocks: ACK - but as doko said, the python problem is a typo, so it should be fixed soon I hope!
<didrocks> hoping so :)
<bobweaver> Hello there anyone know where quicklinks are rendered in unity 2d ?
<bobweaver> I am have troubles with anchors
<bobweaver> I will take screenshot
<bobweaver> http://imagebin.org/238933
<bobweaver> I tried looking under shell/launcher/Launcher.qml and well all the all the rest I fixed the pips because they where off also but I was able to find that
<bobweaver> but I can not find the anchors.{what.ever } for quicklists
#ubuntu-unity 2012-12-12
<tgm4883> Do previews no longer support a URL for the thumbnail_uri?
<smspillaz> duflu: heya, do you want a fix for a stacking bug before we cut 0.9.9 or do you want to wait till next year ?
<duflu> smspillaz: Pretend I never mentioned 0.9.9.0. The dust has to settle and there be a stabilization period before such a tag
<duflu> So not this week anyway
<smspillaz> duflu: that won't really happen unless we say that a stabilization period has begun :)
<smspillaz> duflu: so ... do you want a stacking fix or should it wait ?
<duflu> smspillaz: No, just finish the keybinding and nvidia issues I think
<smspillaz> duflu: ok, well the nvidia thing is more or less done
<smspillaz> resizing windows is something else we can look at, but that's a can of worms IMO because it would involve redesigning the decor protocol
<smspillaz> that's the main slow part
<duflu> smspillaz: I have not seen any work on on the resize problem, so not done. But possibly simple to fix
<smspillaz> duflu: nah, its going to be complicated
<duflu> smspillaz: I doubt it. There's no reason to query the shape for every non-shaped window. That's the main problem
<smspillaz> duflu: a "simple" fix if you wanted one would be to simply not update the decorations while the window is being resized
<smspillaz> duflu: well, the biggest hit is that we do XGetWindowProeprty per-size-increment
<smspillaz> I think not querying the shape might help a little, but not a lot
<duflu> smspillaz: Well in my testing it always hangs in the XSync, and after that the XShareGetRectangles
<duflu> And removing those made a big difference
<duflu> Compiz is a bit buggy if you don't let it use XShape. That might be a bigger problem
<duflu> smspillaz: Anyway, pretend I'm not here for the rest of the week. I have enough commitments to management to complete before vacation without spending days on such things
<smspillaz> duflu: ok. In any case, the stacking fix is ready to go, and I think it fixes one of this biggest problems we had with it
<smspillaz> so if you want it, its there, just give me the word
<duflu> No really. Not interested myself. :)
<duflu> +t
<smspillaz> ok
<smspillaz> duflu: I'll get some stuff together for the new year then, looking at resize perf and other things
<smspillaz> duflu: I have an experimental branch to support GLX_EXT_buffer_age too, which will help with fbo performance as soon as the drivers support it
<duflu> smspillaz: XShape be gone!
<duflu> (where possible)
<smspillaz> ok, I'll look into it
<smspillaz> thanks
<duflu> smspillaz: I found the same problem with hanging on intel graphics (Atom) but did not check the stack to verify the same place
<smspillaz> duflu: well, my understanding is that resizing is slow in two places. 1. is the xshape thing, 2. is updating the decor pixmap every single time the window gets a new size
<duflu> smspillaz: Actually, yeah. I don't remember a test in which it was fast with decor still loaded. But while it was the primary issue was that XShape call
<smspillaz> you can sort-of optimize 2. by only fetching a new pixmap every time the window gets bigger, and then just re-using the last largest one when resizing the window to be smaller. It looks a little weird but is much faster
<smspillaz> I have an experimental thing somewhere which did that
<smspillaz> but the xshape thing is worth looking at
<smspillaz> duflu: in any case, lets stabilize 0.9.9 from this point onwards, and only look at new stuff once we've released it
<duflu> smspillaz: Try scripting up a delayed stack trace to fire off while the screen is frozen, if you haven't already
<duflu> You'll find the results are very consistent
<didrocks> hey Mirv!
<didrocks> so I looked at the compiz precise branch
<didrocks> it seems you didn't base on the packaging branch (it was still debian/ only, remember?). It was up to date on ~ubuntu-desktop/compiz/precise
<didrocks> oh, it's the quantal one, forgot that one
<didrocks> however:
<didrocks> * we did decide to only include unredirect fixes, it seems there are some additional for the grid, isn't it?
<didrocks> * for enabling it by default, did you try to upgrade on one of your quantal machine and ensure it was picking up the new gsettings default value? (on a machine where you never changed it?)
<duflu> smspillaz: Let me know if you're available to fix the segfault I just assigned you. If not I will...
<didrocks> sil2100: hey!
<didrocks> how are you?
<sil2100> didrocks: hello!
<sil2100> didrocks: fine, thanks - and you? I'm rebuilding compiz, testing the fix with the fixed python packages
<sil2100> So far so good!
<didrocks> sil2100: excellent! I'm good as well, thanks :) And thanks again for fixing it :)
<sil2100> np! :)
<sil2100> didrocks: you think it's safe to self-approve?
<sil2100> didrocks: since the compiz build succeeded
<didrocks> sil2100: it seems that duflu approved already :)
<didrocks> sil2100: but yeah, I was fine otherwise with self-approving ;)
<sil2100> Oh, hehe, indeed
<sil2100> duflu: thanks for testing and approving!
<hyperair> didrocks: speaking of the unredirect fixes, what exactly do they fix?
<duflu> sil2100: No testing on that one. It's right in theory and if there's a mistake then Jenkins will find it
<didrocks> hyperair: fullscreen opengl apps framerate
<didrocks> hyperair: compiz won't touch it automatically
 * hyperair is running unity from the something sru ppa
<hyperair> didrocks: wasn't it working before?
<didrocks> hyperair: compiz was handling the windows
<hyperair> how do you tell if a window is being unredirected properly (besides looking at the frame rate)?
<didrocks> hum? the fix is about unredirect them or not automatically
<hyperair> didrocks: i mean i manually flipped that setting using ccsm. did it not work before?
<didrocks> that's it
<didrocks> hyperair: well, it's manual, not automatic for some reason
<hyperair> er
<didrocks> like driver crashes and more fixes needed
<hyperair> ah.
<didrocks> so the fixes are getting in
<hyperair> so basically you couldn't turn it on by default because there were driver crashes?
<didrocks> and we'll switch it on by default
<didrocks> yep
<hyperair> i see.
<hyperair> i had it on already on snb, so i guess that worked..
<didrocks> you would have known really quickly if it didn't :)
<hyperair> how so?
<didrocks> like exiting the fullscreen opengl app -> crash :)
<hyperair> hmm.
<hyperair> but what if compiz doesn't successfully unredirect the app?
<hyperair> does that happen?
<didrocks> I don't think so, duflu can answer
<didrocks> but you can check with the framerate :)
<hyperair> eh well it's really hard to tell with team fortress 2
<hyperair> it lags all the time anyway
<didrocks> :)
<hyperair> it's hard to tell whether it's lagging more or less
<hyperair> it depends on the number of bots running around in the map too
<hyperair> one thing i did notice -- when i turn on the unredirect full screen windows setting, alt-tabbing out and alt-tabbing back in results in a frozen image
<hyperair> it's like it takes 1-2 minutes for team fortress 2 to notice that it's been unredirected.
<didrocks> not sure, maybe duflu would know about it, I didn't have time to play with the setting
<hyperair> okay
<duflu> hyperair: Alt-tab freezes are mostly fixed in compiz 0.9.8.6, with an extra fix in 0.9.8.8. Also, if you're using the fglrx or nouveau drivers then they cause such freezes sometimes too
<hyperair> duflu: it's snb.
<hyperair> sandy bridge
<hyperair> hmm, i'm running 0.9.8.6, and the freeze is present.
<hyperair> it takes around 2 minutes for tf2 to "notice" the unredirection and start drawing an image again, weirdly enough.
<didrocks> sil2100: do you know if Mirv is working today? I pinged him 2 hours ago
<duflu> hyperair: Sounds like bug 1084401 if you're alt-tabbing to a window on another workspace. But even if not then it could still be the same bug.
<ubot5> Launchpad bug 1084401 in Compiz Core "Unredirected fullscreen windows freeze and stay on top when wall sliding (Ctrl+Alt+Left/Right)" [High,Fix committed] https://launchpad.net/bugs/1084401
<hyperair> duflu: that doesn't quite sound like it. i don't have issues alt-tabbing away. i have issues alt-tabbing back into the game.
<hyperair> duflu: after i alt-tab into the game, it shows the screen, and you can click on things in the game and interact with things, but the image doesn't refresh
<hyperair> so you can hear stuff like button hover effects
<hyperair> and if you alt-tab out and alt-tab back in again, the image refreshes.
<hyperair> but you don't actually get a live image until you sit with the game in foreground and wait for ~2 minutes.
<duflu> hyperair: I'll test it but if it's a problem then you should disable unredirection in CCSM>Composite for now
<hyperair> hmm
<sil2100> didrocks: I would think he is, but let me double check that
<didrocks> thanks :)
<popey> didrocks, he sometimes has to go afk downstairs to do multi-monitor testing with his TV :)
<didrocks> ok ;) 2 hours, it's a long film! :-)
<popey> haha
<duflu> EXPECT_TRUE (popcorn)
<didrocks> ;)
<duflu> hyperair: You mean you're using Sandy Bridge graphics and not just the CPU, right? :)
<duflu> hyperair: Also, what Ubuntu version and/or Mesa version?
<Mirv> didrocks: hi, sorry, didn't look at freenode side at all
<hyperair> duflu: yes.
<hyperair> duflu: 12.10, mesa from xorg-edgers
<hyperair> OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
<hyperair> OpenGL version string: 3.0 Mesa 9.1-devel
<duflu> hyperair: We have countless bugs with xorg-edgers. Please test with regular quantal Mesa 9.0 too
<didrocks> Mirv: I'll let you backlog
<Mirv> didrocks: so quantal indeed. the final 0.9.8.6 included the two grid related commits, aside from that it's only unredirect. I thought grid plugin can be tested at the same time.
<Mirv> didrocks: and sure, the new default was also tested and various people have reported back on having speedups and also reported on the tearing problems which were then worked upon
<didrocks> Mirv: by tested, I meant:
<didrocks> they have an old default configuration
<didrocks> added the new one
<duflu> Mirv: You squeezed the fix for bug 1084401 into your 0.9.8.6 didn't you?
<ubot5> Launchpad bug 1084401 in Compiz Core "Unredirected fullscreen windows freeze and stay on top when wall sliding (Ctrl+Alt+Left/Right)" [High,Fix committed] https://launchpad.net/bugs/1084401
<didrocks> and the switch is one?
<didrocks> on*
<didrocks> (without having to play in ccsm)
<Mirv> duflu: yes, and the tearing blacklists
<duflu> didrocks, Mirv: FYI I am aiming to have unredirect on by default for precise in 0.9.7.12
<Mirv> didrocks: and yes, it switches it if default is in use
<hyperair> duflu: i did have issues with it, that's why i went and upgraded to xorg-edgers.
<Mirv> didrocks: so tested in both guest session and a normal user
<duflu> hyperair: We have lots of bugs with xorg-edgers but I have not encountered such a hang with 9.0 on Sandy Bridge quite like yours yet. Please log "ubuntu-bug compiz" so we don't forget your issue
<hyperair> okay
<hyperair> i'll ppa-purge later and check again
<hyperair> duflu: do i have to downgrade my kernel as well?
<duflu> hyperair: Unfortunately, yes. We can't provide effective support unless you at least test with vanilla versions
<didrocks> Mirv: excellent, ok, it's a little bit different than the initial planning as I only wanted unredirect by default, but let's try that
<didrocks> thanks duflu, do you have anything more? like crashes in driver?
<hyperair> hmm okay.
<duflu> didrocks: I have lots of unredirect issues. For quantal aim to have it all resolved in 0.9.8.8, and precise 0.9.7.12
 * popey has crashes in precise with unredirected :(
<popey> but you know about those
<duflu> popey: Your driver will soon be blacklisted because Bryce can't yet figure out what Mesa fixes it needs
<popey> "awesome"
<popey> :)
<hyperair> duflu: is SNA enabled or disabled in stock ubuntu?
<hyperair> quantal i mean.
<duflu> hyperair: Not sure. I thought it was off. Is there an easy check?
<hyperair> check Xorg.0.log
<hyperair> there's a mention of it
<hyperair> just grep -i sna
<duflu> hyperair: No mention. I suspect it's not compiled into quantal (still)
<didrocks> duflu: do you have a list somewhere of the remaining precise compiz unredirect issues?
<hyperair> i see.
<hyperair> i recall there being a regression in xorg-edgers when sna got flipped off, and at the same time tf2 fixed itself. i should try testing with sna off to see how that fares
<duflu> didrocks: https://bugs.launchpad.net/compiz/+bugs?field.tag=unredirect for compiz bugs. The driver bugs I don't have a reliable filter for right now. Just assume nouveau and intel are bad on precise. They will be automatically blacklisted in 0.9.7.12
<Mirv> didrocks: thanks.
<didrocks> duflu: ok, thanks for the head's up
<didrocks> duflu: I guess you work with RAOF and bryce on the driver side?
<didrocks> for intel and nouveau?
<didrocks> (especially intel)
<Mirv> bryce has been cc:d in all discussions
<Mirv> hyperair: yes SNA is still not enabled even in raring, although probably it'd be considered during the cycle given the benefits and the time it has now been maturing (and mostly the only thing getting new work done)
<hyperair> Mirv: i noticed rc6 residency is a lot better with sna than without
<duflu> hyperair: residency? You mean it sticks to rc6 more of the time with SNA?
<Mirv> I used to have regressions on i915 / GMA 3100 (integrated into Atom N470), but now I think SNA has been playing fine also on my netbook.. and on my 965G (GMA X3000) machine, everything seems fine
<hyperair> duflu: yes. a lot more.
<duflu> hyperair: Exciting, thanks. How are you measuring time spent in rc6 BTW?
<hyperair> duflu: powertop reports something like 0-10% RC6pp residency without SNA, but with SNA, it goes up to 60-80% when compiz is idling.
<hyperair> duflu: the second tab of powertop
<duflu> Thought so.
<duflu> Cool
<duflu> (literally)
<hyperair> hahaha
<hyperair> yes, there's a significant temperature difference when rc6 comes into play.
<hyperair> when the kernel disabled rc6 by default, i noticed a 10Â°C jump in idle temperature
<duflu> Hmm, I wonder if that's the big change in raring. I noticed my Sandy Bridge laptop getting much better power usage in raring than quantal
<hyperair> it could be
<Mirv> but, I still have this one regression on sandy bridge where in Unity/compiz the inactive window title bar decoration is drawn wrongly
 * duflu covers ears
<didrocks> mmrazik: not sure if your utf8 fix worked: https://code.launchpad.net/~didrocks/ubuntu-wallpapers/bootstrap/+merge/139400
<didrocks> or is the queue just crowded?
 * Mirv files bug
<Mirv> duflu: FYI it might be interesting also for you to see how it's drawn incorrectly on SNA https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1089269/+attachment/3458107/+files/inactivewindowtitlebar.png
<ubot5> Launchpad bug 1089269 in xserver-xorg-video-intel (Ubuntu) "[sna] inactive window title bar sometimes drawn incorrectly" [Undecided,New]
<Mirv> duflu: rc6 has been enabled by default in Ubuntu kernels since precise, and SNA is still not enabled by default (except for xorg-edgers)
<duflu> Mirv: Yeah I know
<hyperair> Mirv: weird, i don't get that here.
<didrocks> Mirv: looking good and working fine here, sponsoring to quantal-proposed! Thanks :) FYI, I pushed the branch as we discussed last time to ~ubuntu-desktop/compiz/quantal
<Mirv> didrocks: thanks a lot, and yes I remember. let's see how long it takes to spend in the queue.
<didrocks> Mirv: want to bet on that? :p
<Mirv> no bets, but I hope for slightly faster turnaround than with the last updates when queue just kept queueing more
<didrocks> hey JohnLea! do you have a minute to discuss about wallpaper?
<JohnLea> didrocks; good timing, fire away?
<JohnLea> ignore the '?@
<JohnLea> can't type this morning again ;-)
<didrocks> heh, so reading https://bugs.launchpad.net/ayatana-design/+bug/1081702 I think people are right about compression quality
<ubot5> Launchpad bug 1081702 in ubuntu-wallpapers (Ubuntu) "Update the default wallpaper in 13.04" [Undecided,Confirmed]
<didrocks> JohnLea: as we don't have the CD size limit, can we envision have lower compression? even maybe none at all with loseless png?
<JohnLea> didrocks; are we no longer space limited then?  There is also one other problem we are solving with the noise however, on cheep monitors you get 'colour banding' that the noise fixes, this isn't a problem on high quality monitors
<JohnLea> didrocks; I'll speak to Otto and see what he says
<didrocks> JohnLea: ah, so maybe it's linked, indeed :)
<didrocks> JohnLea: ok, keep me posted, I'm not pushing before that
<didrocks> thanks!
<JohnLea> didrocks; will do, thx!
<didrocks> yw ;)
<JohnLea> didrocks; can we use .png as wallpapers?
<didrocks> JohnLea: you can encode in png, just leave the filename the same
<didrocks> it's already a filename containing .png btw
<didrocks> JohnLea: if you want to test on your system, just replace /usr/share/backgrounds/warty-final-ubuntu.png with your file
<didrocks> fail :)
<didrocks> 11:40:35   JohnLea | didrocks; can we use .png as wallpapers?
<didrocks> 11:40:52  didrocks | JohnLea: you can encode in png, just leave the filename the same
<didrocks> 11:42:01  didrocks | it's already a filename containing .png btw
<didrocks> 11:42:12  didrocks | JohnLea: if you want to test on your system, just replace /usr/share/backgrounds/warty-final-ubuntu.png with your file
<JohnLea> didrocks; thx for re-posting
<didrocks> yw! :)
<mmrazik> didrocks: srry. I was on a phone...
<didrocks> no worry :)
<sil2100> JohnLea: I assigned the design team to 2 bugs
<sil2100> https://bugs.launchpad.net/unity/+bug/1076424
<ubot5> Launchpad bug 1076424 in unity (Ubuntu) "Fuzzy lens icons in dash overview." [Low,In progress]
<sil2100> https://bugs.launchpad.net/unity/+bug/1089258
<ubot5> Launchpad bug 1089258 in Unity "Music Lens icon metaphor is incorrect." [Undecided,In progress]
<JohnLea> didrocks; bug #1081702 updated with the non-compressed wallpaper.  I have tested it on my computer and it works well.
<ubot5> Launchpad bug 1081702 in ubuntu-wallpapers (Ubuntu) "Update the default wallpaper in 13.04" [Undecided,Confirmed] https://launchpad.net/bugs/1081702
<didrocks> sweet, let me look at the size :)
<JohnLea> sil2100; looking at them now
<JohnLea> didrocks; 5.5MB
<didrocks> JohnLea: did you notice any slowliness?
<didrocks> like login time?
<didrocks> JohnLea: I would appreciate a middle-ground if possible :)
<didrocks> not going like 10x bigger
<didrocks> (wondering about the speed on a hard drive)
<sil2100> JohnLea: thanks! :)
<JohnLea> didrocks; I was soo stunned by the improved quality of the background, that all other thoughts and considerations faded into meaningless
<JohnLea> ;-)
<didrocks> JohnLea: ahah! I can see that ;) do you think you can find this middle-ground between quality and size?
<JohnLea> didrocks; I'll ask Otto, he is in a meeting atm, will have to grab him later.  But I know this image is hard to compress because the noise which is added to fix banding makes compression harder.
<didrocks> keep me posted :)
<didrocks> mmrazik|lunch: hum, I then didn't see your answer on the wallpaper stalled merge :)
<JohnLea> didrocks; hyia, just spoke to Otto, he said that if possible it would be much better to use the 5.5MB png image I uploaded, because making it any smaller will require changing to .jpg compression that *will* introduce artefacts even at low levels of compression
<didrocks> JohnLea: I'm a little bit worrying about reading that and effects on boot time
<didrocks> JohnLea: can we try to first have a 2Mb image, put that for now, then, when the benchmarking is there, we can try to switch to it?
<JohnLea> didrocks; can we quantify that?  also is their any gain to offset the increased read time as a result of not having to decompress a .jpg?
<didrocks> and mesure :)
<didrocks> JohnLea: not right now, well, decompression of a .jpg file is not an issue as it's handled by the gpu nowadays natively
<JohnLea> didrocks; or put the 5.5MB image in, and then see the effect?  we can always revert if people complain
<didrocks> so it's more quicker to pass small amount of data AFAIK :)
<didrocks> JohnLea: well, we don't do that anymore in ubuntu, breaking and seeing the feedback :)
<didrocks> otherwise, I'll just put the 700 kb if there is no way to have a middle-sized image
<JohnLea> didrocks; the question is 'what is the impact of a 5.5BM image versus a 2MB image on boot time' and how does the cost of this balance against 'a high quality background with no compression artefacts versus some background compression artefacts'.  My vote is that for example a less than 1 second increase in boot time is a worthwhile price for a better fidelity background, but I know others may have other opinions ;-)
<JohnLea> more than 1 sec increase in boot time is not worth the cost IMHO
<didrocks> JohnLea: well, you can count 1s of boot time is fine for design, but when you budget is 4s to load the whole desktop, 25% of this time just to load the background is not acceptable
<didrocks> JohnLea: so as long as we don't have benchmarks, I would prefer that we don't explode the time on presumption
<JohnLea> didrocks; Otto is having a go at making a mid way file now, will see how that goes
<JohnLea> didrocks; agreed, difficult to decide without benchmarks
<didrocks> JohnLea: yeah, so let's get better for now, without going bindly in one direction :)
<solancer> Any c++ devs in the house
<solancer> anyone ?
<solancer> anyone who can fix this PPA https://launchpad.net/~ikarosdev/+archive/unity-revamped
<Mirv> solancer: according to the user page the PPA is maintained by IRC nick ikarosdev or isaacj87, but he's not on this channel
<mhr3> JohnLea, could you comment on https://bugs.launchpad.net/unity-lens-music/+bug/972987 ? (it's a quick one) :)
<ubot5> Launchpad bug 972987 in Music Lens "Genre "Classic" should be "Classical"" [Undecided,In progress]
<JohnLea> mhr3; does the word "Classical" fit in the button?  If so +1 from me
 * mhr3 checks
<JohnLea> sil2100; I've attached the new Dash nav bar icons to a bug report for uploading, see bug #1089373  Could you upload these?
<ubot5> Launchpad bug 1089373 in Music Lens "Dash - Update Dash nav bar icons" [High,Triaged] https://launchpad.net/bugs/1089373
<sil2100> JohnLea: I'll try creating a merge request after I'm done with lunch - thanks!
<mhr3> JohnLea, it fits, can you add your +1 on the bug?
<didrocks> mhr3: can you try to grab existing translations to not break them, please?
<mhr3> didrocks, i'm doing it now so translators have enough time
<mhr3> and we don't have the translations upstream
<didrocks> mhr3: well, it's better to grab and keep current translations right now
<didrocks> mhr3: that's something which can be fixed :)
<mhr3> i had a feeling it was desired
<didrocks> mhr3: I think it would be nice to the whole translator community to not break that
<mhr3> didrocks, so what do you want me to do exactly?
<didrocks> mhr3: maybe do the change, and let's keep an eye on it, right?
<JohnLea> sil2100; thx!
<didrocks> mhr3: if we don't see that many translations coming by the end of the cycle, we can steal from them
<didrocks> wdyt?
<JohnLea> mhr3; already added +1 to https://bugs.launchpad.net/unity-lens-music/+bug/972987
<ubot5> Launchpad bug 972987 in Music Lens "Genre "Classic" should be "Classical"" [Undecided,In progress]
<mhr3> didrocks, it's conflicted anyway, will give the author some time to fix it
<didrocks> we'll see :)
<mhr3> JohnLea, thx
<solancer> Unity-Revamp PPA is not working any solutions ?
<didrocks> solancer: you already asked here and Mirv answered you
<didrocks> this is not an official ppa
<didrocks> and you should ping the maintainers that are not on that IRC it seems
<didrocks> sil2100: seems your compiz fix failed: https://launchpadlibrarian.net/125569887/buildlog_ubuntu-quantal-i386.compiz_1%3A0.9.9~daily12.12.05bzr3524pkg0quantal0_BUILDING.txt.gz
<didrocks> :(
<solancer> oh I din't see that
<solancer> sorry
<didrocks> sil2100: oh it did work!  * State: Failed to upload
<solancer> my question was if there was a way to clone the PPA and work on it
<didrocks> sil2100: sorry, was trapped by the email :)
<didrocks> solancer: you can add the deb-src in your source file
<didrocks> and apt-get source from it
<didrocks> you will get the code that way :)
<solancer> oh no I'm not gud with C++ I'm more of a python guy
<solancer> I was looking for someone who could do work on the PPA
<didrocks> solancer: ok, not sure who apart from the maintainers of this PPA is working on it, but here, you have more the upstream guys, making unity in ubuntu, no tweaked changes :)
<mmrazik> didrocks: is the "Fix Committed" for the Autopilot task here a bug?
<mmrazik> https://bugs.launchpad.net/autopilot/+bug/1067161
<ubot5> Launchpad bug 1067161 in Autopilot "No timestamp in verbose log" [Low,Fix committed]
<mmrazik> shouldn't it be Fix Released?
<didrocks> mmrazik: not really, so this is a discussion I should open after the end of years holidays
<solancer> didrocks, oh I see
<mmrazik> didrocks: okay :)
<didrocks> mmrazik: there is a debate if the autoupload should only close downstream bugs or should close the upstream ones
<mmrazik> didrocks: I was just asked by thomi yesterday
<mmrazik> fginther: ^^^
<didrocks> mmrazik: I have no strong opinion either way :)
<solancer> didrocks, where can I discuss this topic ?
<didrocks> solancer: no idea, try to reach/contact the maintainers that Mirv pointed out first
<solancer> didrocks, I did but the guy never replied back, looks like he's on vacation or something
<solancer> didrocks, thanks for your help I try looking into the code and see if I can't find a hack
<solancer> didrocks, nice talking to you
<fginther> mmrazik, didrocks thanks
<mterry> fginther, hello!  Are you aware that we forgot about libunity-misc in the last round of inlining?  I have an inline-packaging branch, but I didn't want to set it to approved until the landing job is adjusted for it
<fginther> mterry, please point me to the merge proposal and I'll get it set up
<didrocks> thanks mterry, fginther :)
<didrocks> mterry: how was your day off?
<mterry> fginther, thanks: https://code.launchpad.net/~mterry/libunity-misc/inline/+merge/139110
<mterry> didrocks, fine!  Hung out with some friends
<didrocks> mterry: sweet! :) you missed again the fun with python breaking compiz ;-)
<mterry> didrocks, perfectly planned then  :)
<mterry> didrocks, what happened?
<didrocks> indeed, you have a gift I guess!
 * mterry is still reading emails
<didrocks> oh, it's not on emails, it's just that they multiarched one file
<didrocks> and they broke a few project using the direct path for including it, some indicators, compiz, and apparently firefox
<didrocks> but sil2100 pushed a fix :)
<didrocks> mterry: once you would have finished with your catch up, can you sanitize the hud project to follow the same packaging than the rest? bootstrapping and so onâ¦
<didrocks> also, https://launchpad.net/testapp if you have time
<mterry> didrocks, yup, still got that on my TODO
<mterry> didrocks, testapp?
<didrocks> mterry: yeah, apparently, autopilot needs it to run some of the tests from unity
<mterry> didrocks, seems poorly named....
<didrocks> mterry: and finally, I know that cyphermox is stricking in 4 projects to have the tests running in a chroot, would be nice if you can give a hand
<didrocks> mterry: do you sometimes overlap with thomi?
<didrocks> he's just living at the opposite side of the world and my 12 hours of daily presence is missing him :)
<didrocks> I would agree it should be renamed
<mterry> didrocks, I haven't noticed
<mterry> cyphermox, heyo!  Poke me when you get a chance if I can help with the chroot projects
<didrocks> mterry: well, try to catch him in your evening if you can (there is no hurry on this one)
<mterry> didrocks, what's this about?
<didrocks> mterry: oh, the testapp naming :)
<didrocks> he's the upstream
<mterry> didrocks, ah ok
<didrocks> mterry: FYI I know that cyphermox is sick today, so maybe not really reponsive :)
<didrocks> that's it for you, I'll let you go back to your catchup! Thanks a lot mterry :)
<mterry> didrocks, OK, I'll lie in wait for him
<didrocks> sounds good :)
<didrocks> unico powerpc finally built \o/
<mterry> didrocks, now that I'm subscribed to unity bugs and merges, catchup takes so much longer.  Though I realize I'm whining to the wrong person here
<didrocks> mterry: if you only saw what was the frequency of bugs and merges just a year agoâ¦ :)
<didrocks> it's really quiet, you should enjoy it! :-)
<JohnLea> sil2100; Matthieu has just added a updated icon for the Gwibber Lens to bug #1089373     Did you see how quickly this was posted by omg!
<ubot5> Launchpad bug 1089373 in Music Lens "Dash - Update Dash nav bar icons" [High,Triaged] https://launchpad.net/bugs/1089373
<didrocks> JohnLea: btw, did you find anything for the wallpaper?
<JohnLea> they wrote a story about it only 15min after I posted the bug!
<sil2100> JohnLea: ACK ;)
<sil2100> hohoho
<sil2100> Nice
<didrocks> sil2100: ignoring my messages about the test results? I'm not sure if it's a ack or nack :p
<JohnLea> didrocks; not yet, otto's has been at lunch and in meetings, will try to grab him when he gets back
<didrocks> JohnLea: ok, let's try to do that before christmas holidays :)
<didrocks> JohnLea: and I won't push that on Friday! :p
<JohnLea> didrocks; I want to try to get it over to you today
<didrocks> JohnLea: that would be awesome!
<seb128> sil2100, hey
<didrocks> mterry: oh btw, for everything that could use a test, please note them on http://pad.ubuntu.com/ubuntu-unity
<didrocks> that's easier to track then :)
<mterry> ah right
<didrocks> thanks ;)
<sil2100> didrocks: wait wait!
<sil2100> didrocks: I'm working on the autopilot test failures, which in fact cause closing of all my terminals
<sil2100> So I didn't see what's going on on my screen's, sorry about that ;)
<sil2100> Let me read up what's going on
<didrocks> sil2100: ahah, that's not a funny bug :)
<sil2100> It's due to me using self.start_app instead of self.start_app_window ;p
<sil2100> seb128: hi!
<sil2100> didrocks: hm, what test results do you have in mind exactly? It seems I would have to backtrack a lot to get to it!
<seb128> sil2100, hey, we were wondering if you were receiving IRC pings or not ;-)
<sil2100> seb128: sorry about that, damn that autopilot clean-up code!
<seb128> sil2100, no worry ;-)
<didrocks> sil2100: the one I pointed to you:
<didrocks> http://dc-jenkins:8080/job/ps-indicators-autopilot-release-testing/28/testReport/
<sil2100> Aaaaaaaah
<sil2100> Ok, sorry, I'm working on those just now ;)
<sil2100> hehe, man, I think hm, I was a bit confused and just didn't register your question correctly ;p
<didrocks> sil2100: oh, you just didn't answer me, hence I was wondering :)
<sil2100> didrocks: ok, so a few tests are a bit unsafely written, which I am modifying a bit so that the failures won't happen gladly
<didrocks> sil2100: excellent, keep me posted! :)
<didrocks> excellent ;)
<didrocks> hence the flackyness?
<sil2100> Most likely yes
<fginther> sil2100, I can spare some cycles if you need me to look at some of those failures
<fginther> mterry, libunity-misc is ready to autoland. I'll keep an eye on it in case it fails
<mmrazik> fginther: btw. it looks like jenkins has (again) issues picking up new jobs/configs (long queue). Not sure if its because something got stuck or it naturally grows now
<mterry> fginther, awesome, thanks
<mmrazik> fginther: I was triggering some autolandings manually today with the trigger-autolanding job
<fginther> mmrazik, :-( I'll trigger this one as well
<didrocks> fginther: it seems unity-merger picked it up first
<didrocks> fginther: maybe it's still configured for libunity-misc :)
<fginther> didrocks, I also noticed that and disabled it :-). I had completely forgot about that
<didrocks> ok ;)
<mhr3> mterry, ping?
<mterry> mhr3, hello
<mhr3> mterry, hey, re https://code.launchpad.net/~mterry/unity-lens-music/valac-0.18/+merge/139037 could you revert the m4 changes? i don't think it makes sense to change the behaviour for a single lens, if there was a standard macro that did this, it'd be awesome but this just adds to confusion imo
<mhr3> plus one can just do `./configure VALAC=/usr/bin/valac-0.18`
<popey> didrocks, bug 1060543  . what's that waiting for?
<ubot5> Launchpad bug 1060543 in One Hundred Paper Cuts "Additional Drivers is not discoverable in Quantal" [Undecided,New] https://launchpad.net/bugs/1060543
<popey> needs to go to raring first?
<mterry> mhr3, sure, for this simple case.  I use that macro in a lot of packages though, and sometimes you want to prefer say 0.16, allow 0.18, and fallback to unversioned.  But sure.  I can revert the m4 change and manually specify it in the rules file instead
<mhr3> mterry, as upstream i can promise we'll support latest stable vala ;)
<mhr3> although with warnings from time to time :)
<didrocks> popey: a release?
<didrocks> popey: if you don't see one past this holidays period, just ping me back
<popey> didrocks, ok thanks
<popey> just seeing people complaining that searching for "drivers" gets them golf clubs
<popey> which is sub-optimal :)
<didrocks> ahah, really?
<didrocks> awesome!
<mterry> mhr3, branch updated
<mhr3> mterry, thx, approved
<mterry> didrocks, did you want me to keep an eye on the hud package going forward?  (i.e. add it to my list of cared-for-packages)
<didrocks> mterry: it's more on cyphermox's plate I guess, but as it's cross stack, one more isn't bad :)
<mterry> k
<mterry> wait, I don't follow
<mterry> You want us both to look at it?
<mterry> didrocks, or I guess I'm reading that as me
<didrocks> mterry: no the "one more" is that, if you can double check this one in particular
<didrocks> as it's going to a lot of changes in the coming days (as most of the code is moving for indicator-appmenu), it's good to be more than one looking at it
<didrocks> then, on a maintenance base, cyphermox alone should be enough :)
<mterry> didrocks, gotcha
<didrocks> thanks :)
<mterry> didrocks, what about testapp?
<didrocks> mterry: will be on cyphermox's plate for sure
<mterry> who owns autopilot?
<mterry> ok
<didrocks> "misc" stack
<didrocks> JohnLea: I guess there will be no new wallpaper today?
<sil2100> didrocks: besides the badly written autopilot tests, we were able to find a regression as well \o/
<sil2100> https://bugs.launchpad.net/unity/+bug/1089482
<ubot5> Launchpad bug 1089482 in Unity "Unity HUD uses wrong icon when switching from the Dash to HUD" [Undecided,New]
<sil2100> Confirmed with trunk on both raring and quantal
<didrocks> sil2100: excellent \o/ this is useful as well! :)
<didrocks> sil2100: and you are writing/fixing a test for it? :)
<sil2100> No, I fixed another test, this AP test was actually working correctly ;) And failing as it should!
<didrocks> ahah ;)
<JohnLea> didrocks; I have a new wallpaper for you, 2.1MB ;-) https://bugs.launchpad.net/ayatana-design/+bug/1081702
<ubot5> Launchpad bug 1081702 in ubuntu-wallpapers (Ubuntu) "Update the default wallpaper in 13.04" [Undecided,Confirmed]
<didrocks> JohnLea: sweetness!
<JohnLea> didrocks; skype?
<didrocks> JohnLea: mumble or hangout, my skype setup doesn't really work
<mterry> tedg, why does the hud install hud-service in the indicator-appmenu location?
<mterry> tedg, (are there hardcoded paths to it outside of the service file?)
<tedg> mterry, hud package?
<tedg> mterry, Or the indicator-appmenu package?
<mterry> tedg, yeah in the new hud split package
<tedg> mterry, Uhm, bug.  I thought I'd fixed it though...
<mterry> tedg, oh maybe you have in a separate branch, but not in trunk.  OK
<mterry> tedg, I'm working on a branch to have the packaging do the same stuff as the rest of PS packages (dh9 etc)
<tedg> mterry, ?  Trunk is dh 9 for me.
<mterry> tedg, fascinating...
<tedg> mterry, bzr branch lp:hud ?
<mterry> tedg, ah...  you mean you depend on dh9, but you didn't bump compat
<mterry> doesn't do much good without bumping compat
<tedg> Oh, oops.
<tedg> mterry, But yeah, the hud service is a libexec program.
<tedg> mterry, It shouldn't be in indicator-appmenu.
<tedg> Oh, the install file is moving it.
<tedg> Weird
<mterry> tedg, yup.  it was just installing into /usr/lib/indicator-appmenu and I thought it was for compatiility reasons
<tedg> I must have looked through the code and forgot to change that line twice.
<mterry> OK.  no biggie, I can fix in my branch
<didrocks> fginther: is this one merging? https://code.launchpad.net/~didrocks/ubuntu-wallpapers/raring-wallpaper/+merge/139517
<mterry> alesage, https://jenkins.qa.ubuntu.com/job/testapp-ci/build=pbuilder,distribution=quantal,flavor=amd64/7/console
<mterry> alesage, fails during 'archiving the artifacts'
<mterry> alesage, looks coverity related.  Do I need to do something to fix coverity for this branch?
<alesage> mterry this has to do with finding JUnit-type test results, simply untick that box in the config
<alesage> if this is mmrazik template job, both JUnit test reporting and coverage results are enabled by default--if you have none you should disable
<alesage> mterry what's testapp?
<mterry> fginther, ^ for the testapp package
<mterry> alesage, some helper for creating windows to test a window manager.  I'm working on getting them to change the name
<alesage> as if they could encompass all of testing of apps in Ubuntu indeed :)
<fginther> alesage, testapp is some tool that thomi built to provide specific application features to an autopilot test. Like creating an app that doesn't have a menu
<alesage> fginther, o gotcha
<thomi> ...I think someone needs to package it for raring however
<thomi> not sure if veebers fixed that or not
<veebers> thomi: no I didn't
<veebers> thomi: let me know what needs to happen and I will :)
<thomi> veebers: I guess we need inline packaging, if it's not already got it, and then we need to talk to fginther about adding it to the new fancy-pants build system
<veebers> thomi: sweet, sounds good. I'll start badgering fginther about that then :)
 * alesage admires fginther's pants
<fginther> veebers, the dull-pants build system will probably suffice
<veebers> fginther: heh, nice :) Alright sounds good
<fginther> veebers, but I can still help get that going :-)
<veebers> fginther: awesome
<fginther> veebers, looks like lp:testapp already has inline packaging
<veebers> ah cool, was just branching to check
<fginther> mterry, it looks like the testapp-ci job was just configured incorrectly. I removed the step where it was looking for test files which did not exist
<mterry> fginther, thanks!
#ubuntu-unity 2012-12-13
<smspillaz> duflu: hollyyyy ... did you see the new nvidia driver release ?
<smspillaz> Improved performance of OpenGL framebuffer object binds with Xinerama enabled by 2000-3000% when the application's windows do not span screen boundaries.
<smspillaz> lol
<duflu> Hah
<duflu> Nice
<smspillaz> duflu: buffer age support too!
 * smspillaz cracks open his branch to try it out to see how much faster it is
<smspillaz> duflu: buffer_age means that we can finally use glXSwapBuffers without redrawing the whole backbuffer on every frame
<duflu> That's handy, but not if only 1 or 2 drivers do it
<duflu> smspillaz^
<smspillaz> still great if at least one does!
<smspillaz> the free drivers will support it in the next kernel release from what I've heard
<duflu> smspillaz: Mesa claimed to implement GLX_OML_swap_method but it never really worked. So I'm not holding my breath
<smspillaz> duflu: buffer age is different
<smspillaz> its really easy to implement driver side
<duflu> My point still holds. I'll believe it when it's released and working
<smspillaz> :)
 * smspillaz adds xorg-edges
<smspillaz> *xorg-edgers
<smspillaz> duflu: seems to work OK, though I suspect their implementation is a bit slow atm
<smspillaz> maybe they do the buffer age tracking server side
<smspillaz> duflu: nope, scratch that, forgot to enable lazy positioning :)
<smspillaz> duflu: so awesome, it works great. I'll have something up for you /others to test tomorrowish
<duflu> smspillaz: Tomorrow is my last day before vacation. No promise of any more large reviews this year :/
<smspillaz> duflu: no problem, it needs lots of testing anyways, it can wait
<smspillaz> duflu: anyways, we no longer need to worry about the performance impact of doing that fbo bind on every frame, at least on nvidia \o/
<smspillaz> I think nvidia is going to go from our worst performing driver to our best
<duflu> smspillaz: Cool. I thought I modified the FBO class to be smart enough to never rebind until absolutely required though
<duflu> (when it needs a different FBO)
<smspillaz> duflu: ah, when was that ?
<duflu> smspillaz: Before GLES landed
<smspillaz> right
<smspillaz> duflu: althoguh you still have to switch between fbo and backbuffer to draw a frame
<duflu> smspillaz: But that is only optimal for that class. If you can make the calling code (opengl plugin) rebind to different FBOs less often then that could still help
<smspillaz> indeed, although for most frames we only do it once
<smspillaz> erm, twice
<smspillaz> once to fbo, once to back
<smspillaz> glxswapbuffers
<smspillaz> with buffer_age we don't even have to do that
<smspillaz> I wrote some code a few days ago to track damage regions across old backbuffers, so gl tells you how old (in frames) your backbuffer is and then you just repair the relevant regions
<duflu> smspillaz: Also worth checking Nux to see if and where it does its own rebinds. I suspect it does too much but don't really know
<smspillaz> duflu: it does do way too much :(
<duflu> smspillaz: Which history says is a significant bottleneck :(
<duflu> smspillaz: I am curious because Nux+Unity works with all Compiz rendering modes now. If you're already using FBO then Nux should rebind less
<smspillaz> duflu: the best thing we can do
<smspillaz> duflu: is to determine when you're using a framebuffer object of the same size
<smspillaz> and then switch between the color attachments
<smspillaz> thats basically free
<smspillaz> it'll require a bit more infrastructure between nux and compiz
<duflu> smspillaz: Nux seems flexible enough that it *should* be able to work without FBOs. I don't understand why it needs them at all. Just give it a backbuffer...
<smspillaz> duflu: you need fbos to do gaussian blurs
<duflu> smspillaz: Oh, I forgot
<smspillaz> well, you can do them without fbos but its much slower :)
<duflu> smspillaz: I think it should be much faster. The need for FBOs in blurring is to only ensure there is no "drift" like you see with an in-situ blur
<duflu> But regardless, if Unity turns off active blur, that should in the least prevent Nux using FBOs. People should have the option of making things faster even if it's not the default
<smspillaz> duflu: also nux uses fbos becauses its convenient really
<smspillaz> even though it shouldn't
<smspillaz> duflu: anyways, the thing with gaussian blurs is that you need to do the 2nd pass using the results of the first
<smspillaz> there might be ways to have pseudo-gaussian blurs which don't use 2 passes, but at the moment we use 2 passes
<smspillaz> multiple color buffers are the best way to do that - reading off the backbuffer is expensive
<duflu> smspillaz: Yes true for Gaussian. However there other countless other algorithms that don't require multiple orthogonal passes.
<smspillaz> indeed
<smspillaz> gaussian looks the best though
<smspillaz> anways gottan run
<duflu> Yeah Gaussian looks best but in a real-time UI, people will never tell the difference
<duflu> Sorry, I don't mean to be one who abuses the term "real-time". I know Linux is not a real-time OS
<didrocks> sil2100: hey! when you get some time, do you mind updating me on the failing tests?
<sil2100> didrocks: sure thing! I already have a branch prepared, when I'm done with this one more fix I will give it out for review - we this should fix 2 failing tests at least
<didrocks> sil2100: sweet! do you think we'll be able to get down to 0 from this list failing?
<didrocks> sil2100: as it's only a subpart of tests for non regressing other stacks, I would love setting the value to 0
<sil2100> I would hope to get it down to 0, but some test failures are hard to track down, especially when they're hard to reproduce or some singular cases - I tried one of them yesterday and didn't yet find the root cause for the 'accidental' failure ;/
<didrocks> sil2100: maybe fghinter can give you access to the machine? as we are not using them, we can keep them in a fail case maybe so that it's easier for you to run them by hand?
<sil2100> didrocks: hm, I guess it wouldn't mind to try, I'll ping Francis when he's online
<niktto> hi all! I have one quick question about AppIndicator3 in python. I'm using it as an alternative to GtkStatusIcon and I'm connecting same GtkMenu to it but it seems that I can't catch 'button-press-event' on GtkMenuItem
<niktto> is there any road around this without using 'activate' signal?
<smspillaz> duflu: hey, see my comment on the MRQ - I think the checks for nBounding < 1 and nInput < 1 are wrong and the source of the problem
<duflu> smspillaz: Ah yes, good point. But we still want to support !XShape
<smspillaz> duflu: indeed, see my comment for an idea on how to do that
<duflu> So feel free to propose something that solves it
<duflu> Night
<smspillaz> duflu: are you working tomorrow ?
<duflu> Yep
<smspillaz> duflu: ok, well, I guess you can probably handle it
<didrocks> mterry: hey, thanks on the testapp MP! Feel free to get it merged, but I think we shouldn't automate it for daily process until we settle down on the name :)
<mterry> didrocks, yeah
<didrocks> mterry: something else, I think you saw that libunity-misc is not merging :/
 * didrocks keeps seeing autolanding branch being stalled
<mterry> didrocks, oh?  wait I thought it did
<didrocks> https://code.launchpad.net/~mterry/libunity-misc/modernize-build/+merge/139499
<didrocks> still approved
<didrocks> fginther: ^
<didrocks> fginther: do you have anything to spot those branches? I keep having 3/4 a days in that stalled situation
<mterry> didrocks, ah right. But not rejected due to jenkins.  Just no jenkins around
<didrocks> not really efficient to have to ping you or mmrazik every time
<didrocks> mterry: ah, something else (and sorry to add more to your plate), but there will maybe be some SRU on webapps for youtube which changed its layout, so the script broke
<didrocks> mterry: robru will do the packaging, but he will need a sponsor next week I guess
<mterry> didrocks, OK
<didrocks> so if you can have a look at it when it will be time :
<fginther> didrocks, yes, we have job that checks for these. It's probably emailing marting, but not me...
<fginther> s/marting/maring/
<fginther> s/maring/martin/
<didrocks> thanks mterry ;) FYI, I don't really know how the source packages are created (there is one source package for each script, but the real source is webapps-applications)
<mterry> didrocks, yeah, they generate them somehow.  also not sure how
<didrocks> mterry: so for this security fix, mdeslaur and I just apt-get source and distro-patch until ken is back and we know how it works with their pkgme
<didrocks> (the one we uploaded less than an hour ago)
<didrocks> I guess you will have to do the same for the youtube one
<didrocks> fginther: it needs patching then! :)
<fginther> didrocks, mterry. sorry about that. It should be building shortly
<didrocks> fginther: no worry, thanks! :)
<didrocks> and one more on the autolanding list (even if the unity stack is not scheduled)
<mterry> didrocks, what's the blocker for the unity stack?  autopilot still?
<mterry> (in terms of turning on autopublishing)
<didrocks> mterry: yeah, we just got the first reliable results yesterday
<didrocks> mterry: so, trying that + adding the dependencies between stacks (more on that in a publishing doc) once sil2100 will have few tests ironed out
<didrocks> we'll probably do "one blank shot" tomorrow (without really releasing) with jibel
<didrocks> but I don't feel confortable enabling that just before going on vacations :)
<didrocks> mterry: I think I'll disable all the jobs btw. I don't think that in what is bootstrapped and running already, we'll have emergency fix
<sil2100> didrocks: yes, and I also probably found a bug in appmenu in the meantime as well
<didrocks> sil2100: \o/
<didrocks> larsu: ^
<sil2100> Trevinho is helping me out here as well
<didrocks> oh sweet!
<fginther> mhr3, can you review https://code.launchpad.net/~fginther/dee/add-code-coverage/+merge/139586 or suggest someone?
<larsu> didrocks, what do you mean? The appmenu bug?
<didrocks> mterry: not sure you were able to talk to cyphermox yesterday, I didn't get any feedback, did you have a chance to work with him on the failing tests in a chroot?
<didrocks> larsu: not sure it's the same than Trevinho and sil2100 are looking at
<cyphermox> didrocks: I was out cold all day yesterday
<didrocks> so maybe better that the 3 of you sync!
<cyphermox> I poked mterry this morning
<mterry> didrocks, huh.  I can't mark the testapp branch approved.  Can you do that?
<didrocks> cyphermox: yeah, hello btw! do you feel better?
<cyphermox> didrocks: a little, yeah
<didrocks> mterry: do you want that power?
<didrocks> cyphermox: thÃ© + miel? :)
<mterry> didrocks, sure (muhahaha!   more power!)
<cyphermox> at least now I can actually stick to one physical location at home... ykwim
<didrocks> ykwim?
<didrocks> you know what I mean
<didrocks> I guess :)
<cyphermox> ;)
<didrocks> cyphermox: take it easy! :)
<cyphermox> meh, things still need to get done, and it's been taking way too long already
<didrocks> mterry: waow! you are an autopilot hacker now, impressive! :p
<didrocks> fginther: mterry: libunity-misc merged now and adding to the bootstrapped list! awesome :)
<mhr3> fginther, configure.ac:146: cannot open `build/autotools/gcov.m4': No such file or directory
<mhr3> fginther, looks like it doesn't support non-srcdir build
<fginther> mhr3, thanks I'll fixt that
<fginther> mhr3, how are you doing the non-srcdir build?
<mhr3> fginther, mkdir builddir; cd builddir; ../autogen.sh; make
<fginther> mhr3, thanks
<didrocks> larsu: sil2100: sweet a fix and perf improvments!
<larsu> didrocks, the performance increase was rather tongue-in-cheek ... it's only 4 empty indicators not being transferred over the bus
<sil2100> :)
<larsu> but otherwise: yeah! I love how easy this was to fix
<didrocks> larsu: ah ok, I thought it was for all exported menus :)
<sil2100> I'm testing larsu's solution now
<larsu> didrocks, yes, all exported menus (that are GMenuModels)
<larsu> didrocks, 4 is the number for charmap, it's really the amount of toplevel menu items
<larsu> but still, since the indicators are empty, there's not much data ...
<didrocks> ah ok, only toplevel menu indicators ;)
<didrocks> yep
<larsu> yeah but it's more Right now :)
<sil2100> larsu: tested, works! Can I approve globally, or do you want someone else to also review it before that?
<larsu> sil2100, I want tedg to have a look as well, it's his code
<larsu> sil2100, thanks for testing!
<sil2100> Would be awesome to have it merged in, I won't have to push the autopilot test-hack otherwise ;)
<Zhenech> ?window 36
<tedg> larsu, Any clue on why GtkMenu inserts separators?
<tedg> larsu, Seems kinda ridiculous.
<larsu> tedg, that's the only way to do separators with GMenuModel (have them between all toplevel sections/items)
<tedg> larsu, Ha, okay.  Feeling sorry for who ever has to write appmenu-gtk for GMenuModel.  :-)
<larsu> otherwise you'd never have any separators
<larsu> tedg, attente? :)
<larsu> aww, he's not in here
<tedg> Ah, didn't realize someone was on it.
<tedg> It's going to be super painful as GMenuModel is so inflexible.
<larsu> tedg, I hear he's making good progress, though :) Let's see how it turns out
<larsu> tedg, thanks for approving
<larsu> sil2100, should land soonish
<tedg> larsu, No problem, finding it is harder than approving it :-)
<larsu> tedg, right...
 * larsu was searching in unity-panel-service at first
<tedg> larsu, I'm sure he will, just inferring what the app was trying to do is going to be tricky.  A lot of fakery.  Plus you have to deal with lots of things changing that GMenuModel doesn't allow.
<larsu> tedg, ya, when I first heard about it I thought it was an impossible job :)
<sil2100> \o/
<sil2100> Thanks :)
 * larsu <-- dinner
 * tedg is a little concerned that larsu just got turned into dinner, but is hoping for the best.
<didrocks> tedg: you know, on those countriesâ¦
 * tedg is a little concerned that didrocks is going to be turned into wine, but is hoping it is a nice wine ;-)
<didrocks> tedg: who will be the cheese then? :)
<tedg> didrocks, seb128!
<seb128> tedg, heh, are you saying that I smell?
<didrocks> seb128: I would find that offensive as well
<tedg> Heh
<tedg> I'm saying you age nicely.
<didrocks> :)
<seb128> lol
<alo21> hi all..
<alo21> I read some ideas here: https://wiki.ubuntu.com/Unity/Lenses/Ideas
<alo21> and I would to implement one of them. What should I do?
#ubuntu-unity 2012-12-14
<smspillaz> duflu: what's wrong with changing the if condition as I suggested in your MRQ ?
<duflu> smspillaz: I could not see any way we could do so without regressing something. So regressing support for !XShape seemed least evil
<smspillaz> duflu: you didn't answer my quesiton
<smspillaz> as I mentioned, those if checks were only there for the !XShape case, so you should just be able to put them in an else block
<duflu> smspillaz: Your suggested solution regressed something. I will have to review again to remember
<smspillaz> okay, keep looking into it
<smspillaz> BTW, the way the fake minimization code is supposed to work is that we change the input and bounding shape on the client window
<smspillaz> which is automatically updated to be reflected in the frame window
<smspillaz> so there shouldn't be any problems there - I tested the life out of it
<duflu> smspillaz: Hmm, I think I was assuming XShape keeps working with fake-minimize, but obviously it does not (hence the bug)
<smspillaz> indeed
<duflu> Ok...
<smspillaz> uhh oh actually
<smspillaz> depends on what you're referring to
<smspillaz> if the window changes shape while we've removed it, we automatically catch that and save the new shape, then restore the "null" input shape
<duflu> smspillaz: Right, so there's still a risk in the old logic that a dead zone could appear... ?
<smspillaz> duflu: can you explain further?
<duflu> smspillaz: I mean how do we not get an XShape while the window is fake-minimized?
<duflu> Just pure luck that it does not resize during that
<smspillaz> duflu: we do get them
<duflu> ?
<duflu> So... the potential regression you raised is already an issue right now. Not a new problem
<smspillaz> I ... didn't raise a potential regression ?
<smspillaz> unless you're talking about the if (w->minimized ()) thing
<smspillaz> in which case, that's different
<duflu> smspillaz: Ok, too confusing. I will implement your suggestion and see if anything breaks
<smspillaz> evidently so ...
 * duflu has had little sleep and so far today been too unwell to go get the food he needs for dinner. Not thinking well
<duflu> smspillaz: How/why do we not get a shape during fake minimize?
<duflu> It hinges on that
<smspillaz> duflu: during the fake minimize ?
<smspillaz> duflu: unity is calling XShapeSelectInput (... NoEventMask)
<duflu> smspillaz: Ok, ta
<duflu> A simple explanation
<smspillaz> I believe we do that so that we don't get a feedback loop
<smspillaz> and call XSendEvent instead
<smspillaz> (so we can tell when we shaped ourselves)
<duflu> Though it means we have (already) some nasty assumption coupled to Unity
<smspillaz> inside of compiz ?
<duflu> Yeah
<smspillaz> what's the assumption ?
<smspillaz> that we're not going to get a shape event ?
<duflu> If some other plugin implemented a fake minimize without disabling the shape then we'd have big problems. So we're assuming it is done along with XShapeSelectInput
<smspillaz> not really
<smspillaz> so the only reason why we call XShapeSelectInput with NoEventMask in unity is because
<smspillaz> we need to be able to tell the difference between when we shaped a window and when someone else did
<smspillaz> BUT compiz needs to know that the window was shaped
<smspillaz> so, in unity we call XSendEvent and send a fake ShapeNotify on that window
<smspillaz> and then compiz gets it shape event
<smspillaz> and when unity gets it, it can tell it was just the same one that it sent, because it checks the send_event field
<smspillaz> It might be better to implement that through XNextRequest and checking the event serial
<smspillaz> but it would be similar
<smspillaz> duflu: anyways, the bottom line is that when the window is fake-minimized, compiz should definitely get a shape event, because unity will have sent one
<duflu> smspillaz: Right but we're relying on XShapeGetRectangles returning nInput = 0
<smspillaz> indeed, and that will happen
<duflu> Ok
<smspillaz> because the window will have been shaped :)
<duflu> I think it's ugly but want to minimize what gets touched right now
<smspillaz> the current implementation? yes it is :)
<smspillaz> if I knew about XNextRequest and event serials when I wrote it I would have used that
<duflu> smspillaz: Now the boundingShape is empty during minimize. So the window is missing during the minimize animation. That's why both the old code and my proposal has to treat bounding and input shapes differently :P
<smspillaz> duflu: right, we remove both shapes
<smspillaz> duflu: though, I would imagine the logic you'd use for both would be the same
<smspillaz> if !XShape -> assume both have one rect each
<smspillaz> if XShape -> query rectangles, apply to frame window
<duflu> smspillaz: I will try hacking the old behaviour back in... fall back to the unshaped boundingShape if not available
<smspillaz> uh ?
<smspillaz> duflu: that doesn't make any sense to me
<smspillaz> all you want to do, is just, in the case that xshape is supported, query both the bounding and input shapes on the client window and apply them to the frame window respectively
<smspillaz> and if it isn't support, assume that the bounding and input shapes exactly match the window geometry
<smspillaz> *supported
<duflu> Ok, I went too far down the track of cleaning up the whole function
<duflu> Should just do what you mentioned
<duflu> smspillaz: BTW, non-XShape seems to work much better if you set priv->[input]region = geom
<smspillaz> duflu: show me the change you've made afterwards just so I can see if we're on the same page
<smspillaz> duflu: at resizing? I would imagine so
<duflu> smspillaz: I mean no gaps any more
<smspillaz> gaps ?
<duflu> smspillaz: I think it improved https://bugs.launchpad.net/compiz/+bug/1087198
<ubot5> Launchpad bug 1087198 in Compiz "When XShape is disabled, many windows open with their contents partially missing on the right hand edge" [Medium,Triaged]
<duflu> But should double check
<smspillaz> ah
<duflu> priv->region = geom as the fallback looks like it might be more correct
<duflu> smspillaz: With XShape, it still looks like you have to fall back for region, but never for inputRegion. You need to fall back for region to ensure the window is not blank during animation. And you can't fall back for inputRegion because doing so causes the dead zone bug
<smspillaz> ah
<smspillaz> hmm
<duflu> smspillaz: As the old code and my proposal do
<duflu> So a new proposal needs such an ugly inconsistency too
<smspillaz> duflu: I remember that unity removed both the input and bounding shape, but now that I think of it, that approach is probably incorrect
<smspillaz> it should just remove the former
<duflu> Great
<duflu> So both projects needs fixing
<smspillaz> though I remember I had some weird side effects when I didn't remove both
<smspillaz> (like with chromium for instance)
<duflu> smspillaz: I've had enough for the year. Approving the revert and you think about proper fixes if you feel so inclined
<smspillaz> okay, have a good holidays :)
<duflu> Well, enough of this issue for the year
<smspillaz> duflu: I remember when I first wrote the fake minimization code for unity, some of the xshape paths in the server were broken
<smspillaz> that was fun
<smspillaz> duflu: the fact that the fake minimization code worked the whole time even though we didn't remove the bounding shape from the frame window certainly is telling though
<duflu> smspillaz: My only real concern was you understanding that inconsistency. Now you do I think I can actually propose a super-fix
<smspillaz> duflu: a super-fix ?
<duflu> smspillaz: It worked because of the copy-paste bug!
<smspillaz> well, it didn't work *because of* it, it just meant that removing the bounding shape from the client window was largely ineffective anyways
<smspillaz> since we don't unreparent fake minimized windows
<duflu> smspillaz: I will propose something. Then you decide what to do with it
<smspillaz> duflu: what are you proposing ?
<duflu> smspillaz: A rewrite of the function to cover all bases without reverting
<duflu> May as well I guess
<duflu> Just won't respond to any reviews :)
<smspillaz> I'll give the unity thing a try in the meantime to see if the fake minimization code works the way I expect without removing the bounding shape
<duflu> smspillaz: Don't worry too much. It sounds like there's no much support for keeping the Unity side much longer
<duflu> Not sure
<Mirv> ok then, we'll aim straight to the compiz 0.9.7.12 (with unredirect enabled by default) for 12.04
<Mirv> when we have it in the PPA, testing can commence :)
<Mirv> enough workarounds, blacklists etc start to be in place
<smspillaz> duflu: actually now that I think of it, its probably because of the typo you identified that I had such wonky behaviour with applications that set the bounding shape
<duflu> smspillaz: Yes. And if it wasn't for the slow resizing I would not have gone looking at XShape-related code :)
<smspillaz> duflu: if you're still around I've confirmed to have got fake minimization working without setting ShapeBounding with your fix applied
<duflu> smspillaz: Only physically around. I suspect
<smspillaz> duflu: okay, I'll put both fixes in my experimental ppa
<smspillaz> so we can get some testing
<duflu> smspillaz: I would prefer we just had a snapshot or icon for minimized windows and removed the complexity. But if the bugs are fixed then there's less argument for removing it
<smspillaz> duflu: live previews aren't really that complicated
<duflu> Not now that we have spent several days over the past year or two fixing the bugs
<duflu> But removing complexity is about being nice to the future of humanity...
<smspillaz> well, this is the first time we've had to touch the code in quite some time
<duflu> Yeah true. The pain of when it used to crash is still with me somehow
<smspillaz> duflu: that being said, I think compiz is the only WM right now that has a relatively bug-free implementation
<smspillaz> I remember mutter and kwin implemented it (in different ways) and it was a complete nightmare for them
<smspillaz> they didn't use xshape, they used stacking tricks instead
<duflu> smspillaz: I would not say that in too many public forums, given the resize/move performance and decorator glitches
<duflu> But it's improving a lot
<duflu> smspillaz: Oh... relatively bug free live minimize preview... yes.
<smspillaz> duflu: well, my WIP change has been reported to completely eliminate movement perf problems for those who tested it :)
<duflu> smspillaz: It was awesome on the old Atom
<smspillaz> I'm still letting it get more testing though just to see if there are any other weird corner cases
<duflu> smspillaz: I think the Nexus 7 needs the move/resize improvements desperately. Have not tried them there yet I think
<smspillaz> duflu: BTW, the buffer_age stuff is awesome. I know glxgears is not a benchmark, but I get something like +200FPS
<smspillaz> can't wait until its supported in other drivers
<duflu> smspillaz: What is it relative to copy subbuffer?
<smspillaz> duflu: haven't checked
<duflu> The same at least I would hope. Maybe better because you can still use SwapInterval for concurrent rendering
<duflu> (or on Nvidia, avoiding glCopyPixels)
<smspillaz> duflu: indeed
<smspillaz> duflu: I can check now if you want
<duflu> smspillaz: Don't really want to know. I have too much to deal with yet
<duflu> today...
<duflu> smspillaz: But you did get Phoronix excited
<smspillaz> :p
<smspillaz> duflu: unity is still having an impact, even though I thought it did nothing when damage regions didn't intersect the shell
<duflu> smspillaz: Yes I noticed a similar problem on the Nexus this week. I think it's paintDisplay'ing too much
<smspillaz> duflu: showRepaint says its damageScreening on every frame but that doesn't seem right
<duflu> smspillaz: Very bad.
<duflu> smspillaz: Look at r2872. It fixes flickering but maybe that's why I never had such a call in the original regionalDamage work.
<duflu> Like something is getting queued in UnityScreen::compizDamageNux despite not intersecting
<smspillaz> duflu: the panel is redrawing on every frame
<smspillaz> being called from UBusServer::DispatchMessages -> OnBackgroundUpdate
<smspillaz> how is our battery life /not/ screwed
<smspillaz> uhh right
<smspillaz> so ubus is spamming us every frame telling us the background color changed
<duflu> smspillaz: What?!
<Mirv> smspillaz: yeah, really cool blog post
<smspillaz> Mirv: :)
<smspillaz> Mirv: sadly, its still going to be slow on unity. The fact that we reverted regionalDamage and replaced it with (if something_nux_drawn) damageScreen (); means theres a feedback loop causing the screen to be damaged every frame regardless of whether unity drew
<smspillaz> I'm trying to see if we can unrevert that safely
<sil2100> regionalDamage got reverted?
<didrocks> hey sil2100, do you have a little status now that you've merged some tests about which ones are still broken?
<sil2100> didrocks: yes, one moment - I'll just fetch the list
<didrocks> thanks ;)
<sil2100> didrocks: so, currently from the latest test result, 2 test failures are probably gone for good, 2 are being worked on, 4 are actual regressions (;p) and one of them seems to be hm, a singular case I wasn't able to figure out
<didrocks> sil2100: so, we'll just have one remaining when then 2+4 are fixed? That's awesome \o/
<didrocks> sil2100: do you have time to track those and ensure it's done by end of next week? (not sure about your schedule and holidays)
<sil2100> didrocks: yes! Well, I even think that one failed test will anyway not fail next time I hope, probably a single case of a failure due to 'bad luck'?
<didrocks> sil2100: let's see ;)
<sil2100> didrocks: no problem, I hope to finish those till this EOW
<didrocks> sil2100: you rock! I won't be there next week, but just drop me an email if possible so that once I'm back from holidays, I don't bother you :)
<sil2100> didrocks: I'm just doing some formalities regarding the compiz SRU for precise, like bug descriptions
<didrocks> sweet ;)
<sil2100> didrocks: np! Will do so!
<didrocks> thanks again sil2100, that's a life saver to have those tests running for stacks! :)
<axyz> hello
<axyz> currently, if I have let's say 4 skype (or any other app) windows opened, when i click on launcher i will see them arranged on the screen
<axyz> i want to see only their titles, like in windows/kde
<axyz> is this possible ?
<axyz> anyone here ?
<sil2100> smspillaz: hi, are you around ;) ?
<fginther> mhr3, ping
<mhr3> fginther, pong
<fginther> mhr3, I resolved the non-srcdir build issues in https://code.launchpad.net/~fginther/dee/add-code-coverage/+merge/139586, would you like to review?
<mhr3> fginther, it was merged 5hours ago ;)
<fginther> ackk! thanks. I should learn to refresh my web pages :-)
<fginther> Trevinho, ping
<sil2100> larsu: hi!
<Trevinho> fginther: hi
<fginther> Trevinho, can you recommend a reviewer for https://code.launchpad.net/~fginther/bamf/add-code-coverage/+merge/138590?
<Trevinho> fginther: someone from distro, or I can do that
<fginther> Trevinho, I'm looking for someone familiar with bamf to make sure I've added coverage to the right places and didn't break any existing work-flow
<Trevinho> fginther: well, I am familiar with it
<Trevinho> fginther: quite EOW for me... But I'll try to give it a look on next days
<fginther> Trevinho, no rush. Thanks in advance
<didrocks> sil2100: hey, before I'm going on holidays, do you have any good news on the test fronts?
<didrocks> now, the plumbings are connected here, so it's just a question to get the list of failure for indicators down to 0 \o/
<didrocks> mterry: cyphermox: just confirming that I disabled the daily landing on purpose before going on holidays
<cyphermox> ack
<mhr3> didrocks, oh, you're leaving us already?
<mhr3> didrocks, enjoy christmas then!
<didrocks> mhr3: thanks a lot! will do, you too when you will be on holidays :)
<didrocks> (still here for 30 minutes before holidays, finishing some catching up)
<mhr3> didrocks, you're doing it wrong, no need to catch up before going away :P
<didrocks> ahah :)
<mhr3> you need to catch up when you come back :)
<didrocks> well, let's say it's to have *less* to catch up :)
<didrocks> I see that seb128 is emptying his old emails to answer as well :p
<seb128> didrocks, that's correct!
<mhr3> i'm sure he just implemented a new bot! ;)
<didrocks> heh
<didrocks> mhr3: with what I received, it's very much possible :p
<mhr3> you guys know that an intelligent system is just an aggregation of simple parts? one day lp will become self aware and it'll be because of your bots!
<didrocks> heh ;)
<mterry> whoops, just missed didrocks
<alo21> hi. When a new lens' idea could be imported into standard Ubuntu installation?
<gatox> hi, quick question...... unity is building in raring?
<gatox> well...... i see it's building..... but i was looking for the recipe to see the dependencies listed there
<bregma> gatox, if you want to see the Unity build dependencies for raring, look in lp:unity in the file debian/control ... they're listed under Build-Depends:
<gatox> bregma, thx... yes. i see the problem was i was based my recipe in an older debian/control it seems
<gatox> bregma, thx
<smspillaz> bregma: hey, how is it going? do you think I might be able to get some of the people on your team to do some reviews ?
<bregma> ask bschaefer for reviews, but we've already got a big backlog and a lot of people gone for the holidays
<bregma> so don't get too impatient
<smspillaz> yeah I saw XD
<smspillaz> bregma: maybe someone should clean up the +activereviews page its getting a bit big
<smspillaz> just reject everything that's not had any activity for > 2 months
<bregma> on my list, but, I'm supposed to be on vacation myself
<smspillaz> heh, I'm not supposed to be "working", though I do need a desktop that doesn't lag like crazy ... and now that I have some free time I felt like actually going and doing that :p
<smspillaz> since everyone is so busy :)
<bschaefer> smspillaz, you need a review?
#ubuntu-unity 2012-12-15
<ooshhhs> how can i dowbload ubuntu unity?
<yellabs> hello there
<yellabs> in unity dash , when we hit super, and search , the first icon, home, it does not have an lens ?
<yellabs> in /usr/share/unity/lenses , there are several lenses, but none that is the home lens, how is it constructed ? any tips are welcome
<yellabs> hmm
<yellabs> better ask ayatana ?
#ubuntu-unity 2012-12-16
<MCR1> smspillaz: Hi :) Is bug 1085846 the reason for having to restart Unity with setsid unity for my Flat-file Configuration Backend and Default Profile to be correctly loaded ?
<ubot5> Launchpad bug 1085846 in Compiz "COMPIZ_CONFIG_PROFILE is not actually the name of the profile that gets loaded" [Wishlist,New] https://launchpad.net/bugs/1085846
<MCR1> smspillaz: When I boot the system my keyboard shortcuts are not correctly loaded, once I run setsid unity my profile loads correctly and when logging out/in everything works as expected until I reboot
<MCR1> smspillaz: Another info regarding this issue - Once I try to "Add a new profile" in CCSM Preferences by clicking the + button and enter a name Compiz/Unity crashes...
<MCR1> Does this make sense ? : http://paste.ubuntu.com/1443489/
<MCR1> Seems like a copy-paste mistake to me, no ?
<MCR1> look @ m_Minimum
<MCR1> Nux/IntegerValidator.cpp, line 45ff
#ubuntu-unity 2013-12-09
<anacrolix> where is the documentation for python bindings to appindicator? all the links here are broken: https://unity.ubuntu.com/projects/appindicators/
<tsdgeos> morning
<tsdgeos> i think i either caught the ubuflu or the heathrow flu
<tsdgeos> feeling quite sick
<Saviq> tsdgeos, get a swap day, take it easy
<Saviq> tsdgeos, *in* Heathrow meaning you slept at the airport?
<tsdgeos> meanig i didn't sleep
<tsdgeos> but yeah :D
<Saviq> jeez
<tsdgeos> got a plane for sunday at 6am
<tsdgeos> so i had to be there at 4am anyway
<tsdgeos> so didn't make much sense trying to get somewhere to sleep
<tsdgeos> bought last Dan Brown's book and read it all :D
<Saviq> tsdgeos, :D how was it?
<tsdgeos> i actually liked it
<Saviq> tsdgeos, either way - get a swap day for that - especially if you're feeling sick
<Saviq> tsdgeos, and also, there's a flight delay compensation to be fought for within the EU
<tsdgeos> actually it was no that my flight got delayed
<tsdgeos> is that awesome piccadilly line broke
<tsdgeos> and i had to take an 1:30h detour
<tsdgeos> so i got there late
<tsdgeos> my plane actually flew as scheduled
<Saviq> tsdgeos, ah
<Saviq> that's "it's easier to get to Heathrow" for you...
<Saviq> MacSlow, hey, sorry to hear about your N10
<Saviq> MacSlow, there's one thing, though - company hardware is somewhat insured - would be good to verify what's covered
<MacSlow> Saviq, yeah... thanks... Murphy struck hard this weekend for everybody... in some way or another
<Saviq> MacSlow, yeah
<MacSlow> Saviq, hm... who would know details about this?
<Saviq> MacSlow, start with msm
<MacSlow> Saviq, ok
<Cimi> Saviq, hey boss, I'm looking for week's tasks
<Saviq> Cimi, "week's"? "this week's"?
<Cimi> this week
<Saviq> Cimi, how 'bout bug #1259005
<ubot5> bug 1259005 in unity8 (Ubuntu) "Swiping over SEARCH header in top left of phone Dash does not show search" [Undecided,Confirmed] https://launchpad.net/bugs/1259005
<Cimi> Saviq, ok
<mzanetti> Saviq: did we switch to use the fake applications intentionally with ./run on the desktop or is there some import path breakage going on too?
<Saviq> mzanetti, we never had non-fake ones ;)
<mzanetti> err... not the fake apps, but the fake scopes content
<Saviq> mzanetti, do you have unity-plugin-scopes installed?
<mzanetti> ah... right... going back to qt 5.0 seems to have removed all that stuff
<mzanetti> thanks
<Saviq> mzanetti, it now picks stuff up from ./plugins, /usr/lib/*/unity8/qml, ./tests/mocks - in that order, more or less
<Saviq> mzanetti, so we override system-wide plugins and fall back to mocks
<Saviq> s/system-wide/installed/
<mzanetti> ah ok. makes sense
<Saviq> biab, post office
<Saviq> greyback, ping
<Saviq> dednick, welcome back!
<dednick> Saviq: :) thanks
<Saviq> dednick, were you flying during UK's air traffic shutdown?
<greyback> Saviq: pong
<dednick> Saviq: no, missed it by a day luckily
<dednick> i arrived a few hours ago :)
<Saviq> dednick, straight into the office, eh? ;)
<dednick> *home office* ;)
<Cimi> Saviq, does qmltestrunner run with touch emulation events?
<Saviq> Cimi, we have a custom touchtestrunner that does
<Saviq> Cimi, used by the indicator tests, for example
<Cimi> ok
<Cimi> maybe I can use that
<Saviq> Cimi, I *think*
<Cimi> Saviq, cause was failing
<Saviq> Cimi, either way - panel tests are fine with edge drags
<Saviq> Cimi, so that must work some way ;)
<Cimi> Saviq, I added this edgedragarea
<Cimi> Saviq, but my tests fail
<Saviq> Cimi, added? there is an EdgeDragArea in the panel already - would be best to use that one probably
<Cimi> Saviq, it's only for the indicators row iirc
<Cimi> Saviq, I'll have a look
<Saviq> Cimi, I'd rather not, if possible, have two separate ones - maybe some refactoring is in order
<Cimi> Saviq, in the meanwhile I'd like to have tests working :)
<Saviq> Cimi, as in trunk tests?
<Cimi> Saviq, nope referring to this search swipe
<Cimi> Saviq, took me 5 mins to get the feature in
<Cimi> Saviq, still debugging the tests failing
<Saviq> Cimi, ok sure
<Cimi> Saviq, ok was this mouseClick -> tap
<Cimi> Saviq, mouseFlick -> touchFlick
<Cimi> Saviq, when you use touch events
<Saviq> Cimi, yeah, thought we have those :)
<Cimi> Saviq, having one big edgedragarea common won't simplify things
<Cimi> on the tablet it will be huge
<Cimi> while currently it's only 40gu
<Saviq> Cimi, right
<Cimi> also you have to abstract properties from the indicators to the panel, making them 'public'
<Saviq> Cimi, ok, fine with split areas
<Saviq> Cimi, makes sense when they're spread out on the tablet
<Cimi> Saviq, you remember the tolerance area of clicks?
<Cimi> how big is it
<Saviq> Cimi, you mean tap vs. long-press?
<Cimi> Saviq, I meant
<Cimi> Saviq, I'm faking mouse clicks in the edgedragarea
<Saviq> Cimi, that depends
<Cimi> Saviq, so I don't have to use two input areas
<Saviq> Cimi, EdgeDragArea.qml has them all set up
<Cimi> Saviq, I have mouseAbs (touchx - initialtouchx) < tolerance
<Cimi> Saviq, does not have onClicked IIRC
<Saviq> Cimi, clicks just go through the EdgeDragArea
<Cimi> Saviq, so you want me to use a edgedragarea AND a mousearea?
<Cimi> thought faking was better
<Saviq> Cimi, yeah, just have a MouseArea below - that's how the EDA is supposed to be used
<Saviq> Cimi, or well, see how the IndicatorRow has those
<Saviq> Cimi, it does react to press
<Saviq> Cimi, and it seems it's the EDA that handles it
<Cimi> Saviq, they use tolerance 0 for swipes
<Cimi> Saviq, so you can swipe right to reveal
<Cimi> or swipe up
<Cimi> it seems wrong
<Cimi> to me
<Cimi> for reference, my current code http://bazaar.launchpad.net/~cimi/unity8/searchIndicator-swipe/revision/582
<Cimi> two ways to show search indicator
<Cimi> 1. click within units.dp(2) from the original click
<Cimi> 2. swipe down of at least units.gu(1.5)
<Cimi> Saviq, edgedragrea eats mouse clicks
<Cimi> gnam gnam, it's hungry area
<mhr3> Saviq, forgot to bring up one topic last week - running apps
<mhr3> Saviq, i still don't want those in a scope
<mhr3> it's just silly
<Cimi> mhr3, they'll go away
<Saviq> mhr3, no worries, we might end up without them there completely
<mhr3> wooo :)
<mzanetti> greyback: hmm... should ApplicationManager.startApplication() cause ApplicationManager.focusedApplicationId to change eventually?
<mhr3> Saviq, and one more, tests in the scopes plugin - gtest or qtest?
<mhr3> or rather do you see a reason why qtest would be a better choice?
<Saviq> mhr3, your call - we use qtest mostly, as it's just better integrated
<Saviq> mhr3, but I'm completely fine on gtest
<mhr3> Saviq, tell me more about the integration
<Saviq> mhr3, stuff is named Q*
<Saviq> ;)
<Saviq> mhr3, no really, don't see a reason
<Saviq> mhr3, maybe the fact that it launches QApplication automagically
<Saviq> mhr3, but it's not like you can't do it yourself if necessary
<mhr3> i'm all for simpler life :)
<mhr3> hmm, think i'll stay with qtest just to have QTRY_*
<mhr3> will be handy for the highly-async scope tests
<Saviq> mhr3, maybe the SignalSpy - useful, too
<mzanetti> test rows/column might be useful too
<mzanetti> and the nice output formatting :)
<mzanetti> Saviq: is there something special in regard to the order of the recent applications grid? as in, do mainstage apps need to be before sidestage ones?
<mzanetti> or could I get rid of firstModel and secondModel and just show all of ApplicationManager's recent apps in whatever order the appmanager holds them
<kgunn> Saviq: snowboarding...ok...now i hate you
<mzanetti> kgunn: finally back home?
<greyback> mzanetti: sorry was at lunch. ApplicationManager.focusedApplicationId should update yes
<kgunn> mzanetti: yep, yesterday afternoon
<kgunn> mzanetti: heard you made with no issues...lucky
<mzanetti> kgunn: mostly, yes. 45 mins late
<mzanetti> greyback: no problem. ok. seems our various ApplicationManager implementations start to drift apart
<mzanetti> will fix
<Saviq> mzanetti, TBH it should be recency
<Saviq> mzanetti, but I don't think we have that proper yet
<mzanetti> Saviq: I agree. but I think it'd be better if the applicationmanager is sorted itself according to that
<mzanetti> but anyways, dropping that firstModel, secondModel hack
<Saviq> mzanetti, I'd be worried about reshuffling the launcher all the time
<Saviq> mzanetti, not sure what's the plan there
<mzanetti> Saviq: no. the launcher doesn't follow that order
<mzanetti> Saviq: as when an app is pinned it needs to be there, not where it is in the app stack etc
<Saviq> mzanetti, yeah exactly, but what about recent apps in launcher
<Saviq> mzanetti, not the pinned ones
<mzanetti> Saviq: well, they are appended as they show up
<mzanetti> Saviq: and stay there until either moved or removed from the recent list
<Saviq> mzanetti, that'd be good I think
<mzanetti> I've dropped shell's knowledge about multiple stages... that's why I asked if we need to have that distinction in the recent apps grid
<Saviq> mzanetti, still, if we go for split right edge
<Saviq> mzanetti, we need separate models for main and side stage
<mzanetti> Saviq: then we still can put a sortfilterproxymodel on top
<Saviq> mzanetti, or maybe the other way 'round - let app manager give up three models? main, side, merged?
<mzanetti> but I'd say where we need it.. instead of keeping two separate lists in shell.qml and aggregate them again all over
<mzanetti> Saviq: so when we designed the appmanager api we went for this:
<mzanetti> appmanager itself is a model of all apps, having a role "stage"
<Saviq> kgunn, sorry...
<mzanetti> so we could easily put a sortfilter on top
<Saviq> kgunn, it's not like you don't have places to go to do that
<Saviq> mzanetti, yeah, I'd rather it be provided by the app mgr itself
<Saviq> mzanetti, or well maybe it really doesn't matter in that case
<mzanetti> ok well, sure... we can always create instances of filtermodel's inside the appmanager if really wanted
<mzanetti> but yeah... the question was more the other way round
<Saviq> mzanetti, yeah, we need a merged model from app manager indeed
<mzanetti> Saviq: yeah... that's the thing... we do have that
<mzanetti> Saviq: then ApplicationManagerWrapper was splitting it up
<mzanetti> the split thing was used everywhere and merged again everywhere with fancy javascript
<Saviq> mzanetti, yeah, that's why I'm thinking we should simply have three - main, side, merged
<mzanetti> Saviq: actually I was thinking to not have that distinction anywhere except inside the tablet stages code. Given that not all devices will have that
<Saviq> mzanetti, yeah maybe
<Saviq> greyback, dednick_ standup
<sil2100> tedg: hello!
<sil2100> tedg: not sure if it's still super valid, but we've been discussing and wondering if the ust requirement for upstart-app-launch could be somehow made optional?
<sil2100> tedg: by ust I mean liblttng-ust of course
<Saviq> mzanetti, hey, I can has you to look at https://code.launchpad.net/~saviq/unity8/new-scopes-integrate-card/+merge/197930/comments/459061 ?
<mhr3> heh, was just about to ping you about that
<mhr3> Saviq, how is the visibility of items going to work?
<mhr3> for example right now the height is too much, cause there's no subtitle, summary etc
<Saviq> mhr3, items meaning price etc.?
<Saviq> mhr3, that depends
<Saviq> mhr3, in a static-height scenario (grid, carousel), we'll to lay out a maximum card size and stick to it
<mhr3> Saviq, right, so for those it's about the components
<mhr3> but for the other ones it's about both components and the data
<mzanetti> Saviq: ack
<Saviq> mhr3, yes, prices and attributes will be just stacked next to each other - based on contents
<Saviq> mhr3, but still we'll have to cater for the biggest case
<Saviq> mhr3, for variable-height/width (journals) it will be what it will be in reality
<mzanetti> Saviq: line 117, 118 is some more commented stuff. reason?
<Saviq> mzanetti, because the card does not yet have those signals
<Saviq> mzanetti, but it will need them - can add FIXME
<mzanetti> ok
<Saviq> mzanetti, shall I add FIXME?
<mzanetti> Saviq: nah... given that you will change this soon enough in any case, no need to nitpick on it
<Saviq> mzanetti, yup
<mzanetti> Saviq: I'd prefer to investigate the crash in the other fixme as I have a feeling otherwise that fixme will be in there for all eternity
<Saviq> mzanetti, oh no it won't, but yeah
<Saviq> mzanetti, we need the sourceSize there, and need it working
<mzanetti> yeah...
<Saviq> mzanetti, otherwise we'll load huge images
<Saviq> mzanetti, so I basically need to try it out with 5.2
<mzanetti> seeing what sort of fixme's I came by in the application stuff today :D
<mzanetti> Saviq: ah damn... I just went back to 5.0 as too much other stuff was crashing with 5.2
<mzanetti> otherwise I could have tested for you
<Saviq> mzanetti, will manage
<Saviq> mzanetti, we shall have it resolved before that whole thing gets into lp:unity8
<mhr3> although the sooner it would get there, the better :)
<mhr3> would lower the barrier for testing it
<tedg> sil2100, We'd prefer to leave it in so that we could get timing results on images.  Is it causing a problem?
<Saviq> mzanetti, I'm worried the "Qt.test.qtestroot" missing thing might be that we're trying to run the testcase under qmlscene
<mzanetti> Saviq: not following
<Saviq> mzanetti, remember when you tried to do make tryCard under 5.2?
<mzanetti> ah, ok
<mzanetti> hmm... that'd be bad
<Saviq> yeah, we'd need to find a way to run it under qmltestrunner
<Saviq> which, btw, could be doable
<mzanetti> yeah, quite sure. It's just the input thing right?
<Saviq> mzanetti, well, not even
<Saviq> mzanetti, for tryFoo we're not testing at all
<Saviq> mzanetti, just loading the QML and let you play with it
<Saviq> mzanetti, so we'd need to be able to the same under qmltestrunner
<Saviq> mzanetti, maybe our custom runner with a command line option to not actually start the tests
<Saviq> mzanetti, or set a context prop, for that matter
<Saviq> that we'll bind to TestCase.when:
<Saviq> which would mean we'll load everything under the test runner, just we won't start the tests
<mzanetti> Saviq: but wait... iirc I had the crash when doing make testCard
<Saviq> mzanetti, yeah, unrelated
<Saviq> mzanetti, crash is there indeed
<Cimi> ppa:canonical-qt5-edgers/qt5-daily is for qt 5.2?
<Cimi> or we have others?
<Saviq> Cimi, qt5-beta2
<Saviq> mzanetti, but it doesn't even start with qmlscene, complaining about Qt.test.qtestroot not being there - probably something qmltestrunner imports / adds an import path  / something
<mzanetti> mhm
<Saviq> mzanetti, the only symbols I got out of the qmltestrunner crash:
<Saviq> http://pastebin.ubuntu.com/6546538/
<Saviq> mzanetti, look familiar?
<mzanetti> yeah. the JIT was involved here too
<mzanetti> not sure if its the exact same thing
<mzanetti> qv4functionobject.cpp... yeah, I think it is
<Saviq> mzanetti, meaning https://bugs.launchpad.net/unity-api/+bug/1258057 ?
<ubot5> Ubuntu bug 1258057 in Unity API "unity-api fails to build against Qt 5.2" [Critical,New]
<mzanetti> Saviq: right... I didn't try to debug testCard... so that must be the one
<Saviq> mzanetti, thanks, will try to add more info
<Saviq> mzanetti, https://bugreports.qt-project.org/browse/QTBUG-33658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
<Saviq> looks legit
<mzanetti> Saviq: hmm... looks similar. but I wouldn't be able to say it's this one
<Saviq> mzanetti, yeah of course - I'll try to build it locally with the patch applied
<anpok> ls
<mhall119> Saviq: do you have time for a quick chat about Unity 8 desktop mode?
<Saviq> mhall119, can you please put something in my calendar for tomorrow?
<Saviq> mhall119, I'm almost at the door today
<Saviq> mhall119, also, depending on the topic I might have more questions than answers for you...
<mhall119> Saviq: ok, I'll find us a time tomorrow
<Saviq> mhall119, thanks
<mhall119> Saviq: done
<untitled1> Saviq:  hi.  I am running run_on_devce and the build-deps for unity8 is missing  deps lcov and gcov.  are these imporant ?
<Saviq> untitled1, that's just a warning
<untitled1> camke warrning yeah but what are they used for ?
<Saviq> untitled1, unless you want to see test coverage, no - they're not important
<untitled1> thanks
<Saviq> untitled1, http://en.wikipedia.org/wiki/Gcov
<untitled1> I also had to mount my devce as dpkg would not work with out it
<untitled1> maybe could add to bash script  ?
<Saviq> untitled1, you mean make writable?
<untitled1> yeah
<Saviq> untitled1, that's dangerous, we don't want to do it by default
<untitled1> what is up with that ?
<Saviq> untitled1, we could bail out if not writable, though
<untitled1> I can not run_on_device with out that ?
<Saviq> no
<untitled1> because of the build deps and what not
<Saviq> yes
<untitled1> cmake and many other thins are not installed by default
<Saviq> untitled1, having a writable rootfs on a phone is not feasible - battery outage could result in unbootable phone
<Saviq> untitled1, exactly
<Saviq> untitled1, it's really like making the phone go into developer mode
<untitled1> I see
<Saviq> untitled1, we have plans to make it better / less invasive on your installation
<untitled1> thanks Saviq
<Saviq> untitled1, ideally you should be able to revert what you did during the development session
<Saviq> untitled1, at least to the rootfs
<untitled1> maybe I should make a qprocess app for this like a gui that uses them scripts
<untitled1> or add to qtcreator not sure what are your thoughts ?
<untitled1> at that what do you think about qprocess ?
<Saviq> untitled1, a qtcreator target could be used, sure
<Saviq> untitled1, although for that we'd rather cross-build and transfer pre-built onto the device
<Saviq> untitled1, this should happen relatively soon
<untitled1> Saviq:  are the plugins for the creator still in source or are they outside branchs now ?
<Saviq> untitled1, the ubuntu plugins?
<untitled1> Saviq: yeah
<Saviq> untitled1, they are separate - and will mostly remain so
<Saviq> untitled1, until we get upstream support for Ubuntu in QtCreator at least
<untitled1> I built ubuntu-ui-toolkit to qt5.2 and might go after the creator today
<untitled1> qtcreator takes forever to build lol
<Saviq> untitled1, naah, qtcreator is nothing - try qt itself ;)
<untitled1> lol
<untitled1> esp on arm
<untitled1> done that many times when android was getting "wheels" on Qt
<untitled1> Saviq:  one of the things that is hard for me to deal with is when I press the qt home screen and then press develop to go to last session and it opens like 5 windows that I can not close :(  know any work a rounds ?
<Saviq> untitled1, here's a branch I did off of qtcreator 3.0-beta
<Saviq> https://code.launchpad.net/~unity-team/kubuntu-packaging/qtcreator-30
<untitled1> thanks
<Saviq> untitled1, it should build now - importing rc could be useful, though
<Saviq> untitled1, ough
<untitled1> Oo
<Saviq> untitled1, if that's still the same in QtC 3.0
<Saviq> untitled1, that's a bug that needs fixing
<Saviq> untitled1, in the mean time you can use File > Sessions or so
<untitled1> Thanks I think that I will build to rc and see what is going on in the welcome plugin
<Saviq> untitled1, actually, let me quickly update that branch to rc
#ubuntu-unity 2013-12-10
<Saviq> Mirv, hey, do you think there will be a rc2 of Qt 5.2?
<Saviq> Mirv, also, do you have branches for all the packages in qt5-beta2 somewhere?
<tsdgeos> Saviq:
<tsdgeos> Hi all,
<tsdgeos> We have new packages available for your testing & verification in http://download.qt-project.org/snapshots/qt/5.2/5.2.0/2013-12-09_204/
<tsdgeos> subject: Qt 5.2 final candidate packages available
<Saviq> tsdgeos, right ;)
<tsdgeos> doesn't look like there'll be an RC2
<Saviq> tsdgeos, "final candidate" sounds very much like rc2 ;D
<tsdgeos> maybe
<tsdgeos> i just think it's packages we'll flip the switch tomorrow if noone complains about
<tsdgeos> and not a more formal RC2
<tsdgeos> but i'm still not at 100% :D
<Saviq> tsdgeos, ;)
<tsdgeos> so may not be reading it correctly
<Saviq> tsdgeos, good news, at least, is that both crashes we've encountered (unity-api and my test with JSON parsing)
<Saviq> tsdgeos, are gone with release
<Mirv> Saviq: no formal rc release I think (http://download.qt-project.org/development_releases/qt/5.2/). all packaging is under https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging
<tsdgeos> Saviq: awesome
<Mirv> Saviq: that's great news.
<Saviq> Mirv, seen there's a "final candidate" tarballs around?
<Mirv> Saviq: tsdgeos: I have set around 50+ recipe builds to qt5-beta2, a lot of build failures in some packages, at least something has changed regarding running tests (opengl tests are tried to be run in gsettings-qt on builders)
<Mirv> Saviq: sure, there are tarballs, but no rc release tarballs
<Saviq> Mirv, right, only snapshots
<Mirv> Saviq: yeah, date coded snapshots which all are called "final candidate builds"
<Mirv> Saviq: it seems the patched qtdeclarative is now there, so I'm clicking rebuild for unity-api
<Saviq> Mirv, next time we need to make it so we have a recipe just following the release branch ;)
<Saviq> Mirv, cool
<Mirv> Saviq: the problem with automated Qt packaging is that during development the files tend to change all the time in at least qtbase/qtdeclarative, so *.install files are outdated, and same goes for symbols files (which I've now mostly temporarily removed simply until final release)
<Saviq> Mirv, yeah, I know, just a dream there :)
<Mirv> Saviq: I'll probably cc: you later today with my tinkerings around the opengl es on x86..
<Saviq> Mirv, great, thanks
<Saviq> tsdgeos, there's like 6 newer builds in here http://download.qt-project.org/snapshots/qt/5.2/5.2.0/ - does it go regardless of the lack of changes?
<Saviq> tsdgeos, i.e. is 204 that you linked different from 209 do you think?
<tsdgeos> hmm
<Saviq> no commits in qtdeclarative at least since 5.12
<tsdgeos> i guess they might change
<tsdgeos> no idea how to find out which one though
<tsdgeos> other than git logging
<tsdgeos> Cimi: did i convince you in https://code.launchpad.net/~aacid/unity8/search_history_pointer_correct_pointer_position ?
<tsdgeos> Cimi: also do you have time for https://code.launchpad.net/~aacid/unity8/dash_show_home_no_index/+merge/197714 ?
<Saviq> Mirv, segfault :/
<Saviq> Mirv, built fine here yesterday with that patch...
<Mirv> so it seems :(
<Saviq> Mirv, hum
<Saviq> Patch correct_geometry_for_2x_pixmaps.patch does not apply (enforce with -f)
<Saviq> Mirv, that's on freshly branched lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
<Saviq> Mirv, how could it build, then...
<Saviq> Mirv, <facepalm>
<Saviq> Mirv, it's only the packaging branch :)
<Mirv> Saviq: yes, that's still how all Qt packaging is handled also in Debian :) wget .orig.tar.xz from qt5-beta2 PPA
<Saviq> Mirv, yeah, never did much with merge-style packaging
<Saviq> Mirv, but managed my way around it
<Mirv> Saviq: btw regarding qtwebkit 5.2, add_experimentalDevicePixelRatio.patch is again disabled since it didn't apply.. I guess rsalveti or someone should look at it
<Mirv> Saviq: interesting. there was an autobuild of webbrowser-app in qt5-beta2 with the latest 5.2 fix, and it seems it also segfaults on i386 and armhf, but not on amd64 when running tests
<Saviq> Mirv, right, sounds like unity-api then
<Saviq> Mirv, aah, so it never segfaulted on amd64 did it?
<Saviq> Mirv, I'm on amd64 <facepalm/> :/
<Saviq> Mirv, anyway - you might find http://bazaar.launchpad.net/~unity-team/kubuntu-packaging/qtdeclarative-opensource-src-5.2-rc2/revision/95 useful - the patch conflicted with the 209 snapshot, so once there's a proper release, that patch should apply fine
<Mirv> Saviq: :) yep, never segfaulted on amd64.
<Mirv> thanks for that, I'll fetch that already so that I don't forget about it, because maybe I won't build another qtdeclarative until the final is out
<Saviq> Mirv, cheers
<Mirv> merged and pushed
<Saviq> mzanetti, pushed a fix to new-scopes-integrate-card
<Saviq> mzanetti, apparently 38/2 != 18.5, but 19!
<mzanetti> :D
<mzanetti> Saviq: cheers. will give it another run
<mzanetti> ah... wait
<mzanetti> did you see the other one?
<Saviq> mzanetti, looking
<Saviq> mzanetti, that you mean https://code.launchpad.net/~saviq/unity8/new-scopes-integrate-card/+merge/197930/comments/459628 ?
<Saviq> mzanetti, that's what I just fixed
<Saviq> mzanetti, doesn't segfault when passing...
<mzanetti> yip. all passing here
<mzanetti> Saviq: ok. good to go I'd say
<Saviq> mzanetti, hit it!
<mzanetti> Saviq: happroved
<Saviq> mzanetti, thanks /me merges
<nic-doffay> Saviq, got any tasks floating around?
<Saviq> nic-doffay, yeah, review https://code.launchpad.net/~bfiller/unity8/fix-password-autocaps/+merge/198319 please?
<nic-doffay> Saviq, cool
<Saviq> nic-doffay, test on the phone please
<nic-doffay> Saviq, yep
<mhr3> there's no default implementation of qhash for strings?
<mhr3> as in std::string
<Saviq> mhr3, I'd imagine they want QString...
<Saviq> tsdgeos, feelin' better btw?
<tsdgeos> yeah
<tsdgeos> not 100%
<tsdgeos> but rest really helped
<mhr3> Saviq, they do, but i dont
<tsdgeos> mhr3: then define your qHash operator for std::string
<Saviq> â
<Saviq> that just wraps it into QString ;)
<tsdgeos> lol
<tsdgeos> slow++
<mhr3> think i'll just go for std::map
<Saviq> or that
<mhr3> oh wait, there's unordered_map now
<mhr3> that should have the algorithmic complexity as qhash, no?
<mhr3> the same*
<Saviq> mhr3, card integration landed
<tsdgeos> mhr3: yeah
<Saviq> mhr3, yeah sounds sane
<mhr3> Saviq, coolio, lp:unity8? :)
<Saviq> mhr3, weell now let's not get ahead of ourselves ;)
<mhr3> Saviq, would be nice to get it in there ;)
<Saviq> mhr3, there's too many FIXMEs in there still
<Saviq> mhr3, that need to go before getting into trunk
<tsdgeos> Saviq: want me to add the code for the case in which you change the width of a column in a vJournal with items on it and so i need to force resize on them?
<tsdgeos> or we're not planning to do that and i can leave a TODO?
<mhr3> Saviq, so chop, chop, fix them ;P
<Saviq> tsdgeos, I think it'd be good, as we might scale the window without refreshing the model
<tsdgeos> ok
<tsdgeos> doing
<Saviq> mhr3, s/icon/art/ anyone?
<mhr3> Saviq, got it in a branch, but adding real tests in the same branch... so it's... "fun"
<Saviq> mhr3, OMG REAL TESTS?
<mhr3> RIGHT?!
<Saviq> mhr3, btw, so if you export the FORCE_NEW_SCOPES=1, Unity 0.1 becomes the same as Unity 0.2?
<mhr3> Saviq, pretty much, yea
<Saviq> mhr3, so if we wanted to merge new-scopes into unity8, how could we differentiate between the two when selecting a renderererererer?
<Saviq> mhr3, we could just go for .hasOwnProperty("template") or so
<mhr3> Saviq, well the new scopes give you the an object for category.renderer, old ones just a string :)
<Saviq> mhr3, yeah, which should not be "renderer" btw, but "template" :P
<mhr3> Saviq, i thought it wouldn't like undefined
<Saviq> mhr3, it can deal fine with undefined
<mhr3> but sure, if a bit of code is added to handle it
<Saviq> mhr3, or we can make it deal with it
<Saviq> mhr3, yeah, that
<mhr3> Saviq, but yea, the ultimate idea is to have all the code sitting in trunk but disabled by default
<mhr3> makes dev on it easy
<Saviq> mhr3, I'm just worried that will hold us back too much
<Saviq> mhr3, like the above â you'd name it template, but didn't want to break old stuff, so went for renderer
<mhr3> right
<mhr3> there are pros and cons
<Saviq> mhr3, and then we'll build all kind of bolierplate code to make it work both ways
<mhr3> as always :)
<Saviq> and then after we flip the switch we'll have to rip that all out again
<mhr3> Saviq, ultimately in unity8 pretty much all the changes will be limited to the new card renderer
<Saviq> mhr3, that is true, but that's the thing - we could rip out half of the code there already
<mhr3> this renderer <> template snafu doesn't sound like a big deal
<Saviq> mhr3, sure, that's just one example
<greyback> Mirv: hey, are the QtQuick Controls packaged in the Qt5.2 PPA?
<mhr3> Saviq, imo the cost of keeping compability with both isn't that high
<mhr3> at least not right now
<mhr3> things will get more fun once we do previews and stuff
<mhr3> for me it's the classical let's not diverge from trunk unless we have to
<Saviq> mhr3, yeah of course - but that's what I mean is holding us back, for which I'm not sure we have time - or want it to
 * tsdgeos finds a bug in the verticalJournal implementation
<tsdgeos> damn unittests!
<mhr3> Saviq, i can work eitherway really, it's a have-a-look-dear-manager feature :P
<Mirv> greyback: no, sorry. raising on my todo list.
<mhr3> Saviq, so if you want to do gutting of code from the branch, feel free to
<mhr3> Saviq, i don't think that's worth it, will just complicate merging
<greyback> Mirv: it's not critical for me, so no need to re-prioritize just for me
<mhr3> i mean, it should be right before merging to trunk
<Mirv> ok, only slightly notching it up then ;)
<dednick> mhr3: ping
<mhr3> dednick, pong
<Saviq> mhr3, yeah
<dednick> mhr3: howdy. just looking back into the dee thing i left off. I agree with not linking having a new base class.
<dednick> mhr3: although i may have to change the DeeModelface if we want to do it properly
<dednick> mhr3: so that we can get the multiplexer from the filter model backend.
<mhr3> dednick, what do you have in mind? cause yea, i'm not sure what would be the nice way to do it
<mhr3> dednick, also, how was capetown?
<dednick> mhr3: nice and warm. although i was only there for 2 days. Hiked table mountain.
<mhr3> dednick, oh? just 2 days? did the city frighten you or something? :)
<dednick> mhr3: hehe. no, just had other places to go :) Want to spend more time there next time around though. Really good climbing on table mountain.
<mhr3> did you do actual climbing there as well?
<dednick> mhr3: no, just some hiking.
<Saviq> Mirv, .install updates for qtdeclarative: http://bazaar.launchpad.net/~unity-team/kubuntu-packaging/qtdeclarative-opensource-src-5.2-rc2/revision/97
<mhr3> dednick, will want some more tips, heading there as well in a month ;)
<tsdgeos> Saviq: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1371/?#showFailuresLink still happening?
<Saviq> tsdgeos, that's new actually
<tsdgeos> is it?
<Saviq> tsdgeos, if you look at the videos
<Saviq> tsdgeos, unity8 never shows up
<tsdgeos> ok
<Saviq> tsdgeos, https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1371/artifact/results/autopilot/artifacts/
<tsdgeos> may be that i broke something in the merge
<Saviq> tsdgeos, I don't think so, seen that for other branches yesterday
<dednick> mhr3: awesome. you going for sprint?
<mhr3> dednick, yep
<tsdgeos> Saviq: ah
<Saviq> tsdgeos, "init: unity8 main process (11206) killed by TERM signal"
<Saviq> tsdgeos, is what ends up in .xsession-errors
<Saviq> tsdgeos, no idea where that comes from :/
<tsdgeos> Saviq: so we're crashing again?
<Saviq> tsdgeos, TERM, not crashing
<Saviq> tsdgeos, and there's no .crash file around
<tsdgeos> right
<Saviq> tsdgeos, it's like it's killed before it really starts
<tsdgeos> Cimi: so what comment would you add?
<tsdgeos> Cimi: are you going to ask for a comment in all the lines that do something right?
<dednick> mhr3: lucky! You must hike up a route called India Venster. book through http://www.hiketablemountain.co.za/ . They are really nice guides.
<Saviq> greyback, â
<tsdgeos> because i am a bit against literate programming tbh
<Mirv> Saviq: thanks
<Saviq> mhr3, you staying past the sprint?
<mhr3> Saviq, nope, but will be there the whole weekend before it
<Saviq> mhr3, cool, we're staying a few days past with greyback
<mhr3> Saviq, and arriving on sunday?
<Saviq> mhr3, yes
<greyback> mhr3: yep
<dednick> can I come?
<dednick> :)
<dednick> its cold here
<mhr3> i'm flying there on friday, so should have most of saturday and whole sunday free
<mhr3> a few more designers are doing that as well
<RAOF> You guys have *another* sprint?
<Saviq> RAOF, design one
<Saviq> RAOF, we're just there to say NO
<Saviq> from time to time
<RAOF> :)
<Saviq> and get fired
<RAOF> All of the things we saw last week looked perfectly fine from Mir's point of view (ie: they didn't involve us doing anything different âº).
<RAOF> As the people implementing them you may have other ideas :P
<Saviq> RAOF, yes, there's kgunn that will be saying NO for you guys ;)
<mhr3> nice summary :)
<mhr3> dednick, the link looks good, will check it out :)
<mhr3> dednick, anyway back to dee, i was thinking about something like - http://paste.ubuntu.com/6550461/
<mhr3> dednick, the nice thing about it, is that the usage of a FilterModel is just an impl detail
<mhr3> and there could even be a "demultiplex-changeset" property
<mhr3> default TRUE
<mhr3> the not-so-nice thing is that doing things a bit more lazily would need more thought
<mhr3> so for example the impl wouldn't keep a filtermodel unless you called _get_bin for it yet
<mhr3> s/yet//
<Cimi> tsdgeos, link to bugreport
<Cimi> tsdgeos, on that line
<tsdgeos> Cimi: why do you want a link to a bugreport that has nothing to do with the code?
<tsdgeos> the code is not a workaround
<tsdgeos> the code is correct code that works by itself
<tsdgeos> sure it happens that the old code should have worked and does not
<tsdgeos> and that is a bug
<Cimi> tsdgeos, ah
<tsdgeos> but the new new code is correct
<tsdgeos> as i already mentioned in the comment i made
<Cimi> ok so don't add comment
<Cimi> I thought was a workaround
<seb128> Cimi, hey, could you review/ack the change on https://code.launchpad.net/~larsu/overlay-scrollbar/hide-scrollbars-before-unmapping/+merge/197415 ?
<Cimi> seb128, I wasn't a fan of that but I'll have a look
<tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/search_history_pointer_correct_pointer_position/+merge/197423/comments/457546
<seb128> Cimi, if you are not a fan please find another way to fix bug #1086494, those warnings are annoying
<seb128> Cimi, thanks
<ubot5> bug 1086494 in overlay-scrollbar "GtkScrolledWindow is mapped but visible child GtkScrollbar is not mapped" [Undecided,In progress] https://launchpad.net/bugs/1086494
<Cimi> seb128, yeah will think about it
<seb128> Cimi, thanks
<Cimi> seb128, it's weird
<Cimi> seb128, dunno why mapped children should be mapped if parent is mapped :-\
<Saviq> mzanetti, what we talked about yesterday https://qt.gitorious.org/qt/qtdeclarative/commit/75a6f86f685f1a5ce6cb91212641fe446a37be2e
<seb128> larsu, ^
<Cimi> seb128, if that's the warning, you should unman not hide
<Cimi> *unmap
<mzanetti> Saviq: nice one :)
<Saviq> mzanetti, we need a qmltryrunner that does that
<seb128> Cimi, well, I'm running larsu's fix for a week and it made those warning go away without side effect
<seb128> but maybe
<seb128> I'm not picky on the solution
<Cimi> seb128, hide unmaps and change visible flag as well
<nic-doffay_> Saviq, is this still the same write issue as before? (Getting this on run_on_device -s) W: Not using locking for read only lock file /var/lib/dpkg/lock
<seb128> I just want gedit to stop spamming stdout
<Cimi> seb128, unmaps just unmaps but does not change visible gtk flag
<Saviq> nic-doffay_, very possible, did you make your device writable?
<seb128> ok
<Cimi> seb128, better to use unmap if possible
<seb128> let's way for larsu to comment
<seb128> he understand those stuff better than me
<larsu> Cimi: unmap is not enough, you'd also need to unrealize
<nic-doffay_> Saviq, no I assumed that step wouldn't be required...
<mzanetti> Saviq: you mean exporting the QTestRootObject?
<nic-doffay_> What's the command?
<larsu> Cimi: that's what the warning is about
<Saviq> nic-doffay_, it alwaysis
<Saviq> nic-doffay_, building unity8 on the device requires installing packages on the phone - so you need writable
<Saviq> mzanetti, yeah
<Saviq> mzanetti, although... that might mean the tests will actually run under qmlscene, too ;)
<mzanetti> Saviq: hmm... but shouldn't happen in the QtTest import?
<Saviq> mzanetti, oh well, right
<Saviq> mzanetti, it's interesting why they'd do it in the runner and not the plugin indeed
<Cimi> larsu, it's about map, not realize
<mzanetti> Saviq: not sure what I'm missing... but I think this commit does it in QtTest
<mzanetti> so I'm not sure why exactly it fails
<mzanetti> unless we have a version where this commit is just not in yet
<Saviq> mzanetti, we do
<Saviq> mzanetti, right, so... more investigation to be had
 * Saviq finds it confusing that libqt5declarative5 comes from qtquick1....
<larsu> Cimi: I think it complains about realize when only unmapping and remapping (I vaguely remember trying that first)
<larsu> Cimi: feel free to fix it differently, but I don't want to spend more time on it, as the solution I proposed seems to work fine
<seb128> larsu, Cimi: bug #1086494 (the title has it)
<ubot5> bug 1086494 in overlay-scrollbar "GtkScrolledWindow is mapped but visible child GtkScrollbar is not mapped" [Undecided,In progress] https://launchpad.net/bugs/1086494
<larsu> and makes seb128 happy :)
<dednick> mhr3: why are there void func pointers on the end of interfaces in dee?
<larsu> seb128: ya, I think I tried unmapping-only first and then it complains about realize
<dednick> mhr3: is it byte alignment?
<Saviq> /food
<mhr3> dednick, it's for extending the interface without having to break the abi
<seb128> larsu, +1 on not spending more time on it, that solution works, if Cimi has a better one I guess you are fine commenting on it though?
<dednick> mhr3: ah, so add a function and remove a void?
<mhr3> dednick, yep
<dednick> mhr3: smartypants
<Cimi> seb128, larsu I just don't see the point why we should change visible gtk flag for that
<mhr3> dednick, seen the pastebin?
<Cimi> I guess we can play with realise and map as well
<mhr3> dednick, that wouldn't need changes to DeeModel itself
<Cimi> if we call unrealise, we call unmap
<seb128> Cimi, can you propose a patch with what you describe?
<larsu> Cimi: okay, please do that, then
<dednick> mhr3: ah, no i hadnt seen it.
<Cimi> seb128, can do later
<seb128> thanks
<mhr3> dednick, so stop ignoring me! :P
<nic-doffay_> Saviq, yeah it's working now, that's weird though because usually I haven't had any write issues after a flash.
<dednick> mhr3: so basically just keep a static map of backend->Demultiplexer?
<mhr3> dednick, not exactly, this allows you to even have multiple demultiplexers on top of the same model
<mhr3> dednick, and you'd get the individual FilterModels by calling the _get_bin() method
<mhr3> dednick, eh yea, i'm missing self ptr in the get_bin()
<dednick> mhr3: um, so how do we use the same demultiplexer across multiple filter models if it's not using the same one for the given backend?
<dednick> since we're not exposing DeeDemultiplexer to unity anymore that is.
<mhr3> dednick, since the usage of FilterModel is just an impl detail, it's up to the Demultiplexer itself to ensure that the models(bins) have proper data
<mhr3> dednick, and eh, the idea is that the Demultiplexer itself would be a public class in the lib
<mhr3> but it's a generalized data demultiplexer, not just a changeset-* signals demultiplexer
<dednick> mhr3: so we're still creating the demultiplexer in unity?
<mhr3> yes
<mhr3> and using it to get the per-category models using its get_bin()
<dednick> mhr3: then what is the point of changing it? who cares if it's generalised?
<mhr3> it's just an idea
<dednick> mhr3: "on the other it's very specific functionality which is now exposed as a base dee class" :)
<dednick> mhr3: i thought the idea was not to expose.
<mhr3> splitting data from one model into multiple is a valid use case
<mhr3> and the demuliplexer seems like a correct way to do it
<mhr3> what i didn't like about the previous approach is that it was too loose - just demultiplexing the signals, and having to manually "tag" each model that should use it
<dednick> mhr3: i c
<mhr3> dednick, that all being said, maybe you have a better idea with the change to DeeModel? i'm not sure what exactly you want to do there
<dednick> mhr3: i'm still unclear as to how the FilterModel knows it has a demultiplexer if it isn't told.
<mhr3> dednick, fwiw the usage of filtermodel is optional, it's up to the demultiplexer to split the data, it could just as well create new DeeSequenceModels and maintain the rows itself (using the bin_func)
<mhr3> of course that would be silly and expensive :)
<mhr3> but the point remains, the split is up to it, not necessarily the submodel
<mhr3> and since this will be inside dee, you could just add internal methods to filtermodel
<dednick> mhr3: i'm still confused... How would we create the demultiplexer in unity (using dee_multiplexer_new) and have the BinFunc in dee if it's internal to FilterModel.
<dednick> mhr3: you are very confusing...
<mhr3> dednick, would be easy with a whiteboard, how come you're not at the office?
<mhr3> and how come i'm not at the office? :P
<mhr3> dednick, the bin func is something the user of the demult has to provide
<mhr3> otherwise it'd be pretty useless
<dednick> mhr3: right. but then what are the internal methods in FilterModel?
<dednick> mhr3: because i'm lazy
<dednick> maybe i'll just leave this and come in tomorrow
<mhr3> dednick, dunno really what the internal method would be, whatever is needed to make it work :)
<mhr3> afaict it might not even be necessary to add an internal method
<dednick> mhr3: lol. ok
<mhr3> dednick, but agreed, let's postpone till tomorrow
<mhr3> i'll have a deeper look at it meanwhile :)
<nic-doffay_> Saviq, want to top approve this? The fix is working for me.
<tsdgeos> errrrr
<Saviq> nic-doffay_, sure, can you add a "needs-ap-test" to the bug pleaes
<Saviq> please, even
<tsdgeos> un errrr
<Saviq> tsdgeos, ?
<Saviq> tsdgeos, -
<Saviq> dednick, added more data to https://bugreports.qt-project.org/browse/QTBUG-34351
<Saviq> dednick, btw, there's "provide missing info" at the top, that changes the status back from NEEDINFO to REPORTED
<Saviq> dednick, it might slip through the cracks otherwise
<dednick> Saviq: ah. thanks
<Saviq> dednick, btw, https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 is correct still, is it? meaning we haven't decided on anything that would make this not needed?
<tsdgeos> Cimi: mzanetti: we broke the delegateRange stuff when merging the dashrenderer stuff
<Saviq> dednick, only question there - will this work fine with encoding? as in does g_date_time_format cough up UTF8 - and if so, shouldn't we go for QString::fromUtf8?
<Cimi> delegaterange?
<mzanetti> meh
<tsdgeos> delegateCreationBegin
<mzanetti> really?
<tsdgeos> yep
<tsdgeos> it's assigned in the wrong direction
<tsdgeos> never gets to the filter grid
<Saviq> :/
<tsdgeos> i guess i'll go over all the changes from that merge
<tsdgeos> because it's broken lots of things
<tsdgeos> so a post review won't hurt
<Saviq> tsdgeos, list down what test could be added please
<dednick> Saviq: my opinion is that it's the correct way to do it. But yes, should be using fromUtf8
<tsdgeos> Saviq: it's hard to test what test could be added
<tsdgeos> because the test would be "make sure the item of the list gets that assigned"
<tsdgeos> and that is happening
<Saviq> tsdgeos, I understand
<tsdgeos> is just that the item is not correctly passing that to its children
<tsdgeos> which is an implementation detail
<Saviq> tsdgeos, just when going over it again - try to see if there's anything else worth testing
<tsdgeos> i.e. we could not have had that test before the change because the change is that introduced it
<Saviq> tsdgeos, not necessarily that particular thing
<tsdgeos> sure
<Saviq> larsu, dednick, where does the time format come from, btw? locale? are the choices hardcoded in the indicator?
<Saviq> larsu, I mean for the datetime indicator, sorry for the lack of context
<larsu> Saviq: don't know, let me check
<Saviq> nic-doffay_, you can add tags to bugs, just below the description
<Saviq> nic-doffay_, this way you can then find all of them with that tag by: https://bugs.launchpad.net/bugs/+bugs?field.tag=needs-ap-test
<larsu> Saviq: ugh, right now datetime sends a string :(
<larsu> containing the time itself
<Saviq> larsu, do you know about the messaging indicator then?
<Saviq> larsu, I'm looking at https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343
<larsu> Saviq: messaging indicator sends unix timestamps
<Saviq> larsu, and the format?
<larsu> Saviq: I don't think they send it
<Saviq> hrmpf /me is lost
<larsu> why?
<Saviq> why would we need the TimeFormatter then
<Saviq> instead of using Qt's internal formatting based on locale
<Saviq> as well, I assume LC_TIME is what it's for
<larsu> ya, it changes the time when the timezone changes
<larsu> also (in the future (maybe)) when coming back from suspend
<Saviq> larsu, sure, but that has nothing to do with the formatting
<Saviq> larsu, as long as we take the timestamp
<Saviq> and format it according to LC_TIME
<Saviq> that should do
<Saviq> dednick, thoughts â?
<Saviq> if nothing gives us an explicit time format
<dednick> larsu: datetime sends x-canonical-time & x-canonical-time-format
<nic-doffay_> Saviq, cool
<larsu> Saviq: you want the time string to change when the timezone changes
<larsu> this is all that the Timeformatter thing does
<dednick> which is unit time
<dednick> *unix
<larsu> dednick: ah, datetime doesn't send strings anymore? It does on my desktop...
<Saviq> dednick, right, so I'm trying to find out where does the format string come from :)
<dednick> larsu: i mean for appointments
<Saviq> dednick, if it comes from locale
<Saviq> and well - if it doesn't... shouldn't it?
<dednick> Saviq: it's hardcoded
<dednick> Saviq: in appointments
<dednick> Saviq: well, appointments have this funky format where it can be daily, or single, and changes based on proximity to event.
<Saviq> dednick, right, I'm just wondering if it's the right thing to do
<Saviq> dednick, the proximity thing should be system-wide
<Saviq> dednick, so SDK-ish
<dednick> Saviq: i'm sure design would tell us if it wasnt. :)
<dednick> it's same i desktop
<Saviq> dednick, wherever you wanted "human readable time", you'd just use a time formatter from the SDK
<Saviq> dednick, and tell it to do smart things
<Saviq> dednick, doing it in the indicator seems weird
<larsu> Saviq: ya, I could totally see this being in the sdk
<Saviq> dednick, we should just get a timestamp from them
<dednick> Saviq: right. so basically what this thing is, but without the format string
<Saviq> dednick, well, more, if we said it's meant to be smart about formatting
<Saviq> dednick, and do "yesterday" / "tomorrow" and such
<dednick> Saviq: sure.
<Saviq> dednick, but it really feels like the indicators should just cough up timestamps
<Saviq> dednick, and let the UI decide what's best for each use case
<Saviq> dednick, btw, we had something doing the smart thing for the people scope
<Saviq> dednick, pure JS
<dednick> Saviq: yeah, i think i did mention that before. But it's being used in desktop as well, so we cant really get right of it easily.
<dednick> s/right/rid
<Saviq> dednick, well, we can just ignore it :)
<larsu> dednick: what do you mean? We should always port towards using timestamps only
<larsu> and I think datetime is the only one left
<dednick> Saviq: what would we do about the format gsettings? they're @ com.canonical.indicator.datetime . It applies to both time label & calendar entries.
<Saviq> dednick, it feels weird to have it only for the indicator
<Saviq> dednick, it should be a system-wide setting
<larsu> Saviq: afaik, this is not possible, as different places in the ui want to refer to times differently
<Saviq> larsu, yeah, that, why?
<Saviq> larsu, I think other than it being "long", "short", "human-readable" etc.
<Saviq> larsu, which can be derived from locale, AFAICT
<larsu> Saviq: don't remember. I think it was mpt who told me at some point
<larsu> or another designer...
<Saviq> larsu, but nothing should explicitly chose a time format...
<Saviq> mpt, hey, we're pondering on why would you want different time formatting in different places - other then referring to those formats by descriptive names like "long", "short", "human-readable" etc.
<dednick> Saviq: because we dont want the time to be "Now"
<dednick> :)
<dednick> hey Saviq, what is the time? reply: "now"
<Saviq> dednick, that's why I'm saying - a few different formats, but not arbitrary ones
<Saviq> dednick, but derived from the locale
<Saviq> mpt, is it really necessary for things to come up with arbitrary time formats? doesn't that result in inconsistency in the UI? and make it confusing when you need/want to change this - changing the time global time formatting would not affect, say, the indicator
<Saviq> dednick, I mean TimeFormatter { timestamp: 123456; format: "short" }
<Saviq> dednick, instead of  TimeFormatter { timestamp: 123456; format: "hh:mm" }
<Saviq> dednick, as hh:mm is not locale-independent
<dednick> Saviq: right, well i didnt mean abritrary. but there was no central place to get this global thing from. I agree.
<dednick> But for the time indicator, it's using a label for the widget, which i guess is going to have to change to a timestamp.
<Saviq> dednick, oh yes
<Saviq> dednick, fortunately it can, just by adding a new prop - while keeping the other for desktop
<Saviq> dednick, actually BUT
<Saviq> dednick, the label should not be coming from the indicator at all, should it...
<Saviq> dednick, we just need to know it's the current time
<Saviq> dednick, so that indicator does not need to send up new stuff at all
<dednick> Saviq: well we need it for desktop unless we port that as well.
<Saviq> dednick, yeah, what I'm saying - we can just leave the indicator be
<Saviq> dednick, but ignore what it's coming up with
<Saviq> dednick, and just format the time ourselves
<dednick> Saviq: you mean to use QTime::getCurrentTime or whatever?
<Saviq> dednick, and not even get the current time from the indicator - as why would we
<Saviq> dednick, yeah
<dednick> Saviq: we use it to sync time on greeter as well.
<dednick> but i guess that can just be QTime as well.
<Saviq> dednick, only thing we might need from the indicator is the timezone
<Saviq> dednick, and well, we need https://blueprints.launchpad.net/ubuntu-ui-toolkit/+spec/time-component, too
<dednick> Saviq: we sort that out in the formatter
<dednick> Saviq: the tz i mean
<Saviq> dednick, the only thing the indicator gives us right now, is timely updates without the above component
<Saviq> dednick, yeah ok
<Saviq> aaanyway
<Saviq> that's a bigger task
<dednick> Saviq: should we put the formatter in toolkit then?
<Saviq> dednick, ultimately, yes - not in the state it's in atm probably
<Saviq> dednick, it needs to be much more complete
<dednick> Saviq: yay. wont take months to get through
<Saviq> dednick, so *while* we care about time formats from the indicators, we'll merge your things, but I'll be filing bugs against projects
<Saviq> this may even be a blueprint, FWIW
<dednick> ok
<Saviq> dednick, so, UTF8?
<dednick> Saviq: yeah, changing now
<mzanetti> kgunn: Why "Opinion"? https://bugs.launchpad.net/bugs/1240939
<ubot5> Ubuntu bug 1240939 in ofono (Ubuntu) "[ofono] PinRequired doesn't change to "puk" any more on 3 invalid attempts" [Undecided,Fix released]
<mpt> Saviq, I donât understand the premise of the question. What things are coming up with arbitrary time formats?
<Saviq> mpt, the datetime indicator has a gsetting, for one
<Saviq> mpt, the events coming from the messaging indicator send them up, too, depending on the time proximity of the event
<Saviq> dednick, larsu, do you know they have those formats hardcoded for events, or are they constructed based on the locale ââ?
<mpt> Saviq, is there a way to implement the settings shown in <https://wiki.ubuntu.com/TimeAndDate?action=AttachFile&do=view&target=settings-clock.png> that is better than using a gsetting?
<dednick> Saviq: it's definately generated manually.
<Saviq> mpt, well, datetime indicator is slightly trickier, as it's more about user preference rather than locale
<Saviq> mpt, and yeah we can have those settings without actually trying to come up with a datetime string
<larsu> Saviq: the messaging indicator uses relative times. The strings for time periods are translated normally
<larsu> there's nothing in the locale that can help us there
<larsu> datetime is a different matter
<larsu> charles might know why we're not using locale there
<Saviq> larsu, well, for human-readable you still want the same resolution
<Saviq> larsu, so saying, "tomorrow" is not enough
<larsu> maybe because we want to be able to change it dynamically?
<Saviq> larsu, but for "tomorrow, 12:00am", you need the locale
<larsu> Saviq: the same resolution as what?
<Saviq> larsu, the human-readable thing usually needs to carry as much information as "a format"
<Saviq> if you have "2013.12.11 12:00am", you can't just convert that into "tomorrow"
<Saviq> you need "tomorrow, 12:00am"
<Saviq> so that's where locale comes into play as well
<larsu> the messaging menu uses relative times
<Saviq> larsu, isn't "tomorrow" relative?
<Saviq> what would it do with the 12:00am?
<larsu> I mean relative as in "24 hours ago"
<Saviq> sure, and past that, it's going to be yesterday
<larsu> no
<Saviq> 36 hours ago?
<larsu> it does "days ago!
<larsu> "days ago"
<Saviq> well, it might be fine for messages
<Saviq> it's not for events
<larsu> right, and that's what my original point was: every ui component needs it a bit differently
<larsu> so having a few gsettings might not be enough
<Saviq> larsu, doesn't mean it needs to deal with all of it internally
<larsu> but then, ianad
<Saviq> larsu, we just need a flexible enough time formatter
<larsu> which is what the MR is about, no?
<Saviq> not if it deals with arbitrary time formats
<Saviq> which it does
<Saviq> coming with the events
<dandrader> does the battery indicator icon turn to "charging" (that lightning bolt) when you plug your Nexus 10 to your pc's usb port?
<dandrader> with me it happens only when I plug to the actual charger
<mpt> Saviq, as I recall, ted used a datetime string so that geeks could, if they wanted to, use a datetime format that wasnât represented by the checkboxes. I donât really mind one way or the other, as long as the checkboxes work.
<Saviq> dandrader, no, might be it's not getting enough umph
<Saviq> mpt, right, sure, we can leave the gsetting option there, but I'm after a generic solution here
<dednick> Saviq: pushed fromUtf8 change
<mpt> Saviq, what do you mean by a generic solution?
<dandrader> Saviq, but I suppose it still charges, albeit slowly, right?
<Saviq> dandrader, possible both ways, really
<Saviq> mpt, that app authors can just use a simple-as-possible API for displaying time in their apps - one that's consistent with what the user chose as their locale
<Saviq> mpt, or their preferred time format
<Saviq> mpt, instead of everyone and their mother inventing a time format just-right for their usage
<Saviq> mpt, that completely disregards any locale/user-preference there might be
<seb128> Saviq, you want to standardize stuff like "display the current month as part of the time"?
<seb128> that feels weird
<Saviq> seb128, no
<seb128> gettext/the locale should already give you a 24/12 format adapted to your locale
 * Saviq needs to write this down
<Saviq> seb128, I'm after: user selects a locale or their preferred time formatting in the settings app
<seb128> Saviq, yeah, you need some concrete examples I think
<seb128> Saviq, like "display the month with the time" (what the indicator currently have)
<Saviq> seb128, everywhere where there's time displayed, it will adhere to the user-selected preference above
<Saviq> seb128, datetime indicator is very specialized
<seb128> or if not what preferences do you see?
<mpt> Saviq, as I understand it, problems with the GNU locale system include (1) not being overridable in a way that works across apps, (2) not updating instantly in every app, and (3) not standardizing either relative dates (e.g. âYesterdayâ) or relative times (e.g. â2 minutes agoâ). Maybe Qt/QML fixes some of those? A new API might fix the others.
<seb128> we don't have any "time format preference" atm
<Saviq> seb128, yeah, we just use locale - but we might let people select a different format than the locale comes up with, right?
<mpt> Saviq, oh, and (4) requiring everyone to use the Gregorian calendar.
<Saviq> mpt, (1) not sure why? you can override LC_TIME and assuming everything uses locale (as opposed to arbitrary format strings), all should work
<seb128> Saviq, how different? I never felt the need to change my time format, just wondering how common/useful that is
<Saviq> mpt, (2) yeah, that's a problem
<Saviq> mpt, (3) that's exactly something I'd like to solve on the SDK level
<Saviq> mpt, (4) yeah... can't help you there...
<Saviq> seb128, people that want their phone in US English, but can't read 01/01/2013, for example
<seb128> Saviq, looking to my android, it doesn't seem they have a time format preference
<seb128> that seems a geeky usage (and it's date, not time)
<Saviq> seb128, doesn't matter, really - if we just say your selected locale is your time format, that's fine, too
<Saviq> seb128, everything I was talking about applies
<Saviq> seb128, in the N9 I have separate "Language" and "Regional format" selection
<Saviq> seb128, and can change 12h vs. 24h separately
<mpt> Saviq, (1) for example if Iâm CTO on a military base and I want 24-hour time everywhere, thereâs no radio button I can toggle that will set it in LibreOffice and Thunderbird and XChat. If thatâs *only* because there isnât a GUI for it, rather than because the underlying setting doesnât exist or because some of those apps would ignore it, then wonderful. :)
<seb128> Saviq, right, so basically you want to create a "get_time()" that calls e.g strftime with the right parameter, depending of a gsettings config (e.g "show 24 hours" would use %R)
<Saviq> seb128, yeah, something like that
<Saviq> seb128, the app developer should never know
<Saviq> seb128, they should just say "I want the long date-time format", "I want the short time format", "I want the human-readable date-time format", "I want the human-readable time format"
<seb128> seems like a JDI thing then? e.g we need a bug with a list of options to support and somebody to write the code
<seb128> or was there something to discuss?
<Saviq> seb128, JDI?
<Saviq> ah Just Do It
<Saviq> YOLO
<seb128> just do it
<seb128> ;-)
<seb128> well, you just listed 4 cases
<Saviq> seb128, yeah, this grew from "indicators should not give up time formats" to a more generic "GNU locale is bad" conversation ;)
<Saviq> seb128, sure, there's more
<Saviq> seb128, much more
<seb128> soon you are back to having strftime and % options :p
<mpt> Saviq, (3) I would be keen to review or contribute to that API design. Itâs bothered me for about seven years.
<Saviq> mpt, will
<mpt> I could help collect use cases, for example.
<Saviq> mpt, that would be fantastic
<Saviq> mpt, let me file a blueprint
<mpt> ok
<Saviq> mpt, https://blueprints.launchpad.net/ubuntu-ui-toolkit/+spec/time-formatter
<nic-doffay_> dandrader, any idea when this is ready  to land? https://code.launchpad.net/~dandrader/unity8/runningAppsEndClose/+merge/196257
<nic-doffay_> dandrader, nm
<nic-doffay_> merged already.
<dandrader> nic-doffay_, not only merged, but also released as well :)
<nic-doffay_> dandrader, haha yeah I shot off those questions while reading the diff :P
<nic-doffay_> dandrader, can I use it to fix this: https://bugs.launchpad.net/unity8/+bug/1213034
<ubot5> Ubuntu bug 1213034 in Unity 8 "Can't dismiss keyboard by tapping outside of search entry" [High,Opinion]
<dandrader> nic-doffay_, to remove focus from the text input field?
<mzanetti> Saviq: what do I need to do in order to make an application show up? Context: I dropped Stage.qml and trying to reimplement it
<Saviq> mzanetti, "show up"? you need to focus it
<mzanetti> Saviq: so it is started, I get ApplicationManager.focusedApplicationIdChanged(). but I don't see it on the screen
<Saviq> mzanetti, you also need to hide the dash I think
<mzanetti> mhm... /me tries
<Saviq> mzanetti, IIRC the shell is always on top of apps (only way we can get the launcher on top of apps)
<dandrader> nic-doffay_, using the PressedOutsideNotifier seems a bit of an overkill for that. I think what we need is to make the dash background or something take/accept input focus when touched
<nic-doffay_> Saviq, ^
<mzanetti> Saviq: right... I thought something like this. just didn't find the place in the old Stage where that happens. will search more
<Saviq> dandrader, well, it's not just about the dash
<Saviq> dandrader, but say you pull the launcher in, pull the panel in
<Saviq> dandrader, and that's exactly what we need - see, here's an area where I'm at (and my popover)
<Saviq> dandrader, if you touch anything else, I want to unfocus
<dandrader> Saviq, hmm, right. so you want to lose focus regardless, even if noone else is interested in it
<Saviq> dandrader, yes
<dandrader> Saviq, nic-doffay_  therefore having it working differently than a traditional text entry field when using a mouse
<dandrader> where is loses focus only once another focusable widget is clicked
<Saviq> dandrader, yeah, because we want to hide the OSK
<Saviq> dandrader, so it's more about that than the mouse
<Saviq> dandrader, as soon as you've stopped typing - you don't want the OSK
<Saviq> dandrader, and to bring it back - you want an action from the user on the field they want to type in
<dandrader> Saviq, is this behavior specific for this search text entry or is it for any text entry in general?
<Saviq> dandrader, probably not specific for us, no
<Saviq> dandrader, not even for the "we have a drop-down" case, since that component should be available in the SDK, too
<dandrader> Saviq, I'm asking because there's (or might be) this case where you want to vertically scroll your ui without unfocusing the text entry.
<Saviq> dandrader, not sure - could be a prop on the text entry, FWIW
<Saviq> dandrader, the OSK is something you usually want to get rid of
<Saviq> dandrader, when looking at other things
<Saviq> dandrader, just 'cause it takes a lot of screen real estate
<Saviq> dandrader, what usecase do you have in mind?
<tsdgeos> Cimi: i remerged https://code.launchpad.net/~aacid/unity8/dash_show_home_no_index/+merge/197714
<dandrader> Saviq, just recalling how it worked witht the N9 when on a web page, for instance. you're typing on a text entry but could peek up or down the page for some information relevant to what you're typing. then the next char you type make the page scroll back to have the focused text entry on screen again
<Cimi> ok
<Saviq> dandrader, right, but OTOH it hides when typing in the address bar - as soon as you touch the history
<dandrader> Saviq, so, in that case, hiding the vkb (i.e. unfocusing the text entry) is not right or wrong, I think. But it's a design decision that should be consistent throughout the system
<dandrader> "that case" meaning my example use case
<Saviq> dandrader, right, care to file a bug against ubuntu-ui-toolkit and ubuntu-ux?
<dandrader> Saviq, to ask about the "when to unfocus" behavior?
<Saviq> dandrader, it probably is basically about "what area do I consider being Â«in focusÂ» for my text field"
<Saviq> dandrader, yeah, for the dash it's definitely search entry + search history
<Saviq> dandrader, but for a website it might be the whole website
<Saviq> dandrader, it might be indeed a case by case thing
<dandrader> Saviq, will file the bug
<Saviq> dandrader, thanks, please provide a few use cases as you can think of, that justify one or the other behavior
<Saviq> dednick, you need to merge trunk into the formatter
<Saviq> Cimi, when you see a failure like https://code.launchpad.net/~aacid/unity8/dash_show_home_no_index/+merge/197714/comments/459831
<Saviq> Cimi, don't auto-re-approve - it's usually an issue - either a conflict or whitespace
<Cimi> Saviq, I approved again because albert merged trunk
<Saviq> Cimi, oh
<Saviq> Cimi, it wasn't there in the list of comments
<Saviq> Cimi, interesting
<Saviq> Cimi, sorry, reapproved
<Cimi> Saviq, your automatic launchpad bot is failing :P
<Saviq> Cimi, yeah, that's 'cause lp is failing - there should be a comment listing the new revision :P
<dednick> Saviq: thanks. will check now
<Saviq> mzanetti, you said something about haptic feedback / vibration? did you read about it coming, somewhere?
<mzanetti> Saviq: my galaxy nexus vibrates on every touch since the last flash
<mzanetti> trusty-proposed that is
<Saviq> hm interesting
<Saviq> mzanetti, wonder if it's something low-level that got enabled
<nic-doffay_> Saviq, so I'm assuming I should hold off on that then?
<mzanetti> Saviq: I thought so... weird thing is, it doesn't do any more. but no clue what I did
<nic-doffay_> re the keyboard dismissal...
<Saviq> nic-doffay_, no, please implement locally
<Saviq> nic-doffay_, if/when we get it from the SDK, we'll just use it
<Saviq> nic-doffay_, but let's have it in the mean time
<Saviq> mzanetti, lol
<nic-doffay_> Saviq, cool
<mzanetti> Saviq: well, I'm sure it did on friday when I last flashed
 * mzanetti flashes again
<Saviq> mzanetti, tsdgeos, /me and greyback|lunch have a meeting over standup
<mzanetti> greyback|lunch: o/
<Saviq> mzanetti, tsdgeos, and nic-doffay_ can't speak, so he put his stuff in the doc
<Saviq> tvoss, mtg?
<mzanetti> greyback: what's the difference between ApplicationManager's focusedApplicationIdChanged() and focusRequested() signals?
<tsdgeos> Saviq: standup?
<tvoss> Saviq, https://plus.google.com/hangouts/_/canonical.com/application
<greyback> mzanetti: focusRequested is when for some reason Mir changes the focused application in a way that shell wasn't responsible - e.g. an application started not by shell
<greyback> mzanetti: that signal is listened to by shell so that shell can decide if that new focus decision is correct or might need over-riding
<mzanetti> greyback: it's missing in unity-api
<greyback> mzanetti: it doesn't belong there really. It's a hack. It should go away once Mir looses the concept of focus
<mzanetti> greyback: huh? you mean the shell is responsable for it
<Saviq> greyback, https://plus.google.com/hangouts/_/canonical.com/application
<mzanetti> anyways. ok. it means I have to keep it for now I guess... thanks
<dednick> Cimi: you in office tomorrow?
<Cimi> afternoon
<tsdgeos> sorry internet broke
<tsdgeos> standup finished i guess?
<mzanetti> tsdgeos: no prob
 * mzanetti goes to pick up his car from the service... bbiab
<tsdgeos> collapsing still broken ^_^
 * tsdgeos hides
<kgunn> mterry: yo
<mterry> kgunn, hello!
<kgunn> mterry: got time in about 15 min to chat with me and greyback ?
<mterry> k
<kgunn> greyback: ?
<kgunn> dednick_: meant to say ....welcome back
<dednick_> kgunn: thanks!
<dandrader> Saviq, nic-doffay_ https://bugs.launchpad.net/ubuntu-ux/+bug/1259596
<ubot5> Ubuntu bug 1259596 in Ubuntu UX "When should a text entry lose focus?" [Undecided,New]
<Saviq> dandrader, cheers
<dandrader> Saviq, nic-doffay_ regardless of the decision, I'm thinking that it would be best if the unfocus action is taken not by the text entry itself but by the entity that has given focus to it in the first place (the input handling logic?). Otherwise we might get some race conditions: E.g. user taps outside focused entry onto yet another focusable item.
<dandrader> not sure if this centralized approach is actually doable, though
<dandrader> as we might end up having to change code in QQuickWindow ....
<Saviq> dandrader, I don't even think if it's that complicated
<Saviq> dandrader, all the use cases I can come up with, it's actually the text area itself that knows whether it makes sense for it to be focused when you tap outside of it (or outside of an area)
<greyback> kgunn: am there
<dandrader> Saviq, right, because the item itself sets its focus property to true (in hope of getting activeFocus) when pressed. Thus it would just set it back to false upon "pressed outside", letting the activeFocus go to someone else
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/more_filter_fixes/+merge/198427
<dandrader> Saviq, but I believe that approach (focused item unfocusing itself) won't work if we are to implement the "do not unfocus if it's a content scroll" case
<dandrader> but, anyway, let's wait to see what's the desired behavior
<dednick_> Saviq: getting a "Could not determine plugin installation dir" error building trunk
<tsdgeos> dednick_: dist-upgrade ?
<tsdgeos> you need the new scopes-shell thingie
<tsdgeos> dednick_: you're on trusty?
<dednick_> tsdgeos: no,
<dednick_> hm. maybe i should upgrade..
<tsdgeos> dednick_: i'm not sure we support non trusty nowadays
<tsdgeos> mhr3: is the unity-scopes-shell released for non trusty?
<mhr3> tsdgeos, nope, only trusty
<mhr3> tsdgeos, it's buildable on saucy, but you'd need to build all the dependencies as well
<tsdgeos> dandrader: there you go, you need some trusty-ness
<tsdgeos> err
<tsdgeos> dandrader: that was for dednick but he left and tab-completion decided to autocomplete to you, sorry :D
<dandrader> tsdgeos, np
<Saviq> dednick_, ./build -c
<dandrader> anyone has success shutting down Nexus 10 for good?
<dandrader> for me it just reboots when I try to shut it down
<Saviq> dandrader, hold power until it dies - should turn it of
<Saviq> dandrader, otherwise, hold all three
<Saviq> dandrader, and choose POWER OFF
<dandrader> Saviq, ok, thanks
<dednick> ahhh. how do I update to 14.04?! my update manager not picking it up
<tsdgeos> anyone knows what's broken with otto? https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1382/console
<dednick> tsdgeos: how do you upgrade to 14.04?
<tsdgeos> dednick: i did it the manual way
<tsdgeos> replace saucy  for trusty in /etc/aot
<tsdgeos> apt
<dednick> tsdgeos: ah...
<dednick> i can see that ending in tears..
<tsdgeos> it was pretty easy back when i did it
<tsdgeos> but it was just at the start of the cycle
<tsdgeos> so there were very few changes at that time
<cwayne> sudo do-release-upgrade -d
<cwayne> but disable extras first, i kept 404'ing on extras for trusty
<dednick> cwayne: thanks!
<cwayne> dednick: np :)
<Saviq> dednick, do-release-upgrade -d
<mhall119> Saviq: FYI, Kaleo has the work item to detect keyboard & mouse: https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-apps-convergence
<Saviq> ââ that
<Saviq> mhall119, yup
<mhall119> I assume everything in the SDK is available to Unity 8
<Saviq> mhall119, yeah of course
<Saviq> mhall119, we're pushing stuff up from unity8 into the SDK where it makes sense
<mhall119> cool, I'll try and find out when that will be implemented then
<tsdgeos> guys, i'm going to take a bit early EOD, not feeling too well atm
<tsdgeos> see you tomorrow
<Saviq> mzanetti, traceback from crashing unity-api test: http://paste.ubuntu.com/6551990/
<mzanetti> Saviq: that's a good one :)
<Saviq> mzanetti, yeah, but 95 steps...
<Saviq> we don't get as much in unity8 alone ;)
<Saviq> well, with 5.2 we probably do, then ;)
<mhr3> mzanetti, you wanted more tests - https://code.launchpad.net/~mhr3/unity-scopes-shell/scopes-ng-tests/+merge/198437
<mhr3> Saviq, ^ has your role changes too
<Saviq> mhr3, cool
<mhall119> Saviq: trying to load CMakeLists.txt in Ubuntu SDK, I get the following error when trying to configure cmake:
<mhall119> CMake Error at CMakeLists.txt:64 (message): Could not determine plugin installation dir.
<mhall119> do I need to add some Arguements to get it working?
<mhr3> Saviq, oh and i was supposed to ask which renderer is likely to come next
<mhr3> Saviq, as supported in the category templates
<Saviq> mhr3, by renderer you mean grid/carousel etc.?
<mhr3> Saviq, yep
<Saviq> mhr3, carousel, probably, then v. journal
<mhr3> thx
<Saviq> mzanetti, here's another one - seems to be racy
<Saviq> http://paste.ubuntu.com/6552106/
<mzanetti> Saviq: same test?
<Saviq> mzanetti, yes, stripped down
<Saviq> mzanetti, http://paste.ubuntu.com/6552115/
<mzanetti> Saviq: hmm... it's at the end of the test when cleaning up?
<Saviq> mzanetti, yeah
<nic-doffay_> Saviq, currently the inverse mouse area in the PageHeader dismisses the search box and activates whatever was pressed. Is this desired behaviour?
<Saviq> nic-doffay_, not sure, ideally it should block the tap, but allow for swiping... which is trickier somewhat
<nic-doffay_> Saviq, yeah I def think it should block the tap.
<Saviq> nic-doffay_, +1
<nic-doffay_> Saviq, there's still the issue of the swipe though and differentiating the touch inputs...
 * greyback to the airport
<Saviq> greyback, fly safe
<nic-doffay_> gl greyback
<mhall119> Saviq: any idea what I'm doing wrong in QtCreator?
<Saviq> mhall119, not if you don't tell me what's happening :)
<mhall119> CMake Error at CMakeLists.txt:64 (message): Could not determine plugin installation dir.
<mhall119> pasted 30 minutes ago :-P
<mhall119> when opening CMakeLists.txt and at the dialog to configure cmake
<mhall119> Saviq: http://ubuntuone.com/54blhOH0aIf6WnBtt3PPBr
<Saviq> mhall119, you don't have the build deps installed :)
<Saviq> mhall119, ./build-s
<Saviq> erm
<Saviq> ./build -s
<mhall119> build -s gives:
<mhall119> Note, selecting 'qtdeclarative5-unity-notifications-plugin' instead of 'unity-notifications-impl'
<mhall119> E: Unable to locate package unity-plugin-scopes
<nic-doffay_> dandrader, any thoughts on using your component to differentiate between touches and swipes?
<Saviq> mhall119, you not on trusty are you?
<mhall119> no, on saucy still
<Saviq> mhall119, we only support trusty atm...
<Saviq> mhall119, we could do a ppa with the other bits
<Saviq> that are unavailable on saucy
<mhall119> if we can do a PPA, that would be best
<mhall119> docs currently say only saucy is supported
<Saviq> mhall119, right, outdated... sorry
<mhall119> I'll fix the docs, how long would it take to get a PPA to let it work with saucy?
<Saviq> mzanetti, whatever I do in the test, it has a different crash :/
<Saviq> mhall119, it's probably just the above package alone
<Saviq> mhall119, and it should Just Buildâ¢
<mzanetti> Saviq: :/ it might help to start locking the dtor of the singleton.
<Saviq> mzanetti, hmm interesting, Qt should manage the dtion of singletons
<mzanetti> Saviq: yeah. well... seems something is accessing it while/after dtion, or maybe it's deleted twice, C++ and QML context
<dandrader> nic-doffay_, you mean PressedOutsideNotifier? I don't think it's a good idea.  This thing of differentiating between touches and swipes sounds like the kind of problem that gesture cancellation solves. like what the Flickable does when it detects a swipe and therefore sends a TouchCancel to the item inside it that received the press
<dandrader> and grabs the touch from the child item that got the press event
<dandrader> nic-doffay_,  but I would need to dive into the problem to come up with a more solid opinion
<mhall119> Saviq: where can I find that one package?
<Saviq> mhall119, lp:unity-scopes-shell
<nic-doffay_> dandrader, that's what I figured too just judging by the name of your class.
<nic-doffay_> Saviq, your thoughts?
<mhall119> Saviq: no binary I can install?
<Saviq> mhall119, it's there in trusty
<Saviq> http://launchpad.net/ubuntu/+source/unity-scopes-shell
<Saviq> mhall119, nothing for saucy atm
<mhall119> I'll try installing that one
<mhall119> with any luck, I won't completely break everything
<mhall119> Saviq: ok, build --setup is happy now, but I still can't get cmake working within QtCreator
<mhall119> same error
<Saviq> mhall119, that's probably because qtcreator tries to pick up the wrong cmakecache
<Saviq> mhall119, make sure you point it at the right build dir
<Saviq> i.e. unity8/builddir
<mhall119> ./builddir/ right?
<mhall119> yeah, tried that, same error still
<Saviq> mhall119, if you go there
<Saviq> mhall119, in that dir
<Saviq> and go cmake ..
<Saviq> mhall119, does that work?
<mhall119> FWIW, ./build gives the same error in the terminal
<mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/unity8/builddir$ cmake ..
<mhall119> -- Could NOT find Lcov (missing:  LCOV_EXECUTABLE GENHTML_EXECUTABLE)
<mhall119> -- Could NOT find gcovr (missing:  GCOVR_EXECUTABLE)
<mhall119> CMake Error at CMakeLists.txt:64 (message): Could not determine plugin installation dir.
<mhall119> -- Configuring incomplete, errors occurred!
<Saviq> mhall119, right, it's ./build that installs the deps
<Saviq> mhall119, try ./build -c, it might've cached something
<mhall119> The following packages will be REMOVED: unity8-build-deps
<mhall119> is that okay?
<Saviq> mhall119, yeah, that means you can't install some of the build deps
<Saviq> mhall119, try interrupting that
<Saviq> mhall119, and apt-get -f install to get more info
<mhall119> -f install dosn't give me anything more, just that it's going to try and remove it
<Saviq> mhall119, ah, new libunity-api-dev, too
<Saviq> mhall119, https://launchpad.net/ubuntu/+source/unity-api
<Saviq> mhall119, let me go through that tomorrow on a clean system, will put stuff into a ppa
<mhall119> ok, let me know when you're done and I'll test it out again
<mhall119> thanks Saviq
<mhall119> Saviq: for now I've updated the docs to say it's 14.04 only, I'll update them again with instructions for 13.10 that uses the PPA
<Saviq> mhall119, can you please put a unity8 branch that updates the same in CODING for ~unity-team?
<Saviq> mhall119, so that we don't diverge
<mhall119> Saviq: sure thing, give me a couple minutes
<Saviq> mhall119, I'll put my changes / updates there as well
<mhall119> Saviq: https://code.launchpad.net/~mhall119/unity8/update-CODING-to-1404/+merge/198443
<Saviq> mhall119, cheers
#ubuntu-unity 2013-12-11
<chaz-yorba> anybody have an idea why an application menu would be titled "Unknown Application Name" instead of the name of the application?
<chaz-yorba> I'm trying to add application menus to Geary, and it's working, just showing up with the wrong name, and I don't know how to make it see the correct name
<Saviq> mornin'
<Saviq> tsdgeos, better today?
<tsdgeos> almost there
<tsdgeos> my throat still not happy
<tsdgeos> got some kind of infection i'd say, but head's mostly fine
<tsdgeos> so it's a good thing we don't talk that much in here :D
<Saviq> tsdgeos, good ;D
<Saviq> seen https://code.launchpad.net/~aacid/unity8/more_filter_fixes/+merge/198427/comments/459996 ?
<tsdgeos> yep
<tsdgeos> i guess the tests are not as separate one from eachoer as they should be
<tsdgeos> and i only was testing my new test isolated
<tsdgeos> should be an easy matter to make the test be self contained
<tsdgeos> on it
<tsdgeos> actually it's weird, a mouseClick is not getting where it should :-S
<tsdgeos> actually it's weird, a mouseClick is not getting where it should :-S
<tsdgeos> err
<tsdgeos> i meant
<tsdgeos> ok, found out what's wrong
<Saviq> \o/
<tsdgeos> pushed
<tsdgeos> should fix it
<tsdgeos> now let's see the tabbar ones
<tsdgeos> that have the problem that pass here afair
<tsdgeos> we still don't have videos for the qml tests, right?
<tsdgeos> interesting adding a waitForRendering i can make it fail here too
<tsdgeos> good
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/more_filter_fixes/+merge/198427 passed now
<Saviq> tsdgeos, thanks
<Saviq> dednick, ping
<dednick> Saviq: yo
<Saviq> dednick, hey, did you see my comment on the messaging app time issue?
<Saviq> bug #1253810
<ubot5> bug 1253810 in unity8 (Ubuntu) "Messages in Incoming not always display the correct date and content" [High,In progress] https://launchpad.net/bugs/1253810
<Saviq> dednick, I got kinda lost in the menu vs. model vs. modelIndex and which model is it supposed to call the loadExtendedAttributes on...
<Saviq> dednick, it could use some streamlining...
<Saviq> dednick, but to start with, in all the Component.onCompleted:, you need to check whether model is there already, and also react to modelChanged - so you basically need BaseMenuItem to introduce a property that will hold that model (and modelIndex, for that matter), and have those bound in onLoaded
<dednick> Saviq: can you give me a few minutes. Just going into a meeting with john.
<Saviq> dednick, I know it's not entirely your code, but remember the rule of thumb: never reach outside of the current file - if you need something - bind it
<Saviq> dednick, sure
<Saviq> tsdgeos, still one failure in tabbar dash
<tsdgeos> yeah
<tsdgeos> bit lost tbh
<tsdgeos> pushed a small change to try to find out if it's the tab not changing
<tsdgeos> or the tab change not propagating to the dash
<tsdgeos> let's see what the next run says
<Saviq> tsdgeos, cheers
 * Saviq builds qt5 release for i386 to see if it helps with bug #1258057
<ubot5> bug 1258057 in Unity API "unity-api fails to build against Qt 5.2" [Critical,In progress] https://launchpad.net/bugs/1258057
<Saviq> oh no /me isn't ;?
<Saviq> ok back in the game
<dednick> Saviq: hm. ok, trying to sort out the naming and "outside of source", but I don't think we need to react to modelChanged. if it does, all the items will invalidate anyway.
<Saviq> dednick, somehow model is null in onCompleted
<Saviq> dednick, I did find it weird indeed
<Saviq> dednick, especially since it was reaching out of scope
<dednick> I don't want to put the model or anything like that into the items. That adds impl detail. all impl detail properties are added to the Components in the Factory.
<Saviq> dednick, s/null/undefined/
<dednick> Saviq: hm. weird.
<tsdgeos> EphemeralNotificationsTests is also unstable now?
<Saviq> tsdgeos, shouldn't be
<dednick> Saviq: oh, model, or modelIndex undefined?
<Saviq> dednick, model
<dednick> Saviq: for messaging items?
<tsdgeos> Saviq: it failed twice in my tabbar branch, which has nothing to do with notifications :-/
<Saviq> tsdgeos, only jenkins, of course?
<tsdgeos> Saviq: of course
<Saviq> tsdgeos, ah autopilot?
<dednick> Saviq: model is defined in the Factory, so i'm not sure why it's out of scope.
<tsdgeos> Saviq: yep
<Saviq> dednick, what I *think* might be happening there
<Saviq> dednick, is that model is ambiguous
<Saviq> dednick, remember "model" is something a ListView provides in delegates' context
<Saviq> dednick, so maybe it's enough to just prefix it with menuFactory
<dednick> Saviq: ok. well I'm changing the names. let me see if that fixes it.
<Saviq> dednick, yeah, I was quite lost what was what
<Saviq> tsdgeos, hm? https://code.launchpad.net/~aacid/unity8/tabbar_dash/+merge/192505/comments/460186
<tsdgeos> that's the last one
<tsdgeos> but see http://s-jenkins:8080/job/unity8-ci/1865/console
<tsdgeos> and also i have seen it somewere else
<mzanetti> greyback: Saviq: https://code.launchpad.net/~mzanetti/unity-api/new-screenshot-api/+merge/198536
<mzanetti> If you're happy with this I'd go ahead updating tests and changing unity-mir to reflect it
<Saviq> tsdgeos, it looks like a crash or something
<Saviq> mzanetti, looks good
<tsdgeos> ok, so ui tests failed again, obviously
<tsdgeos> confusing
<greyback> mzanetti: +1 from me
<mzanetti> nice. thanks
<tsdgeos> ok, new iteration in the way
<Saviq> tsdgeos, seen http://pastebin.ubuntu.com/6555591/ ?
<tsdgeos> hmmm
<tsdgeos> nope
<tsdgeos> but tbh i don't usually compile webkit
<mhr3_> Saviq, question about the json validation - how much validation do you think it should do? just ensuring that keys have proper types, or check values as well?
<mhr3_> Saviq, ie should a "card-size": "xx-large" cause an error?
<Saviq> mhr3_, if we use the json schema, that would be an error, yes
<Saviq> mhr3_, or we can say that this is just a string and not an enum
<Saviq> mhr3_, at which point we'd need to warn outside of the schema validation, that this is an incorrect value
<mhr3_> Saviq, the way i see it is that the validation is a top-level thing, and if it fails, things are too bad, you can no longer just fallback to a default for one key
<mhr3_> the question is really about extensibility
<Saviq> mhr3_, yeah, that's why I'm saying it could be a warning at a higher level
<mhr3_> when we do add support for xx-large, we want the old devices to still work with that scope, don't we?
<Saviq> mhr3_,  but yes, IMO it should check the values and any other rules we might have (say you're required to map at least one of title, price, rating, or that you can only map subtitle if you've mapped title as well)
<Saviq> mhr3_, that would be a new version of the schema, though
<mhr3_> Saviq, but then it's for sure that the old device wouldn't support it
<Saviq> mhr3_, right
<Saviq> mhr3_, so... maybe the client needs to send the highest version it supports, then?
<Saviq> mhr3_, and we might have conversion rules
<Saviq> mhr3_, but anyway, still, we need to discern between a recoverable and non-recoverable errors
<Saviq> mhr3_, i.e. we can recover from xx-large
<mhr3_> sure, it's just starting to sound like too much work for the scope authors
<Saviq> mhr3_, by falling back to the default medium
<Saviq> mhr3_, the conversion rules would be our side
<Saviq> mhr3_, so you get results v10 from the scope
<Saviq> mhr3_, but client only supports v8
<mhr3_> then you don't have code that understands v10
<Saviq> mhr3_, well, you won't have a v10 scope in that case
<Saviq> mhr3_, I'm thinking SSS
<mhr3_> i'm thinking scopes in app store
<Saviq> mhr3_, yeah, that's framework version, though
<Saviq> mhr3_, they would require 14.04 or 14.10 - and won't be available for older devices
<mhr3_> hm, ok that solves that part
<Saviq> mhr3_, for SSS, we'd need v10-to-v8 conversion code
<mhr3_> weeee, "fun"
<Saviq> indeed
<Saviq> mhr3_, still better than us requiring scope authors to support multiple versions
<mhr3_> think sss will just hide those scopes for the older devices :)
<Saviq> mhr3_, that can work as well, yeah
<Saviq> it's supposed to be s, after all
<Saviq> mhr3_, so, done! ;)
<Saviq> mhr3_, bu
<Saviq> t
<Saviq> mhr3_, error vs. warning
<mhr3_> aah, no buts
<Saviq> mhr3_, xx-large size would be a warning, fallback to default
<Saviq> mhr3_, but mapping only subtitle would be error
<mhr3_> sounds reasonable
<Saviq> mhr3_, so we can't do "real" schema for card-size
<mhr3_> the schema will be super complex for such checks though
<Saviq> mhr3_, we need a sanitizer layer on top of the schema
<Saviq> mhr3_, so yeah, schema could not error out for any recoverable error
<Saviq> mhr3_, the sanitizer layer could do both warning and error
<mhr3_> Saviq, i'm just doing http://paste.ubuntu.com/6555663/
<mhr3_> so wondering how much it'll grow in the future
<Saviq> mhr3_, yeah, that will grow a lot, I'm afraid...
<Saviq> mhr3_, especially if we say some things are recoverable errors
<Saviq> mhr3_, but then... do we really want that?
<mhr3_> future me will be pissed when he has to implement it
<Saviq> mhr3_, couldn't we say that "dude, you've seen the errors in the dev tool, sod off"?
<mhr3_> well, something still has to produce those
<Saviq> mhr3_, the schema would, tehn
<Saviq> then
<Saviq> mhr3_, and on top of that only stuff the schema can't catch
<mhr3_> so we'd maintain a super-strict and a regular schema?
<Saviq> mhr3_, yeah
<Saviq> mhr3_, wait
<Saviq> no
<Saviq> one schema
<Saviq> mhr3_, we just say no-fallbacks, your stuff needs to be correct
<mhr3_> hmm
<Saviq> mhr3_, and if it's not, we ignore results from your scope completely
<Saviq> mhr3_, if we do the dev tool right, that *could* be enough
<mhr3_> yea, just wondering whether i'm happy or sad about that :)
<Saviq> mhr3_, it's either that or a thick sanitizer layer
<mhr3_> but ok, i see your point
<davidcalle> mhr3_, Saviq, my two cents as an author: if you are going with the no-fallbacks road, awesome docs please :)
<Saviq> davidcalle, I know :)
<Saviq> davidcalle, it's just for the JSON definitions, though, and will be validated by a JSON schema that we maintain and agree to
<Saviq> davidcalle, so basically, if we failed to do the schema right, and you have something that passes the schema and sanitization checks - it's our responsibility to deal with it
<Saviq> davidcalle, but as long as you don't pass the schema, you're on your own ;)
<Saviq> davidcalle, that schema will be documented, too, btw
<mhr3_> the schema *check* that is
<Saviq> mhr3_, yes, validation and sanitization
<mhr3_> clarifying cause it sounded like you need to pass some kind of schema
<Saviq> ok yeah, sorry
<davidcalle> Authors can still pass the layout - according to the specs - they want, right ?
<Saviq> davidcalle, yes yes
<davidcalle> Saviq, ok
<dednick> Saviq: https://code.launchpad.net/~nick-dedekind/qmenumodel/loadExtAttributes-dataChanged/+merge/198549
<Saviq> dednick, cool
<Saviq> dednick, did you manage to verify it fixes the bug?
<Saviq> dednick, or is that just a road to that?
<dednick> Saviq: it's only part of it.
<Saviq> dednick, ok
<dednick> Saviq: is there actually a bug? or is it just log messages?
<Saviq> dednick, https://launchpad.net/bugs/1253810
<ubot5> Ubuntu bug 1253810 in unity8 (Ubuntu) "Messages in Incoming not always display the correct date and content" [High,In progress]
<dednick> Saviq: ah, yeah, i ddint see that in original comment
<Saviq> biab
<dednick> Saviq: is there a way you can reproduce reliably?
<dednick> hm. just realised my nexus 10 doesnt have sim, so no messaging... boo
<dednick> but of an issue
<dednick> s/but/bit
<om26er> mzanetti, are music previews supposed to work? i.e. able to play a song in the dash ?
<tsdgeos> yes
<mzanetti> om26er: yes. it doesn't work?
<mzanetti> hmm... it doesn't indeed
<mzanetti> greyback: how do you test unity-mir changes on the device? Do you sync code manually and compile on the device or is there some run_on_device thingie for it?
<greyback> mzanetti: sync usually.
<tsdgeos> mzanetti: ? works here (desktop)
<Saviq> dednick, you don't have a phone at all?
<Saviq> dednick, I can reproduce semi-reliably
<Saviq> dednick, so I can test anything you need
<dednick> Saviq: yeah, i have a galaxy nexus, but didnt bring it to the office with me today :(
<Saviq> dednick, well, there's bound to be *someone* with a phone in the office ;)
<Saviq> dednick, but regardless - let me know, I can test
<dednick> Saviq: cool. i can't seem to reproduce with the test app.
<Saviq> dednick, it's a race, basically, so makes sense that it only happens on some devices but not others
<Saviq> dednick, you can try restarting unity8 while things stay in the indicator to see - happened for me some times, too
<dednick_> Saviq: you mind checking if trunk qmenumodel fixes the issue for you? Will most likely still get nasty log messages though.
<dednick_> when you have a few minutes free of course
<Saviq> dednick_, will do
<dednick_> Saviq: thanks
<Saviq> tsdgeos, how do I tell Qt to use a certain QPA plugin path? i.e. a locally built one?
<dandrader> Saviq, I think you have to install it
<Saviq> dandrader, yeah, it's installed in a prefix
<Saviq> dandrader, but I now need to tell Qt what that prefix is...
<dandrader> Saviq, I mean that I think it must be installed in Qt's regular plugin path
<Saviq> dandrader, ugh
<Saviq> that can't be :/
<dandrader> Saviq, one way to avoid messing up things is giving your QPA a different name
<dandrader> Saviq, so that you can choose when to use it with the QT_QPA_PLATFORM env var
<Saviq> dandrader, yeah, thing is... if I set the prefix during building Qt, shouldn't the "regular plugin path" be under that prefix anyway?
<dandrader> Saviq, I guess so
<Saviq> dandrader, yeah, which is why I'm surprised it doesn't *just work*
<tsdgeos> Saviq: there's some envvar
<tsdgeos> Saviq: have you found it?
<Saviq> tsdgeos, no
<tsdgeos> let me check
<tsdgeos> QT_QPA_PLATFORM_PLUGIN_PATH
<tsdgeos> not sure what you have to make it point to
<tsdgeos> or oyu can use -platformpluginpath to the binary
<Saviq> tsdgeos, thanks, will check it out in a bit
<Saviq> tsdgeos, weird that it wouldn't pick them up from the default prefix by default, 'innit?
<tsdgeos> it is
<tsdgeos> wow now the tabbar test crashed
<tsdgeos> do we keep the .crash files for them?
<MacSlow> Saviq, mumble doesn't start here... keep trying
<Saviq> MacSlow, tsdgeos, mzanetti, we're in a meeting still with greyback and kgunn
<tsdgeos> ok
<MacSlow> Saviq, ok
<MacSlow> hm... -> "Settings schema 'com.canonical.unity-gtk-module' is not installed"
<Saviq> tvoss, btw, added benefit for out-of-process content picker â it can be contained read-only, so it can't b0rk the app's data
<tvoss> Saviq, I'm just thinking that it really is the right way of doing it for tight integration
<Saviq> tvoss, "it" â separate process?
<tvoss> Saviq, separate process, with the app providing a "factory" for a content picker that runs under read-only confinement and probably resource limited
<tvoss> Saviq, with the content hub providing the "executor"
<Saviq> tvoss, yeah, and that can actually be stateful as well
<Saviq> tvoss, per-content-picking sessions
<Saviq> -s
<tvoss> Saviq, sure, that's what I mean
<Saviq> tvoss, so actual app and its content picking sessions can be archived separately
<Saviq> tvoss, archived, killed, resumed etc.
<Saviq> tvoss, without affecting any of the other content pickers or the app itself
<tvoss> Saviq, yup, but I still think the vanilla picker integration would be a good first cut, too, as it would work for all apps regardless
<Saviq> tvoss, sure
<tvoss> Saviq, okay, I will note down those thoughts
<Saviq> tvoss, first step â single instance
<tvoss> Saviq, ack
<tvoss> Saviq, driving use-case for second step: gallery
<Saviq> tvoss, yup
<tvoss> DONE ... almost ;)
<mhr3_> Saviq, mzanetti, https://code.launchpad.net/~mhr3/unity-scopes-shell/json-defaults/+merge/198591
<greyback> looks like Qt5.2 is out
<dednick_> Saviq: https://code.launchpad.net/~nick-dedekind/unity8/indicator-menuitems-lp1253810/+merge/198597
<dednick_> it's probably a bit more than you hoped for though
<Saviq> mhr3_, cheers
<Saviq> dednick_ conflicts?
<dednick_> ...
<dednick_> Saviq: ok, fixed conflicts
<mhr3_> mzanetti, hm, know about https://code.launchpad.net/~sil2100/unity-scopes-shell/revert_25/+merge/198595 ?
<sil2100> mhr3_, mzanetti: testing this revert on my phone to make sure
<kgunn> Saviq: ^
<mhr3_> i just don't see why it shouldn't work... unless the unity8 part didn't get merged
<Saviq> hrmpf
<Saviq> mhr3_, http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/563 did get merged
<kgunn> Saviq: mhr3_ so we had all the relevant merges but we didn't test if a click package could launch ?
<sil2100> mhr3_, Saviq: but we're not releasing unity8 now
<Saviq> kgunn, we did
<Saviq> sil2100, it was released already
<kgunn> weird
<Saviq> kgunn, something else must be in play
<Saviq> kgunn, the unity8 change was safe either way
<sil2100> Then something's wrong, somewhere else it seems
<mhr3_> Saviq, was that the only thing? doesn't seem enough
<kgunn> Saviq: right...so are we reverting the correct thing? or are we just reacting to fast ?
<kgunn> can we bisect ?
<Saviq> mhr3_, 562, too
<Saviq> mhr3_, http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/562
<Saviq> mhr3_, sil2100, do we need to release scopes-shell today?
<sil2100> Saviq: we released it already
<Saviq> ah
<sil2100> Saviq: since no AP tests caught this behavior
<Saviq> :/
<sil2100> :|
<sil2100> Saviq, mhr3_, kgunn: the revert works fine and fixes the issue, so we'll be pushing it out as a temporary solution
<kgunn> sil2100: Saviq ...does AP test cover this behavior ?
<Saviq> sil2100, ok
<sil2100> Sadly...
<kgunn> sil2100: ok
<mhr3_> sil2100, ok
<Saviq> kgunn, we're launching apps, apparently not click ones
<mhr3_> kgunn, sounds like it doesn't
<Saviq> kgunn, although for that there's no excuse - we just have low integration coverage all over
<Saviq> https://bugs.launchpad.net/bugs/+bugs?field.tag=needs-ap-test FWIW
<kgunn> Saviq: ok, no time like the present...can we elect someone from our team to add an AP test to download a known click and launch it ?
<Saviq> kgunn, don't even need to download
<Saviq> kgunn, there's some preinstalled
<kgunn> sweet...1/2 done
<kgunn> surely...even when this was on trunk, someone tried to launch a click app ?
<Saviq> kgunn, it was in trunk unity8 (safe), unity-scopes-shell (apparently non-safe) was just tested during the review
<kgunn> Saviq: ok...well, let's pick a victim for tomorrow to go add a specific AP test
<mhr3_> Saviq, it's weird though, if ap is launching at least non-clicks it should catch the issue
<mhr3_> both are launched the same way
<Saviq> mhr3_, it's launching them directly
<Saviq> mhr3_, not from the shell
<mhr3_> then we really want a test to do it via shell
<Saviq> mhr3_, oh yeah, definitely
<kgunn> Saviq: would zanetti be best for this ?
<kgunn> i added a critical bug https://bugs.launchpad.net/unity8/+bug/1260013
<ubot5> Ubuntu bug 1260013 in Unity 8 "[ap test] need to test click package app launching from dash" [Critical,Triaged]
<Saviq> kgunn, actually we can ask veebers to get this overnight
<kgunn> ok...will put his name on it
<Saviq> except...
<Saviq> I can launch clicks fine from the launcher
<sil2100> kgunn, mhr3_, Saviq: thanks guys, the revert is in the build right now
<kgunn> right...need to launch from the dash right ?
<Saviq> kgunn, right, it doesn't go through the scopes..
<mhr3_> Saviq, how can the revert even work? shouldn't it blow up because unity expects just app_id now?
<Saviq> launched fine
<Saviq> from dash
<Saviq> mhr3_, shell doesn't really care
<Saviq> sil2100, is there a bug reporting that issue?
<sil2100> Saviq: let me file it
<sil2100> Saviq, mhr3_: https://bugs.launchpad.net/unity-scopes-shell/+bug/1260020
<ubot5> Ubuntu bug 1260020 in unity-scopes-shell "After revision 25 cannot launch click applications from the unity8 scopes" [High,New]
 * Saviq no get it...
<Saviq> can confirm with released unity8, trunk works fine, with no related change between the last release and now :?
<sil2100> Saviq: what do you mean?
<Saviq> sil2100, I mean that it works fine when I run unity8 trunk with the release of unity-scopes-shell
<sil2100> Ah
<sil2100> hm
<Saviq> sil2100, but not when running released unity8, where there's nothing in trunk unity8 related to it at all
<Saviq> sil2100, might be my env is unclean
<Saviq> sil2100, building from scratch now
<Saviq> sil2100, yeah, something must've remained in my environment
<Saviq> kgunn, â that could've bit us when testing, FWIW
<cwayne_> davidcalle, is there a list of keywords somewhere for the server-side scopes?
<cwayne_> i know for local ones you can just rgrep keyword in /usr/share/unity/scopes/
<davidcalle> cwayne : https://productsearch.staging.ubuntu.com/smartscopes/v1/remote-scopes here you go :)
<davidcalle> cwayne_, wait, remove the staging from the uri
<cwayne_> davidcalle, awesome, thanks!
<cwayne_> davidcalle, some of them never seem to return anything, (e.g. stackexchange: and grooveshark:)
<Saviq> mhr3_, activating "/com.ubuntu.weather_weather_1.0.158.desktop"
<Saviq> :/
<mhr3_> Saviq, ehm? but the code did .basename()
<Saviq> mhr3_, yeah
<mhr3_> so... wtf?
<Saviq> which seems to not do what it's expected to
<davidcalle> cwayne_, yes, they are part of the API limited scopes, so they will work again in a few hours, when they don't hit their queries limits anymore. There is some caching work going on, to make these outages less noticeable.
<Saviq> mhr3_, ah wait, that's *before* the basename
<mhr3_> Saviq, aah... dots
<mhr3_> will try to activate "com"
<mhr3_> needs to be .completeBaseName()
 * mhr3_ out
<Saviq> uh :/
<Saviq> alesage, dednick is back this week
<alesage> Saviq, ok super, shall we get a review from him?
<Saviq> alesage, yeah, we need to get indicator-stubs through, first...
<Saviq> alesage, and I've completely no idea what's happening there :/
<alesage> Saviq, ok understood--so it is the test failures that are blocking us
<Saviq> alesage, yeah
<alesage> Saviq, I'll try to take it up with CI
<Saviq> alesage, I don't think they can do anything there - I can reproduce it locally - just have no idea what's happening
<Saviq> kgunn, FWIW https://code.launchpad.net/~saviq/unity-scopes-shell/fixed-click-launch/+merge/198626
<Saviq> .baseName() vs. .completeBaseName()
<alesage> Saviq, weird, but is it just our (i.e. my) branch?
<Saviq> alesage, yeah, that's the thing
<Saviq> alesage, your tests do *something* to the test env that makes them fail
<Saviq> alesage, they pass in isolation, of course
<alesage> Saviq grr ok
<Saviq> alesage, so it's pretty difficult to pin down, I just need to sit down and look at the phone while it's doing the tests at least
<alesage> Saviq ok right I haven't run the whole suite, will do so this afternoon and get some help
<mhall119> Saviq: did you get a chance to work on a Unity 8 Saucy PPA today?
<Saviq> mhall119, I'm afraid not, was a hot day
<mhall119> no worries, just let me know when it's there and I'll go back and update the documentation (after trying it, of course)
<Saviq> mhall119, do you think daily recipes from trunks would be ok?
<mhall119> what's going into trusty's archives currently?
<Saviq> mhall119, manual releases
<Saviq> mhall119, but that would add burden on that process, if it was to go to saucy, too
<mhall119> right, do we want *only* saucy builds in the PPA then, or saucy *and* trusty from trunk?
<Saviq> mhall119, I'd say saucy only
<Saviq> mhall119, as a "try this, but if it doesn't work, it's not our top priority"
<Saviq> mhall119, we basically can't maintain both
<mhall119> ok, that's fine with me
<Saviq> mhall119, ok, I put unity-api and unity-scopes-shell in recipes for https://code.launchpad.net/~phablet-team/+archive/desktop-deps
<Saviq> mhall119, at least temporarily (I'd like to move it under ~unity-team)
<mhall119> why didn't you put it under ~unity-team to begin with?
<Saviq> mhall119, that PPA I had already, and it has increased points
<Saviq> mhall119, those two should be all that's needed to build unity8 on saucy, will verify later today
<Saviq> points == build score
<mhall119> ok, I'll try from there
<Saviq> http://download.qt-project.org/official_releases/qt/ cool beanz
<Saviq> greyback, still around?
<kgunn> Saviq: hey hey...think that means we'll get 5.2 before christmas ?
<kgunn> in touch that is
<Saviq> kgunn, looking at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2
<Saviq> kgunn, not necessarily
<Saviq> kgunn, or well https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages
<Saviq> kgunn, a *lot* of red :/
<kgunn> Saviq: you still on?...if i modified an AP test...can i check that out by doing run_on_device...and then doing all the other steps for running AP tests?
<kgunn> or more simply...how would i go about doing that
<kgunn> ?
<Saviq> kgunn, if you only modified the AP test
<Saviq> kgunn, it's enough to go on the device (ssh preferred for better terminal)
<kgunn> yes...that's all
<Saviq> kgunn, issue `initctl stop unity8`
<Saviq> go into ~phablet/shell
<Saviq> and run `PYTHONPATH=tests/autopilot autopilot run unity8` for the whole suite
<Saviq> or `PYTHONPATH=tests/autopilot autopilot run unity8.test.foo` for a single test
<Saviq> you can see the available test names with `PYTHONPATH=tests/autopilot autopilot list unity8`
<Saviq> kgunn, only difference if you want to run the tests on the local build - `ninja -C builddir install` first
<kgunn> Saviq: that's pretty cool...thanks...i'm trying to disable some tests on maguro...want to make sure i didn't break anything for mako
<Saviq> kgunn, as in - the autopilot tests will pick up the locally built/prefix-installed unity8
<kgunn> ok...nah, i was gonna use todays image
<Saviq> kgunn, ugh, disabling tests ;/
 * Saviq just runs the suite on mako and maguro to see what's the whole deal
<kgunn> so didrocks complaining that some tests are flakey on maguro...so instead of arguing...and avoid turning them off completely, i was going to disable them on maguro
<kgunn> so you might not see failures
<Saviq> or! we could fix the flakiness of the tests ;)
<Saviq> kgunn, did you actually see them fail, btw?
<kgunn> Saviq: didn't "see" them...but reported here http://ci.ubuntu.com/smokeng/trusty/touch/maguro/56:20131210:20131203/5363/unity8-autopilot/
<kgunn> and http://ci.ubuntu.com/smokeng/trusty/touch/maguro/55:20131209.1:20131203/5355/unity8-autopilot/558729/
<Saviq> no crashes at all?
<Saviq> that's good :)
<kgunn> yes
<Saviq> kgunn, so, that really is just one flakiness - that we should just fix
<Saviq> kgunn, all the tests failed to unlock unity8
<Saviq> (failed ones, that is)
<Saviq> so it's the unlock emulator that needs fixing - but first we need to reproduce locally
 * kgunn abandons skipif maguro
<kgunn> Saviq: that's the strange thing...seems to be happening on maguro
<Saviq> kgunn, yeah, it might be some timing - TBH it might  just be that 10s isn't enough for maguro
<kgunn> wow
<Saviq> to start unity8 and get it in a state that's considered "ready"
<Saviq> mind you, that's loading the dash and such
<kgunn> yeah...so maybe 15 sec would be ok for maguro...seems it does pass sometimes
<Saviq> most times
<kgunn> so right on the edge
<Saviq> yup
<Saviq> kgunn, if you want to try
<kgunn> its worth a shot
<Saviq> kgunn, tests/autopilot/shell/emulators/greeter.py:40
<Saviq> kgunn, add timeout=15
<Saviq> as a second argument
<Saviq> to wait_for()
<kgunn> its like you can see me searching :)
<Saviq> kgunn, wanna review something? :)
<Saviq> https://code.launchpad.net/~saviq/unity8/add-autopilot-pydev/+merge/195589
<Saviq> kgunn, if you install eclipse, and pydev from http://pydev.org/manual_101_install.html
<Saviq> kgunn, importing the existing unity8/tests/autopilot project into eclipse
<Saviq> kgunn, will get you a nice python IDE
<Saviq> unless you're a hardcore VI user, that is
<Saviq> ;)
<Saviq> kgunn, so yeah, that timeout would really be my guess
<kgunn> pydev installed on eclipse...done
<kgunn> Saviq: ah...so that mp just allows you to open the project in eclipse easily
<Saviq> kgunn, yeah, just saves you 5s... every time you clean your branch - so a substantial amount of time, IMO :)
<Saviq> kgunn, and well, QtC is useless for python, so :/
<Saviq> kgunn, in case you didn't do it before - Eclipse doesn't "open" projects
<Saviq> kgunn, you have to go File â Import â Existing projects into workspace
<kgunn> Saviq: was just about to ask...was pretty sure it'd be an import
<Saviq> kgunn, 25 passed on maguro here
<Saviq> kgunn, will add some timings
<kgunn> Saviq: you mean 25 seconds ?...did it fail for you with less ?
<kgunn> or the original 10
<Saviq> kgunn, no, 25 tests pass
<Saviq> kgunn, i.e. 100% pass rate
<Saviq> for the original 10s
<kgunn> ah yeah
<Saviq> so we really must be *just* there
<Saviq> like the phone getting hotter in the lab and throttling down or something
<Saviq> but I'll add some prints just to be sure
<Saviq> if we're reaching like 8s or something, I'm certain that's it
<Saviq> on mako - reliably 100% pass rat
<Saviq> e
<kgunn> yeah...i wondered about temp too...or even age
<kgunn> hell even strong vs weak silicon
<Saviq> ok so that theory goes down the drain...
<kgunn> Saviq: i might be doing something wrong....but the .project & .pydevproject don't show up in the import ?
<Saviq> greeter took 1.3s
<Saviq> greeter took 1.2s
<Saviq> kgunn, Import â Existing projects into workspace â Select root directory (point to unity8 checkout)
<Saviq> Should come up with "Unity8 Autopilot" project
<kgunn> Saviq: ah yes..magic...
<kgunn> thot i had to navigate to the test dir
<Saviq> kgunn, well, it should show up if you selected tests/autopilot, too
<Saviq> kgunn, it just looks for .project in the subtree
<Saviq> kgunn, so, it's actually the unlock gesture that fails
<kgunn> Saviq: eeewww
<Saviq> kgunn, yeah, it's probably a timing issue in the sense that the gesture is ignored 'cause the movement is not delivered in a timely manner
<Saviq> because the device is too slow
<kgunn> stupid omap
<kgunn> Saviq: so...maybe a retry ?
<kgunn> i mean it passes more than not
<Saviq> kgunn, it was supposed to be retrying
<Saviq> kgunn, I think we lost that as part of a refactor actually
<mhall119> Saviq: unity-scopes-api failed to build in the PPA
<Saviq> mhall119, yeah, I pung michi in #ferrets
<mhall119> ok
<mhall119> I'll check again tomorrow
<Saviq> mhall119, yeah, I'll monitor it, too
<mhall119> thanks
<mhall119> Saviq: seriously though, you're allowed to sleep :)
<Saviq> mhall119, bollocks
<mhall119> we're contractually guaranteed a full 3 hours of sleep every night
<kgunn> mhall119: actually...no that's not true
<alesage> tedg, thomi having a question about how to install indicator-network minus unity (?)
<tedg> alesage, ?
<alesage> tedg nm for now thx :)
<Saviq> veebers, hey, can you please check out https://code.launchpad.net/~saviq/unity8/helper-retry-unlock/+merge/198648
<veebers> Saviq: sure, I'll look now
<veebers> Saviq: hmm, I don't think retrying is very good in a test, surely it should work or fail?
<veebers> Saviq: oh I'll read scrollback, see if ther is more information
<Saviq> veebers, flaky tests on maguro
<Saviq> veebers, that's really an issue of timing
<Saviq> veebers, the gesture recognizer is quite strict about the velocity of the gesture
<veebers> Saviq: is there a way that we can check if the device is ready for input or if the greeter is ready to receive input?
<veebers> Saviq: perhaps there is a way to fix the swipe gesture used
<Saviq> veebers, there's no real data as to why it fails, really - we suspect that the device is still under heavy load initially
<Saviq> veebers, and so the gesture is jerky or so
<Saviq> veebers, ideally we'd control the time from outside
<Saviq> veebers, but then we start to influence the test too much
<veebers> Saviq: I don't understand the comment " ideally we'd control the time from outside"
<Saviq> veebers, velocity is calculated based on RTC
<veebers> ah ok
<Saviq> veebers, and if the movement isn't smooth
<Saviq> veebers, that calculation might result in the gesture being rejected
<Saviq> veebers, just because the device has not settled yet
<Saviq> veebers, if we controlled the time the velocity calculation takes - we'd probably be rid of such issues, but it's a Schroedinger's Cat problem
<veebers> Saviq: you're suggesting that the device not being settled yet means that theh python script (autopilot) that is sending the drag events will miss or lag and thus causing the gesture to be rejected?
<Saviq> veebers, yeah, more or less
<Saviq> veebers, the input isn't delivered in a synchronous manner
<veebers> right, make sense
<Saviq> veebers, so it seems retrying is actually something least hacky (we could just wait a few seconds) ;)
<Saviq> veebers, it won't influence us at all in the 95% of cases where it unlocks at first swipe
<Saviq> veebers, but won't fail for that reason in the remaining 5%
<veebers> Saviq: right. ok that makes sense. Could you add a comment as to why we're using a retry approach please (i.e. a very edge-case). I would hate for a test author to see it and consider it good practice
<Saviq> veebers, sure, doing
<Saviq> veebers, if we later come up with a better metric of "it's ready" than looking whether the home scope is focused, we might be fine
<Saviq> veebers, especially when we split the greeter out
<veebers> Saviq: good point. Could you then also file a bug (stating the AP test is using a retry because of: blah) and reference that in the comment
<veebers> Means we can keep track of these hacks/workarounds and fix them when we can
<Saviq> veebers, +1
<mzanetti> Saviq: If this is still the issue where the greeter gets stuck half way through swiping I suspect there is acutally something else.
<Saviq> mzanetti, no, that's not it
<Saviq> mzanetti, or at least we don't know what it is
<Saviq> mzanetti, we'd have to look at the devices under test
<mzanetti> Saviq: I debugged this a while back when we had this on the VMs still
<mhall119> kgunn: we only get 2 hours or sleep?
<mzanetti> Saviq: and no matter what I tried it (in terms of delaying, retrying etc) did not make any difference
<Saviq> mzanetti, let's see, then, if retrying helps
<Saviq> mzanetti, if it doesn't, we'll investigate more
<Saviq> mzanetti, asking for a camera pointing at the devices
<Saviq> mzanetti, https://code.launchpad.net/~sil2100/unity-scopes-shell/revert_25/+merge/198595 btw :(
<mzanetti> Saviq: also the fact that the video was showing the greeter just being stuck at the position where autopilot would release the gesture, and not bouncing either left or right made me think there is something really stuck
<Saviq> mzanetti, fortunately https://code.launchpad.net/~saviq/unity-scopes-shell/fixed-click-launch/+merge/198626
<veebers> Saviq: oh, I had presumed that you had already tested and this solved the issue ;-) perhaps it could be an input being ignored issue? I think there is a bug + workaround for something similar already
<Saviq> veebers, guess what - not reproducible locally ;)
<veebers> Saviq: oh, the best kind of bugs ^_^
<Saviq> veebers, this at least will give us more output
<mzanetti> Saviq: so I'm confused, there was this revert and then you submitted it again?
<veebers> Saviq: ack, makes sense to me. We can always remove it if it doesn't work or makes things worse
<Saviq> mzanetti, baseName vs. completeBaseName
<Saviq> mzanetti, clicks have dots in their desktop file names
<Saviq> mzanetti, so we ended up sending "com" in the signal
<mzanetti> awww meen
<mzanetti> sorry :/
<Saviq> mzanetti, what's worse, run_on_device didn't show that happening for me initially
<Saviq> mzanetti, possible due to left-over Unity plugin being there in shell/builddir
<Saviq> mzanetti, so even when testing, that could've masked the issue for you guys
<Saviq> mzanetti, so yeah, lack of tests bit us here
<Saviq> veebers, pushed
<dmo> Hello.  I cannot seem to add or remove items from the launcher.  Right-clicking on an icon and selecting 'Unlock from launcher' does nothing.  Also, when I drag an icon to the launcher, it won't dock.  Any ideas?
<veebers> Saviq: awesome, have bottom approved
<Saviq> dmo, that's under unity7?
<Saviq> dmo, as in desktop Ubuntu?
<dmo> Ubuntu desktop 13.10
<Saviq> dmo, can you please file a bug using `apport-bug unity`?
<Saviq> veebers, will you top-approve once jenkins says "aah whatever, do whatever you want" aka "PASSED"?
<Saviq> of course.. bad whitespace..
<dmo> I'm not familiar with apport-bug-unity.  Would you give me more information?
<dmo> What's strange is this used to work for me.
<Saviq> dmo, alt+f2, write "apport-bug unity" and follow the instructions
<Saviq> ok, it's time i/
<Saviq> \o
<Saviq> ttyl
<Saviq> ah mzanetti one last thing - even more symbols http://paste.ubuntu.com/6557929/
<Saviq> and we're off  \o
<dmo> Sending of the report failed, probably due to the company's firewall.  Do I need to do anything special to get around this?
#ubuntu-unity 2013-12-12
<veebers> Saviq: the qmlui tests seems to have a different failure, looking at this job from earlier: https://code.launchpad.net/~saviq/unity8/helper-retry-unlock/+merge/198648
<veebers> I've fired off the job again  as the failing test is different each time :-\
<Saviq> veebers, right :/ - thanks, I'll take over now
<Saviq> mornin'
<Saviq> tsdgeos, o/
<Saviq> tsdgeos, can you make anything of http://paste.ubuntu.com/6557929/ ?
 * tsdgeos reads
<tsdgeos> wow :D
<tsdgeos> is that a crash
<tsdgeos> ?
<tsdgeos> basically seems to me that something completed it's building and a lot of properties are being evaluated/set
<tsdgeos> Saviq: ââââ
<Saviq> tsdgeos, yeah, it's a unity-api qmltest crashing under 5.2
<Saviq> tsdgeos, unfortunately whatever I touch in that test, the crash is different straight away :/
<Saviq> tsdgeos, and well, somewhere else, too
<tsdgeos> ouch
<tsdgeos> nothing really obvious tbh
<tsdgeos> argggg damn test dashbar tests
<tsdgeos> tabbar i mean
<Saviq> dednick, hey, review done
<mhr3> could use reviews for the testing stuff in scopes-shell
<dednick> Saviq: thanks
<dednick> Saviq: text: menuData && menuData.label || ""    - really? thats pretty weird
<mhr3> Saviq, any progress on the dev-tool?
 * tsdgeos cries
<tsdgeos> why is the tabbar not creating children on CI :-/
<tsdgeos> oh wait
 * tsdgeos <--- stupid
<tsdgeos> the sdk code needed still not been released
<tsdgeos> and here i was trying to make it work  ^_^
<tsdgeos> children you shall not make install to the system and then don't remember you had done it
<tsdgeos> good thing at least i found one of the bugs i was having in the verticalJournal implementation meanwhile :D
<Saviq> mhr3, didn't get there yet, but plan to start real soon
<Saviq> mzanetti, can you do review for mhr3?
<mzanetti> Saviq: yip yip
<Saviq> mzanetti, https://code.launchpad.net/unity-scopes-shell/+activereviews
<mzanetti> cheers
<Saviq> mzanetti, I'll do the json-defaults
<nic-doffay> Saviq, hey. Got a second to chat about the component to dismiss the keyboard? As you mentioned it's a bit more complicated differentiating between taps and swipes.
<Saviq> nic-doffay, well, yeah, only I don't think we can do it right now, maybe it's fine to tap-to-launch straight away
<Saviq> dednick, yeah it's weird, more concise, but as I said, not really readable
<nic-doffay> Saviq, I'm dubious about that. But if you'd like me to commit it I'll go ahead. It's a one line change since it looks like someone already added an inverse mouse area for this behaviour.
<dednick> Saviq: is it a javascript operator?
<dednick> *expression, or whatever
<dednick> thingy
<Saviq> dednick, false || undefined === undefined
<Saviq> dednick, false || "foo" === "foo"
<Saviq> nic-doffay, while having moved to dandrader's TappedOutsideNotifier?
<dednick> Saviq: true || "foo" ?
<Saviq> dednick, true
<Saviq> dednick, true && "foo" === "foo"
<Saviq> dednick, it's kind of like python's `True and "foo" or "bar" == "foo"`
<dednick> Saviq: i c
<tsdgeos> wops, my vertical journal does not get reconstucted up correctly :-D
<Saviq> dednick, when using logical operators on non-bools, they're not converted into bools, but the expression evaluates to the last encountered value, more or less
<Saviq> dednick, so when you do foo && foo.bar ? foo.bar : ""
<Saviq> dednick, it does not evaluate to bool(foo) && bool(foo.bar) ? foo.bar : ""
<Saviq> dednick, but rather to bool(foo && foo.bar) ? foo.bar : ""
<Saviq> dednick, so if foo.bar is "baz"
<Saviq> bool("baz") ? "baz" : ""
<Saviq> so true ? "baz" : ""
<Saviq> so "baz"
<Saviq> and foo && foo.bar || ""
<Saviq> goes, more or less, to "baz" || "", so "baz"
<dednick> hm
<Saviq> tvoss, there?
<tvoss> Saviq, yup
<nic-doffay> Saviq, sorry not sure what you meant: '<Saviq> nic-doffay, while having moved to dandrader's TappedOutsideNotifier?'
<Saviq> nic-doffay, just one line change for switching from InverseMouseArea to TappedOutsideNotifier?
<Saviq> nic-doffay, that'd be great ;)
<Saviq> nic-doffay, we need to switch to TON, 'cause IMA didn't work well on devices
<nic-doffay> Saviq, haha yeah it's just one line.
<nic-doffay> Saviq, or two I think :P
<Saviq> nic-doffay, sure, please test it works on devices then
<Saviq> nic-doffay, and write a test, too!
<nic-doffay> Saviq, sure
<mzanetti> mhr3: https://code.launchpad.net/~mhr3/unity-scopes-shell/scopes-ng-tests/+merge/198437 line 437. wanted?
<mhr3> meh, it's copied over from the lib
<mhr3> which means there's lgpl licenced test... guess i should change that
<mzanetti> true
<tsdgeos> 5.2.0 official out
<mzanetti> huh? that was fast
<mzanetti> didn't they just discuss when the next rc should come?
<mhr3> mzanetti, pushed
<tsdgeos> damnit, reconstructing the verticalJournal up is not easy at all :/
<Saviq> mzanetti, tsdgeos old news, it was out yesterday ;)
<Saviq> tsdgeos, less easy and doing top-down?
<tsdgeos> Saviq: not officially ;-)
<Saviq> tsdgeos, pfft
<Saviq> tsdgeos, I SAW IT THERE IN official-releases!
<greyback> the tarballs were out
<Saviq> here http://download.qt-project.org/official_releases/qt/ !
<greyback> it was on hacker news too :)
<Saviq> see? 11-Dec-2013 16:12
<tsdgeos> Saviq: there was no email ;-)
<Saviq> tsdgeos, bah!
<tsdgeos> tarball may had been changed :D
<Saviq> ;)
<tsdgeos> Saviq: anyway, thing is that when you go up in the verticalJournal you can't really know in which of the columns you have to position the item
<tsdgeos> because the next item you position up may mean you have to rearrange the things
<tsdgeos> so i'll have to do that i guess, which is not cool
<tsdgeos> that or remember the columns of every item
<tsdgeos> which is worse :D
<Saviq> tsdgeos, hmm ah in case one of the previous items is like *long*?
<tsdgeos> yep
<Saviq> tsdgeos, so that it covers two rows when going top-down, but you don't know that yet when going up
<Saviq> tsdgeos, you think it's really worse to store them?
<tsdgeos> if i order them the same way going up that when going down
<tsdgeos> when i reach the top
<tsdgeos> stuff is jaggy and not 0 aligned
<Saviq> tsdgeos, yup, understood
<tsdgeos> ideally i should be able to reorder them before you see them on screen
<tsdgeos> since i have a buffer zone too
<Saviq> tsdgeos, I just wonder if it's really that bad to store the positions...
<Saviq> tsdgeos, more memory-hungry, sure (how much?)
<tsdgeos> well it's not bad, just a bit more memory intensive
<Saviq> tsdgeos, but the other one is much more computationally heavy
<tsdgeos> not much, i just need to store the integer of the column
<Saviq> yeah exactly
<Saviq> tsdgeos, your call, I can see pros and cons of both
<tsdgeos> i mean storing the column is so much easier
<Saviq> mzanetti, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1237923 â Confirmed
<ubot5> Ubuntu bug 1237923 in Ubuntu UI Toolkit "SSH keys should not be generated automatically - or at least kept for QtCreator use only" [Undecided,New]
<Saviq> tsdgeos, yeah, and what... a kB memory per 1000 entries?
<tsdgeos> getting the algo right to reconstruct + move the stuff as needed is much harder
<Saviq> (probably more, but not much)
<mzanetti> Saviq: done
<Saviq> mzanetti, cheers
<tsdgeos> Saviq: ok, let's go storing the column for now and we can always make it better if we find it's taking to much memory
<Saviq> tsdgeos, I really doubt we will :)
<tsdgeos> Saviq: storing the column doesn't work if we want to support resizing
<Saviq> tsdgeos, right, but I'm fine with redoing it in that case
<Saviq> tsdgeos, like I can actually agree to do the whole model top-down when you resize the column
<tsdgeos> sure, but means i still need to write the algorithm :D
<tsdgeos> ah
<Saviq> tsdgeos, it's not like resizing is going to happen often
<tsdgeos> sure
<Saviq> tsdgeos, iteration 2, basically
<nic-doffay> dandrader, did you write any tests for PressedOutsideNotifier?
<dandrader> nic-doffay, yes
<dandrader> in tests/plugins/Ubuntu/Gestures
<dandrader> nic-doffay, â
<nic-doffay> dandrader, cool
<dandrader> nic-doffay, adding stuff to it?
<nic-doffay> dandrader, nah not yet at least.
<mhr3> mzanetti, regarding the QVariant returns, i find it odd when a method is returning QVariant and you see "return QString(foo);"
<mzanetti> mhr3: fair enough... it's personal preference. So, your code, your rules. feel free to ignore
<mhr3> mzanetti, otoh i do like less typing :) if it's a common thing with variants i can change it, and will get used to it
<mzanetti> mhr3: yeah. it's quite common in Qt to let it convert to QVariants implicitly
<mhr3> fine then
<dednick> anyone noticed that if you exit the unity8 shell app on desktop, if stops the desktop indicators? :)
<dednick> oops
<dednick> i think it's sending upstart a command
<greyback> dednick: yep, here too. I usually restart them with "start indicator-session"
<nic-doffay> dandrader, do I need to change any CMakeLists to use Ubuntu gestures from qmluitests?
<dandrader> nic-doffay, you mean you want a test listed in tests/qmltests/CMakeLists.txt to "import Ubuntu.Gestures"?
<Saviq> dednick, one for you https://code.launchpad.net/~saviq/unity8/clean-paths-cmakelists/+merge/198725
<nic-doffay> dandrader, that's right.
<dandrader> nic-doffay, you will have to add "${CMAKE_BINARY_DIR}/plugins" to the IMPORT_PATHS parameter of his add_qml_test entry
<Saviq> isn't that default?
<Saviq> nope
<dandrader> Saviq, no. some tests want to use mock versions of some of the plugins there
<Saviq> dandrader, yup
<Saviq> nic-doffay, so something like:
<Saviq> add_qml_test(Panel Indicators IMPORT_PATHS ${CMAKE_BINARY_DIR}/plugins ${qmltest_DEFAULT_IMPORT_PATHS})
<dandrader> nic-doffay, so bear in mind the order of the IMPORT_PATHS
<dandrader> matter
<nic-doffay> dandrader, cool I see it's already been added for dash etc.
<dednick> Saviq: ok, will take a look after lunch.
<Saviq> dednick, cheers
<tsdgeos> Saviq: So  lp:~aacid/+junk/verticalJournal  should be pretty good
<tsdgeos> Saviq: needs someone to go over the functional and test review
<tsdgeos> Saviq: and a place to merge it :D
<Saviq> tsdgeos, new-scopes
<Saviq> tsdgeos, or well...
<tsdgeos> Saviq: unity-scopes-s
<Saviq> tsdgeos, it can go into lp:unity8 directly
<tsdgeos> right
<tsdgeos> ok
<Saviq> tsdgeos, it doesn't have to be used, as long as it's tested
<tsdgeos> sure
<tsdgeos> i need to work a bit more on the tests
<tsdgeos> but it's almost there
<Saviq> mhr3, hmm scopes.get(scopeSelector.selectedIndex) â ASSERT failure in QList<T>::at: "index out of range"
<mhr3> who was telling me that those index checks in data are useless?
<mhr3> mzanetti, tsdgeos ^? :P
<mzanetti> mhr3: I did
<mhr3> oh but wait, that's get(), not data()
<mzanetti> mhr3: well... otherwise noone would have noticed and there's just some data missing
<mzanetti> ah wait... this is a manual get()
<mzanetti> not the data() method
<mzanetti> in that case it's different
<mhr3> fixing in the tests branch
<mhr3> and adding test for it :)
<dandrader> Anyone up for a quick & east review? https://code.launchpad.net/~dandrader/unity-mir/lp1248795/+merge/198731
<Cimi> mzanetti,
<dandrader> s/east/easy
<Cimi> https://bugs.launchpad.net/unity8/+bug/1258126
<ubot5> Ubuntu bug 1258126 in Unity 8 "Arrow in tabs in indicators positioned badly" [High,New]
<Cimi> this is weird
<Cimi> in ambiance theme
<greyback> dandrader: I'll take it
<Cimi> the indicator is placed with x: button.width - width
<dandrader> greyback, thanks!
<greyback> dandrader: I always get it wrong and thing 'var' is the deprecated one
<Saviq> mhr3, lp:~unity-team/unity8/scope-dev-tool
<Cimi> with button.width being text.paintedWidth + text.anchors.leftMargin + text.anchors.rightMargin
<greyback> s/thing/think/
<Cimi> text is the label in indicators
<dandrader> greyback, http://qt-project.org/doc/qt-5.0/qtqml/qml-variant.html
<dandrader> "The variant type is a generic property type. It is obsolete and exists only to support old applications; new applications should use var type properties instead."
<greyback> dandrader: yep I know. I just get that mixed up in my head
<dandrader> greyback, a ok, got what you meant now :)
<mzanetti> Cimi: hmm... maybe paintedWidth borked?
<greyback> dandrader: approved
<Cimi> mzanetti, it's my guess too
<Saviq> mhr3, re: auto â sure, easier to write, not easier to read ;)
<Saviq> mhr3, but yeah, maybe var names should just carry what they are, so that you don't have to go and look at its type anyway
<mzanetti> mhr3: complaining about me nitpicking on "auto" :P ?
<mhr3> yes :)
<mhr3> Saviq, pushed the index thing
<Saviq> mhr3, you mean fixed it?
<mhr3> yes
<Saviq> mzanetti, does QtC resolve auto?
<Saviq> mhr3, ok
<mzanetti> dunno..
<Saviq> mzanetti, I mean it should ideally resolve it in a tooltip, for example
<greyback> 2.9 wasn't able to, I remember that anywy
<Saviq> mzanetti, or well, you can look at return type of the function anyway
<Saviq> mzanetti, and I agree with mhr3 that unless you put type info into the var name itself,  you still need to hunt for the type
<mzanetti> Saviq: sure... but it requires me to move the mouse and wait a second for the tooltip to show up :D
<mhr3> pfff :P
<mzanetti> *the mouse*
<mzanetti> :P
<mhr3> the horror!
<Saviq> mhr3, http://people.canonical.com/~msawicz/scope-tool/
<mhr3> Saviq, also, why do you call scopes.get() with incorrect index? :)
<Saviq> mhr3, I wasn't
<Saviq> mhr3, well, was trying not to
<mhr3> Saviq, yey, lovely :)
<mhr3> i mean the tool
<Saviq> mhr3, right, it's a race probably
<Cimi> mzanetti, confirmed...
<Saviq> mhr3, I get assert with 0
<mhr3> Saviq, calling too early?
<mzanetti> Cimi: hmm.. can you reproduce that in a simplified testcase?
<Saviq> mhr3, binding
<Saviq> mhr3, the option selector already created and selected its 0 index
<Cimi> mzanetti, nope
<Saviq> mhr3, but somehow the model isn't ready for it yet
<mhr3> Saviq, yea, it takes a while to init the scopes model, anyway, with the patch you'll get null back
<mhr3> Saviq, you could wait for the loaded signal though
<mhr3> Saviq, also ekran is screen?
<mhr3> sounds like a wild animal :D
<Saviq> mhr3, yes :)
<Saviq> mhr3, how about "zrzut"? ;)
<Saviq> mhr3, not sure where covers went, though :/
<mhr3> yea, that one is *just* odd, no associations :)
<mhr3> but ekran totally has wings
<mhr3> and is blue
<mhr3> https://www.google.co.uk/search?q=ikran&source=lnms&tbm=isch&sa=X&ei=d7SpUta_OoTnywPFmYCACA&ved=0CAcQ_AUoAQ&biw=1301&bih=656
<Saviq> ;D
<Saviq> mhr3, look again http://people.canonical.com/~msawicz/scope-tool/
<mhr3> why the double edit?
<Saviq> mhr3, 'cause you can't access it in phone layout
<Saviq> mhr3, there's no "SEARCH" panel
<mhr3> oh
<mhr3> ok
<Saviq> mhr3, we could go for button, but thought that would be good enough
<mhr3> sure, doesn't need to be perfect
<Saviq> mhr3, any idea where covers went?
<Saviq> mhr3, don't get them in plain unity8 either
<mhr3> hmm, server issue?
<mhr3> Saviq, oh do you have the icon -> art branch installed?
<Saviq> mhr3, good question
<Saviq> mhr3, prolly not
<mhr3> that would explain it
<dednick|lunch> Saviq: what is shell_app_HDRS?
<Saviq> dednick, yeah, exactly - nothing
<Saviq> dednick, it's not defined anywhere
<dednick> ok
<Saviq> ok... I was trying to get food for two hours now...
<Saviq> /food
<Saviq> mhr3, right - icon vs. art indeed - where *is* that branch, btw?
 * Saviq got lost
<mhr3> Saviq,  lp:~mhr3/unity-scopes-shell/scopes-ng-tests
<mhr3> so also in the json-defaults one
<Saviq> mhr3, right!
<Saviq> mhr3, http://people.canonical.com/~msawicz/scope-tool/ ;)
<Saviq> mhr3, will package it and it basically get in into new-scopes
<Saviq> +can
<mhr3> much better :)
<Saviq> mhr3, tests will only come later when we do something the dash itself doesn't do (like putting JSON through the validator)
<Saviq> really... */food*
<mhr3> i'll also play with it so it's able to talk to an uninstalled scope
<dednick> Saviq: hm, that getProperty doesnt work yet. changes to roles doesnt update the values :(
<dednick> Saviq: because it's a string property we're checking for.
<dednick> Saviq: ie getProperty(menuData, "label", "") will not respond to changes to menuData.label
<Saviq> dednick, "obviously that assumes that extAttrib only changes
<Saviq> atomically - which is not the case for menuData, for example - so it makes
<Saviq> sense to keep menuData explicit, while moving extAttrib and maybe some others.
<Saviq> Or well, menuData could be handled as well, by means of Qt.binding(), I think."
<dednick> would have nice to have the menuData like that it as well.
<dednick> Saviq: can you return a binding from a function?
<Saviq> dednick, Qt.binding(function() { return menuData[property] }) should work
<Saviq> dednick, hmm or not
<Saviq> dednick, you'd have to make sure that menuData.property is named somewhere there
<Saviq> dednick, so that the binding attaches to dataChanged
<Saviq> dednick, not sure [] will be good enough
<dednick> eh. would need to do it in onCompleted as well. can't use binding in declaration
<dednick> i knew there was a reason for all those && ?, i tried this before...
<Saviq> dednick, why?
<Saviq> dednick, as long as the changing thing is called explicitly in the binding
<Saviq> dednick, it should update fine
<Saviq> dednick, that's why I mentioned a custom get(object, property, default) method
<Saviq> dednick, as .getProperty assumes the object is !undefined
<Saviq> dednick, the get() would not assume that
<dednick> Saviq: yeah, but need get(object, property, propertyName, default
<Saviq> dednick, and should be evaluated whenever any of its arguments change
<Saviq> dednick, property vs. propertyName?
<dednick> hasOwnProperty.
<dednick> i guess can just to !== undefined
<Saviq> dednick, yeah, first check if object is defined
<Saviq> dednick, then if it has property
<Saviq> dednick, if either is false, return default
<Saviq> dednick, and that should cause the thing to reevaluate as needed - *assuming* that object changes atomically
<dednick> Saviq: how to you check if it has a property? you mean just "menuData && menuData.label != undefined"
<Saviq> dednick, which menuData doesn't - but extendedAttr has
<Saviq> dednick, right, menuData is different
<Saviq> dednick, that's why I said that a binding is needed
<Saviq> dednick, and I doubt menuData[property] will be good enough
<Saviq> dednick, you need to call menuData.label explicitly for dataChanged to be connected
<Saviq> dednick, so for menuData indeed I'm not sure it makes sense
<Saviq> dednick, you *could* hack it around with something along the lines of: menuData.onDataChanged: menuData.changed()
<Saviq> dednick, but that's probably not the best thing to do
<dednick> Saviq: http://pastebin.ubuntu.com/6561497/
<dednick> can really use either for extended data
<dednick> dont need a binding if we give the property, as it will be reevaluated when the parameter changes
<Saviq> dednick, only extendedData.xCanonicalTime will complain about extendedData undefined
<Saviq> dednick, as will menuItem.label
<dednick> oh, you mean when you call into the function? hmm.
<Saviq> dednick, yeah, at that point you'd have to go menuData && menuData.property
<Saviq> dednick, as the argument - which is bleh.
<dednick> Saviq: but as you said, doesnt that statement evaluate to the value of menuData.property if it's true? or is that only if you use || ?
<dednick> but i guess that defeats the purpose. sigh....
<Saviq> dednick, yeah, it will, but yes - it defeats the purpose exactly
<dednick> i might just change the menuData.label back to good old && || . dont think there's really any other neat way around it.
<Saviq> dednick, only thing I could think of was menuData[propertyName] in a Qt.binding()
<Saviq> dednick, but I'm worried that doesn't actually work
<dednick> Saviq: it doesnt.
<dednick> plus you need to use inside onCompleted, which sucks
<Saviq> dednick, yeah, I'm ok with && for menuData
<Saviq> dednick, since there's no clean way around it
<Saviq> dednick, standup
<Cimi> Saviq, you should have another automated bot for automated standup calls
<mzanetti> MacSlow: hey. as you'll be gone soon, what's the status of the SIM pinlock?
<mzanetti> MacSlow: did you fix those two issues I found?
<MacSlow> mzanetti, branch is ready since London with your requested fixes
<mzanetti> MacSlow: oh... damn... ok... I'll review it and fix any comments myself then while you're away
<MacSlow> mzanetti, I confidnet you'll be happy with the current state
<mzanetti> MacSlow: so far I only did a testing review. not a code review. but yeah... I don't think its really far off any more
<mzanetti> MacSlow: I'll try to have it merged by the time you come back.
<MacSlow> mzanetti, even made a screencast for you -> https://www.youtube.com/watch?v=raJpJx6DkQU :)
<mzanetti> haha
<mzanetti> always fun to see some motor bikes
<Saviq> ;D
<MacSlow> mzanetti, no bikes in that screencast this time :)
<Saviq> MacSlow, there's some in the "you should also watch" screen ;)
<mzanetti> and in your avatar
<MacSlow> Saviq, those are "bugs" in Google's recommendations-algorithms ;)
<Saviq> Cimi, re: bug #1258571 - yeah, that's what we discussed in London
<ubot5> bug 1258571 in unity8 (Ubuntu) "Select backgrounds based on aspect ratio and read them from dconf" [High,Triaged] https://launchpad.net/bugs/1258571
<Saviq> Cimi, stretching is the worst thing you can do to any image ;)
<Cimi> Saviq, stretch/crop
<Cimi> Saviq, all OSes do that
<Saviq> Cimi, so fit, not stretch
<Cimi> whatever
<Cimi> scale
<Saviq> Cimi, yes
<Saviq> Cimi, yeah, but having a single one that works well on the phone in portrait and on tablet in landscape isn't really easy
<Saviq> Cimi, we decided to go landscape + portrait for the default ones
<Cimi> I think it will be weird
<Saviq> Cimi, when you select a different background - that's when it will be scaled+croped
<Saviq> cropped
<Cimi> rotating the tablet and seeing wallpaper changing
<Saviq> Cimi, no no
<Saviq> Cimi, it's only about native aspect
<Cimi> Saviq, the bug report is about orientation
<Saviq> Cimi, so on tablet it will always be the tablet one
<Saviq> Cimi, ok maybe it's worded wrong indeed
<Saviq> Cimi, so write down in the bug please that the selection is only supposed to be made based on native device orientation
<Cimi> ok
<Saviq> /aspect ratio
<Cimi> ok
<Cimi> done
<Cimi> seb128, ^^
<Cimi> seb128, that bug, we need extra gestating schema
<Cimi> gsetting
<seb128> Cimi, why?
<seb128> what schemas/setting
<Cimi> seb128, look at the bug
<seb128> I did
<Cimi> https://launchpad.net/bugs/1258571
<ubot5> Ubuntu bug 1258571 in unity8 (Ubuntu) "Select backgrounds based on aspect ratio and read them from dconf" [High,Triaged]
<seb128> that doesn't make sense
<seb128> we discussed that via email with Saviq some time ago
<seb128> having per form factor keys doesn't make any sense
<Saviq> seb128, we talked with cwayne and design folk in London
<Saviq> seb128, it's not per-form-factor
<Saviq> seb128, it's for-portrait and for-landscape
<Saviq> seb128, and well, I don't really care whether it comes from gsettings or somewhere
<seb128> are those actually different backgrounds, or just one rotated?
<Saviq> seb128, different ones
<cwayne> apologies if i didn't word the bug clearly enough
<seb128> shrug
<seb128> Saviq, cwayne: and which one of those 2 keys to plan to use in desktop mode?
<Saviq> seb128, the idea is that OEMs can provide two backgrounds, one working well on portrait, one on landscape - only taking *native* aspect into account
<Saviq> seb128, desktop is native landscape - so that one
<Saviq> seb128, so we might just add background_portrait - or even take it from somewhere else than gsettings
<cwayne> we just suggested gsettings as that's where the current background info lives and would be the easiest in terms of customization
<seb128> Saviq, I was going to say, maybe just read the gsettings key and append -portrait to the filename and try to load that first
<seb128> e.g gsettings would be UbuntuRock.png
<seb128> you would try loading UbuntuRock-portrait.png if it's there
<seb128> cwayne, Saviq: the current design of the background config doesn't allow for portrait/landscape difference, what happen if you pick a background in portrait?
<seb128> does it change only that one? or landscape as well?
<seb128> we need design guidance on how the config is going to work to not be confusing
<Saviq> seb128, that's a problem in the settings app - it should reflect the native resolution of the device, I think
<Saviq> seb128, but, again, I probably have even more questions for that than you do!
<seb128> Saviq, well, if there are 2 images for landscape/portrait, do we need to be able to select both?
<seb128> cwayne^^
<Saviq> seb128, again, I have more questions!
<seb128> Saviq, well, let's get those resolved before adding gsettings keys
<Saviq> seb128, like that's gonna happen!
<Saviq> seb128, I'm fine with appending -portrait, tbh
<seb128> Saviq, well, the issue with all those solutions, is that
<seb128> - you end up with the setting not reflecting what you have on screen
<seb128> - if you pick a custom background, how do you got back to the vendor ones?
<Saviq> seb128, right back at you :)
<seb128> well, if you ask me I'm staying that those different images seems like a stupid idea and we shouldn't do it..
<cwayne> well if the device is portrait, only show/care about the -portrait gsettings key
<Saviq> cwayne yeah, which ends up being just one gsettings key ultimately
<cwayne>  right
<Saviq> cwayne, which begs the question... should the default not be per-device?
<cwayne> Saviq: what if we have one key that points to a dir that can contain a -landsape.png and a -portrait.png
<seb128> cwayne: then the configuration behaves differently when you rotate the device without telling you?
<cwayne> seb128: its about the native aspect ratio, not the current one
<cwayne> AIUI its not supposed to switch when you rotate
<Saviq> cwayne, I'm starting to think it should just use the image override
<Saviq> cwayne as in the system image - per-device
<Saviq> cwayne so you'd put a different background on manta, different on mako
<Saviq> even under the same name
<seb128> cwayne: portrait is not supposed to be used in portrait mode?
<Saviq> seb128, only native aspect ratio
<Saviq> seb128, not when you change orientation
<seb128> so it's 1 image by device?
<cwayne> Saviq: right, but then we'd need different custom tarballs for different devices, which we were trying to avoid
<Saviq> seb128, effectively yes
<seb128> so why just not shipping that as the default wallpaper?
<Saviq> seb128, ââ
<Saviq> brb
<cwayne> because then that image wouldn't look good on a mako for example
<cwayne> davidcalle: heya, where would be the best place to file a wishlist bug against a server-side scope?
<davidcalle> cwayne, if you find it in the list of unity-scopes sub-projects (https://launchpad.net/unity-scopes), on the scope itself. Or more generally, against unity-scope. There is no public place for server specific bugs (yet?).
<cwayne> davidcalle: awesome, thanks
<cwayne> seb128: so the whole point is to be able to have 1 custom tarball that will dynamically choose the right background so that we don't have to make a -tablet image
<davidcalle> cwayne, np :) *now waits for bugmail*
<seb128> cwayne: there is 0 difference in image/setup between a phone and a tablet image/for different devices?
<seb128> cwayne, Saviq: do we have some sort of code running on first device boot? could we just set the background key to the right value then?
<cwayne> seb128: correct. there's 1 image that works on both
<seb128> it would make things easy/compatible with what we have now and not at a runtime cost
<seb128> better to do a check/write a key once that check at every unity start
<davidcalle> cwayne, oh wait, you can't actually report a bug against unity-scopes... Ugh. Is it the weather not on top bug?
<tsdgeos> this is veeeeeeery confusing
<cwayne> davidcalle: no it was jcastro asking me, i think he had a wishlist bug for the askunity scope
<tsdgeos>         QTRY_COMPARE(item.y(), y);
<tsdgeos>         qDebug() << item.y() << y;
<cwayne> davidcalle: i just guessed and did the weather one to the home scope
<tsdgeos> FAIL!  : VerticalJournalTest::testVerticalSpacing() Compared doubles are not the same (fuzzy compare)
<tsdgeos>    Actual   (item.y()): 355
<tsdgeos>    Expected (y): 11
<tsdgeos>    Loc: [verticaljournaltest.cpp(33)]
<tsdgeos> QDEBUG : VerticalJournalTest::testVerticalSpacing() 11 11
<cwayne> seb128: that seems reasonable to me, i don't think anyone wanted us to do the check every time unity started, just once :)
<tsdgeos> so it's 355 vs 11 but then i print them and it's 11 and 11 ?Â¿?Â¿?Â¿
<davidcalle> cwayne, it's actually on the scope too... I'll make a place for these bugs. And for askubuntu, it's on unity-scope-askubuntu, I'm pretty sure I already know the bug :)
<cwayne> davidcalle: :)
<mhr3_> tsdgeos, TRY_COMPARE is too much magic, not too surprised :P
<tsdgeos> mhr3_: is not magic at all
<tsdgeos> it's just a loop
<tsdgeos> ahh, know what's going on
<mhr3_> tsdgeos, hm?
<tsdgeos> found my problem
<tsdgeos> or the "hm?" is about try compare being just a loop?
<mhr3_> tsdgeos, "hm" == so what's the actual problem?
<tsdgeos> i was working on deleted memory :D
<mhr3_> nice :)
<tsdgeos> good guy valgrind at rescue
<mhr3_> mzanetti, happy enough with the tests branch now?
<mzanetti> mhr3_: will have a look
<mhr3_> got two more branches built on top of it, so would like it in asap
<Saviq> cwayne, seb128, right, so there's a few jobs that run on system / session startup
<Saviq> cwayne, seb128, that do something only once (and write a .file somewhere to not do it again)
<cwayne> right, we even have some of those for customization already as well
<Saviq> cwayne, seb128, so we could add a job that writes an .override file if it doesn't exist
<seb128> right
<seb128> I like that approach better tbh
<Saviq> seb128, +1
<seb128> ;-)
<Saviq> cwayne, could you mark affefcts bug #1258571 for the customization project? sssssomething?
<ubot5> bug 1258571 in Ubuntu UX "Select backgrounds based on aspect ratio and read them from dconf" [Undecided,New] https://launchpad.net/bugs/1258571
<mzanetti> mhr3_: hmm... not sure if its my setup (probably it is) but tests are failing here
<cwayne> Saviq: done, sorry i thought it had already been attached
<mhr3_> mzanetti, ci likes them
<mhr3_> mzanetti, so it's you :)
<kgunn> dednick: just to be sure...this branch https://code.launchpad.net/~nick-dedekind/unity8/indicator-menuitems-lp1253810/+merge/198597
<kgunn> doesn't really fix that bug right ?
<kgunn> e.g. its just an artifact in the name of the branch
<dednick> kgunn: it's part of the fix.
<dednick> kgunn: along with a qmenumodel fix which has already gone int
<dednick> *in
<Saviq> didrocks, bug #1260379
<ubot5> bug 1260379 in Ubuntu CI Services "A unity8.override file should be shipped to allow apport completion during test runs" [Undecided,New] https://launchpad.net/bugs/1260379
<didrocks> Saviq: I think we can make that part of the -autopilot package
<didrocks> wdyt?
<didrocks> unity8-autopilot that is
<dednick> kgunn: i'm just in the process of checking the tests that i've made against the branch, and we should be able to merge.
<Saviq> didrocks, could
<didrocks> Saviq: I would start with that TBH ;)
<Saviq> didrocks, please comment/mark-affect
<didrocks> ok
<kgunn> dednick: thanks...sorry to be a nag, was that bug consistent enough to know it fixes it for sure
<dednick> kgunn: i haven't been able to reproduce, but Saviq has.
<dednick> although i havent tried it on my phone now that i have it with me.
<kgunn> dednick: mmmm....polish texts :)
<kgunn> ...or excuse me Polish
<dednick> haha
<Saviq> kgunn, excuse me, there were no texts involved - missed calls are enough ;P
<Saviq> dednick, btw, that branch ready yet?
<Saviq> dednick, or are you tweaking still?
<Saviq> ah 8 minutes ago :)
<dednick> Saviq: it's ready.
<Saviq> dednick, ok
<mhr3_> Saviq, seems like you didn't push the search edit
<Saviq> mhr3_, possible
<Saviq> mhr3_, pushed
<mhr3_> lovely
<Saviq> didrocks, but bug #1260384
<ubot5> bug 1260384 in Ubuntu CI Services "Should preprocess .crash files on test devices" [Undecided,New] https://launchpad.net/bugs/1260384
<didrocks> Saviq: can you address those to the CI team? :)
<Saviq> didrocks, isn't the -itself enough?
<didrocks> Saviq: sinon, ack on that one, that would make our life easier :)
<Saviq> didrocks, not sure I can, either
<didrocks> Saviq: should be, but not sure why you really ping me :)
<Saviq> didrocks, for â Confirmed ;)
<didrocks> ah
<didrocks> ok, yeah, can do
<Saviq> didrocks, as we discussed this before
<didrocks> done
<didrocks> with a comment ;)
<Saviq> nic-doffay, a simple one when you have a bit of time https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1260379
<ubot5> Ubuntu bug 1260379 in Unity 8 "A unity8.override file should be shipped to allow apport completion during test runs" [High,Triaged]
<nic-doffay> Saviq, cool
<Saviq> didrocks, see you want for false || value in the end :)
<tsdgeos> Saviq: do you want me to propose the verticaljournal as a new plugin or rename the LVWPH plugin into something like "DashViews" and add it there?
<Saviq> tsdgeos, same plugin is fine I think
<didrocks> Saviq: right ;)
<tsdgeos> Saviq: oki, will do some renaming then
<Saviq> didrocks, erm
<Saviq> didrocks, that was at dednick ;)
<Saviq> sorry
<Saviq> dednick, see you want for false || value in the end :)
<Saviq> dednick, there seem to be some unrelated fixes in there now?
<didrocks> Saviq: I was reacting on "a simple one" (telling, right, it's a simple one)
<Saviq> didrocks, ok :)
<dednick> Saviq: um, related to the Factory, but not necessarily to that bug.
<Saviq> dednick, yeah, it's ok, though - assume there's no other bugs for those
<Saviq> dednick, but we'll get tests for them ;)
<dednick> Saviq: yeah, that's what i'm doing now. I found those bugs with the tests.
<Saviq> dednick, ok awesome
<Saviq> dednick, changes look good, testing again
 * Saviq goes `rm -R shell/builddir`...
<Cimi> mzanetti, ping
<mzanetti> Cimi: o/
<Cimi> mzanetti, so, the binding seems broken
<mzanetti> fix it :)
<Cimi> mzanetti, well, I dunno why doesn't work
<Cimi> mzanetti, on the item
<mzanetti> mhm... can you point me to the line of code?
<Cimi> x: button.width - width
<Cimi> mzanetti, /usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/Themes/Ambiance/TabBarStyle.qml
<mzanetti> Cimi: oh, inside the theme?
<Cimi> you can sudo qtcreator that :)
<Cimi> yes
<Cimi> it's useful to debug
<mzanetti> and why don't the apps suffer from that?
<Cimi> don't ask me yet
<Cimi> I need more brain power
<Cimi> :P
<Cimi> so I need your head as well
<Cimi> mzanetti, for indicatorImage
<Cimi> mzanetti, there's x: button.width - width
<dednick> Saviq: how do i get whitespace test failure output?
<Cimi> but in the case of the indicator button.width changes AFTER x, and x is not update :-\
<Cimi> mzanetti, you can do that if you do onXChanged and onWidthChanged
<Cimi> on indicatorImage and button respectively
<mzanetti> Cimi: probably a binding loop detection that kicks in
<Saviq> dednick, ./tests/whitespace/check_whitespace.py . | grep -v builddir
<dednick> Saviq: ta
<Saviq> dednick, or well, make -C builddir works, too
<Saviq> test
<Saviq> make -C builddir test
<didrocks> Saviq: kgunn: for the unity8 AP failures, as it's due to screenlocking, I don't remember but the fix will be in the unity8 AP tests, right?
<Cimi> mzanetti, I can't see any print
<Cimi> mzanetti, on the terminal
<Cimi> about binding loops
<Saviq> didrocks, https://code.launchpad.net/~saviq/unity8/helper-retry-unlock/+merge/198648
<Cimi> mzanetti, but on the gallery app it updates, not here
<mhr3_> tsdgeos, is there a way to know that a plugin is running under qmlplugindump?
<tsdgeos> mhr3_: no idea, sorry
<didrocks> Saviq: that should fix all the AP issues we saw, right?
<Saviq> didrocks, as far as I can tell, yes
<Saviq> didrocks, bear in mind that's not something I could reproduce locally
<didrocks> Saviq: yeah, still worth a try
<Saviq> didrocks, worse case it will give us more data
<Saviq> *worst
<didrocks> Saviq: we'll release unity8 once the 2 other bugs are fixed as well
<nic-doffay> Saviq, this test_pressed_outside_notifier causes the top test to fail. It doesn't set the search as active even though triggerSearch is being called in the top most test. Any insights as to why?
<didrocks> Saviq: ok, I'm writing that :)
<didrocks> thanks!
<Saviq> didrocks, yup
<Saviq> didrocks, next step - we'll need cameras onto the devices
<didrocks> Saviq: complete +1, that was so helpful in otto
<Saviq> didrocks, if it doesn't help, that is
<mhr3_> tsdgeos, cause that thing is highly broken, it manages to unload the module but doesn't destroy objects it creates from there
<didrocks> Saviq: well, generally, way better to see visually at least what happened
<tsdgeos> mhr3_: and?
<Saviq> didrocks, yup
<Saviq> nic-doffay, nope, sorry
<tsdgeos> mhr3_: does that crash or something?
<mhr3_> tsdgeos, yes, cause i spawn a thread
<tsdgeos> boo
<tsdgeos> mhr3_: on module load?
<mhr3_> after a timeout
<nic-doffay> Saviq, clicking it manually with the mouse causes the tests to pass.
<Saviq> dednick, http://pastebin.ubuntu.com/6562236/ no worky :/
<nic-doffay> But that's just the same as doing triggerSearch?
<tsdgeos> mhr3_: can you delay the spawning until it's really needed? would that help
<tsdgeos> ?
<Saviq> nic-doffay, would need a deeper look, sorry no can do right now
<mhr3_> tsdgeos, it's needed when you instantiate the class :P
<Saviq> dednick, and it does end up broken still
<tsdgeos> mhr3_: then i think someone should fix qmlpluginloader thingie
<tsdgeos> mhr3_: or maybe it even got fixed in 5.2?
<Saviq> tsdgeos, mhr3_, we probably should only be running qmlplugindump manually
<Saviq> tsdgeos, mhr3_, same as with qdbusxml2cpp
<Saviq> stuff like that
<mhr3_> Saviq, you mean to put the generated stuff in bzr?
<Saviq> mhr3_, yes
<mhr3_> yea, that'd work
<Saviq> mhr3_, they're not really meant to be ran automagically
<tsdgeos> but everyone does :D
<dednick> Saviq: :/ i have no idea how that ends as undefined... you can assign null to var surely?
<Saviq> dednick, to var, yes - it tries to assign to UnityMenuModel
<Saviq> dednick, so that actual error is from UnityMenuAction
<dednick> Saviq: it's assigning a undefined to a object pointer..
<Saviq> dednick, should be assigning null instead
<Saviq> ah it is null
<dednick> but it shouldnt be undefined.
<Saviq> dednick, something then changes it to undefined
<Saviq> dednick, but seems unrelated to the fact that I can still reproduce the issue, though
<dednick> yeah
<dednick> Saviq: you still have the qmenumodel update on phone right?
<Saviq> dednick, hmm
<Saviq> dednick, right, I might not have
<Saviq> dednick, I probably don't - forgot about this
<dednick> *cross fingers*
<Saviq> dednick, yeah, that makes sense
<Saviq> dednick, that warning, though, would be good to track down anyway
<Cimi> mzanetti, ideas?
<mzanetti> Cimi: still searching... In Panel/MenuContent.qml there is a fixme which might have influence on this
 * Cimi reads
<mzanetti> referring to a QTBUG... Which btw waits on input from us
<Saviq> dednick, ok, looking good, sorry for the noise
<dednick> Saviq: yay! i'll try sort out the warning though
<Saviq> dednick, other branch?
<Saviq> dednick, or same?
<dednick> Saviq: er. give me a few minutes and i might be able to put it in same.
<Saviq> dednick, ok
<mhr3_> tsdgeos, not much changed in 5.2 for plugindump
<tsdgeos> ok
<dednick> Saviq: was that in tests it was complaining?
<Saviq> dednick, no, when running
<mhr3_> Saviq, btw re basename() re-revert, we ok to get it back? or should it wait for the ap to get committed?
<Saviq> mhr3_, let's get a test
<Saviq> mzanetti, we're not waiting for this, are we â?
<mhr3_> i'm surprised that it still works though :P
<mzanetti> Saviq: waiting for what?
<Saviq> mzanetti, the baseName vs. completeBaseName thing
<Saviq> mzanetti, in unity-scopes-shell
<Saviq> mzanetti, was it cleanup / in-preparation for other things?
<dednick> Saviq: no idea. it's not happening for me.
<dednick> Saviq: i'll have to fix in another branch
<dednick> and test on phone
<mzanetti> Saviq: yeah... my new branch needs it and also is meant to clean stuff up.
<dednick> Saviq: can you check if it still will connect to network if you select access point?
<mzanetti> Saviq: but no. we can get this in now. should not wait for my current branch
<cwayne> davidcalle: hey, what happened to the launchpad scope?
<Saviq> mzanetti, I know we *can* get it in
<Saviq> mzanetti, question was whether we want to wait for ap test
<Saviq> mzanetti, and I said yes, as there's nothing pressing us right now to get it in?
<mhr3_> Saviq, also json-defaults ;)
<mzanetti> ok...
<Saviq> mhr3_, yeah, tomorrow
<Saviq> dednick, i definitely get "menuModelChanged: undefined" from onMenuModelChanged: console.log("menuModelChanged:", menuModel) in MenuItemFactory
<Saviq> dednick, on startup
<Saviq> dednick, and on indicator unload
<dednick> Saviq: hm, yeah, me too
<davidcalle> cwayne, python2
<davidcalle> cwayne, tied to the python2 launchpad API
<MacSlow> ok, see you folks in a few weeks!
<cwayne> davidcalle: ah, is launchpadlb not ported yet?
<Saviq> dednick, anyway, doesn't affect functionality
<Saviq> dednick, acking
<davidcalle> cwayne, I think it's blocked on some other python lib... zope maybe.
<cwayne> davidcalle: ah, makes sense, thanks
<cwayne> is that a good thing to assume for most of the python ones that havent made it in yet?
<dednick> Saviq: give me 2 secs. got it fixed
<Saviq> dednick, oh cools
<davidcalle> cwayne, most of them, yeah, others reasons are : aggressive scraping, touchy content provider
<robru> Saviq, ping about bug 1258655. will it be fixed today? I can land it today if it's fixed in the next 10ish hours.
<ubot5> bug 1258655 in Mir "Abort when blanking/unblanking screen; exception thrown from mir::graphics::android::HWCCommonDevice::mode(MirPowerMode)" [Critical,In progress] https://launchpad.net/bugs/1258655
<davidcalle> cwayne, and bad performance (unreliable APIs, slow, etc)
<Saviq> robru, kdub is working on that one
<Saviq> robru, he's closer to your time zone, so could very well happen
<dednick> Saviq: done.
<cwayne> davidcalle: yeah, makes sense, do we have like a list or some doc on the status of individual scopes?
<robru> Saviq, ok, thanks.
<Saviq> robru, bug #1253810 is almost there
<ubot5> bug 1253810 in Unity 8 "Messages in Incoming not always display the correct date and content" [Critical,In progress] https://launchpad.net/bugs/1253810
<robru> kdub, please ping me when it's done
<dednick> Saviq: kinda weird though...
<davidcalle> cwayne, there is a doc, a bit outdated. There is also this tool, which is not updated either, but is closer to something useful and easy to tweak. http://framli.eu/scopes_browser/index.html?scope=unity-scope-clementine
<dednick> i'm guessing the ListView doesnt register a null model as a change when it's already a empty QVariant
<Saviq> dednick, right, so you're effectively converting an invalid mainMenu.model into null
<Saviq> dednick, it might be that ListView.model will always be undefined, even if you assign null indeed
<dednick> Saviq: yeah, it's a bit dodge.
<dednick> Saviq: the menuModel should probably just be q QtObject
<dednick> Saviq: although same problem at lower level...
<Saviq> dednick, yeah
<Saviq> robru, FWIW, the Mir bug is not a unity8 one, so those can be released separately
<davidcalle> cwayne, updating it right now with a script... but it's been a long time: will probably fail ;)
<Saviq> robru, hence marked invalid
<cwayne> davidcalle: :)
<kdub> robru, okay
<Saviq> dednick, probably worth fixing, too:
<Saviq> WARNING: ListItems.Standard.icon is DEPRECATED. Use iconName and iconSource instead.
<Saviq> dednick, and well:
<Saviq> MenuContent.qml:105:21: QML Loader: Binding loop detected for property "indexActive"
<Saviq> dednick, indicators are pretty vocal, if you ask me!
<Saviq> ;)
<dednick> Saviq: yeah, working on that :)
<Saviq> ok
<Saviq> dednick, thanks for that!
<Saviq> /afk
<kgunn> Saviq: what mir bug ?
<kgunn> > FWIW, the Mir bug is not a unity8 one, so those can be released separately
<cwayne> has there been any progress on shipping scopes as click packages?
<mhr3> cwayne, not yet
<mhr3> cwayne, plus i'd say that primary issue is that there's no design decision on where a scope would be added
<cwayne> mhr3: what do you mean?
<mhr3> i mean what should happen when you install a scope
<mhr3> where does it "go"
<cwayne> mhr3: hm, should we get together with design? or should this wait until the api is further along anyway?
<mhr3> we brought it up last week
<mhr3> so it's on radar
<cwayne> mhr3: awesome, thanks for the info :)
<Saviq> kgunn, the blanking one on mako
<Saviq> kgunn, https://launchpad.net/bugs/1258655
<ubot5> Ubuntu bug 1258655 in Mir "Abort when blanking/unblanking screen; exception thrown from mir::graphics::android::HWCCommonDevice::mode(MirPowerMode)" [Critical,In progress]
<kgunn> ah
#ubuntu-unity 2013-12-13
<didrocks> Saviq: hey! I saw robru released unity8 without qmenumodel (both were listed in the landing ask), is there any risk if I kick an image without qmenumodel?
<Saviq> didrocks, the bug won't be fixed
<didrocks> grrr, I wonder how robru confirmed the fix thenâ¦
 * didrocks *sigh*
<Saviq> didrocks, well, it's a race
<Saviq> didrocks, so he might not have encountered it
<didrocks> ok
<didrocks> Saviq: I'm building qmenumodel right now
<didrocks> will deliver and quick an image with it
<Saviq> didrocks, cool, thanks
<Saviq> didrocks, I found the issue with bug #1256061 - it's unity8 and the indicator in the end - have a fix for unity8 ready, need yet to write a test
<ubot5> bug 1256061 in Unity 8 "clock forcefully switches from 24h to 12h AM/PM format once the panel clock is loaded" [High,In progress] https://launchpad.net/bugs/1256061
<didrocks> Saviq: argh, ok. I'll have to explain that to management then :/
<didrocks> on the "why did we release unity8 without the fix"
<didrocks> Saviq: I'll try to put it nicely ;)
<Saviq> didrocks, well, that bug wasn't blocking
<didrocks> Saviq: for the unity8 release yeah, it was
<Saviq> didrocks, ah right, damn
<didrocks> Saviq: do you think this is going to land soon?
<Saviq> but was attributed to qtubuntu
<didrocks> if so, we can bundle it to the same image :)
<Saviq> didrocks, well, today
<didrocks> Saviq: if it's in the incoming hour, we can
<Saviq> didrocks, but some hours ahead for sure
<didrocks> but ok, so will be too late
<didrocks> nevermind, keep getting things landing :)
<dandrader> Saviq, for getting https://bugs.launchpad.net/unity-api/+bug/1258057
<ubot5> Ubuntu bug 1258057 in Unity API "unity-api fails to build against Qt 5.2" [Critical,In progress]
<dandrader> Saviq, sorry, I meant this http://paste.ubuntu.com/6557929/
<dandrader> Saviq, did you just "bt" or did you also add some arguments
<dandrader> for printing out variables on each frame
<Saviq> dandrader, that was `bt full`
<dandrader> ah
<dandrader> didn't know that one, always used just "bt"
<dandrader> Saviq, is that a normal output for testLauncher from unity-api? http://pastebin.com/d4EKTZ9k (btw, Ubuntu's pastebin refused this text)
<dandrader> I wonder if I'm missing something in my setup...
<Saviq> dandrader, looks that way
<dandrader> the test didn't fail though...
<Saviq> dandrader, yeah, that's just warnings
<Saviq> dandrader, should be cleaned up anyway, true
<dandrader> Saviq, so you don't get those warnings?
<Saviq> dandrader, yes I do
<dandrader> ah, ok. then my setup is fine
<Saviq> dandrader, sorry, the "looks that way" was to your previous message
<dandrader> Saviq, I didn't get any crash in the tests. but testApplication failed, but without crashing
<Saviq> dandrader, under 5.2 on i386?
<dandrader> Saviq,  that's with the "stable" qt5 branch on a i386 chroot
<Saviq> dandrader, ah, stable is 5.1
<Saviq> erm
<Saviq> 5.2.1
<Saviq> dandrader, maybe it was fixed between 5.2 and 5.2.1
<dandrader> so that's good news I suppose
<Saviq> dandrader, yeah, would be awesome to bisect and get the commit into our packages
<dandrader> will check why testApplication is failing...
<Cimi> mzanetti, ping :)
<mzanetti> hi Cimi :)
<Cimi> mzanetti, did you go any further with the exploration? is there anything you suggest ding?
<Cimi> *doing
<mzanetti> Cimi: did you find out if its related to that hack?
<Cimi> nope, didn't try actually
<mzanetti> Cimi: iirc there was some discussion lately regarding dynamically adding/removing tabs. I think the Tabs component gained support for that recently. So I'd say way to go would be to check out if that hack is actually needed any more and if removing it fixes the issue
<mzanetti> as that's the only thing I can think of what's different in apps and unity8
<mzanetti> maybe dednick can explain what exactly is this hack for
<mzanetti> I didn't fully understand the bug report tbh
<tsdgeos> https://code.launchpad.net/~aacid/unity8/verticalJournal/+merge/198897 is up if anyone wants to do some view reviewing
<tsdgeos> Saviq: i'll do hJournal next and try to share as much code as possible with the vJournal
<Cimi> mzanetti, it does not fix the issue
<mzanetti> Cimi: strange
<Saviq> tsdgeos, yup, great
<mzanetti> Cimi: I guess at this point I would start with a new file and Tabs, and starting to build the same thing (with repeater etc) until the issue is reproducable outside of unity
<Cimi> mzanetti, I think it might be for the loaders?
<tsdgeos> dandrader: totally right
<tsdgeos> dandrader: and something like what listviewwithpageheader.cpp has on the top
<tsdgeos> explaining a bit the code won't hurt either
<mzanetti> Cimi: Don't know... but yeah. the fact that the width is set multiple times suggests something like this
<xnox> Saviq: tsdgeos: can we leave out policy changes from cross-compilation fixes? i.e. at the moment unity8 generates dbus code at build time, and I simply fixed it to succeed when cross-compiling.
<xnox> Saviq: tsdgeos: changing when dbus code is generated, or stored. is not my proposal at all.
<tsdgeos> xnox: as said it looks good to me, but i'll let Saviq be the one to decide
<xnox> tsdgeos: cause i have tasty cmake upload which will cross-compile unity8 .... if above is merged.
<xnox> tsdgeos: ah, looks like Saviq agrees to keep regenerating dbus code at build time.
<Saviq> xnox, tsdgeos, yeah
<Saviq> didrocks, good news
<Saviq> didrocks, https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1256061
<ubot5> Ubuntu bug 1256061 in Unity 8 "clock forcefully switches from 24h to 12h AM/PM format once the panel clock is loaded" [High,Opinion]
<Saviq> didrocks, that bug is actually invalid...
<didrocks> Saviq: oh, it's magically fixed?
<didrocks> I'll flash latest
<didrocks> and switch to French
<xnox> tsdgeos: hm, jenkins gave "Needs Fixing" review, is there actually something I need to fix?
<tsdgeos> nah
<tsdgeos> it's some crap we need to fix
<Saviq> xnox, some flakiness still
<tsdgeos> really really
<xnox> tsdgeos: ok, thanks =)
<mhr3_> tsdgeos, something already using the vertical journal?
<tsdgeos> mhr3_: the test :D
<mhr3_> tsdgeos, maybe you want to hook it up with lp:~unity-team/unity8/new-scopes? ;)
<tsdgeos> mhr3_: i just hooked it up where Saviq told me to
<Saviq> tsdgeos, *hook* as in actually make use of it
<Saviq> tsdgeos, mhr3_, let's get it merged into unity8 trunk
<Saviq> tsdgeos, mhr3_ then merge trunk into new scopes, and make use of it
<mhr3_> sure, i'm thinking step 2 already :)
<Saviq> tsdgeos, mhr3_ oh yeah, we can go with new-scopes + vjournal in a branch already
<Saviq> mhr3_, only we don't have variable height cards yet ;)
<mhr3_> :(
<Saviq> mhr3_, or a scope that gives us data that could be used for that, for that matter :P
<mhr3_> Saviq, details :P
<Saviq> mhr3_, I *know*
<mhr3_> Saviq, btw json-defaults was looking for you, and there's one more branch built on top of it
<mhr3_> fwiw those are really simple branches :)
<Saviq> mhr3_, yeah, on my list for today
<Saviq> didrocks, news?
<didrocks> Saviq: flashing right now, under a tons of things :p
<Saviq> didrocks, k
<didrocks> Saviq: not fixed here
<didrocks> Saviq: I move to French
<Saviq> didrocks, rebooted?
<didrocks> set to 19h in the system settings ui
<didrocks> (after a reboot)
<didrocks> and it's written 7:45
<didrocks> for instance
<Saviq> didrocks, but no AM/PM?
<didrocks> no AM/PM
<didrocks> just 7:45
<Saviq> didrocks, let me check
<Saviq> didrocks, ok I think I know what's happening then
<Saviq> didrocks, the default setting is 12hr
<didrocks> Saviq: this default setting is in unity8?
<Saviq> didrocks, no, it's for the datetime indicator
<Saviq> didrocks, that string comes directly from the indicator now
<Saviq> didrocks, preformatted
<Saviq> gsettings get com.canonical.indicator.datetime custom-time-format
<nic-doffay> didrocks, ping
<didrocks> Saviq: can you ensure the indicators guys are in the loop then?
<didrocks> nic-doffay: pong
<nic-doffay> didrocks, going to look into this: https://bugs.launchpad.net/unity8/+bug/1260379
<ubot5> Ubuntu bug 1260379 in Unity 8 "A unity8.override file should be shipped to allow apport completion during test runs" [High,Triaged]
<didrocks> no need to ping me when I'm talking on that channel, just ask :p
<nic-doffay> where should I start.
<didrocks> nic-doffay: ah great!
<Saviq> larsu, around?
<Cimi> mzanetti, found
<Cimi> mzanetti, line 141 of MenuContent.qml
<mzanetti> Cimi: \o/
<Cimi> that binding does not work
<didrocks> nic-doffay: I would say, look at the unity8 file, ship an upstart override file with the extra shutdown period
<Cimi> mzanetti, if you put title: "Example" at line 103 and you remove that binding, the indicator icon is rightly placed
<mzanetti> interesting
<Cimi> mzanetti, obviously the reason why this is causing the style to break is obscure
<Cimi> to me
<Cimi> mzanetti, because you get the title (the text)
<mzanetti> Cimi: so I guess the binding does work, but because it waits for the loader.item to be loaded it overwrites width a second time which breaks the tab
<Cimi> but breaks other bindings
<mhr3_> Saviq, you were trying to build libunity-scopes on saucy and it failed?
<Cimi> mzanetti, good spot
<Saviq> mhr3_, yes
<larsu> Saviq: yep
<mhr3_> Saviq, do we need to fix that?
<Saviq> mhr3_, exceptions in tests
<Saviq> larsu, are you maintaining indicator-datetime?
<mzanetti> Cimi: ok.. but in this case the proper fix is indeed inside the style (I'd say)
<mhr3> Saviq, fwiw i'm running it fine on saucy
<mhr3> but i'm building the pkg locally...
<mzanetti> Cimi: a tab should not break if you change title at runtime
<Saviq> mhr3, https://launchpad.net/~phablet-team/+archive/desktop-deps/
<larsu> Saviq: no, charles is
<Saviq> larsu, I've tracked down bug #1256061 to be, in fact, an indicator-datetime issue
<ubot5> bug 1256061 in Indicator Date and Time "clock forcefully switches from 24h to 12h AM/PM format once the panel clock is loaded" [Undecided,New] https://launchpad.net/bugs/1256061
<mzanetti> Saviq: see, told ya :) (re: OSK swipe down from everywhere)
<Saviq> mzanetti, ;P
<Saviq> larsu, ok, will assign to him then
<larsu> Saviq: yep, looks like it. We should fix this for real and send a time stamp...
<Saviq> larsu, yeah, another bug
<Saviq> larsu, I actually already have a branch that "fixed" it by ignoring what the indicator sent up completely
<Saviq> larsu, but wasn't real happy with it, and it didn't take all the other settings into account etc.
<larsu> Saviq: right, sending a time stamp doesn't even make sense for the current time
<Saviq> larsu, exactly
<larsu> what settings are those?
<larsu> whether to show the year, 24h, etc?
<Saviq> larsu, https://wiki.ubuntu.com/TimeAndDate?action=AttachFile&do=view&target=settings-clock.png
<larsu> right
<dednick> Cimi: ping
<Cimi> dednick, pong
<dednick> Cimi: hey, can i get you to do a review for me? https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/visual-updates/+merge/193301
<dednick> when you have some time.
<nic-doffay> didrocks, what am I looking for in this crash file?
<Cimi> dednick, sure, now
<dednick> Cimi: thanks
<dandrader> Mirv, what's the plan for trusty regarding Qt? is our target to endup shipping 5.2 or there's no fixed target yet, meaning that it could be 5.2.1, etc?
<Saviq> dandrader, 5.2 for sure, if 5.2.1 gets there in time - hopefully
<didrocks> nic-doffay: what you want is to have a stop 30 in this override to let the coredump to be collected before upstart is killing it
<Saviq> didrocks, "kill timeout 30", no?
<didrocks> yep
<Saviq> nic-doffay, just have a unity8.override file with that line ââ
<Saviq> nic-doffay, put it in data/
<Saviq> nic-doffay, and add a line to debian/unity8-autopilot.install
<dandrader> it's interesting that there's already an enormous diff between qtdeclarative release (5.2) and stable (5.2.1)
<Saviq> nic-doffay, to install that .override file into /usr/share/upstart/sessions
<Saviq> dandrader, yeah indeed
<Saviq> didrocks, unless there's a better place to put it in ââ?
<didrocks> Saviq: no, thats perfect
<nic-doffay> Saviq, right will get going with that then.
<Saviq> does anyone else's right-mouse-button get crazy sometimes and does a click as soon as you move the mouse, without you releasing it?
<Saviq> like it creates a new folder on-right-click for me, instead of opening the menu :/
<Saviq> it does that for a minute at a time and then goes back to normal
<Saviq> mhr3, with https://code.launchpad.net/~michihenning/unity-scopes-api/what-for-exceptions/+merge/198872 there will be some actual useful output in the build log
<mhr3> Saviq, yea, just got a mail from michi about that branch
<dandrader> Saviq, working fine on my desktop
<Saviq> dandrader, yeah, I'm not sure if it's my mouse, or the touchpad playing games...
<Mirv> dandrader|lunch: as saviq said, 5.2.x is the target for sure. the focus is on 5.2 + backported patches for now.
<nic-doffay> Saviq, how should I test for this now?
<Cimi> guys, we should fix the scrolling...
<Cimi> of flickable
<Cimi> velocity and deceleration
<Cimi> it's broken on the desktop and on the devices
<Saviq> Cimi, filed a bug yet?
<Mirv> phew, so much to do... (with Qt 5.2)
<Saviq> Mirv, between rc1 and release?
<Saviq> nic-doffay, with unity running, go:
<Saviq> kill -11 `pidof unity8`; stop unity8
<Saviq> nic-doffay, stop unity8 should return after more than 5s
<Mirv> Saviq: not really between those, but doing this correctly instead of ad-hoc. symbols updates for all archs (multiple builds), syncing with Debian, rebuilding everything after noticing Debian did now do the qt5core lib rename, patches coming from all directions for enabling tests etc (which should be then contributed back to Debian also at some point)
<Saviq> Mirv, right, so basically the real packaging
<Mirv> Saviq: so I thought today I would make progress, instead I find myself being back to near beginning with 5.2 final build :)
<Cimi> Saviq, I need to test again on my galaxy nexus, but it's definitely broken in the desktop
<Mirv> but of course progress made reducing delta, going through changes etc
<Cimi> Saviq, try flicking on the sdk components gallery
<Cimi> Saviq, it's like crazy :)
<Cimi> actually now works
<Cimi> :-\
<Saviq> Cimi, yeah, seems fine in the pickers
<Cimi> Saviq, it's fine now for me
<Cimi> Saviq, was badly broken yesterday
<Cimi> Saviq, like over scrolling with no limits
<Cimi> Saviq, can I test qt 5.2 on maguro?
<Saviq> Cimi, you could try
<Saviq> Cimi, ppa:canonical-qt5-edgers/qt5-beta2
<Saviq> Cimi, but it's probably better to wait a bit
<Cimi> Saviq, I wanted to try the scrolling
<Saviq> Cimi, it's all in flux now that 5.2 was released finally
<Saviq> Cimi, I don't think anything changed tehre
<Cimi> Saviq, was broken in all our previous versions
<Cimi> Saviq, try seeing the default velocity of the flickable
<Saviq> Cimi, and it all basically deserves a QTBUG that the default values are a) pixel-dependent and b) not customizable without rebuilding Qt
<Cimi> Saviq, it was 1500 iirc, should be much higher with high dpi
<mzanetti> I have a weird issue right now... I cannot drag (flick) any scope upwards unless I pull it down a little beforehand
<mzanetti> is that known?
<Saviq> Cimi, https://qt.gitorious.org/qt/qtdeclarative/source/e895bc315f9959a5dad80a8f0bf7b73bced0bde1:src/quick/items/qquickflickable.cpp#L61
<Saviq> mzanetti, no
<Saviq> mzanetti, phone?
<mzanetti> yeah
<Saviq> nic-doffay, so the real test there is to see that the package built and the file gets installed into /usr/share/upstart/sessions/
<Saviq> nic-doffay, if it is - that's all we can do TBH
<nic-doffay> Saviq, killing it from a separate console has strange results.
<nic-doffay> Unity8 jus segfaults.
<Saviq> nic-doffay, that's what -11 does
<Saviq> nic-doffay, that's SIGSEGV
<Saviq> nic-doffay, but anyway - more real-life test
<Saviq> hmm crap
<nic-doffay> Saviq, getting this too: stop: Unknown job: unity8
<Saviq> nic-doffay, as phablet
<nic-doffay> Saviq, so run on device then run as phablet user.
<Saviq> nic-doffay, man, run on device won't do you any good
<Saviq> nic-doffay, that file will only get installed where it needs to when packaged
<Saviq> nic-doffay, run_on_device doesn't install anything
<nic-doffay> Saviq, what's the deal with stop: Unknown job: unity8
<Saviq> nic-doffay, you're not logged in as phablet, most likely
<Saviq> nic-doffay, or you managed to uninstall unity8
<nic-doffay> Saviq, the former then.
<Cimi> Saviq, that's bad
<Saviq> Cimi, you've been complaining about this for what, half a year now?
<Saviq> Cimi, did you file a bug?
<Cimi> nope
<Cimi> I'm a lazy guy (my main flaw) and not registered yet to qt bugs
<Cimi> I'm going to to this today and I will be digia's worst nightmare
<Cimi> perfectly in time for Friday the 13th
<Saviq> nic-doffay, just file the merge proposal
<tsdgeos> Saviq: ok i think i know why that test_show_scope_on_load is failing
<Saviq> nic-doffay, we'll know soon enough whether it's correct
<Saviq> tsdgeos, pray tell
<tsdgeos> Saviq: now i want to know if i change the test of the code :D
<nic-doffay> Saviq, yeah was trying to avoid that though!
<tsdgeos> let me to a pastebin explaining
<Saviq> nic-doffay, it's this kind of change
<Saviq> nic-doffay, to test for real you'd have to make unity8 crash on exit
<Saviq> nic-doffay, which isn't difficult, btw, if you want - it's just a case of tweaking the main() to not destroy the view or the application, but return application->exec() straight away
<Saviq> nic-doffay, then, without your .override file, upstart will kill unity8 before apport's managed to collect the full crash report
<Saviq> nic-doffay, with it, upstart will wait for up to 30s (as opposed to 5s) before killing
<Saviq> nic-doffay, giving time for apport to collect the crash file
<nic-doffay> Saviq, I'll give that a go while waiting for jenkins.
<Saviq> nic-doffay, you can do 'stop unity8; start unity8 BINARY=$PWD/builddir/unity8' to launch the locally built unity8 under upstart
<nic-doffay> Saviq, cool thanks
<Saviq> nic-doffay, having built it first with run_on_device, and logging in as phablet, unity8 is built in /home/phablet/shell/builddir/unity8
<Saviq> nic-doffay, and BINARY=... just tells upstart to launch that binary instead of the system-installed one
<tsdgeos> damn it's hard to write the thoughts down
<tsdgeos> Saviq: actually no, scrap that, can't tell :-/
<tsdgeos> but i'm going to add a hell lot of console.log and will find out
<Saviq> tsdgeos, maan :/
<tsdgeos> i'm tired of all those errors
<Saviq> tsdgeos, please do
<Saviq> tsdgeos, +1
<dednick> Saviq: did we decide we would pass https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 ?
<Saviq> dednick, I'm still not really sure what it's supposed to fix ;D
<Saviq> dednick, but then we decided that the indicators should just put up timestamps (in case of non-current time) or nothing at all (in case of current time), and users' preferences should be applied globally by applied globally by new SDK component(s) - TimeFormatter and RealTime or so
<Saviq> dednick, so unless that branch actually fixes something that I'm not aware of, I'd reject it
<dednick> Saviq: right, but thats a todo later right...
<dednick> Saviq: it's for the datetime alarm menu items.
<Saviq> dednick, ah, ok
<Saviq> dednick, can we see them already?
<Saviq> dednick, like if I add an event in my calendar, will they show up?
<dednick> "you can see them", but there are no times.
<Saviq> dednick, which that branch is supposed to fix, correct?
<mhr3> Saviq, ok with exposing the raw json in the category models purely for the dev-tool usage?
<dednick> Saviq: um. it will, when we have an event item :)  It's in ubuntu-settings-components. Currently we're just using the standard item (no time).
<Saviq> dednick, so still no way to see the fix, eh? ;)
<dednick> nope. but this branch also moves the formatter into Utils :)
<dednick> Saviq: oh, and my indicator tests branch is done. :) https://code.launchpad.net/~nick-dedekind/unity8/indicator-page-factory-tests/+merge/198785
<Saviq> dednick, yup, saw that
<Saviq> dednick, and ohkay, if you twist my arm... can you just add a TODO/FIXME somewhere where it makes sense, and refer to bug #1260728
<ubot5> bug 1260728 in Unity 8 "Indicators should send timestamps, not pre-formatted strings" [Medium,Triaged] https://launchpad.net/bugs/1260728
<dednick> Saviq: :) ok
<Saviq> xnox, so does that mean that with the new cmake upload and the unity8 branch, we'll be able to cross-build directly? :)
<xnox> Saviq: yes, along with pleora of other packages. =))) one time setup: mk-sbuild --target armhf, and after that it's just $ sbuild -A --host armhf unity8*.dsc
<Saviq> xnox, YUMMY
<Saviq> xnox, do you know if distcc should work fine when cross-building? ;)
<xnox> Saviq: once qt*-dev stack is co-installable it will be possible to even do it without a chroot with: dpkg-architecture -aarmhf -c cmake ../ && make
<Saviq> xnox, I know ccache does work fine
<xnox> Saviq: why do I need distcc, or ccache if it takes 2m20s to cross-compile unity8 clean from start to finish?
<Saviq> xnox, nice one, we'll have to transition our run_on_device script to that :)
<Saviq> xnox, right, it's much simpler recently ;)
<Saviq> xnox, but then I'm thinking of moving to an ultrabook at some time in the near future, will not get the quad-core thing I have now ;)
<xnox> Saviq: .... cross-building happens on amd64/i386 which is fast and multi-core (typically) so simply DEB_BUILD_OPTIONS=parallel=12
<Saviq> xnox, yeah -j9 is my default
<dednick> Saviq: done. i just put it in the Timeformatter header.
<Saviq> dednick, cheers
<Saviq> xnox, and well, it's not just about unity8, I actually compile other things as well ;)
<xnox> Saviq: you do want to set it via DEB_BUILD_OPTIONS or even specifically in ~/.sbuildrc $build_environment {'DEB_BUILD_OPTIONS' => 'parallel=9'}
<Saviq> xnox, I barely do anything else than bzr bd, which does have sbuild -j9 as the builder
<Saviq> xnox, when building packages, that is
<xnox> Saviq: right. so the only requirement is that distcc / ccache generates / replaces $DEB_HOST_GNU_TYPE-[gcc|g++]
<xnox> Saviq: cause that's the compiler that cmake will pick when cross-compiling.
<Saviq> xnox, yeah, I thought it *should* work in theory
<Saviq> xnox, will do some testing
 * xnox has no need though =)
<xnox> I have 8 core, 32GB of RAM, and I compile in tmpfs with no iowait ;-)
 * dandrader makes a mental note that "good" and "bad" in git bisect mean the other way round when you're looking for the commit that fixes something
<Saviq> xnox, well, I'm 4 core HT, 8GB RAM and compile in shm, too (and SSD to boot)
<Saviq> xnox, but as I said, am thinking of moving to an ultrabook, at which point I'd like to offload some of that umph ;)
<davmor2> xnox: man that is an awesome phone :D
<seb128> Saviq, larsu: so the timestamp issue is back on the indicator side?
<Saviq> seb128, yeah
<xnox> davmor2: =))))) not very portable, and battary UPS only lasts 10m
<Saviq> seb128, it's a string straight from indicator-datetime
<Saviq> seb128, I did fix it unity8-side, by ignoring what that string says at all, but didn't like the solution for now
<Saviq> seb128, bug #1260728 to fix it long-term
<ubot5> bug 1260728 in Unity 8 "Indicators should send timestamps, not pre-formatted strings" [Medium,Triaged] https://launchpad.net/bugs/1260728
<seb128> Saviq, ok, thanks
<xnox> Saviq: right. I made my machine ssh accessible and my terminal on my ultrabook has gnome-terminal with the following shell set $ ssh -X mydesktop.IP
<seb128> Saviq, that's different from the messaging menu one, right?
<Saviq> seb128, yeah, that's fixed in u8 trunk
<seb128> cool
<Saviq> seb128, and released already, btw
<seb128> Saviq, good to read ;-)
 * seb128 didn't keep up with what was going on this week, just too much stuff changing ;-)
<Saviq> seb128, yeah, but it's a good problem to be had :)
<seb128> indeed
<dednick> larsu: howdy. Do you know why are all the messaging menu items "not sensitive"
<Saviq> mpt, hey, q: looking at https://wiki.ubuntu.com/TimeAndDate, there are settings for the clock on the desktop, but not on phone - is that on purpose? would kind-of mean that you can change those when your phone is docked, and it should affect your phone, but you don't get to change those settings on the phone?
<Saviq> mpt, or the other way - you can change it on the desktop, but that doesn't affect your phone clock?
<Saviq> mpt, also, those settings are *only* meant to affect the indicator? no way for users to select 24h clock under British English, for example?
<Saviq> globally, that is
<Saviq> mpt, it'd be pretty weird if you ask me, if you chose your clock to be 24h, but it would only affect the indicator and not the rest of the system...
<Saviq> mhr3, for https://code.launchpad.net/~mhr3/unity-scopes-shell/json-defaults/+merge/198591
<Saviq> mhr3, what I did in JavaScript, and was thinking you'd do as well, is work the other way - parse a JSON file with defaults, and update the values based on data coming from the scope
<Saviq> mhr3, your way involves adding lotsa code just to add a new key with a default for any component/template
<Saviq> marcusto_, hey, did you have a chance to look at http://json-schema.org/ ?
<Saviq> mhr3, oh, and on that note... should those defaults not be applied server-side?
<marcusto_> Saviq: hey, yeah I did, and it looks like this lib fits our needs quite well: http://avro.apache.org/docs/1.6.3/api/cpp/html/
<Saviq> marcusto_, oh, awesome
<marcusto_> Saviq: problem is, until I get something running I'm holding up the web guys on SSS
<Saviq> marcusto_, I'm not pushing - was just wondering if json-schema is still something we can plan for
<Saviq> marcusto_, hmm, avro has it's own schema does it?
<Saviq> mhr3, hmm did I answer your question about exposing raw json for dev-tool? if not - I'd *rather* not in the long run, since we'll have a side-channel for talking to the scope backend directly, could we not get it through there?
<marcusto_> Saviq: I've looked at this briefly, but it looks like standard schema. Its def on the todo list
<Saviq> marcusto_, it doesn't seem to mention any relation to json-schema.org
<Saviq> marcusto_, and looking briefly it does differ slightly (that's not to say it's worse, or bad, for that matter)
<Saviq> marcusto_, but it definitely seems less standardized
<Saviq> if something that's non-standardized can be even less standardized...
<marcusto_> Saviq: hmmm, ok, clearly I have not thought about this enough :p
<Saviq> marcusto_, ;)
<Saviq> marcusto_, no worries
<marcusto_> Saviq: yeah, resources are few
<Saviq> marcusto_, we're not blocked on it, it's only a it-would-be-nice-to-have-when-possible type of situation ;)
<Saviq> marcusto_, but no worries, we have plenty to do regardless
<marcusto_> Saviq: well we are planning on schema validation, just a matter of time
<Saviq> marcusto_, yup, great
<mpt> Saviq, itâs somewhat on purpose, because there is much more screen real estate for variations on the PC.
<mpt> Saviq, but I havenât thought through what happens when you dock a phone.
<mhr3> Saviq, i'm not sure what side-channel you mean
<mhr3> Saviq, ultimately it's just exposing it to qml, i don't see any harm in that
<mpt> Saviq, I talked about having a locale-independent 24-hour option on Tuesday with â¦ with you, actually.
<Saviq> mpt, yeah, that's why I'm asking - 'cause there isn't a setting for it :)
<Saviq> mhr3, the one that will let us "upload" a modified JSON string for a category
<mhr3> Saviq, that will be internal to the shell, it won't talk to the scope
<Saviq> mhr3, otp, back in 0.5h or so
<mhr3> Saviq, right, let's hangout afterwards
<Saviq> mhr3, https://code.launchpad.net/~mhr3/unity-scopes-shell/json-defaults/+merge/198591/comments/461511 in the mean time
<mhr3> thx
<mpt> Saviq, I think the overall setting would go in âLanguage & Textâ (along with settings for decimal places, thousand separators, etc), but with a cross-reference from âTime & Dateâ.
<Saviq> mpt, yup, sounds good
<Saviq> mpt, if you didn't see me saying yesterday, MeeGo I think got it right, by allowing you to select:
<Saviq> language, format-locale, and 12 vs. 24hr clock
<Saviq> format-locale including number format, currency format etc.
<Saviq> mpt, feels like a well-balanced solution
<larsu> dednick: no, I don't. When did that start?
<tsdgeos> dandrader: can you read http://bazaar.launchpad.net/~aacid/unity8/verticalJournal/revision/596 and see if it gives you enough info on what it is supposed to do?
<dandrader> tsdgeos, sure
<tsdgeos> dandrader: it gives it to me, but i know what it's supposed to do so i don't obviously count :D
<nic-doffay> Saviq, I haven't gotten around to testing the branch yet.
<nic-doffay> What was wrong with it?
<Saviq> nic-doffay, it doesn't actually package the file
<dandrader> tsdgeos, "The number of rules is calculated[...]" <- number of *rules*?
<tsdgeos> lol
<tsdgeos> rows
<dandrader> tsdgeos, columns?
<tsdgeos> that
 * tsdgeos slaps himself
<dandrader> hehehe
<tsdgeos> dandrader: ok r597 fixes the typo and adds a bit more of info
<dandrader> tsdgeos, also, why is the documentation in the class instead of in the header?
<dandrader> s/class/cpp
<tsdgeos> dandrader: because it''s what e had for listviewwithpageheader.cpp
<tsdgeos> but yeah it's weird
<tsdgeos> also lvwph.cpp is more about internal
<tsdgeos> and the first part of this is more about external
<tsdgeos> maybe i can split this one into two?
<tsdgeos> so "The implementation is centered around m_columnVisibleItems" and after is on the .cpp and the rest in the .h?
<dandrader> yeah, in the .h I would say "what it is" and in the .cpp I would put the comments about "how it's done"
<dednick> larsu: no idea. I just added enable item by sensitivity and it stopped responding to clicks.
<tsdgeos> dandrader: splitted
<tsdgeos> Saviq: mzanetti: greyback: standup?
<Saviq> tsdgeos, otp again
<greyback> tsdgeos: same for me
<Cimi> mzanetti, notes
<larsu> dednick: is the service reporting disabled actions? Or is it something in qmenumodel?
<dednick> larsu: looks like it's in qmenumodel. the can_activate is false for the menu item actions.
<dednick> larsu: because action_target is null, but parameter_type is not.
<dednick> larsu: same old story
<dednick> !
<larsu> dednick: ah right. Didn't we fix this back when we first found it?
<larsu> apparently not :)
<dednick> larsu: i thought so :)
<dednick> larsu: been fixed in a few places
<larsu> dednick: I'll make the service put a target on there, that will be easiest
<larsu> because we want to keep the logic for "normal" menu items
<codebrainz> hi. is there a way to have a program added to a blacklist or something to opt-out of the GTK+ menu stealing thing?
<codebrainz> the global menu or libdbusmenu or whatever it's called
<tsdgeos> yes there is
<tsdgeos> at least there's an envvar
<tsdgeos> but i don't remember it :D
<tsdgeos> <--- not useful
<codebrainz> yeah, that's what we tell all the bug reporters, but it'd be cool to opt out at the distro level
<tsdgeos> Saviq: obviously all the runs wiht more logs are now passing :D
<codebrainz> to avoid the continuous stream of bug reports about our main menu, which isn't really our main menu :)
<Saviq> tsdgeos, hit it again!
<tsdgeos> i am
<tsdgeos> re-running only the qmluitests instead of the whole thing
<tsdgeos> for faster turnaround
<Saviq> tsdgeos, yup
<codebrainz> maybe on ubuntu we could install a script along with the binary and have the script clear UBUNTU_MENUPROXY before calling the real binary?
<Saviq> codebrainz, is there a reason for this particular app to opt-out from globalmenu?
<codebrainz> Saviq, tons of bug reports to our project not caused by our project
<Saviq> codebrainz, caused by the global menu integration?
<codebrainz> yes
<Saviq> codebrainz, can you forward the bugs to the project that causes them, so that it's fixed instead of disabling it?
<codebrainz> we do, but quite frankly it's super annoying and not very cool to mess with an app that others have to support :)
<codebrainz> none of our devs use unity, we only test/support normal GTK+
<tsdgeos> Saviq: yeah the code is not really awesome, for example in kate if you do "Alt" it shows the menu but then if you press the accelerator (i.e. Alt+F) you get the F written in the text area instead of popping-up the file menu
<tsdgeos> i fixed that already last year
<tsdgeos> and somehow it broke again
<tsdgeos> not cool :D
<tsdgeos> and last year is was less busy than now
<tsdgeos> that helped finding a time to fix it
<Saviq> codebrainz, dunno, don't see that as a reason to disable it, rather a reason to make it more obvious to people reporting bugs against the upstream project that they should report it against ubuntu instead
<codebrainz> Saviq, that's highly optimistic
<codebrainz> I wonder if we could put the main menu bar inside another GtkBox to break the heuristics used to steal the menu from the window?
<Saviq> codebrainz, who does the packaging for ubuntu, btw, and - what's the project, btw?
<tsdgeos> codebrainz: i guess the "easiest" for you is setting that envvar as the first thing in your main.cpp?
<tsdgeos> if you really really really really want to disable it
<codebrainz> I'm not sure setting the envvar from main() would do it, would it?
<codebrainz> Saviq, the app is Geany
<codebrainz> hyperair is the packager AFAIK
<tsdgeos> codebrainz: i'd say it would, but not sure tbh
<codebrainz> tsdgeos, it might, if set before gtk_init() actually
<Saviq> codebrainz, I dunno, if people use the apport to report bugs on ubuntu, they will get to the ubuntu project first
<codebrainz> they use our bug tracker
<codebrainz> some do anyway
<Saviq> codebrainz, I really don't feel like that's the right solution to the problem
<Saviq> codebrainz, feels short-sighted
<codebrainz> Saviq, stealing the menu from an app with a hack, is *definitively* not the right solution :)
<Saviq> codebrainz, yeah, I know Ubuntu/Unity/Canonical is evil
<Saviq> that's established
<codebrainz> no no, I rather like Ubuntu, I use Xubuntu myself
<codebrainz> I just hate this hack because it does something evil
<Saviq> codebrainz, it's a design decision, and at that time it was the only way to apply it
<Saviq> codebrainz, with gtk2 it still is, afaik, and with gtk3 is better, iirc?
<codebrainz> I can only hope it is
<codebrainz> we don't have full/proper gtk3 support yet
<Saviq> codebrainz, I think it's basically a first-class concept that the menu is exported
<Saviq> codebrainz, to support MacOS, for example
<mhr3> Saviq, got time for the hangout?
<Saviq> mhr3, right, forgot to ping you
<Saviq> mhr3, sure
<mhr3> let's do it then
<codebrainz> Saviq, the gtk3 way seems OK, but the dbusmenu hack thing is just plain wrong IMO
<Saviq> codebrainz, again, only way to apply the design decision that was made
<Saviq> codebrainz, we'd have done it otherwise if was possible
<Saviq> and we did, with gtk3, with qt etc.
<codebrainz> Saviq, just because you did it the only way possible doesn't make it any cooler :)
<Saviq> codebrainz, sure it does, because *we did it* ;)
<Saviq> codebrainz, instead of saying it's impossible
<codebrainz> Saviq, it was impossible to do it right, hence all the bug reports :)
<tsdgeos> E_NOT_CONSTRUCTIVE_DISCUSSION
<seb128> codebrainz, it's working pretty well, there is like 10 apps that are known to not be working correctly and they are mostly doing weird stuff
<codebrainz> our app doesn't do "weird" stuff, but it does load stuff dynamically into the menus
<seb128> codebrainz, what app are we talking about?
<codebrainz> I wonder is there a way we could detect the UI changes taking place with a widget signal and pop up a one-time dialog warning the user what is happening and where to report bugs?
<codebrainz> seb128, geany
<seb128> codebrainz, ok, we have https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/1072109 about that it seems
<ubot5> Ubuntu bug 1072109 in indicator-appmenu (Ubuntu) "appmenu shows wrong content" [Undecided,Confirmed]
<codebrainz> seb128, there's more than that (especially on our tracker)
<larsu> dednick: that should fix it: https://code.launchpad.net/~larsu/indicator-messages/set-targets/+merge/198957
<dednick> larsu: cool. will give it a quick test
<seb128> codebrainz, you should open a bug with the specific, and maybe talk to "attente" in #ubuntu-desktop to see if he can help you to get those fixed (if not there is a blacklist, he can add geany to it)
<codebrainz> seb128, it's hard enough to support own bugs though, we can't be proxying all of appmenu's bugs because it proxies our menu :)
<codebrainz> but if the gtk3 way is less crazy, I could try and convince the team to start supporting that :)
<seb128> codebrainz, well, the gtk3 way works with less crazyness/hacks yes
<codebrainz> hmmm, maybe we could put a dialog message on our "Report a Bug" help menu item if ubuntu is detected, asking them to use ubuntu's builtin bug reporter?
<seb128> codebrainz, with traditional menus we need to do hacks to export parse the menus/export them, where gtk3 gmenus does it by itself
<nic-doffay> Saviq, do I specifically need to install the override in autopilot install or is adding the path sufficient?
<dednick> larsu: cheers, worked.
<larsu> dednick: cool
<codebrainz> seb128, yeah I remember looking at the code last year when I submitted a patch to fix an issue on one of the bugs (which AFAIK still hasn't been applied)
<seb128> codebrainz, do you have a link to the patch?
<codebrainz> i can probably find it, one sec
<codebrainz> https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/907635
<ubot5> Ubuntu bug 907635 in DBus Menu "lidbusmenu-GTK crash with Geany IDE using Python" [Undecided,Expired]
<codebrainz> (the patch just fixes a harmless GTK-critical message, but it's still useful to avoid console spam, if it still applies)
<codebrainz> well, it's harmless as long as the program isn't run without assertions :)
<seb128> codebrainz, oh, the bug has expired (and it's usually better to file merge proposal) ... in any case we don't use libdbusmenu anymore for the appmenu stuff (only in some specific cases and we are cleaning those out)
<codebrainz> seems like users' bug reports showing the console output still shows this critical warning
<codebrainz> (often for unrelated bugs)
<seb128> they might still run the lts?
<codebrainz> it's possible
<dednick> Saviq: do we still need to deal with seeds for phone for unity8 dependencies, or is it sorted by the deps?
<seb128> tedg, do you think you could review the null check patch on this bug ^
<seb128> tedg, https://launchpadlibrarian.net/91512767/libdbusmenu-null-submenu.patch
<dednick> Saviq: oh, i think we only needed seeds if there wasn't a dep right?
<tedg> seb128, Sure, can you give me the bug number?  (can't seem to get back to there)
<tedg> Ah, I see.
<seb128> tedg, 907635
<codebrainz> for rationale, see: https://developer.gnome.org/gtk3/stable/GtkMenuItem.html#gtk-menu-item-set-submenu
<Saviq> dednick, yeah, debian/control is the way to go
<Saviq> dednick, it's like: nothing else would depend on unity8, so ubuntu-phone seed depends on it
<Saviq> dednick, but for anything else, standard deps are good
<didrocks> Saviq: we still have 2 flacky unity8 tests I guess
<didrocks> http://ci.ubuntu.com/smokeng/trusty/touch/maguro/64:20131213.1:20131211.2/5443/unity8-autopilot/
<dednick> Saviq: cool
<codebrainz> seb128, here's the latest bug, not sure it'll get reported to the proper place: https://sourceforge.net/p/geany/bugs/1013/
<codebrainz> it's parsing underscores in filenames as mnemonics
<Saviq> nic-doffay, how is dpkg supposed to know where to install that file?
<nic-doffay> Saviq, what's the purpose of this? usr/lib/python*/*/unity*
<nic-doffay> Saviq, I don't know enough about how all this fits in the bigger picture to properly tackle this.
<nic-doffay> It's that simple really.
<seb128> codebrainz, could you open a bug about that on https://launchpad.net/ubuntu/+source/unity-gtk-module/+filebug ?
<alesage> hi I'm getting a ./build error on "Could not determine plugin installation dir.", can someone suggest a remedy? http://paste.ubuntu.com/6567242/
<Saviq> alesage, ./build -s
<alesage> Saviq, thx
<Saviq> alesage, you don't have new libunity-api-dev installed
<Saviq> alesage, or ./build -c, for that matter
<alesage> Saviq, ok will investigate
<codebrainz> seb128, hopefully the bug reporter will
<seb128> codebrainz, you could also do it if you want to help your users... ;-)
<codebrainz> I don't remember my launchpad login, that patch I submitted was likely the first/last time I used it :)
<codebrainz> I can try though, and just link to the source forge bug
<codebrainz> (I'm not affected as I use xfce panel)
<seb128> codebrainz, I've pinged the maintainer in #ubuntu-desktop, I'm sure a bug would still be useful though
<codebrainz> seb128, can you tell me what email address is associated with my account?
<codebrainz> it won't show me unless I'm logged in
<codebrainz> (I have like 50 email addresses)
<seb128> codebrainz, @geany.org
<Saviq> nic-doffay, http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install
<codebrainz> seb128, thanks
<seb128> codebrainz, yw
<Saviq> nic-doffay, so you need:
<Saviq> data/unity8.override usr/share/upstart/sessions
<Saviq> or so
<nic-doffay> Saviq, yeah that's what the manual seems to say, ta.
<codebrainz> seb128, what project/component would that bug go against?
<codebrainz> appmenu-gtk?
<seb128> codebrainz, could you open a bug about that on https://launchpad.net/ubuntu/+source/unity-gtk-module/+filebug ?
<codebrainz> heh, sorry, i missed that the first time :)
<codebrainz> seb128, https://bugs.launchpad.net/ubuntu/+source/unity-gtk-module/+bug/1260777
<ubot5> Ubuntu bug 1260777 in unity-gtk-module (Ubuntu) "Underscores parsed as mnemonics in menu items" [Undecided,New]
<codebrainz> heh
<codebrainz> thanks bot
<seb128> codebrainz, thanks
<codebrainz> np, it actually sounds like an unsolvable issue
<Cimi> people don't like my branch? https://code.launchpad.net/~cimi/unity8/searchIndicator-swipe/+merge/198258
<seb128> codebrainz, why?
<codebrainz> seb128, how could the module know whether an item happened to be created by the constructor that parses mnemonics?
<codebrainz> I don't think it can tell, and it can't assume all menu items were
<codebrainz> unless there is a flag/property on the menu items or something, not sure
<seb128> codebrainz, I don't know that code well, but I think those stuff were working with libdbusmenu, so it should be doable
<seb128> codebrainz, let's trust the guys working on that code and see what they come with ;-)
<codebrainz> ah yeah, there is: https://developer.gnome.org/gtk3/stable/GtkMenuItem.html#GtkMenuItem--use-underline
<codebrainz> so it's totally doable
<Saviq> nic-doffay, I *think* you need absolute path in the .install file there
<Saviq> or, didrocks, can you look at the .install file change in https://code.launchpad.net/~nicolas-doffay/unity8/upstart-kill-fix/+merge/198931
<Saviq> nic-doffay, ah it's still missing data/unity8.override in the .install file
<Saviq> didrocks, unping
<nic-doffay> Saviq, just pushed it now.
<nic-doffay> I was wondering about an abs path though, but we'll see.
<Saviq> nic-doffay, relative is correct
<Saviq> nic-doffay, see debian/unity8.install
<dednick> Cimi: fixed review comments
<seb128> codebrainz, I guess you commented on the wrong bug (https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/1260779)?
<ubot5> Ubuntu bug 1260779 in libdbusmenu (Ubuntu) "Test issues in trusty (g_source_remove invalid use warnings), fails to build" [High,Confirmed]
<codebrainz> seb128, totally, I had too many bugs open
<codebrainz> can i delete it?
<seb128> codebrainz, no, but don't worry about it (or just post a new comment saying "sorry, wrong bug")
<Cimi> Saviq, my first qt bug report <3 https://bugreports.qt-project.org/browse/QTBUG-35608
<Saviq> Cimi, ;)
<Saviq> Cimi, file another one that it's not easily customizable
<Saviq> Cimi, separatet
<Saviq> -t
<Cimi> Saviq, ok
<Cimi> the voice "create issue" is fun
<Cimi> should be file bug imho :D
<Cimi> but let's create an issue :D
<Cimi> Saviq, but how would you address the latter?
<Cimi> Saviq, why would you want to change *all* values?
<Cimi> Saviq, if the default value is sane you don't want to customise it
<Cimi> Saviq, I'm waiting your input
<Cimi> well filed the second https://bugreports.qt-project.org/browse/QTBUG-35609
<Cimi> although I'm not 100% convinced if the first gets fixed
<Cimi> dednick, hey dude
<Cimi> dednick, the comment i wrote
<Cimi> dednick, I have qt 5.2
<Cimi> I believe it's thrown because of the new JS engine
<dednick> Cimi: hm. give me a sec
<Cimi> dednick, or let's do this next week :P
<Cimi> dednick,             tryCompare(function() { signalSpyDismiss.count > 0; }, true);
<Cimi> :-\
<dednick> Cimi: no return maybe...
 * Cimi tries
<dednick> but succeeds for me, which is a bit odd
<Cimi> dednick, no luck for me
<Cimi> dednick, which qt?
<dednick> 5.0.2
<Cimi> dednick, I'm on 5.2
<Cimi> dednick, as said, they changed Js
<dednick> yeah, but still... it's the same in other places
<Cimi> dunno then
<Cimi> let me rebase
<dednick> Cimi: does 'make testSimpleTextMessageMenu' work?
<Cimi> dednick, dismiss fails here
<Cimi> FAIL!  : qmltestrunner::SimpleTextMessageMenu::test_dismiss() A value is required for tryCompare
<Cimi>    Loc: [/home/cimi/Development/usc/visual-updates/tests/qmltests/Menus/tst_SimpleTextMessageMenu.qml(170)]
<Cimi> mzanetti, you should be eod - in case you aren't, any idea on fixing tryCompare with qt 5.2? ^
<dednick> Cimi: i think there may have been checks for 5.2 in unity8 which i dont have in usc
<Cimi> dednick, that's why I asked mzanetti
<mzanetti> hmmm...
<mzanetti> can you paste me the line that fails?
<mzanetti> Cimi: ^
<Cimi> mzanetti,  tryCompare(function() { signalSpyDismiss.count > 0; }, true);
<mzanetti> Cimi: I don't think this works with 5.0 either
<Cimi> or             tryCompare(function() { return signalSpyDismiss.count > 0; }, true);
<Cimi> mzanetti, they both fail
<mzanetti> Cimi: with 5.0 too?
<Cimi> mzanetti, not with 5.0
<Cimi> mzanetti, dednick said it's working for him
<dednick> Cimi: eh...
<mzanetti> Cimi: yeah. what I'm saying is that this is wrong
<mzanetti> and I don't think the test was actually working
<dednick> Cimi: it's supposed to be tryCompareFunction
<mzanetti> yeah
<Cimi> dednick, so why was not failing for you?
<dednick> no idea
<mzanetti> but tryCompareFunction is something we have in UnityTestCase only
<mzanetti> so you'd need to copy that (or upstream into the SDK ideally)
<dednick> mzanetti: yeah, i already have it i think
<Cimi> dednick, with function works here
<Cimi> dednick, but next to fail is
<Cimi> compare(signalSpyTriggered.count > 0, true, "should have been triggered");
<Cimi> which is false here
<dednick> Cimi: yeah, looks like the tests were just bombing on mine, i get that as well.
<dednick> now
<Cimi> dednick, ok no problem, let me know when you fix them
<Cimi> don't worry for today
<sil2100> charles: hi! I saw that you put up a branch for fixing the 24/etc in indicator-datetime - it seems to be still failing on CI
<sil2100> charles: can you take a look what's up?
<charles> sil2100, yes I'm looking at it right now
<charles> sil2100: looks like the unit tests are failing because it doesn't have locales configured s.t. we can test in a 12h and 24h locale
<charles> sil2100: I'm currently adding hooks to debian/ for this
<sil2100> charles: ah, makes sense - thanks for taking care of this!
<dednick> Cimi: fixed and pushed
<xnox> Saviq: if you are around, can you please do a quick review of https://code.launchpad.net/~xnox/unity-action-api/fix-cross/+merge/198847 ?
 * greyback eow
<mhr3_> same
 * mhr3_ out
<Saviq> xnox, hey, so no need to tweak the Qt .cmake modules in the end?
<kdub> Saviq, would know where I could find QDBusConnectionPrivate
<Saviq> kdub, ESYNTAXERROR
<kdub> okay  :)
<Saviq> kdub, lookin'
<xnox> Saviq: what do you mean? =)
<xnox> Saviq: cmake modules are all correct and installed into multiarch paths.
<Saviq> xnox, but I meant to actually find moc and such
<xnox> Saviq: automoc works correctly out of the box, i fixed that in cmake.
<Saviq> xnox, ah, awesome
<xnox> Saviq: same with rcc & qmake, but custom utils are need to be handled by hand.
<xnox> Saviq: i think the cmake modules should provide standard FOO_EXECUTABLE for all qt tools, e.g. qdoc, dbuscpp, etc.
<Saviq> kdub, https://qt.gitorious.org/qt/qt/source/33a34960328cce7a6994d2ea771c82da7bfdb598:src/dbus/qdbusconnection.cpp#L67
<kdub> thanks Saviq!
<Saviq> xnox, you mean that's the current state after your recent cmake upload or that's the desired state?
<xnox> Saviq: rcc/qmake/moc - work out of the box; other tools to be defined by default is a desirable.
<sil2100> bregma: hello! I noticed a FTBFS for lp:unity trunk in daily-build - did you guys see that?
<xnox> (but low priority, upstream should start exposing those)
<Saviq> xnox, ok cool, q: you said "dpkg-architecture -aarmhf -c cmake .." should cross-build locally, doesn't seem to work here?
<Saviq> xnox, i.e. I still get a build for amd64
<xnox> Saviq: well, that works out of the box, if there are cross-dependencies and cross-compilers installed locally.
<xnox> and all the libfoo-dev:armhf packages
<Saviq> xnox, ok, /me goes apt-get build-dep -aarmhf unity8
<xnox> in practice not many libfoo-dev are multiarch:same, thus one would need to remove & install to change arches.
<xnox> Saviq: and that implies to did dpkg --add-foreign-arch armhf & added arch qualified sources in /etc/apt/sources.list
<xnox> and ports archive
<Saviq> xnox, aah right, haven't done that yet apparently
<xnox> yeah, that's what mk-sbuild --target armhf does in a chroot =)
<xnox> so dpkg-architecture -aarmhf cmake ../
<xnox> is intended to be run inside a suitable chroot =)
<xnox> or e.g. under click chroot.
<Saviq> xnox, yeah, what I'm thinking about now is to transition ./run_on_device to cross-build in a chroot and rsync the results to the device and run from there
<xnox> (well click chroots export vars set by dpkg-architecture -aarmhf already, so actually, it's just cmake ../ under those)
<Saviq> xnox, instead of building on the device
<xnox> Saviq: well sbuild --host armhf, should cross-build local dir and spit out ../*_armhf.deb
<xnox> (without specifying path to .dsc, it should work with building unpacked debian package tree, which unity8 folder is)
<Saviq> xnox, yeah, I know, but that's still too long for quickly iterating during development
<Saviq> xnox, and requires a writable device
<Saviq> xnox, which we shouldn't need for unity8-only dev
<xnox> .... dude, that cross-compiles.
<xnox> bzr branch lp:unity8; cd unity8; sbuild -A -d trusty --host armhf; adb push ../*_armhf.deb /userdata/
<xnox> oh, right
<xnox> Saviq: but you can $ dpkg-deb -R *.deb unpack/
<xnox> to unpack them
<xnox> without installing in a home dir.
<Saviq> xnox, sure, that I can do
<xnox> and exectue them, or like make an override in the upstart job to run a custom one
<Saviq> xnox, but still builds the whole thing every time
<Saviq> xnox, usually with installing deps first
<Saviq> xnox, unless you have a pre-made specific sbuild chroot
<Saviq> xnox, it just does more than we generally need for quick iterations
<xnox> e.g. $ echo "exec ~/bin/unity8" > ~/.config/upstart/unity8.override
<Saviq> xnox, no need
<xnox> Saviq: well full clean build here is 2m20s
<Saviq> xnox, yeah exactly
<Saviq> xnox, too long
<Saviq> xnox, we're talking about during-development-deployment
<xnox> Saviq: you can optimise, so for things that I do often i have $ mk-sbuild --target armhf --name unity8
<Saviq> xnox, yeah, I know
<xnox> pre-installing deps into that, I think you can bring the time lower.
<xnox> so i'm not sure what you are asking about?
<xnox> you want dirty builds?
<Saviq> xnox, I'm not *asking* about anything, really :D
<Saviq> xnox, yes
<xnox> while qt-dev is not co-installable?
<Saviq> xnox, no, permanently
<xnox> well, I could point cmake at /var/lib/schroot/unity8-amd64-armhf/* to link/compile against
<Saviq> xnox, I just don't want the overhead of building packages when all we're after is as-quick-as-possible possibly-dirty quick deployments onto device
<xnox> (such that we can re-use the same chroot, for dirty builds, without chrooting into it)
<xnox> (well pre-installed packages)
<Saviq> xnox, yeah, we might use the sbuild chroot indeeed
<Saviq> -e
<Saviq> xnox, even chrooting into it
<Saviq> xnox, but bind-mouting
<xnox> to be honest this calls out to simply prioritise making all -dev packages multiarch-same which unity8 depends on.
<xnox> i never use schroots like them.
<xnox> let me see how it can be used in bind-mounting mode.
<Saviq> xnox, no worries, unless you want to :)
<Saviq> xnox, I'm all-happy with what you enabled for us already
<xnox> hm i ponder how save it is to bind-mount /home/ into schroot.
<Saviq> xnox, I do it all the time
<xnox> so if the named chroot has all the right dependencies one should be able to do: schroot -c unity8-amd64-armhf "cmake .; make"
<Saviq> didrocks, seems indeed the retry helped on maguro, awesome
<Saviq> "Failed to unlock greeter, trying again..." yay
<didrocks> Saviq: yeahâ¦ but still flaky then :p
<Saviq> didrocks, well, not *really*
<Saviq> didrocks, it's just that we don't know when the device is not busy on startup any more
<Saviq> didrocks, to deliver the input in a timely manner
<Saviq> didrocks, aactually
<Saviq> didrocks, we should move to pressing the BFB
<didrocks> Saviq: actually, we start the test 5 minutes after the boot
<Saviq> didrocks, instead of swiping the greeter
<didrocks> so the device isn't busy
<Saviq> didrocks, but unity8 is starting
<Saviq> didrocks, being restarted with testability
<didrocks> ah yeah
<didrocks> yep on that one
<Saviq> didrocks, and loading dash and everything
<didrocks> need to either send an signal
<didrocks> to be more reliable
<didrocks> or use qmltestrunner (shhh) ;)
<Saviq> didrocks, we don't want to open a "ok, signal me and I'll unlock" security hole ;)
<Saviq> didrocks, qmltestrunner might not really help in that case
<Saviq> didrocks, what would help would be having control of the time
<Saviq> didrocks, so with each input movement you'd tell QML how much time passed
<Saviq> didrocks, so it's never jerky in that sense, which it is now, 'cause input just doesn't get timely to the gesture recognizer, which rejects it if it's not smooth enough
<Saviq> didrocks, but yeah, maybe we should move to the BFB - but still would need to swipe the launcher in, so not *really* more reliable
<didrocks> Saviq: totally make sense, should be more reliable
<didrocks> or
<didrocks> hum
<didrocks> we are not really testing unlocking the greeter
<Saviq> didrocks, yeah, that's tested regardless
<didrocks> should be one test
<didrocks> maybe for the other
<didrocks> we should ship a flag/a way only with this AP test
<didrocks> to get the greeter always unlocked?
<Saviq> didrocks, what you called out as flaky in your email... must not have included the latest release of unity8: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/64:20131213.1:20131211.2/5443/unity8-autopilot/570019/
<Saviq> didrocks, there would have to be a "greeter unlocked, continuing" message, or two "failed to unlock greeter"
<didrocks> Saviq: well, the result if flaky
<didrocks> like, I rerun the test, it pass
<Saviq> didrocks, even with the latest unity8?
<didrocks> yeah, this is with latest
<Saviq> didrocks, the log suggests it's not :/
<didrocks> Saviq: http://people.canonical.com/~ogra/touch-image-stats/20131213.1.changes
<didrocks> image 64
<Saviq> didrocks, I need camera on the devices then :/, I'm done guessing
<didrocks> Saviq: I think the CI team has one
<Saviq> didrocks, yeah, sorry for bothering you
<Saviq> didrocks, go have your weekend
<didrocks> well, trying to promote the image first :)
<Saviq> didrocks, ah, those tests don't use the helpers
<didrocks> ahah!
<didrocks> :)
<Saviq> didrocks, where the retrying is done
<Saviq> didrocks, will have to fix that
<didrocks> see, everything has an explanation!
<didrocks> :)
<didrocks> Saviq: great ;)
#ubuntu-unity 2013-12-15
<jalcine> Hey so what window manager does Ubuntu Unity use?
<jalcine> Like KDE uses KWin as its window manager.
<jalcine> Would Compiz be Ubuntu's? (I remembered seeing somewhere that it's been dropped)
<bregma> jalcine, Unity _is_ the window manager
<bregma> compiz is a part of the underlying technology stack, and will continue to be on the upcoming Ubuntu 14.04 LTS release
<jalcine> bregma: thanks. Probably a definite "yes", but Unity exposes some means of control over windows over D-Bus? I'm working on a little project but I only run KDE/KWin at the moment so just interested in keeping DE-parity
#ubuntu-unity 2014-12-08
<willcooke> morning all
<seb128> Saviq, don't blame it on proposed migration, that's not an issue there, if bits moved separatly and shouldn't have then your depends/conflicts/... are buggy, if you have components that need to go together the packaging should enforce that
<seb128> pstolowski, ^
<pstolowski> seb128, yeah, agreed...
<Saviq> seb128, sorry, didn't mean to blame, was cause instead
<Saviq> let me clarify
<seb128> Saviq, no worry, but thanks
<Cimi> can we retrigger https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524?
<Saviq> Cimi, trying
<Saviq> Cimi, nope, CI still down
<pstolowski> Saviq, is tsdgeos off today?
<Saviq> pstolowski, yes
<Saviq> pstolowski, back tomorow
<pstolowski> ok
<mzanetti> Cimi: biw, if both sides of == are real ints, there's absolutely no difference between == and ===
<Cimi> mzanetti, wasn't === always skipping the conversion?
<mzanetti> Cimi: yeah, but if you compare "property int x" to 5, there isn't any conversion ongoing anyways
<mzanetti> Cimi: it's different if you compare "property int x" to "5", e.g. when the "5" comes as a string from a textfield
<Cimi> mzanetti, yes but === is better no?
<mzanetti> not really :D
<Cimi> I would use == only when needed
<Cimi> otherwise ===
<mzanetti> it's the same, and when it's not the same you gotta know which one you want, there isn't a better or a worse one :D
<mzanetti> Cimi: anyways... I changed it in that branch and added a test as you requested
<Cimi> mzanetti, hoping ci will run...
<mzanetti> yep
<Saviq> Cimi, no it won't, CI is down still
<mzanetti> Cimi: one last small thing in here, then I'll approve: https://code.launchpad.net/~cimi/unity8/fix-1368778-2/+merge/242942
<Saviq> greyback_, what's your zsh theme? couldn't find it in oh-my-zsh
<Saviq> mzanetti, I'll add to the silo then
<mzanetti> Saviq: cimi's branch?
<Cimi> mzanetti, ok
<Saviq> mzanetti, yeah
<mzanetti> ack
<Saviq> Cimi, please let me know when it's ready
<greyback_> Saviq: am using slightly tweaked https://gist.github.com/agnoster/3712874
<Cimi> Saviq, well, change will be just in the test so...
<Cimi> Saviq, if you want to do it now or wait 10 mins
<Cimi> :)
<Saviq> Cimi, still, I need to wait for the code to be in LP before building the silo
<Saviq> greyback_, hmm thought it would be that, the |> bit looks like a bad character :?
<greyback_> Saviq: did you do the powerline font hack?
<Saviq> greyback_, did not
<greyback_> that's it, it patches your font to add the extra characters needed
<Saviq> now where do I change my fonts..
<Saviq> greyback_, that worked, thanks
<greyback_> Saviq: np, hope you like it
<Saviq> greyback_, still getting used to zsh, but a few things (like wd) are just awesome
<greyback_> yeah
<greyback_> tab completion a bit buggy for me still
<Cimi> Saviq, mzanetti done
<mzanetti> approved
<Saviq> greyback_, yeah, could definitely use more of that
<greyback_> Saviq: hey, bug 1394645 is fixed in trunk in revision 1436. Can you add it to list of things to be backported?
<ubot5`> bug 1394645 in The Webapps-core project "OSK doesn't appear after OA login" [Critical,Confirmed] https://launchpad.net/bugs/1394645
<Saviq> greyback_, right, good catch
<Saviq> mzanetti, what's the plan to enable desktop mode by default on desktops?
<mzanetti> Saviq: we didn't agree on anything tbh
<mzanetti> well, conclusion was that it would be great to set the dconf key on login
<mzanetti> but that's not working in dconf yet
<mzanetti> and there seems to be confusion about whether it'll land or not soon
<Saviq> mzanetti, can you file a bug ainst unity8 (Ubuntu) then so we can track progress?
<mzanetti> yeah... can do
<mzanetti> Saviq: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400312
<ubot5`> Launchpad bug 1400312 in unity8 (Ubuntu) "On desktop, windowed mode should be by default" [Undecided,New]
<Saviq> mzanetti, tx
<seb128> Saviq, mzanetti, easy step 1 would be to set the key in "ubuntu-settings"
<seb128> until we get per-session defaults
<seb128> that would let desktop installs have it set easily
<Saviq> seb128, sure, please comment on the bug
<seb128> Saviq, I did (just before commenting here)
<mzanetti> ok.
<seb128> Saviq, mzanetti, I can land that change if you want
<mzanetti> works for me
<seb128> k
<balloons> mzanetti, any eta on when this will land?
<balloons> 79+14.10.20141007-0ubuntu1
<balloons> <swordfish90> [07:25:13] gcollura, same here... 1.1.1279+14.10.201
<balloons> sorry; https://code.launchpad.net/~mzanetti/unity8/desktop-stage/+merge/242140
<dandrader> paulliu, would you have some spare time to review https://code.launchpad.net/~dandrader/unity8/properInSceneDialogs/+merge/243998 ?
<dandrader> mterry, goot morning. Updated the greeterRefactoring branch and replied to all your questions
<dandrader> s/goot/good
<mterry> dandrader, oh awesome, will look
<dandrader> mterry, made it Showable again :)
<mterry> dandrader, I didn't mean to be down on some of your refactors, I just wasn't clear on why some changes were made (and have a vested interest in less churn in that component ahead of my own refactor  ;))
<paulliu> dandrader: sure. WIll do it after stand-up.
<dandrader> paulliu, thanks!
<dandrader> dednick, hey. these indicator profiles. what values are supported and where are they defined?
<dednick> dandrader: hm. not sure they're specifically defined anywhere. tedg?
<dednick> dandrader: can take a look at the values in the indicator files. /usr/share/unity/indicators
 * dandrader checks...
<dednick> dandrader: /usr/share/unity/indicators/com.canonical.indicator.network is probably the most exhaustively defined.
<tedg> We've been a bit ad hoc there.
<dandrader> dednick, so the profiles are the values between [ and ]? like phone, phone_greeter, ubiquity, etc?
<dednick> dandrader: yup
<tedg> We really only have [phone|desktop][_greeter]?
<tedg> Ah, and ubiquity.
<dandrader> tedg, I don't know. you tell me :)
<tedg> I would but you left! ;-)
<tedg> dandrader, So I guess the question for me is, what is the list useful for?
<tedg> Are you trying to make an enum?
<tedg> Or do we need to ensure a list is in all hte indicators?
<mzanetti> balloons: in a silo already
<mzanetti> balloons: depending on how testing goes, between today and wednesday
<dandrader> tedg, I'm coming up with a device configuration thingy for unity8 which I'm thinking could also contain that indicator profile name instead of having unity8 fetching it from a UNITY_INDICATOR_PROFILE env var
<dandrader> tedg, to consolidate those device-specific (or form-factor specific, "usage scenario"-spefic) things in a single place
<tedg> dandrader, Cool, make sure to base your branch on mterry's greeter branch as I know he changes some of that logic for the greeter modes as well.
<dandrader> tedg, do you know who sets this UNITY_INDICATOR_PROFILE env var?
<dandrader> dednick? ^
<tedg> dandrader, So I think we can be flexible to what naming makes sense for you. I'd rather be consistent with the names than use the ones we have.
<tedg> dandrader, I imagine that's ubuntu-touch-session today
<mterry> dandrader, that branch is https://code.launchpad.net/~mterry/unity8/greeter-profiles/+merge/237155
<dednick> dandrader: this in a config file somewhere, or command line?
<dednick> dandrader: the indicator-client takes a -profile commandline option
<balloons> mzanetti, ack. I'll follow the silo ty
<dednick> dandrader: but i'm presuming the env var intention was for upstart config to set it.
<tedg> dandrader, For instance, if you get away from the phone/desktop naming (which I know that Saviq is passionate about) I'd like that reflected in the indicator profile names.
<mterry> dandrader, looking at your branch again; it's super annoying that qml doesn't have virtual methods that can be overridden
<dandrader> mterry, it's a javascript trait I guess
<dandrader> dednick, I think this UNITY_INDICATOR_PROFILE env var is not being set or used currently
<dandrader> dednick, couldn't find it mentioned anywhere in /etc or /usr and it's also not in the phone's env
<greyback_> dandrader: they're set in the upstart conf
<dandrader> greyback_, where exactly? which file in the device filesystem?
<dandrader> greyback_, grep could not find anything, as I said ....
<dandrader> greyback_, and env command also doens't show it. unity8 defaults to "phone" is that env var is not present. I guess this is what has been happening
<dandrader> s/if that/if that
<greyback_> dandrader: it's not used on phone, but on desktop
<dandrader> ahhhh
<greyback_> UNITY_INDICATOR_PROFILE=desktop is set for unity8 on desktop, am looking to see what sets it
<greyback_> my mistake, isn't set in upstart conf
<dandrader> greyback_, couldn't find any mention of it in my desktop either...
<greyback_> dandrader: /usr/bin/lightdm-unity8-session
<dandrader> greyback_, don't have that file. what package adds it?
<greyback_> dandrader: unity8-desktop-session-mir
<dandrader> greyback_, got it. so that's likely the only use of it anywhere I guess
<greyback_> yeah
<dandrader> dednick, Is qml/Panel/Indicators/client/IndicatorsClient.qml dead code?
<dandrader> dednick, ah, it's loaded by src/Panel/Indicators/client/indicatorsclient.cpp. nevermind
<dednick> dandrader: ok.
<dednick> dandrader: and the UNITY_INDICATOR_PROFILE env var is for overriding the default "phone" profile.
<dednick> dandrader: or rather. if the env var isn't set, it uses "phone"
<dandrader> dednick, yeah, saw that in main.cpp
<paulliu> dandrader|lunch: what's dialogLoader in ShellDialog.qml?
<paulliu> dandrader|lunch: I mean, line 291
<paulliu> dandrader|lunch: Do you need to set dialogLoader as a property?
<seb128> bah
<seb128> Saviq, bregma, after upgrading my vivid unity8 test machine, I can't run any application on unity8 anymore, is that a known issue?
<seb128> willcooke, ^ works for you?
<bregma> seb128, _any_ application?
<seb128> yeah
<willcooke> seb128, my installation is b0rked from playing with mlankhorsts ppa - so I'm a bad example
<seb128> bregma, I tried webbrowser, notes, system settings
<seb128> start with gedit/eog because I wanted to test gtk stuff
<seb128> then went back to try default ones
<seb128> the unity8 log has "Unable to get cmanager connection" errors
<seb128> and "Unable to get pids for unity8-dash to send signal 18"
<bregma> that's new
<seb128> is it working for you?
<bregma> I haven't updated since last week, it will take a while
<seb128> k
<seb128> let me know if you try
<seb128> http://paste.ubuntu.com/9428906/
<seb128> is my unity8.log
<bregma> ChrisTownsend, have you had trouble with the latest Unity 8 desktop?
<greyback_> "Unable to get pids for unity8-dash to send signal 18" - is nothing to worry about really
<seb128> k, so maybe something else
<greyback_> we need to quieten that
<greyback_> "Unable to get cmanager connection" - that's something I've not seen before
<greyback_> seb128: ^
<greyback_> qtmir.applications: ApplicationManager::onProcessFailed - appId= "webbrowser-app" duringStartup= true
<greyback_> webbrowser crashed?
<seb128> I don't think so
<ChrisTownsend> bregma: No, it seems to work...and this includes the latest Xmir stuff.
<seb128> I click on any icon, see a rectangle start sliding from the right for less than a second and then it closes
<seb128> ChrisTownsend, what unity8 version do you have?
<ChrisTownsend> seb128: 8.01+15.04.20141205-0ubuntu1
<ChrisTownsend> seb128: Seems the cgroups are not right and ubuntu-app-launch is rejecting the app.
<greyback_> seb128: can you launch "QT_QPA_PLATFORM=ubuntumirclient messaging-app  --desktop_file_hint=/usr/share/applications/messaging-app.desktop"
<greyback_> asuming it's installed
<ChrisTownsend> seb128: What version of cgmanager are you running?  I have 0.33-2.
<seb128> ChrisTownsend, greyback_, Saviq, bregma, ignore that, my fault for switching to systemd as init, seems there is something not working correctly with unity8 (or cgmanager)
<bregma> ah, systemd
<ChrisTownsend> seb128: ack:)
<greyback_> seb128: ah yeah, tha'll do it.
<seb128> do we have a bug open for that?
<seb128> if not I'm going to open one, we plan to switch this cycle and that should work
<willcooke> seb128, perhaps unrelated.  I just upgraded my u8 machine and now the option to use u8 is gone from the greeter
<seb128> willcooke, yeah, unrelated
<seb128> willcooke, is unity8-desktop-session-mir still installed for you?
<willcooke> seb128, seems not.  Tried apt-get install unity8 and bad things:
<willcooke> The following packages have unmet dependencies.
<willcooke>  unity8 : Depends: qtdeclarative5-ubuntu-web-plugin but it is not installable
<willcooke>           Depends: ubuntu-system-settings but it is not going to be installed
<willcooke>           Depends: unity8-common (= 8.01+15.04.20141205-0ubuntu1) but it is not going to be installed
<willcooke>           Recommends: unity-scope-click but it is not going to be installed
<willcooke> E: Unable to correct problems, you have held broken packages.
<willcooke> probably because I'm using proposed
<seb128> willcooke, those are fun
<seb128> willcooke, yeah
<willcooke> :)
<seb128> willcooke, usual way is to append things it lists on the install command, until it gives you a real error
<willcooke> I'll give it a go
<seb128> like "apt-get install unity8 unity8-common qtdeclarative5-ubuntu-web-plugin ubuntu-system-settings"
<seb128> and keep going if it gives you other similar errors
<willcooke> bingo:
<willcooke> qtdeclarative5-ubuntu-web-plugin
<seb128> when it gets bored, apt give you a real reason :p
<willcooke> has no installation candidate
<seb128> that's weird, "apt-cache policy qtdeclarative5-ubuntu-web-plugin" ?
<willcooke> qtdeclarative5-ubuntu-web-plugin:
<willcooke>   Installed: (none)
<willcooke>   Candidate: (none)
<willcooke>   Version table:
<willcooke>      0.23+15.04.20141202.1-0ubuntu1 0
<willcooke>         100 /var/lib/dpkg/status
<willcooke> seb128, ^
<seb128> willcooke, do you have a vivid source enable? or did you replace it by proposed?
<seb128> willcooke, proposed is not a full archive it's an overlay
<seb128> it contains only some packages
<willcooke> I replaced everything with -proposed
<seb128> you need a vivid source
<seb128> yeah, that's your issue
<willcooke> seb128, gotya
<willcooke> thx
<seb128> yw
<seb128> greyback_, bregma, just for the record, opened bug #1400394
<ubot5`> bug 1400394 in systemd (Ubuntu) "Unity8 fails to start applications under systemd init (cgmanager issue?)" [Undecided,New] https://launchpad.net/bugs/1400394
<greyback_> seb128: ack
<willcooke> seb128, kinda fixed - in that I can now at least select a U8 session from the greeter and u-s-c looks like its started, but no desktop
<willcooke> seb128, I'll worry about this tomorrow, I've got other things to be getting on with#
<seb128> willcooke, k, if you want/can share your .cache/upstart/unity8(-dash).log
<seb128> greyback_, just saw your comment, systemd being used for init doesn't prevent upstart to work/be used in the session, user session keeps working fine
<greyback_> seb128: ah fair point
<seb128> greyback_, are you sure the issue is ubuntu-app-launch?
<greyback_> hadn't thought of that
<seb128> that seems an orthogonal issue to me
<greyback_> seb128: well I assumed we were only using 1 init system :)
<seb128> we need to make ual use systemd, but it should work with upstart meanwhile
<seb128> we are
<seb128> upstart is used as a job manager for the session, not as an init :p
<seb128> but yeah, I see what you mean ;-)
<greyback_> you could call it a session init :)
<greyback_> but yeah, I'm wrong
<greyback_> feel free to correct me in the bug so
<seb128> just did so
<seb128> thanks
<greyback_> thank you
<dandrader> paulliu, replied in the MP
<elopio> ping Saviq, or somebody else: is there a way to start the edge demo on demand?
<elopio> I want to initctl start unity8, and then start the edge demo on that window.
<dandrader> mterry, all fixed.
<mterry> dandrader, ok looking!
<Saviq> elopio, there's a gsetting
<Saviq> elopio, phablet-config enables it
<elopio> Saviq: thanks. Will try that.
<Saviq> elopio, actually, not a gsetting, accountsservice property
<elopio> yes, looking at it.
<mterry> dandrader, looks good code wise!  will just test around with it and should be good
<mterry> dandrader, we should "tease" on a drag start too -- last time we talked with design they wanted that, I believe because a new user may accidentally do a baby drag and not understand what's going on or what would happen if they finished the drag
<mterry> dandrader, and I'm seeing a local failure in TabletShell::test_leftEdgeDrag
<dandrader> mterry, is it possible to manually reproduce "TabletShell::test_leftEdgeDrag(with demo)" ?
<dandrader> mterry, I mean, with "make tryTabletShell"
<mterry> oh let me try
<mterry> dandrader, you can but you have to futz with the AccountsService mock to have it show the demo by default.  But I see the problem.
<mterry> dandrader, swipeFromLeftEdge starts the drag at x=2
<dandrader> mterry, it's not. would have to add a button for "AccountsService.demoEdges = true" below the "Show greeter" one
<mterry> dandrader, if you make that larger, it works
<dandrader> mterry, ahhh, right
<mterry> dandrader, looks like there's a dead zone on the left (for the launcher?)
<mterry> dandrader, yeah that button would help for sure
<dandrader> mterry, I added a margin on the left for the Greeter DragHandle so that it doesn't overlap with the Launcher one
<dandrader> mterry, so, is it a valid use case to swipe the greeter from he left edge with the demo running?
<dandrader> mterry, ie, with launcher disabled
<mterry> dandrader, yes, that's what the first page of the edge demo asks the user to do (swipe the greeter away)
<mterry> dandrader, i mean
<mterry> dandrader, it asks from the right edge
<dandrader> mterry, the first page asks for a right edge swipe
<dandrader> mterry, exactly
<mterry> dandrader, I haven't confirmed with Design if they care about allowing a left edge swipe in that case.  But we always have allowed it there
<dandrader> mterry, so, should I make a "right edge swipe with demo on" instead?
<mterry> dandrader, I suppose we should at least capture that...  But left edge is also good to test.  I think we just used the left edge tests as stand-ins for both edges
<mterry> dandrader, but if we only have one, maybe you're right that it's better to test right edge
<dandrader> mterry, the left *edge* belongs to the launcher
<mterry> dandrader, well fine...  the test captures swiping right from the left
<mterry> That's a matter of the test name
<mterry> That's why it starts at x=2, because it's specifically *not* testing the left edge, but "from the left"
<mterry> oh wait
<mterry> maybe it is testing the left edge
<mterry> and is meant to be a launcher drag
 * mterry looks at tests closer
 * dandrader checks what happens in trunk
<mterry> dandrader, yeah.  that test is specifically for doing launcher drags
<mterry> dandrader, it has a comment about "to give time to handle dash() signal from Launcher"
<mterry> I don't know why they picked x=2 then instead of x=0.  But I guess they were always equivalent
<mterry> dandrader, so for some reason in your branch, the launcher is disabled in that situation
<dandrader> mterry, just tested with trunk
<mterry> ok, what does it do?
<dandrader> mterry, you can do a drag from the left *edge* with demo on and there will be no launcher
<dandrader> mterry, and there's no such use case I think
<mterry> dandrader, oh right because in demo mode we disactivate launcher when we aren't demo-ing it
<mterry> dandrader, what do you mean no use case?  It caught the fact that your branch has a dead zone on the left, which it shouldn't have
<dandrader> mterry, being able to dismiss the greeter with a left egde drag when the demo is asking the user to dismiss the greeter with a right edge drag
<mterry> dandrader, that doesn't bug me, but that's a question for design.  That's how trunk and rtm work right now.  I'd rather make that a separate/intentional change, than a by-product of a refactor.  I personally think it's better to have the greeter act like it would normally (i.e. allow the rightward drag)
<dandrader> mterry, ok, I will make it work again
<mterry> dandrader, Design is actually dropping that tutorial screen anyway
<mterry> dandrader, the next version of the tutorial doens't have it anyway
<mterry> I wonder if they are done with that yet
<dandrader> mterry, fixed.
<mterry> Does anybody else occasionally get "/home/mike/Work/code/unity8/greeter-refactor/builddir/tests/mocks/Unity/Indicators/libIndicatorsFakeQml.so: undefined symbol: _ZN14UnityMenuModel12setModelDataERK8QVariant" when running ./run.sh -f?
<mterry> I feel like I'm building wrong, but it stays even after a fresh build
<josharenson> Trying to xcompile unity8, whats the deal with libconnectivity-qt1-dev ?
<Saviq> josharenson, what about it? /me tries
<josharenson> saviq, fails when installing
<Saviq> josharenson, looks like there's a bad dep chain there :/
<josharenson> saviq, any remedy to that?
<Saviq> josharenson, let me try one thing
<Saviq> josharenson, doesn't look like it, it's a bigger issue
<josharenson> :-/
<josharenson> ok
<Saviq> josharenson, fwiw, bug #1400502
<ubot5`> bug 1400502 in connectivity-api (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [Undecided,New] https://launchpad.net/bugs/1400502
<josharenson> thanks
<josharenson> There is no way to connect to dbus with qml?
<greyback> josharenson: the primary way we do it is to write a small qml plugin in C++, which is a thin wrapper over the Qt dbus api bits. The plugins directory has many of them, plugins/Unity/DashCommunicator is a nice one to get started with
<josharenson> greyback, thats exactly what I'm doing, just didn't want to unintentionally overengineer
<josharenson> thanks
<greyback> np
#ubuntu-unity 2014-12-09
<lpotter> josharenson: there is a declarative plugin: https://github.com/nemomobile/nemo-qml-plugin-dbus
<josharenson> lpotter, thanks I'll take a look. Don't want to add too much bloat just to handle my single special case :-)
<tsdgeos> Cimi: what's missing for top approval of https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 ?
<tsdgeos> our CI is still down, right
<tsdgeos> ?
<Cimi> tsdgeos, ye
<tsdgeos> is the store scope empty for you guys too?
<Saviq> tsdgeos, remove U1 account, add it back
<tsdgeos> USC just crashed :S
<Saviq> tsdgeos, yeah, it happened to me a few times, too
<tsdgeos> Saviq: what's your opinion on https://code.launchpad.net/~aacid/unity8/fixHamburgerMenu/+merge/243371 ?
<Saviq> tsdgeos, I *think* it should be a dropdown, so same colors as the header
<tsdgeos> i think this is not what we had
<tsdgeos> but ok
<Saviq> tsdgeos, it's not because no one considered it
<Saviq> tsdgeos, I'd have just assumed that if I set the background and foreground of the header, it would do the right thing
<Saviq> unless I override it that is
<mzanetti> Saviq: hey.
<Saviq> mzanetti, oi!
<mzanetti> Saviq: testing the silo on the phone yesterday revealed that hamburger thing
<mzanetti> Saviq: but also it crashes constantly
<mzanetti> and randomly
<Saviq> mzanetti, it's usc that crashes, is it?
<Saviq> tsdgeos, mzanetti, I'd hope for bug 1400449 to be fixed in that silo too
<ubot5`> bug 1400449 in qtdeclarative-opensource-src (Ubuntu) "qmltestrunner crashed with SIGABRT during unity8 tests" [High,Triaged] https://launchpad.net/bugs/1400449
<mzanetti> haven't found any culprit but in like 20 mins the shell went away like 5 times at least
<tsdgeos> mzanetti: what's in /var/crash ?
<Saviq> mzanetti, I think it's usc, not the shell
<mzanetti> might be
<mzanetti> Saviq: yeah, its usc
<mzanetti> according to var/crash
<tsdgeos> Saviq: can't parse the sentence, you mean you're expecting me to come up with a workaround for that crash before landing the silo?
<tsdgeos> or that the workaound is already there?
<Saviq> tsdgeos, I'd like that, yes, as this somehow got introduced by the new bottom edge landing
<tsdgeos> Saviq: ok, let me try to find out what was wrong with https://code.launchpad.net/~aacid/unity8/deparment_jumping/+merge/243639 and i'll do that next
<Saviq> tsdgeos, tx
<tsdgeos> Saviq: can you reproduce on desktop or only phone?
<Saviq> tsdgeos, the test? it's a qml test, on desktop
<tsdgeos> ok
<Saviq> testDash
<tsdgeos> sure, but i meant if it crashes on the desktop too
<tsdgeos> but yeah, there's a x86 there so yes :D
 * Saviq not really here, recovering
<tsdgeos> mzanetti: ping
<facundobatista> Hola!
<mzanetti> tsdgeos: hey
<tsdgeos> mzanetti: not sure i understand your comment in https://code.launchpad.net/~aacid/unity8/deparment_jumping/+merge/243639
<mzanetti> tsdgeos: I'll try again... but last time I applied this patch, when I opened the store I could only see apps from the Music department
<tsdgeos> mzanetti: where you in the music deparment in the apps scope?
<mzanetti> tsdgeos: apps scope
<tsdgeos> mzanetti: yes, apps scope, but where you in the music department or in the all department?
<mzanetti> tsdgeos: it said "All" iirc, when I clicked on the departments dropdown, it only had "All" and "Music" in there
<tsdgeos> mzanetti: you're not answerin my question :D
<mzanetti> I guess I don't understand it then
<tsdgeos> mzanetti: when you clicked in the store icon, you where in the apps scope, in which department?
<mzanetti> "All"
<tsdgeos> ok
<tsdgeos> i don't see how that could happen tbh
<mzanetti> atm the store doesn't show anything any more here :/
<mzanetti> with deel-proposed
<mzanetti> probably OA broken again
<tsdgeos> mzanetti: anyway if you're going to check bug is fixed you should get the two branches i linked this morning too
<tsdgeos> mzanetti: yes, remove your UbuntuOne
<mzanetti> *again*
<pstolowski> tsdgeos, ping
<tsdgeos> pstolowski: hi
<pstolowski> tsdgeos, hey, can you take a look at the problem from the comment for https://code.launchpad.net/~aacid/unity8/deparment_jumping/+merge/243639
<tsdgeos> i already have
<tsdgeos> and i need mzanetti to look at it again
<tsdgeos> i can't reproduce what he says
<mzanetti> tsdgeos: hmmm...
<mzanetti> I think I've fallen for the actual bug when I tried it
<tsdgeos> maybe
<mzanetti> it only does that when you're going to a department first and then open the store
<tsdgeos> you may want to try all the branches together and check it's fixed then :D
<mzanetti> yep
<pstolowski> tsdgeos, mzanetti btw we have this fix in silo 10 (i'm just rebuilding it atm to pick yesterday's landing o Manage Dash)
<mzanetti> ah nice
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/fix_testDash/+merge/244114
<tsdgeos> pstolowski: ping
<pstolowski> tsdgeos, pong
<mzanetti> Saviq: why is bump_manange_dash in silo3 and silo4?
<tsdgeos> pstolowski: can you add  lp:~aacid/unity8/fix_testDash  to that rtm manage dash?
<tsdgeos> and someone review it :D
<tsdgeos> pstolowski: we don't want to merge stuff that make test fail to rtm
<mzanetti> tsdgeos: is this only to be appled to rtm?
<mzanetti> that fix_testDash
<tsdgeos> mzanetti: no, to trunk too
<mzanetti> k
<mzanetti> reviewing it
<tsdgeos> tx
<pstolowski> tsdgeos, url of the MP pls?
<tsdgeos> pstolowski: https://code.launchpad.net/~aacid/unity8/fix_testDash/+merge/244114
<pstolowski> tsdgeos, we need separate MP for rtm. let's land it in vivid first and then cherry pick
<tsdgeos> pstolowski: i'm just saying, that i think (maybe wrong) i saw a branch where you were planning to land the other stuff of the manage dash, maybe wait until we can land with this?
<pstolowski> tsdgeos, Ill add it to our landing of departments fix, ok?
<pstolowski> tsdgeos, yes. i've just added a row to the spreadsheet, it will wait
<tsdgeos> ok :)
<pstolowski> Saviq, ok if we land unity8 version bump together with our stuff in #42?
<mzanetti> tsdgeos: approved. is this meant to go into the current silo?
<mzanetti> pstolowski: what's the ETA on that silo?
<mzanetti> pstolowski: because we already have it in a silo
<Wellark> Saviq: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1382033/comments/5
<ubot5> Launchpad bug 1382033 in indicator-network (Ubuntu) "[SIM PIN] 'Incorrect PIN' warning is not cleared from display for SIM2 PIN entry" [High,Triaged]
<mzanetti> Wellark: he's not around today. can I help?
<pstolowski> mzanetti, today? i'm also ok to pull it from my silo if you're going to land yours today?
<Wellark> mzanetti: no action needed. just followed up on that bug
<Wellark> but thanks :)
<mzanetti> pstolowski: hmm... Unless something goes wrong I guess we could land it soon, yes
<mzanetti> pstolowski: I'm also ok with pulling it out of our silo... we just need to coordinate
<pstolowski> mzanetti, np. i'm pulling it from mine, thanks
<pstolowski> mzanetti, you are not landing the corresponding branch of unity-shell-plugin, do you?
<mzanetti> pstolowski: hmm, no. the branch didn't list any related branches. is that required to land together?
<pstolowski> mzanetti, it's not. that's fine, i'll keep it in our silo then
<mzanetti> ok
<pstolowski> mzanetti, the fix_testDash MP can go in our silo?
<mzanetti> that was the question I had for tsdgeos
<mzanetti> still finding out
<pstolowski> mzanetti, feel free to move it to yours.. i guess that's needed to fix test failure
<mzanetti> I think so, yes
<mzanetti> will know in a bit
<pstolowski> mzanetti, what is your silo #?
<mzanetti> pstolowski: 3
<pstolowski> thx
<dandrader> greyback, it should be good to go now: https://code.launchpad.net/~dandrader/qtmir/supportedOrientations/+merge/242213
<greyback> dandrader: ack
<greyback> dandrader: would you please merge qtmir trunk? It merges cleanly now, but just to reduce likelihood of later conflicts.
<dandrader> greyback, done
<greyback> ta
<tsdgeos> mzanetti: pstolowski: i guess sure it can go in there, why not
<greyback> anyone having sbuild failing with python dependency errors?
<tsdgeos> there's a branch
<tsdgeos> with some gi stuff
<tsdgeos> greyback: https://code.launchpad.net/~dobey/unity8/fix-ap-deps/+merge/244036
<tsdgeos> not sure if that help
<tsdgeos> s
<greyback> tsdgeos: sadly not, was trying to build unity-api
<tsdgeos> ah _D
<Saviq> tsdgeos, tx
<Saviq> mzanetti, prolly because pstolowski|lunch put it there
<mzanetti> Saviq: yeah, problem solved by now
<Saviq> mzanetti, ok
<mzanetti> Saviq: so we have that testDash fix in there silo now too
<mzanetti> tsdgeos: Saviq: whats the thing with the hamburger menu font?
<tsdgeos> mzanetti: whats with it?
<Saviq> mzanetti, yup, thanks
<mzanetti> tsdgeos: should we land this as is and fix the font in another branch? or do you have a fix for it in the queue?
<tsdgeos> mzanetti: does the font need fixing?
<tsdgeos> ah
<tsdgeos> you mean the color
<tsdgeos> sorry
<mterry> dandrader, what's the problem with tst_MultiGreeter?  I couldn't gather from your MP comment.  You should be able to drag away a multi-greeter as long as the currently selected user isn't locked
<dandrader> ah, ok
<dandrader> mterry, didn't know that
<greyback> dednick: hey, what's the status of https://code.launchpad.net/~nick-dedekind/qtmir/1355173.trust-prompt-suspend/+merge/242211
<dednick> greyback: waiting mir approval
<greyback> dednick: ok
<greyback> dandrader: one little comment on https://code.launchpad.net/~dandrader/qtmir/notests/+merge/244139
<dandrader> greyback, ah! so -DCMAKE_INSTALL_PREFIX:PATH=/usr is indeed needed!
<greyback> yep
<dandrader> greyback, I recall you guys saying it wasn't
<dandrader> maybe you were talking about qmake
<greyback> for qmake it isn't. but cmake it is
<greyback> -DCMAKE_INSTALL_PREFIX=/usr is what I use
 * greyback not sure what that ":PATH" is for
<dandrader> mterry, fixed tst_MultiGreeter
<Saviq> pstolowski|lunch, note there is a unity8 rtm silo under testing right now
<Saviq> heh
<Saviq> pstolowski, FWIW, we generally prepare a MP similar to https://code.launchpad.net/~unity-team/unity8/rtm-14.09-staging/+merge/243829, reusing the rtm-14.09-staging branch
<pstolowski> Saviq, are you going to land Manage Dash then?
<Saviq> pstolowski, well, we need to land it together
<pstolowski> Saviq, exactly.. that's where I was heading ;)
<tsdgeos> mzanetti: which scope has background and hamburger menu so i can see the problem?
<Saviq> pstolowski, and I was just showing what we usually do, I can help prepare the unity8/rtm MP
<mzanetti> tsdgeos: weather
<Saviq> pstolowski, but we need to wait for http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-008 to land first
<Saviq> pstolowski, and ideally http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-003 too, so that we include the fix_testDash MP
<mzanetti> tsdgeos: only when not favorited
<tsdgeos> mzanetti: right
<Saviq> tsdgeos, we do have skip() in qml tests ya know ;)
<tsdgeos> right :D
<tsdgeos> let me change it
<pstolowski> Saviq, yes pls (about preparing unity8-rtm); we can wait for other silos. I'll prepare rtm MP for unity-api (which doesn't have rtm branch yet)
<tsdgeos> Saviq: pstolowski: updated ~aacid/unity8/fix_testDash to use skip() instead of return
<Saviq> mzanetti, â you might wanna rebuild silo 3...
<mzanetti> Saviq: waiting for the font color fix
<Saviq> mzanetti, right, that too
<Saviq> coolz
<mzanetti> Saviq: what about usc?
<mzanetti> just ignore those crashes?
<mzanetti> I broke the dash :D
<Saviq> mzanetti, they're not related to the silo that's for sure
<Saviq> oops errors.ubuntu.com down
<mzanetti> Saviq: try this: unfavorite all scopes, do the bottom swipe, click the app icon in the upper right corner
<mterry> dandrader, interesting about having to select the "no-password" user -- I agree that should be there, but curious why it never triggered before.  you didn't add new tests to that file or change names...  I would expect order to be the same.  Note that there is the same test in SingleGreeter which could use the same fix, though it doesn't bite you yet
<Saviq> tsdgeos, huh, were you even supposed to be able to unfavourite applications?
<tsdgeos> Saviq: yes
<tsdgeos> it's not special at all anymore
<Saviq> mzanetti, I've a blank dash, can't do bottom swipe at all
<mterry> dandrader, Maybe before the is-locked logic was handled in the onTease handler, rather than when emitting the signal.  That's why it didn't matter before
<mterry> ?
<Saviq> sounds like a bug
<mzanetti> Saviq: after tapping that icon in the bottom edge list?
<dandrader> mterry, I wish we could use a single mock lib for the greeter instead of having multiple qml tests
<dandrader> mterry, just to be able to link against a different mock lib
<mzanetti> Saviq: I could still bottom swipe on the empty dash, but after tappig that icon it crashed and doesn't recover any more on reboot
<pstolowski> ouch
<dandrader> mterry, maybe. to be honest I didn't investigate the why
<mterry> dandrader, that could be done...  would involve changing number of users on the fly, but that could be possible
<dandrader> mterry, because in the shellRotation branch, for intance, I'm testing phone, N7 and N10 in the samle qml tests
<dandrader> *same
<Saviq> mzanetti, ah, I can bottom swipe once after unfavoriting all
<Saviq> pstolowski, looks like it might have to wait before getting into rtm â
 * mzanetti thinks we should probably require at least one favorite scope
<mterry> dandrader, sure, that's size though.  these tests are split due to different user models provided by our fake lightdm.  But even so, they could be unified into some featureful-fake-lightdm
 * Saviq not sure if you should be allowed to exit Manage Dash after having unfavorited all, or â that
<Saviq> not allow to unfavourite the last one
<mzanetti> yeah
<dandrader> mterry, because some function helpers and even tests apply to different form factors, I mean, usage scenarios :)
<tsdgeos> Saviq: mzanetti: will you open a bug about it?
<mzanetti> applause for dandrader :)
<Saviq> tsdgeos, doing
<mterry> dandrader, agreed!
<mzanetti> dandrader: are you resizing the screen in the test?
<mzanetti> heh... even reflashing doesn't make it recover. need to wipe or manually fix it
<dandrader> mzanetti, I'm not resizing the QQuickWindow in the test, I'm unloading OrientedShell.qml and loading it again with a different size
<mzanetti> right... yeah
<dandrader> and configuration options
<mzanetti> ack
<mzanetti> we need to get tst_Shell towards that too
<pstolowski> Saviq, yeah.. sound like we need to block unfavoriting in the plugin
<mzanetti> atm it heavily relies on the phone stuff
<dandrader> mzanetti, there's a drop box there to select make, manta or flo
<dandrader> *mako
<Saviq> pstolowski, actually not sure that's the level on which this should be done
<Saviq> pstolowski, it'd be good enough if we just remained on the Manage page if there are no favorites
<Saviq> mzanetti, can't get it to crash though
<pstolowski> Saviq, makes sense, but i think backend needs a safeguard too
<mzanetti> Saviq: me neither atm... I guess that was usc giving up here
<Saviq> pstolowski, well, that depends, if we allow an empty favorites list, then we don't need a safeguard
<mterry> dandrader, where's jenkins for that branch?
<pstolowski> Saviq, but then you need to bring up Manage Dash on boot?
<Saviq> pstolowski, yup, that we'd need
<Saviq> pstolowski, it makes sense too
<Saviq> pstolowski, what if you remove your only favourite scope
<mzanetti> fair enough
<pstolowski> Saviq, true
<dandrader> mterry, it seems jenkins ir not running at all. it's not the only unity8 branch where jenkins results are absent...
<tsdgeos> mzanetti: i have fixed the color of the text, can you please re-review ? https://code.launchpad.net/~aacid/unity8/fixHamburgerMenu/+merge/243371
<mzanetti> tsdgeos: yep, thanks
<tsdgeos> greyback: seen the comment on your thread fix branch? i don't see any change
<greyback> tsdgeos: really? Huh, I musta screwed up. Sorry
<tsdgeos> greyback: i think at some point you may have wanted to remove the this from the new ()
<tsdgeos> but it's still there
<greyback> quite right
<tsdgeos> mzanetti: can you do https://code.launchpad.net/~aacid/unity8/bottom_list_store_no_favorites/+merge/244177 and https://code.launchpad.net/~aacid/unity8/bottom_list_no_favorites/+merge/244169
<mzanetti> tsdgeos: looking
<tsdgeos> mzanetti: cool :)
<mzanetti> tsdgeos: can you try remove all favorites and then reboot the phone?
<mzanetti> tsdgeos: I have a feeling the dash is not coming up without one favorite
<tsdgeos> mzanetti: define "coming up"
<mzanetti> stays at splash screen
<tsdgeos> usc is crashing
<tsdgeos> i'll try after that
<tsdgeos> or maybe just reboot
<mzanetti> it's not crashing. it just keeps on displaying the splash screen
<mzanetti> when I execute this: it appears a second later:
<mzanetti> gsettings set com.canonical.Unity.Dash favorite-scopes "['scope://clickscope']"
<mzanetti> those two branches seem ok
<mzanetti> although I guess we should automatically open the list when you unfavorite the last one and disable closing it until you have a new favorite set
<mzanetti> is there any design input what to do in this case?
<tsdgeos> mzanetti: loads fine here
<mzanetti> hmm... it did now here too
<tsdgeos> mzanetti: well there's https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400762
<ubot5> Launchpad bug 1400762 in unity8 (Ubuntu) "Manage Dash allows to unfavourite all scopes and leave you with a blank page" [Critical,Triaged]
<mzanetti> ack
<tsdgeos> mzanetti: no, there's no design input, i just fixed the obvious things
<tsdgeos> later if there's better ways to do stuff we can improve them i guess
<mzanetti> sure
<mterry> What do you folks do for developing on rtm?
<mterry> I can't build it anymore in vivid
<mterry> Needs old versions of unity-shell-launcher and unity-shell-scopes
<mterry> @unity ^
<mzanetti> mterry: hmm... tbh I didn't really need that so far. but I guess you could use a vm or an emulator if you can't downgrade those libs any more
<mzanetti> actually the x86 emulator might come in handy here
<kgunn> good news, i think pat is pushing for a mass resynch of vivid to rtm
<mterry> mzanetti, I thought the emulator was for running, not building it.  It does both?
 * mterry prepares a utopic VM
<mzanetti> mterry: hmm... well if its for building arm stuff, I still do that on the phone mostly
<mzanetti> but only compile the one plugin I need and copy it manually to the destination
<mterry> mzanetti, oh good point...  I could do that on my rtm device
<Saviq> mterry, it will be *slow*
<Saviq> mterry, you can just as well do a native (i.e. qemu-emulated) chroot
<Saviq> mterry, since you can't cross-build, I would actually recomend getting a chroot in $HOME on the device and build there
#ubuntu-unity 2014-12-10
<dangerranger11b> hey guys I cant find any help on this I am new to linux and am using the latest version of ubuntu. When I shut my lid and open it the lights on my keyboard light up but the screen wont turn on. It is a pavilion g6. I have read the forums but no real solutions can be found
<pstolowski> mzanetti, hey, do you plan to land https://code.launchpad.net/~aacid/unity8/bottom_list_no_favorites/+merge/244169 this with your existing silo?
<pstolowski> tsdgeos, ^
<tsdgeos> Saviq: how's the sickness today?
<Saviq> pstolowski, yes, that's what we were waiting for
<Saviq> tsdgeos, I'm around, not 100%, but am ok
<tsdgeos> Saviq: was thinking on https://code.launchpad.net/~seb128/unity8/set-inline-reply-hint/+merge/240766, do we want the pot regeneration to be included in it?
<pstolowski> Saviq, k, thanks. get well!
<Saviq> pstolowski, we still don't have a clear solution on bug #1400762 though
<ubot5> bug 1400762 in unity8 (Ubuntu) "Manage Dash allows to unfavourite all scopes and leave you with a blank page" [Critical,Triaged] https://launchpad.net/bugs/1400762
<Saviq> pstolowski, I'd like to wait for design guidance on it
<Saviq> tsdgeos, makes sense, yeah
<tsdgeos> waaaaaaaaaa
<tsdgeos> what's up with the wizard now
<tsdgeos> we won all it's messages, but will it work?
<Saviq> tsdgeos, ?
<Saviq> tsdgeos, ah
<tsdgeos> Saviq: http://paste.ubuntu.com/9454259/
<Saviq> tsdgeos, that'd be mterry's importing the wizard into our codebase (since we want to have it run as part of unity8 on first launch)
<Saviq> but it's not used yet
<Saviq> maybe we should make all the tr()s for the wizard use the settings' domain for now
<tsdgeos> Saviq: i don't think it makes sense, the messages will disappear from settings once they go away from the codebase
<Saviq> tsdgeos, right
<tsdgeos> Saviq: question is if i should propose a MR with the .po changes or tell seb to merge trunk in his and re-use it for that too?
<Saviq> tsdgeos, separate MP please
<tsdgeos> then it will conflict :D
<Saviq> let's put it in the silo we have now already
<Saviq> tsdgeos, we'll release that sooner
<tsdgeos> ok
<Saviq> tsdgeos, yeah, I know, we really need the train to do it, but apparently I don't have enough push to get that implemented :/
 * Saviq needs food
<tsdgeos> Saviq: there it goes https://code.launchpad.net/~aacid/unity8/make_pot_file/+merge/244267
<tsdgeos> dednick: ping on https://code.launchpad.net/~nick-dedekind/qmenumodel/lp1385331.led/+merge/241422 ?
<Saviq> tsdgeos, re: power on lock, this was the initial approach https://code.launchpad.net/~mterry/unity8/cache-greeter-bg/+merge/239144
<Saviq> tsdgeos, but it's contested because of the increased mem usage
<tsdgeos> aha
<dednick> tsdgeos: the ActionStateParser created in the constructor is qobject parented to the QDBusActionGroup.
<dednick> so it will be deleted
<Saviq> dednick, can you explain on bug #1372061 what needs to happen?
<ubot5> bug 1372061 in unity8 (Ubuntu) "SMS notification: time format not translatable" [High,In progress] https://launchpad.net/bugs/1372061
<tsdgeos> dednick: right, but wouldn't be my suggestion simpler?
<dednick> tsdgeos: urrg. not really. QStateAction uses the actionState method. Wont be able to override the actionStateParser unless i put a actionStateParser property in there...
<dednick> tsdgeos: i could give it a go...
<dednick> tsdgeos: it would be a bit neater though
<tsdgeos> dednick: who calls actionState ?
<dednick> tsdgeos: QStateAction in qmennumodel, ActionRootState & ModelActionRootState in unity8
<tsdgeos> dednick: i see, ok, maybe then just add a comment to setActionStateParser saying that the class does not take ownership of actionStateParser?
<dednick> tsdgeos: ok
<tsdgeos> qt5.4 is out \o/
<tsdgeos> dednick: you're probably the best to review https://code.launchpad.net/~paulliu/unity8/lp1378469_MessageMenu/+merge/244164 right?
<dednick> tsdgeos: ok
<Saviq> dednick, thanks
<facundobatista> Holas
<mzanetti> Wellark: ping
<Wellark> mzanetti: pong
<mzanetti> Wellark: so, what's the issue?
<mzanetti> and what's the status?
<Wellark> mzanetti: I have an MP that clears the errorAction status when the first pin unlock dialog is closed
<Wellark> but still
<Wellark> the second dialog picks up the error message from the first dialog (this might be because of the async nature of all of this communication)
<Wellark> and displayes the error message from the first dialog on the second one as well
<mzanetti> Wellark: what's the branch?
<Wellark> mzanetti: https://code.launchpad.net/~unity-api-team/indicator-network/lp1382033-14.09/+merge/244128
<Saviq> Wellark, bug #1400502 is getting annoying, think you could make something happen?
<ubot5> bug 1400502 in connectivity-api (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [Undecided,Confirmed] https://launchpad.net/bugs/1400502
<Wellark> Saviq: for some reason that has escaped my filters
<Wellark> python3-xdg:armhf not being installable
<Wellark> any idea what's behind that?
<Wellark> sounds like a root cause
<Saviq> Wellark, it's Arch :all
<Saviq> Wellark, so it would have to be python3-xdg:any maybe, but I'm not sure that's good to have in runtime depends
<Wellark> Saviq: I don't know where that dependency is coming
<Wellark> oh, right
<Wellark> from i-network
<Saviq> Wellark, yeah
<Wellark> but I don't know how that is not working
<Wellark> python3-xdg is a main package
<Wellark> anyway, I need to grab a quick lunch
<Saviq> Wellark, but it's :all, and :armhf is being requested
<Saviq> Wellark, so well, I agree this might be an apt dep resolution bug
<Wellark> Saviq: how would you suggest to fix this?
<Wellark> i-network only lists plain "python3-xdg" dep
<Saviq> Wellark, I think we talked about making i-networj a Recommends
<Saviq> if possible
<Saviq> otherwise this pulls in unity8 itself, even
<Wellark> yes, but the real issue seems to be python3-xdg not being installable
<Wellark> which is weiard
<Saviq> Wellark, you can emulate by trying to do "sudo apt-get build-dep -ai386 unity8"
<Wellark> so, having connectivity-api Recommends i-network would leave it uninstalled?
<Saviq> Wellark, yeah, I agree, you might wanna raise this with core devs
<Saviq> Wellark, yes
<Wellark> me? :)
<Wellark> I have not seen this issue :P
<Saviq> Wellark, fine, I will
<Wellark> Saviq: if the above line provides an easy repro, please add it to the bug report
<Wellark> so I can get back to this
<Wellark> Saviq: will change i-network as recommends then
<Saviq> Wellark, just added to bug
<Wellark> but now.. some lunch
<tsdgeos> mzanetti: i can randomly reproduce the fact that dash doesn't come up with no scopes
<tsdgeos> having a look
<mzanetti> tsdgeos: ah good. yeah, didn't happen 100% here either.
<mzanetti> tsdgeos: so the splash goes away when the app paints its first frame
<mzanetti> I think that's not happening in that case. the fact that you added the pull up thingie decreased chances of it happening, as that one comes in and causes the app to paint
<tsdgeos> well
<tsdgeos> but we should still have the gray background no?
<tsdgeos> otherwise it seems there's a race somewhere
<Saviq> tsdgeos, I think we know that issue
<Saviq> bug #1394208
<ubot5> bug 1394208 in qtmir (Ubuntu) "Unity8 unable to find the dash, which is also running in the background" [High,Triaged] https://launchpad.net/bugs/1394208
<Saviq> mzanetti, â
<Saviq> this happens sometimes when dash starts too early and AppMan misses its startup
<Saviq> Cimi, mzanetti, why the "autohideEnabled: false" prop?
<Saviq> in https://code.launchpad.net/~cimi/unity8/fix-1368778-2/+merge/242942 that is
<Saviq> tsdgeos, is it by design that Manage header text and icon is lighter than the default for scopes?
<Saviq> tsdgeos, also, what's happening with the header icons in the dash when opening Manage Â¿?
<Saviq> Cimi, tsdgeos, what's up with https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 btw?
 * Saviq logs in to unity8@desktop
<mzanetti> Wellark: ok... so seems that error text is coming in again when the second notification is created
<mzanetti> Wellark: UnityMenuAction triggers a stateChanged event with an error text
<Saviq> seb128, seems your override says lowercase "unity8", the setting is under title-cased "Unity8" though
<Cimi> Saviq, to disable autohide
<Cimi> Saviq, we will need autohide on desktop
<Cimi> Saviq, he asked me to keep the code and just disable it with a property
<Wellark> mzanetti: hmpf..
<Saviq> Cimi, we could hook it up to the unity7 setting already...
<Wellark> mzanetti: I'm trying to make sense of the dbus logs I got
<Wellark> to see if i-network is actually doing with the states
<Cimi> Saviq, well we want always off for now...
<Cimi> Saviq, let's hook it up later
<Saviq> Cimi, meh, ok
<Cimi> Saviq, and have this bug fixed
<Wellark> or is this just that the actiongroups are cached on unity8 side and something weird happens with the loader
<Cimi> Saviq, not sure which are defaults...
<mzanetti> Saviq: yeah, I'm gonna work on this as soon as I have mouse input available
<Saviq> Cimi, default is no hiding
<Wellark> mzanetti: would it still be possible to clear the error text immediately if unity8 gets errorAction.stateChanged signal that contains "" ?
<Saviq> but yeah, fine
<mzanetti> Wellark: yeah, but once you set some error it'll shake
<Saviq> mzanetti, is power indicator b0rked for you on unity8 desktop?
<mzanetti> Saviq: with the silo? or in general?
<mzanetti> need to test
<Saviq> mzanetti, in general
<mzanetti> Saviq: seems ok
<mzanetti> what's wrong?
<Saviq> mzanetti, has a 2GU correct background and black for the rest, here
<mzanetti> let me start the vm with the real session
<Saviq> mzanetti, yeah, it has to be the actual desktop session
<mzanetti> still good here
<Saviq> weird
<tsdgeos> Saviq: i'm waiting on Cimi on that one, no idea what's going on
<tsdgeos> Saviq: is it different color? it's using the same component
<tsdgeos> Saviq: not sure what you mean with the header icons
<tsdgeos> you're right is a different color
<Cimi> Saviq, tsdgeos did we get a silo for that?
<tsdgeos> Cimi: i don't know, yuo can still compile the code, no?
<Cimi> tsdgeos, sure but I have been told many times we were building a silo :)
<tsdgeos> Cimi: well then ask who told you, not me :)
<Cimi> tsdgeos, I did :P
<tsdgeos> Saviq: regarding the color, i can bind the root scope style to  the header, but it's still not coming down, so it'll still be a differnet color than applicaions that specifies a color
<tsdgeos> but i'll write a MR with it
<tsdgeos> so it can be changed if needed
<seb128> Saviq, sorry, I copied from the bug description
<seb128> Saviq, no bonus point to mzanetti if he wrote it wrong in the summary
<mzanetti> :D
<mzanetti> seb128: yep, true, my bad
<seb128> mzanetti, Saviq, so do I need to change it to Unity8?
<mzanetti> seb128: yes," gsettings set com.canonical.Unity8 usage-mode Windowed" would be the call
<mzanetti> let me verify :D
<seb128> mzanetti, k, need to redo an upload I guess
<seb128> when is the unity side going to land?
<mzanetti> seb128: Saviq is currently testing the silo
<greyback>  libconnectivity-qt1-dev:armhf : Depends: libconnectivity-qt1:armhf (= 0.0.1+14.10.20140826-0ubuntu1) but it is not going to be installed
<greyback> anyone see that when trying to sbuild unity8?
<pstolowski> Saviq, mzanetti what's your eta for landing of silo 3?
<tsdgeos> greyback: merge ?
<greyback> tsdgeos: I have
<tsdgeos> greyback: ok, i could build not much ago
<greyback> ok
 * greyback checks if he did a bad merge
<tsdgeos> greyback: any idea what logs UbuntuWindow::handleSurfaceResize  ?
<greyback> tsdgeos: qtubuntu
<tsdgeos> greyback: any quick guess on why sometimes unity8-dash would not get there? if not it's ok, i'm debugging it
<greyback> tsdgeos: so that is printed when shell resizes the surface on the app. Shell only resizes surface when it has been added to the qml scene, which happens only when the app  has drawn its first frame
<tsdgeos> greyback: can it happen that the app renders its first frame before the shell "is looking"?
<greyback> I don't understand "is looking" ?
<greyback> you mean, is it possible for app to render a frame and shell to not know about it?
<tsdgeos> yes
<tsdgeos> because it'd seem it's what i'm having
<greyback> that isn't possible, unless I screwed up somewhere
<greyback> to show you the relevant parts of the code, look at lp:qtmir in modules/Unity/Application/mirsurfaceitem.cpp
<greyback> there's a MirSurfaceObserver::frame_posted method in there - that is registered as a callback with Mir, and is called when the app has drawn its frame & swapped
<tsdgeos> oki
<tsdgeos> i'll dig a bit more around there
<tsdgeos> tx
<greyback> MirSurfaceManager::onSessionCreatedSurface creates the MirSurfaceItem, which should be called in a blocking manner by Mir also
<dandrader> tsdgeos, mind if I claim that review? https://code.launchpad.net/~mterry/unity8/power-button-on-lock/+merge/239076
<tsdgeos> dandrader: all yours
<Saviq> greyback, bug #1400502
<ubot5> bug 1400502 in connectivity-api (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [Undecided,Confirmed] https://launchpad.net/bugs/1400502
<Saviq> greyback_, bug #1400502
<ubot5> bug 1400502 in connectivity-api (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [Undecided,Confirmed] https://launchpad.net/bugs/1400502
<Saviq> greyback_, looks like i-network is missing Multi-Arch: foreign is the actual issue
<dandrader> Saviq, that build failure might be related to it I guess?  https://launchpadlibrarian.net/192260397/buildlog_ubuntu-vivid-armhf.unity8_8.02.4%2Bbzr1487~ubuntu15.04.1_FAILEDTOBUILD.txt.gz
<Saviq> dandrader, yes, same issue
<greyback_> Saviq: cool, thanks for finding it
<mterry> dandrader, removed tags  :-/
<Saviq> mterry, dude, where are you taking them from :D
<mterry> Saviq, I DON'T KNOW
<mterry> Saviq, they showed up in a remote branch that I only ever worked on locally in a checkout that didn't have any tags
 * mterry is paranoid now
<Mirv> I think people in general are paranoid on "where do those tags come from!? ghost tags, I say, ghost tags!"
<tsdgeos> greyback_: how do i build qtmir on the device? cmake && make don't seem to work
<Mirv> they just keep on coming back no matter how many times they're killed
<greyback_> tsdgeos: don't work - how?
<greyback_> is it crashing?
<tsdgeos> greyback_: http://paste.ubuntu.com/9460651/
<tsdgeos> i'm guessing i need some cmake option/Define/somethig
<tsdgeos> th README is old btw, mentions qmkae
<greyback_> tsdgeos: as if it's missing -lgl in the linker flags. Odd. I'll be honest, I've not built on device since we switched to cmake, it might be a bug
<greyback_> lemme try it here
<greyback_> also, might need  -DCMAKE_C_COMPILER=arm-linux-gnueabihf-gcc-4.9 -DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g++-4.9
<greyback_> to ensure it uses g++4.9 - not sure if that's relevant on vivid
<greyback_> tsdgeos: need to add " -DUSE_OPENGLES=1" to cmake command
<tsdgeos> greyback_: tx
<greyback_> that's annoying, need to autodetect that somehow
<tsdgeos> +1
<tsdgeos> a compile check should not be that hard, no?
<tsdgeos> LastFamousWords
 * tsdgeos runs
<dandrader> mterry, what do the qml/Greeter/Infographics.qml changes have to do with making loading async?
<mterry> dandrader, there was a race between the animation and objects being constructed async by qml
<mterry> Got some console warnings
<mterry> dandrader, the actual "make it asyn" change was relatively simple.  Most of those code changes are cleanup to handle objects being loaded async
<dandrader> ok
<dandrader> mterry, speaking about console warnings
<dandrader> mterry, I'm getting thousands of warnings in "make testMultiGreeter" like this one: file:///home/dandrader/unity8/power-button-on-lock/qml/Greeter/Infographics.qml:188: TypeError: Cannot read property of null
<dandrader> mterry, could you also fix this one in this MP? hopefully it's a one liner
<dandrader> mterry, although it's not strictly related to subject of this MP
<mterry> dandrader, will look
<mterry> dandrader, done
<dandrader> mterry, thanks!
<mterry> dandrader, huh!
<mterry> dandrader, doing that brought the tags back
<mterry> Oh!  I wonder if it's because I have a local repo, not just a branh
<dandrader> mterry, the tags must be in your local rope. did you run strip_tags on it?
<dandrader> rope/repo
<mterry> dandrader, not in my local branch, but I'm guessing they're hiding in the repo itself
<mterry> but the strip script doesn't handle repos
<dandrader> mterry, works for me
<dandrader> mterry, I do "~/unity8$ ./strip-tags.py power-button-on-lock"
<mterry> dandrader, are we talking about the same thing?  You created a shared repository using "bzr init-repo" that you store all your u8 branches in?
<dandrader> mterry, I've a unity8 dir from where I do "bzr branch lp:oo"
<dandrader> mterry, so I have a trunk subdir  there with lp:unity8, a  power-button-on-lock with your branch, and so on
<mterry> dandrader, right, that's a branch not a repo.  A repo is a directory which can share commit history between many branches that share history, to reduce storage space and run time
<dandrader> mterry, oh, don't know about that stuff
<mterry> dandrader, nor does the strip script  :)
<mterry> dandrader, well, while I figure that out, I also stripped the remote branch again
<mterry> dandrader, removed that id: too
<dandrader> mterry, and not tags in tow this time :)
<mterry> dandrader, I stripped again
<mterry> dandrader, I don't know what's going on, I think I may just nuke all my checkouts and start fresh
<dandrader> mterry, check the video in the comment I just added
<mterry> dandrader, oh boy ok
<mterry> dandrader, so I'm not convinced that's the regression
<mterry> dandrader, on vivid normal, I can also interact with the background before the greeter appears
<mterry> dandrader, I could buy that there is a timing difference
<mterry> dandrader, like maybe it takes longer for greeter to come up with async mode?  (but I would naively expected the opposite)
<dandrader> mterry, I did "ubuntu-device-flash touch  --channel devel-proposed" on both devices
<mterry> dandrader, I just did that myself
<dandrader> mterry, before buidling and installing your branch on the N4
<mterry> dandrader, and I can interact with background if I quickly turn on screen again
<dandrader> mterry, but ok, will try out the N4 without your branch
<dandrader> mterry, that would be quite odd. why such a big difference between devices? there should be none...
<mterry> dandrader, it's a performance thing, how quickly the greeter appears
<mterry> kgunn__, btw, I filed bug 1401213 to track the issue
<ubot5> bug 1401213 in unity8 (Ubuntu) "Can't enter passphrase in unity8 wizard" [Undecided,New] https://launchpad.net/bugs/1401213
<mterry> Do we have a good way to test the OSK in qmluitests?  Or do we need to do autopilot for that?
#ubuntu-unity 2014-12-11
<ypwong> hi there
<ypwong> Does anyone also have the issue https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1397801 ?
<ubot5> Launchpad bug 1397801 in goget-ubuntu-touch (Ubuntu) "Emulator shows black screen after booting up" [Undecided,Confirmed]
<Saviq> ypwong, we've seen this issue when people did not have virtualization enabled - bug #1396919
<ubot5> bug 1396919 in unity8 (Ubuntu) "unity8 display blank in emulator when virtualization disabled" [Medium,Confirmed] https://launchpad.net/bugs/1396919
<ypwong> Saviq, we confirmed that the machine already has virtualization enabled in bios
<Saviq> ypwong, ah, this would be bug #1394208 then
<ubot5> bug 1394208 in qtmir (Ubuntu) "Unity8 unable to find the dash, which is also running in the background" [High,Triaged] https://launchpad.net/bugs/1394208
<tsdgeos> CI is back \o/
<tsdgeos> or is it?
<Saviq> tsdgeos, partly
<tsdgeos> this is weird
<tsdgeos> https://code.launchpad.net/~aacid/unity8/autopilot_drag_more/+merge/243367/comments/602515
<ypwong> Saviq, looks like it is the same issue. Is there an ETA for a fix?
<tsdgeos> failed, but everything inside is success?
<Saviq> tsdgeos, there's None in two jobs
<Saviq> tsdgeos, that's a fail
<Saviq> ypwong, not atm
<tsdgeos> Saviq: what about https://code.launchpad.net/~mzanetti/unity8/fix-left-edge-on-spread/+merge/243400/comments/602513 then?
<Saviq> tsdgeos, Waiting for the completion of unity-phablet-qmluitests-vivid
<Saviq> ERROR: unity-phablet-qmluitests-vivid aborted.
<veebers> Saviq: hey, just saw your update on the bug I filed earlier(1401361), quick query is there a quick way to close the browser perhaps using initctl etc. ?
<Saviq> veebers, autopilot should talk to UAL to find the running apps and stop them all
<Saviq> veebers, there are GI bindings for it
<Saviq> veebers, other than that there's command line utils "ubuntu-app-*"
<veebers> Saviq: right, I'm pretty sure it already closes (or kills as a last resort) any apps it launches from within a test, this test I'm writing at the moment actually taps it open from the scope
<veebers> Saviq: sweet, thanks. that gives me a start now :-)
<Saviq> veebers, I'll mark the bug invalid then, ok?
<veebers> Saviq: sure, I'll let you know if I still hit the issue. Thanks again for the insight
<tsdgeos> greyback: so yeah, there's never a frame_posted happening when the splash screen stays there forever
<tsdgeos> greyback: what should trigger a frame_posted that i can put a debug in?
<greyback> tsdgeos: when the application swaps a frame, frame_posted is called for shell. Has the app swapped? QSG_RENDER_TIMING=1 will print after a swap
<tsdgeos> void UbuntuOpenGLContext::swapBuffers(QPlatformSurface* surface)
<tsdgeos> looks like a good place to put a debug
<greyback> yep
<tsdgeos> that's the client side, right?
<greyback> yep, in qtubuntu
<tsdgeos> greyback: so buffers swap happens
<tsdgeos> what never happens is a handleSurfaceResize
<tsdgeos> which makes it bad it seems
<tsdgeos> now i need to find out who is supposed to call that handleSurfaceResize :D
<greyback> tsdgeos: is frame_posted called in shell?
<tsdgeos> greyback: no
<greyback> tsdgeos: if frame_posted not called in qtmir, qtmir hasn't added it to the qml scene yet. Only when its added to QML scene is it resized to suit
<greyback> what sort of client are you testing? Can I have a try?
<tsdgeos> greyback: you mean unity8 ? :D
<tsdgeos> unity8-dash
<tsdgeos> sure you can have a try
<tsdgeos> remove all scopes
<tsdgeos> greyback_: got my answers?
<greyback_> tsdgeos: no, please repeat them
<tsdgeos> [11:29:44] <greyback> what sort of client are you testing? Can I have a try?
<tsdgeos> [11:32:00] <tsdgeos> greyback: you mean unity8 ? :D
<tsdgeos> [11:32:03] <tsdgeos> unity8-dash
<tsdgeos> [11:32:24] <tsdgeos> sure you can have a try
<tsdgeos> [11:32:29] <tsdgeos> remove all scopes
<greyback_> tsdgeos: stupid question but: how do I remove all scopes?
<greyback_> their packages?
<tsdgeos> greyback_: you open the dash manager and unfavorite them all
<tsdgeos> bottom swipe
<tsdgeos> vivid
<greyback_> ah vivid
<Saviq> greyback_, on rtm you can force a gsetting
<tsdgeos> greyback_: who/what is calling setWidth on the MirSurfaceItems?
<greyback_> tsdgeos: qml is. MirSurfaceItem inherits QQuickItem. When the surface swaps a frame, that surface added to a model, which is eventually parented inside SurfaceContainer.qml
<greyback_>     Binding { target: surface; property: "anchors.fill"; value: root }
<tsdgeos> i guess i'm still missing what in the client tells the server that a frame has been swapped
<tsdgeos> UbuntuOpenGLContext::swapBuffers doesn't seem to do much to tell the server
<tsdgeos> unless eglSwapBuffers is telling the server
<greyback_> tsdgeos: the call eglSwapBuffers does it
<greyback_> well that's what I've always thought
<tsdgeos> he he
<dandrader> Saviq, what MPs are coming on the next unity8 landing? when do you expect it to happen?
<Saviq> dandrader, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-003
<tsdgeos> greyback_: shall we ask some mir guys?
<greyback_> tsdgeos: gimme 2 mins until my phone boots and I can try
<tsdgeos> ok
<dandrader> Saviq, and the "when"? :)
<Saviq> dandrader, I just rebuilt it, testing
<Saviq> dandrader, so, unless something else broke, soon
<dandrader> Saviq, not adding https://code.launchpad.net/~dandrader/unity8/greeterRefactoring/+merge/243823 ?
<Saviq> dandrader, no, wanted to leave that for the next silo
<greyback_> tsdgeos: all scopes unfavourited, restarted shell, I see the dash wallpaper now. You are stuck at the dash loading screen?
<tsdgeos> greyback_: phablet-shell
<tsdgeos> and start/stop unity8-dash a few times
<dandrader> Saviq, should runtests.sh work?
<tsdgeos> eventually you will get stuck in the splash screen
<greyback_> trying...
<greyback_> yeah got it
<Saviq> dandrader, it should, in theory
<dandrader> Saviq, do you or CI use it?
<Saviq> dandrader, didn't try for a while locally, but CI does
<tsdgeos> greyback_: so thing is UbuntuOpenGLContext::swapBuffers is happening but MirSurfaceObserver::frame_posted not
<tsdgeos> greyback_: i can continue pulling strings if you give me some lead
<greyback_> tsdgeos: qtmir.surfaces: MirSurfaceManager::onSurfaceAttributeChanged - surface= 0xaf206998 visibility=occluded
<greyback_> I get that, do you?
<greyback_> yeah something is weird here
<tsdgeos> let me see, that when fails, no?
<greyback_> possibly, am trying to boot correctly to compare
<tsdgeos> yeah
<tsdgeos> qtmir.surfaces: MirSurfaceManager::onSurfaceAttributeChanged - surface= 0xad5b1bb8 visibility=occluded
<tsdgeos> sometimes happens on boot too
<tsdgeos> it's not a "restart only" scenario
<Saviq> mzanetti, bug #1401488 - I retraced the random u-s-c crash
<ubot5> Error: Launchpad bug 1401488 could not be found
<mzanetti> mhm
<tsdgeos> greyback_:  i get the occluded too when works
<tsdgeos> only that after i get a
<tsdgeos> qtmir.surfaces: MirSurfaceManager::onSurfaceAttributeChanged - surface= 0xa909e0b0 focus=focused
<greyback_> ok
<tsdgeos> and not when it fails
<greyback_> focus shouldn't impact visibility
<greyback_> you're right in that it does appear that dash has drawn a frame, but our frame_posted callback didn't fire
<greyback_> perhaps qtmir registers that callback a little too late?
<tsdgeos> maybe
<greyback_> for a trivial qml file Rectangle { color: "blue"} - it displays ok
<greyback_> it draws a frame and get a focus & resize event just after that
<greyback_> QSG_RENDER_TIMING=1 qmlscene blue.qml --desktop_file_hint=/usr/share/applications/mediaplayer-app.desktop
<greyback_> makes tat easy to see
<tsdgeos> yep
<greyback_> but if I run dash manually, it doesn't appear
<tsdgeos> yep
<tsdgeos> if you run it enough times
<tsdgeos> it'll appear eventually
<greyback_> I've a theory
<greyback_> I'm watching the QSG_RENDER_TIMING output
<greyback_> if I see 2 "Render Thread" messages, I don't see dash appearing
<greyback_> if I see, I do
<tsdgeos> if you see what?
<greyback_> if I see 3, I do
<greyback_> no that doesn't explain anything though
<tsdgeos> :D
<facundobatista> Holas
<greyback_> tsdgeos: the simple qml file working makes me think Mir is ok
<greyback_> tsdgeos: try something for me - comment out the Dash's DashCommunicator thingy
<tsdgeos> greyback_: i disagree, if you can code a client that breaks mir, mir is wrong
<tsdgeos> it's not like unity8-dash is doing much at that stage
<tsdgeos> greyback_: out from unity8-dash or from unity8?
<greyback_> tsdgeos: dash
<tsdgeos> greyback_: that seems to fix it
<tsdgeos> greyback_: but now explain me how this is not a mir/qtmir/qtubuntu problem
<greyback_> tsdgeos: yeah, I was fighting with something like this earlier in the week, for slightly different reason
<greyback_> tsdgeos: my suspicion is that when dash's dbus service comes up, Qt's GUI thread blocks a bit while introspecting dash's service
<greyback_> that doesn't mean it's not qtmir's fault though
<greyback_> where those frame posted events go to, I don't know. They shouldn't be lost
<tsdgeos> greyback_: you're going off branches i say
<tsdgeos> UbuntuOpenGLContext::swapBuffers proves there's frames posted
<tsdgeos> and there is no MirSurfaceObserver::frame_posted calls
<tsdgeos> that's the problem
<greyback_> tsdgeos: because qtmir might be blocking the mir thread that calls frame_posted
<greyback_> why is dash special? Why would it behave differently to a simple qml app?
<tsdgeos> because it takes more time to start
<greyback_> the only differene I'm aware of is that it communicates with shell via dbus
<tsdgeos> and it races
<greyback_> if I remove DashCommunicator from the shell, and restore it to the Dash, Dash starts up ok too
<tsdgeos> sure
<tsdgeos> you're workarounding the problem
<tsdgeos> not fixing it
<tsdgeos> greyback_: because if you re-add scopes
<tsdgeos> it will work with the dashcommunicator too
<greyback_> my guess is that with scopes enabled, dash draws more frames after that shell thread is unblocked. only guess tho
<greyback_> sure, I'm not handing you a solution, but if qtmir can't rely on the GUI thread being unblocked, then yeah weird things can happen
<greyback_> in which case, will have to redesign the qtmir threading model
<greyback_> tsdgeos: this is a patch I use to work around something similar: http://pastebin.ubuntu.com/9475014/ - would it help by any chance?
<tsdgeos> greyback_: that patch is unnecessarily complicated
<tsdgeos> you can just change a false to true in ./plugins/Unity/DashCommunicator/dbusdashcommunicatorservice.cpp
<tsdgeos> and i will still claim that is a workaround and the real problem will still come and bite us
<tsdgeos> but let's see if it helps
<greyback_> I'd genuinely appreciate insight into the real problem, if you see anything plain wrong
<greyback_> let me know
<tsdgeos> well
<tsdgeos> i know nothing on how mir calls frame_posted
<tsdgeos> and you told me not to ask the mir guys
<tsdgeos> so i can very well spend a few days on this
<greyback_> you're welcome to ask mir guys
<tsdgeos> eh :D
<tsdgeos> funnily
<tsdgeos> -    UnityDBusObject("/com/canonical/UnityDash", "com.canonical.UnityDash", false, parent)
<tsdgeos> +    UnityDBusObject("/com/canonical/UnityDash", "com.canonical.UnityDash", true, parent)
<tsdgeos> deadlocks everything
<greyback_> ouch
<tsdgeos> may actually even be a good thing
<tsdgeos> let me bt
<tsdgeos> if i only had more space in /
<Saviq> tsdgeos, I usually apt-get download dbgsyms (and actually keep them around)
<tsdgeos> i guess i need to change to compiling in chroots as you mentioned
<greyback_> tsdgeos: how can I add scopes back? bottom edge swipe does nothing
<tsdgeos> greyback_: muhahahahahaha
<greyback_> XD
<greyback_> http://www.nooooooooooooooo.com/
<tsdgeos> greyback_: https://code.launchpad.net/~aacid/unity8/bottom_list_no_favorites/+merge/244169
<tsdgeos> there's some gsetting call to add one back
<tsdgeos> but i don't know exactly the syntacx
<greyback_> np, will look
<Saviq> greyback_, gsettings reset com.canonical.Unity.Dash favorite-scopes
<greyback_> Saviq: ta, almost had it ;)
<Wellark> Saviq: hey, getting those packaging changes in to vivid
<Saviq> Wellark, coolz, thanks
<Wellark> is that enough, or do we need them on rtm as well?
<Wellark> Saviq: as messing with the packaging on rtm is quite scary
<Saviq> Wellark, no, that's enough
<Wellark> Saviq: great! :)
<Saviq> it's not like we can cross-build rtm anyway :P
<Saviq> and it doesn't seem to be a problem otherwise
<Saviq> dandrader|afk, could https://code.launchpad.net/~dandrader/unity8/properInSceneDialogs/+merge/243998 impact the shutdown dialog? reboot doesn't work with the silo :/
<Saviq> yeah, looks like it, I'm pulling from the silo
<dandrader> Saviq, how do I get to the shutdown dialog on the device?
<dandrader> Saviq, ah... it's missing one diff chunk from shellRotation
<dandrader> Saviq, could you wait a minute? :-)
<dandrader> Saviq, problem is that the mock service used in the test doesn't match the real one
<dandrader> Saviq, pushed the plugins/Unity/Session/dbusunitysessionservice.h change make them both match
<dandrader> s/make/that makes
<Saviq> dandrader, it's almost built now, will have to wait until the next landing
<dandrader> noooooooooooooooo.com
<Saviq> dandrader, that's not noooooooooooooooo.com
<dandrader> who clicks on those URLs anyway ;)
<Saviq> that's nooooooooooooooo.com
<Saviq> I do!
<dandrader> it doesn't work on my browser. lousy website
 * dandrader clicks that button and nothing happens
<Saviq> dandrader, speakers on
<Saviq> ?
 * dandrader refuses to reply
<mzanetti> http://www.dramabutton.com/
<Saviq> Cimi, what's up with https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 ?
<Saviq> mterry, guess what
<mterry> Saviq, tags?  I saw your comment
<mzanetti> :D
<mzanetti> dude :D
<Saviq> mterry, yeah, really, where do you take them from
<dandrader> Saviq, ah, now it works. I had some kind of blocker refusing to load the audio thingy
<mterry> Saviq, "I'm *guessing* my use of a "bzr repository" is causing tags to stay around even when local branches are clean? -- I tested and stripped tags from this local branch and remote version.  Then pushed my local to this remote.  And tags appeared again.  When done with my current MPs I'm just going to nuke my whole unity8 directory."
<mzanetti> mterry: you just need to run the script on *every* branch. that's it
<mzanetti> every == local and remote
<mterry> mzanetti, I do and have
<mterry> mzanetti, I suspect I'm the only one using these "bzr repos", so that may likely be the cause
<dandrader> mzanetti, he user a "bzr repository" thingy which is not the "bzr branch lp:foo" we layman people use
<mzanetti> might be... never heard of that
<mterry> mzanetti, bzr help repositories
<mterry> mzanetti, it's a way to save space and time when dealing with a lot of branches off the same trunk
<mterry> mzanetti, and a way to never let tags die I guess
<dandrader> and a way to keep tags forever :)
<mterry> :)
<mzanetti> :)
<mzanetti> mterry: anyways, I have a AS based launcher backend mostly ready
<mzanetti> mterry: hwever, AS is really slow
<Saviq> mterry, yeah, sounds like it
<mzanetti> mterry: it blocks for 0.25 secs or so to update that key in AS
<Saviq> mterry, I'm using colo
<mterry> mzanetti, we can't use async?
<mzanetti> probably, yes
<Saviq> mterry, *and* repositories are the reason we have the tags in the first place
<mzanetti> haven't tried it yet. just got it working properly with the sync approach
<Saviq> mterry, lp:unity and lp:unity/8.0 were put in the same repo, resulting in shared tags ;/
<mterry> mzanetti, cool
<mterry> Saviq, what is colo?  colocating offered by bzr directly or something else?
<Saviq> mterry, it's a plugin
<Saviq> mterry, lets you manage branches git-style
<mterry> Saviq, ah, my brain is bzr native, so I'm not sure that would help me
<Saviq> mterry, ;)
<mterry> Cimi, for wizard-passphrase-osk, did you mean to approve as well?
<Saviq> mterry, Cimi doesn't seem to top-approve recently :P
<mzanetti> push ups!
<mterry> Saviq, or even bottom approve now
<dandrader> oh.. new fancy qt docs webpage
<mterry> Just leaves checklists
<mterry> And disappears into the night
<mzanetti> mterry: using async calls would help a lot. think there is a problem with switching AccountsServiceDBusAdaptor::setUserProperty to use async always?
<mterry> mzanetti, I think we'd need to look at all cases that use it now to verify they don't expect sync semantics
<mterry> mzanetti, some people might assume change is made after set
<mzanetti> mterry: I could introduce a setUserPropertyAsync...
<mterry> mzanetti, heh that would probably be easier  :)
<mzanetti> ack
<dandrader> am I the only one to find that the new style of the qt docs makes it way harder to read?
<greyback_> dandrader: not just you
<Saviq> and all my history is b0rked again is it?
<greyback_> yep
<greyback_> http://doc-snapshot.qt-project.org/qt5-5.3/index.html
<Saviq> no actually history seems fine
<Saviq> at least that
<greyback_> true. You just get 5.4 docs now
<greyback_> better than the broken links from last time
<Cimi> Saviq, asked yesteday which silo is for that
<Cimi> mterry, ci is broken, can we rerun it?
<mterry> Cimi, I don't know what the status of CI is now.  I've been running things locally generally
<cwayne_> Saviq, heya, how can I make a preview text widget collapsible?
<Saviq> cwayne_, you need to put it in a collapsible widget
<Saviq> or rather, an expandable one
<cwayne_> oh "expanadble:
<cwayne_> when did that happen?
<cwayne_> is that new?
<Saviq> cwayne_, nope, it's been there for months
<Saviq> cwayne_, when mhr3 was still with us
<cwayne_> i swear to god i never saw it in the list of preview widget types
<cwayne_> damn
<cwayne_> ok
<cwayne_> btw table still isn't documented :)
<Saviq> cwayne_, you know where these docs come from ;P
<cwayne_> when a mommy doc and a daddy doc love each other very much...
<Cimi> Saviq, is there a plugin to read dbus from qml?
<Saviq> Cimi, we generally build small purpose-built plugins for that
<Cimi> ok
<Saviq> charles, hey, was this by design that I can't dismiss calendar reminders now?
<Saviq> charles, they only last a few seconds, so that's kinda better than before
<Saviq> charles, but then not being able to snooze or dismiss..
<charles> Saviq, it's intentional that they're temporary rather than looping audio + requiring manual dismissal by user
<charles> Saviq, this was a hallway discussion in DC, afaik there's no design writeup saying what the notifications should look like
<Saviq> charles, yeah, temporary, sure, but not interactive at all
<tsdgeos> Saviq: i built a chroot in the phone home, but now everything i build there seems to be incompatible with the phone, any idea why that may be?
<Saviq> tsdgeos, how did you create the chroot?
<Saviq> tsdgeos, sure it's rtm?
<tsdgeos> Saviq: vivid
<tsdgeos> but it's a vivid phone
<Saviq> tsdgeos, oh, interesting
<Saviq> tsdgeos, any chance your phone is not updated?
<tsdgeos> Saviq: debootstrap
<tsdgeos> no image is from today
<Saviq> tsdgeos, hmm hmm, and incompatible in what way?
<tsdgeos> Saviq: so i copied the libqpa-ubuntumirclient.so i just compiled to the proper place
<tsdgeos> and when starting unity8 i get
<tsdgeos> Ubuntu Platform API: Unable to load selected module. -- Aborting
<Saviq> tsdgeos, I wonder, permissions?
<tsdgeos> Saviq: nah
<tsdgeos> it is weird
<Saviq> tsdgeos, could probably use a more interesting output... I'd try building a .deb maybe
<tsdgeos> will try
<Saviq> tsdgeos, -nc to not clean, btw
<tsdgeos> Saviq: yep i know
<tsdgeos> Saviq: interestingly the deb package works :D
<tsdgeos> mterry: maybe your loader -> slow is because there's lots of other stuff in not a loader happening and thus the loader gets postponed?
<tsdgeos> Cimi: there's qt connectivyty thing
<tsdgeos> we mantain
<Cimi> ok
<mterry> tsdgeos, it's possible.  :(  loader is happening when screen is turning off, and I naively wouldn't expect too much going on then.  But maybe I'm wrong
<Cimi> tsdgeos, does this give a state of wifi connection?
<tsdgeos> Cimi: no, only if there's connection or not
<Cimi> tsdgeos, you mean if is connected or not?
<tsdgeos> Cimi: i mean if the phone can access the interwebs or not (either via phone stuff or wifi)
<Cimi> tsdgeos, mmm that's not what I need
<tsdgeos> ah, ok
<Cimi> tsdgeos, I need to see if I am connected via wifi
<pstolowski> tsdgeos, hey, have you seen the update to https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400762 ?
<ubot5> Launchpad bug 1400762 in unity8 (Ubuntu) "Manage Dash allows to unfavourite all scopes and leave you with a blank page" [Critical,Triaged]
<tsdgeos> pstolowski: yeah i'll do tomorrow first thing morning
<tsdgeos> now i have my mind somewhere else
<pstolowski> tsdgeos, sure, np, i'll also add the restriction in the plugin back
<tsdgeos> oki
<mterry> What might cause tryCompare to fail even if it spits out a warning that seems to show actual and expected as true?  (i've tested type and both are booleans)
<Saviq> mterry, an exception?
<Saviq> mterry, hmm no wait
<Saviq> it says "expected": "true"; "actual": "true" and still fails?
<mterry> FAIL!  : qmltestrunner::DashContent::test_altNavigation()
<mterry>    Actual   (): true
<mterry>    Expected (): true
<mterry>    Loc: [/home/mike/Work/code/unity8/greeter-refactor/tests/qmltests/Dash/tst_DashContent.qml(74)]
<mterry> Saviq, ^ only warnings beforehand are binding loop warnings
<Saviq> mterry, you really sure they are both bools? one of them isn't a string?
<mterry> Saviq, I printed typeof and it said boolean
<Saviq> mterry, yikes
<mterry> Saviq, it's not on trunk, only my refactor branch.  So I'm sure I did something weird
<mterry> just don't know how to figure out what
<mterry> I didn't even touch the Dash
<Saviq> mterry, can I see a branch?
<mterry> Saviq, it's a huge diff right now
<mterry> but sure
<Saviq> mterry, I just wanna try, not gonna read
<mterry> Saviq, heh
<mterry> Saviq, lp:~mterry/unity8/greeter-refactor  (probably will infect you with tags, knowing me)
<Saviq> mterry, at least we know where they're coming from again
<mterry> brb
<Saviq> mterry, testDashContent passed here
<Saviq> mterry, I looped it, that test went fine like 20 times
<mterry> Saviq, oh
<mterry> Saviq, good?  Maybe my checkout is bonkers.  Will blow away builddir and try agani
<mterry> Saviq, thanks for trying
<Saviq> mterry, sounds like a good idea, otherwise I'd start looking sideways at the HW ;P
<mterry> yay, it passed
<mterry> Stupid cosmic rays
<dkessel> good evening. i am thrilled to try unity8-in-lxc to help with QA
<dkessel> however, this blocks me from doing anything at all: bug 1391815
<ubot5> bug 1391815 in unity8-lxc (Ubuntu) "unity8 processes uses 100% cpu, desktop frozen" [Undecided,New] https://launchpad.net/bugs/1391815
<ChrisTownsend> dkessel: Hi, I saw your bug update and added the unity8-lxc task.  However, looking at the description, it seems this occurs for you on a live image as well.  Is that correct?
<dkessel> ChrisTownsend: well, yes it did in november. i guess it would still do that.
<ChrisTownsend> dkessel: fyi, there is a known limitation when using the LXC version that vt switching currently doesn't work, as you pointed out.  Is it possible for you to try the live image again just to be sure so we can rule out the LXC part of this?
<ChrisTownsend> dkessel: Also, what graphics is on your machine?  Intel, Nvidia, or AMD?
<dkessel> ChrisTownsend: ok, will try the current live image. graphics: Intel + Nvidia (you know... "Optimus" hybrid)
<ChrisTownsend> dkessel: Ok, thanks.  Since you originally said unity8 was spinning at 100%, I'm suspecting an issue somewhere in that stack.  It might be good to try to reproduce this on the live image and then switch to a VT and then break in to the unity8 process with gdb and get a stacktrace to see maybe where it's getting stuck.
<ChrisTownsend> dkessel: Once we get a bit more info in the bug, then we can add the unity8 task.
<ChrisTownsend> dkessel: I'm also wondering if Mir is having fits with your graphics.  Any way to just force Intel in the BIOS or unload the Nvidia driver?
<ChrisTownsend> dkessel: As I say that though, you probably wouldn't see the desktop at all.
<dkessel> ChrisTownsend: hmm thanks for trying to help. too bad my downlink speed is really unstable today - i don't think i will be able to download that image today :/
<dkessel> but i will come back!
<dkessel> or we can try something else if there could be any logs, for example...
<ChrisTownsend> dkessel: Ok, no problem.  Feel free to update the bug if/when you have more info.   Umm, yeah, logs...
<ChrisTownsend> dkessel: You could try attaching ~/.cache/upstart/unity8.log after this occurs and see if it's spewing anything.
<dkessel> ChrisTownsend: ok, will try doing that
<ChrisTownsend> dkessel: ok, thanks
#ubuntu-unity 2014-12-12
<didrocks> mzanetti: Saviq: hey, did you submit any talk for FOSDEM? I don't see them now that the proposal period is over
<Saviq> didrocks, yeah, I did, and bregma, too
<didrocks> Saviq: what's the title of your conference?
<didrocks> I see bregma's one
<Saviq> didrocks, "Ubuntu on phones and beyond"
<didrocks> Saviq: ah, typo in your name :)
<didrocks> Saviq: ok, all good, it's listed ;)
 * Saviq was worried did not fill the forms right, they're rather convoluted
<didrocks> Saviq: I won't even mention the backend-voting-side :p
<didrocks> (we are back to using some google spreadsheet for easyness, due to that)
<Saviq> ;)
<Saviq> spreadshits FTW!
<didrocks> heh
<Saviq> tsdgeos, hey, could you work today on making the apps scope non-unfavouritable?
<tsdgeos> yep
<tsdgeos> i was talking with xavigarcia about some card stuff
<tsdgeos> i will do that now
<tsdgeos> and then maybe fix the race in qtmir we indentified with gerry yesterday
<tsdgeos> that = non-unfavoritable
<tsdgeos> bign landing btw \o/
<tsdgeos> -n
<tsdgeos> now if Cimi would review the moreAsyncDash ;)
<tsdgeos> Saviq: do you know if ci is back ?
<Saviq> tsdgeos, yeah, it should mostly be back
<Saviq> tsdgeos, if you're touching cards, maybe you can have a look at bug #1393008
<ubot5> bug 1393008 in unity8 (Ubuntu) "Horizontal cards don't get backgrounds" [Critical,Triaged] https://launchpad.net/bugs/1393008
<tsdgeos> yeah
<tsdgeos> that was what we were talking about
<Saviq> oh good
<tsdgeos> that's not a bug according to spec
<tsdgeos> :
<tsdgeos> :D
<Saviq> orly?
<tsdgeos> yeah
<tsdgeos> well if you read the spec in a certain way
<tsdgeos> of course
<Saviq> ah ok ;)
<Saviq> thostr_, says it was working before ;)
<tsdgeos> never
<tsdgeos> the code says
<tsdgeos> hasBackground = !isHorizontal && stuff;
<tsdgeos> don't think that changed lately
<Saviq> heh
<tsdgeos> Saviq: can you log into http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/5023/rebuild ?
<tsdgeos> well log
<tsdgeos> does it even show up?
<Saviq> tsdgeos, do you have the new VPN set up?
<tsdgeos> probably not
<Saviq> tsdgeos, kicked that rebuild
<Saviq> tsdgeos, ok and as far as the spec goes, where did we read it that horizontal cards can't have backgrounds?
<tsdgeos> i'm writing it down
<Saviq> thanks
<tsdgeos> done
<tsdgeos> Saviq: imho our bug should be back to incomplete and add ubuntuux there for them to decide if what i understand is what they wanted to write
<Saviq> tsdgeos, sure
<tsdgeos> and bring back the designer that wrote that ^_^
<Saviq> tsdgeos, yeah, you're right
<Saviq> tsdgeos, it clearly says it can't be shaped, so no background
<tsdgeos> well that's how we coded it yes
<Saviq> pstolowski, I'll start prepping the unity8 counterpart for dash bottom edge
<Saviq> pstolowski, but we'll have to wait for apps-special-after-all
<pstolowski> Saviq, yeah, i'm going to prepare MP for that
<Saviq> pstolowski, you want to ensure that plugin side?
<tsdgeos> in case our 1 line of code fails :)
<Saviq> tsdgeos, truth is we might need to have multiple special scopes for OEMs, or at least replacing the apps one
<Saviq> tsdgeos, but then we don't need to implement that right now
<tsdgeos> i'll go back
<tsdgeos> to what we had
<tsdgeos> i.e. lame
<tsdgeos> showStar: model.scopeId != "clickscope" && (root.isFavoritesFeed || root.isOtherFeed)
<tsdgeos> damn, that also makes it unmovable
<tsdgeos> and we want it movable, right?
<tsdgeos> hmmm
<tsdgeos> and we need to make it unfavoritable also from das
<tsdgeos> h
<pstolowski> Saviq, yes, I had it before in the plugin as a safeguard, i just need to find and revert that commit
<tsdgeos> is that something we do
<tsdgeos> or that the plugin does
 * tsdgeos checks
<pstolowski> Saviq, but you also need to special case it in the shell (not to show star)
<tsdgeos> something we do
<Saviq> pstolowski, yup
<tsdgeos> it's again something the scope should tell us
<tsdgeos> if we're going to make this generic for the FUTURE
<Saviq> trueth
<Saviq> or at least the registry
<tsdgeos> btw i just found a bug
<tsdgeos> not sure if it's ui or backend
<tsdgeos> but if you open manage dash, go to edit mode, reorder, leave edit mode and now click some scope, it will bring you to the "before reordering" position
<tsdgeos> pstolowski: if i had to say something i'd say that's on your plate â
<tsdgeos> but maybe not :D
<Saviq> tsdgeos, worked fine here
<Saviq> tsdgeos, is "some scope" favourited or not?
<pstolowski> otp
<tsdgeos> Saviq: yes, otherwise that's the point of the reordering breaking it
<tsdgeos> and now it works
<Saviq> oh there's one more thing
<tsdgeos> :S
<Saviq> the scope gets refreshed every time I click in Manage Dash
<Saviq> sounds wasteful
<tsdgeos> ah made it fail again
<tsdgeos> it may be on our side
<tsdgeos> will debug more
<tsdgeos> meanwhile https://code.launchpad.net/~aacid/unity8/apps-special-after-all/+merge/244548
<tsdgeos> Saviq: ok my way to reproduce, have 3 fav scopes, move 2 to 1, click on 3rd
<tsdgeos> end in first
<Saviq> tsdgeos, confirmed
<tsdgeos> and it's probably our
<tsdgeos> s
<tsdgeos> looking at it now
<Saviq> tsdgeos, could we have a test for apps-special-after-all?
<tsdgeos> you want to test that !== works? :D
<Saviq> tsdgeos, no, I want to test that there is no star next to the click scope
<Saviq> or in the click scope's header
<tsdgeos> Saviq: which is basically testing !==, it will still break when backend decides to rename the click scope to "mooscope" and we're still checking for !== "clickscope"
<Saviq> tsdgeos, great, we'll have a failure that we might even be able to catch in proposed thanks to that test being executed on autopkgtest
<Saviq> soon
<tsdgeos> Saviq: no, we won't have a failure, why would we?
<Saviq> tsdgeos, because if they changed, the star would be there when it shouldn't be?
<tsdgeos> it's not like we use real scopes in tests
<Saviq> tsdgeos, oh well, right
<tsdgeos> so as i said, we're testing that !== works
<Saviq> meh
<tsdgeos> but if it makes you happy
<tsdgeos> it's 10 minutes of my time
<tsdgeos> so doing
<Saviq> tsdgeos, I think we should have that test indeed
<Saviq> tsdgeos, and while right now it might not make all kinds of sense
<Saviq> it hopefully will once we have a property on scopes that decide whether they can be unfav'ed or not
<tsdgeos> and nobody will remember to update the tests :D
<pstolowski> Saviq, tsdgeos i guess I can add new role for such property in OverviewResultsModel
<Saviq> pstolowski, not enough
<Saviq> pstolowski, we need to know it for the scope as well, to show the star in the header or not
<pstolowski> Saviq, tsdgeos and I'd special case apps in shell plugin for now (no configurability), but at least it won't bubble up
<pstolowski> ah right
<pstolowski> Saviq, so, new property in Scope interface? again special cased for now in shell plugin
<pstolowski> ?
<tsdgeos> i'd leave it as it is now tbh
<Saviq> pstolowski, â
<Saviq> pstolowski, once we know we do need to replace / add special scopes
<Saviq> is when we'll deal with that
<pstolowski> Saviq, tsdgeos ack
<facundobatista> Hola!
<tsdgeos> Saviq: tests added
<Saviq> tsdgeos, thanks
<Saviq> tsdgeos, did you push?
<tsdgeos> nope :D
<tsdgeos> and even then, there's a bug
<Saviq> k
<tsdgeos> now :)
<tsdgeos> Saviq: â
<Saviq> tx
<tsdgeos> i hate listview
<Saviq> tsdgeos, that's re: went to the wrong scope?
<tsdgeos> ywah, i know what's wrong
<tsdgeos> my workaround for a listview "bug" breaks it
<tsdgeos> i'll add a few tests
<tsdgeos> which we have none
<tsdgeos> to at least make sure those two things work
<tsdgeos> in a separate MR
 * Saviq starts being afraid of cherry-picking...
<Saviq> UUGH
<tsdgeos> yeah
<tsdgeos> Saviq: i appreciate you doing the cherry-picking, but it's most probably something the guy that did the original branch should do
<tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/bottom_list_drag/+merge/244563 has the fix for the issue i found with dragging + click with a test for it and some other stuff
<Saviq> tsdgeos, it's not even that
<Saviq> tsdgeos, the real problem is the ordering
<tsdgeos> ah
<Saviq> tsdgeos, like now we're landing the bottom edge
<Saviq> tsdgeos, but there were things that changed for the performance fixes
<tsdgeos> right
<Saviq> tsdgeos, so it's conflicting (a bit) now, and will conflict again later, not to mention that I might actually break things
<Saviq> tsdgeos, and then... there's unity-api, which has a launcher change that we don't (yet) want in rtm
<Saviq> tsdgeos, so I need to cherry-pick that and do something weird with unity-api's version so that we don't break that...
<Saviq> so that we can actually reconcile in the futuer
<Saviq> but maybe it's gotta be what it's gotta be...
<Saviq> and then there's you not being able to make your mind on how the test should work and changing it back'n'forth ;P
<Saviq> but well, the test passed, so it must be right, right?
<tsdgeos> totally
<tsdgeos> :D
<tsdgeos> Saviq: which test?
<Saviq> tsdgeos, test_manage_dash_search_temp_scope
<tsdgeos> ah don't worry about that one, we don't support search yet anyway
<tsdgeos> so the skip() at the beginning is the important part
<Saviq> tsdgeos, that's searching in *temp* scope
<Saviq> tsdgeos, not in manage dash?
<tsdgeos> no
<tsdgeos> is searching in manage dash
<Saviq> ok
<tsdgeos> that's why it's called manage_dash_search
<Saviq> tsdgeos, anyway, there was no tryCompareFunction(), then you added it when doing "less delegates" and then removed it again in bottom swipe :P
<tsdgeos> he he
<Saviq> tsdgeos, it's fine, I'm just trying to keep the diff sane
<Saviq> mzanetti, can you please whip up a quick vivid silo with tsdgeos's fixes for the bottom edge?
<mzanetti> kk
 * Saviq tries not to land in rtm before vivid
<Saviq> mzanetti, https://code.launchpad.net/~aacid/unity8/apps-special-after-all/+merge/244548 and https://code.launchpad.net/~aacid/unity8/bottom_list_drag/+merge/244563
<Saviq> mzanetti, if you could review the latter one, too, would be obliged
<Saviq> ah and https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244293 too
<Saviq> tsdgeos, that's it, right â ?
<Saviq> greyback__, just discovered hash -d in znc, better'n'wd ;)
<tsdgeos> mzanetti: Saviq: yeah that one too, though effectively it does nothing at the moment it's "better code"
<greyback__> Saviq: Sorry, I've no idea what that sentence means. znc the IRC bouncer?
<Saviq> greyback__, zsh, of course ;)
<Saviq> greyback__, hash -d alias=/some/dir/foo
<Saviq> greyback__, cd ~alias
<greyback__> Saviq: there's a "jump" plugin I like a lot.
<greyback__> ets you bookmark directories with a name, and then jump from one to another. Is very similar
<Saviq> greyback__, sounds the same :), but IIRC jump lets you do more
<greyback__> and have it aliased to "j" so I can just "j qtmir" to land in my qtmir root
<Saviq> yup
<Saviq> tsdgeos, https://code.launchpad.net/~unity-team/unity-api/rtm-14.09-staging/+merge/244567 please
<Saviq> pstolowski, is there a citrain row for bottom dash rtm yet?
<tsdgeos> Saviq: looks good, want me to approve?
<Saviq> tsdgeos, yup
<pstolowski> Saviq, no, but i have another silo where i'm currently building two other fixes (including department jumping fix)
<Saviq> pstolowski, that's for vivid though?
<pstolowski> Saviq, and it has shell plugin
<pstolowski> Saviq, yes vivid
<Saviq> pstolowski, I'm talking rtm
<Saviq> this silo should only include bottom edge things IMO
<pstolowski> Saviq, agree. but we need todays fix in vivid first
<Saviq> pstolowski, do you have rtm branches yet?
<Saviq> pstolowski, btw, you know we're limited to "3 fixes" per rtm silo? could we not land bottom edge separately?
<pstolowski> Saviq, i only have rtm MP for plugin and it will need updating with todays fix
<mzanetti> tsdgeos: I don't really understand what the issue is this one fixes: https://code.launchpad.net/~aacid/unity8/bottom_list_drag/+merge/244563
<Saviq> pstolowski, sure, I don't have complete MPs yet, either
<Saviq> pstolowski, but want to start early
<pstolowski> Saviq, yeah, I know of limits. actually, is it 3 MPs or 3 bugfixes?
<mzanetti> :)
<Saviq> pstolowski, neither, it's 3 "fixes"
<Saviq> pstolowski, it can be more or less MPs
<pstolowski> Saviq, yeah... i already prepared target rtm-14.09 branch for unity-api (which wasn't branched yet)
<tsdgeos> mzanetti: without the patch do this, get to manage dash, move second scope to first, click third scope, see how you're not in the third scope as you should be
<Saviq> pstolowski, yeah, got an MP for that up already
<pstolowski> cool
<mzanetti> tsdgeos: thanks
<Saviq> pstolowski, https://code.launchpad.net/~stolowski/unity-scopes-shell/manage-dash-rtm/+merge/244117 is the one?
<tsdgeos> mzanetti: note there may be a race in the test, i got it failing 1 every 20 or so if i loop it
<mzanetti> tsdgeos: you fixing that?
<tsdgeos> having a look yes
<pstolowski> Saviq, also, I've rtm silo 3 (rows #23) that needs qa sign off, or will block other landings of shell plugin
<pstolowski> Saviq, yes, that's it
<pstolowski> Saviq, it may also need dependency update
<Saviq> pstolowski, you'll need to chase product folk to accept https://launchpad.net/bugs/1394155
<ubot5> Launchpad bug 1394155 in unity-scopes-shell (Ubuntu) "Crash of unity8-dash possible through Today scope" [Critical,In progress]
<Saviq> pstolowski, we'll need -api for the new silo too, right?
<pstolowski> Saviq, unity-scopes-api? yes
<mzanetti> tsdgeos: this one fails here all the time: test_manage_dash_move_current_click_other
<tsdgeos> mzanetti: hmmm
<tsdgeos> with the patch?
<mzanetti> this branch: https://code.launchpad.net/~aacid/unity8/bottom_list_drag/+merge/244563
<tsdgeos> you didn't revert the change in qml/Dash/Dash.qml
<tsdgeos> right?
<tsdgeos> can you add console.log("setCurrentScope", scopeId, scopeIndex); to Dash.qml::setCurrentScope after the for loop?
<mzanetti> no, didn't revert that
<mzanetti> trying the debug print
<mzanetti> tsdgeos: qml: setCurrentScope MockScope1 1
<tsdgeos> right
<tsdgeos> that's wrong
<tsdgeos> should be MockScope5 2
<tsdgeos> you're probably hitting my race more often :D
<mzanetti> so far 100%
<tsdgeos> i have a tentative fix, let me push it and see if it fixes it for you
<mzanetti> ack
<tsdgeos> pull!
<mzanetti> tsdgeos: pass
<tsdgeos> good
<tsdgeos> it's weird how something that was just a one off here was there all the time
<mzanetti> yeah, I ran it as testDash
<mzanetti> no xvfb
<mzanetti> anyone knows where that "Using blocking call!!!" message is coming from?
<mzanetti> I see that in my apps too
<mzanetti> ok. passes in xbfb too. fixes the issue
<Saviq> mzanetti, never saw that
<Saviq> but judging by the 3 exclamation marks... Wellark â? ;P
<mzanetti> lol
<mzanetti> actually it's just one... the double ll! gave me that impression
<Saviq> rofl
<mzanetti> *that* funny?
<greyback__> Saviq: wdyt, enough? Or should I implement a signal to be emitted to unity8, so unity does the sigstop: https://code.launchpad.net/~gerboland/qtmir/emitSigstopAtCorrectTime/+merge/244570
<Saviq> greyback__, good enough for now
<greyback__> yep, thought was enough for patch
<Saviq> greyback__, later I want to be more granular
<greyback__> sure
<Saviq> greyback__, but that might as well wait for systemd
<greyback__> that'll fix everything
<Saviq> yeah, we'll be done then
<mzanetti> tsdgeos: https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244293/comments/603140
<tsdgeos> mzanetti: honestly i think it's testing again that qml bindings work
<tsdgeos> but i can make it happen
<mzanetti> tsdgeos: I'm rather thinking of the chain of qml bindings... if it's just easy please add a small one. if you need to start with creating a mock framework, it's probably not worth it
<mzanetti> tsdgeos: a small glitch I just noticed: go to manage dash, click on a temp scope, see how the arrow label at the bottom slides in and fades out... probably shouldn't do that
<mzanetti> not related to the above branches I think
<tsdgeos> should be fine
<tsdgeos> yeah i saw that the other day
<tsdgeos> it's a thing between setting the scope and bla bla
<tsdgeos> could be fixed
<tsdgeos> mzanetti: would you mind creating a bug for me?
<mzanetti> sure
<tsdgeos> tx
<Saviq> tsdgeos, did you notice how the scope header icons go transparent when you start dragging from the bottom?
<mzanetti> tsdgeos: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1401869
<ubot5> Launchpad bug 1401869 in unity8 (Ubuntu) "bottom edge arrow label comes in when it shouldn't" [Undecided,New]
<tsdgeos> Saviq: i'd say is because of the disabling
<mzanetti> Saviq: gotta go for an hour. I've tested this branch, works fine: https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244293
<mzanetti> Saviq: however, we agreed to add a mock and test for it
<mzanetti> Saviq: so once that's there, feel free to approve
<tsdgeos> Saviq: not sure how that would be fixed
<mzanetti> the other branch is approved already
<Saviq> tsdgeos, right, makes sense
<Saviq> mzanetti, yeah, thanks, I'll take over now
<mzanetti> kk. see you in a bit
<Saviq> Cimi, you there?
<tsdgeos> mzanetti: Saviq: wops, actually yep, i think it's wrong ^_^
<dandrader> Saviq, ubuntu-ui-toolkit with my dialog changes have landed, btw
<Saviq> dandrader, coolz
<dandrader> Saviq, bumped unity8 dependency accordingly
<Saviq> dandrader, I don't think you should have
<Saviq> dandrader, as you said, it's not actually a requirement
<Saviq> dandrader, like things will work without it
<Saviq> dandrader, and then improve when you get new UITK
<Saviq> dandrader, what I mean by that is dependencies generally represent hard requirements
<dandrader> Saviq, right... but does it do any harm? "make tryDialogs" look proper at least
<dandrader> (with the new uitk)
<dandrader> when you rotate things
<Saviq> dandrader, do the test depend on the new UITK?
<Saviq> dandrader, the "harm" is unnecessary packaging changes, and suggesting that things won't work otherwise
<dandrader> Saviq, no strictly. but it will *look* broken without it
<dandrader> well, I will revert it then
<dandrader> Saviq, done
<Saviq> dandrader, thanks
<Wellark> Saviq, mzanetti: what!?
<Wellark> :)
<Wellark> where is that message?
<Saviq> Wellark, log output from apps sometime
<Saviq> greyback, I'll pop qtmir into the silo as well
<Saviq> ah no, you have one already
<Wellark> Saviq: well, I could write something like that, sure
<Saviq> greyback, did you ping folks for publishing silo 14?
<Wellark> but I usually augment my shit with a __PRETTY_FUNCTION__ or something :)
<cwayne_> anyone have an idea why this renderer wouldn't show up with a background? http://paste.ubuntu.com/9488814/
<Saviq> lol
<Saviq> cwayne_, bug #1393008
<ubot5> bug 1393008 in unity8 (Ubuntu) "Horizontal cards don't get backgrounds" [Undecided,Incomplete] https://launchpad.net/bugs/1393008
<Saviq> cwayne_, horizontal == no shape == no background, per spec
<Saviq> that is
<Saviq> (horizontal - summary) == no shape
<tsdgeos> mzanetti: Saviq: ok, make this work https://code.launchpad.net/~aacid/unity8/scopeListPageHeaderScopeStyle/+merge/244578 good call for testing ;)
<tsdgeos> now food!
<greyback> Saviq: I just set as tested, I didn't ping
<Saviq> greyback, yeah, it helps to ping, gets them off their a$$es quicker
<Saviq> greyback, but I think we're low on landing team atm
 * Saviq hates to be blocked by that
<greyback> Saviq: ok, wasn't aware, but wasn't in rush either
<greyback> Saviq: I removed one qtmir branch you added, as it's caused visual errors. Forgot to set it unapproved, done now
<Saviq> greyback, ok thanks
<cwayne_> Saviq, oh, is that new? this renderer used to work (even if it shouldn't have :P)
<Saviq> cwayne_, no, the spec is old, we might just not have enforced it until recently (due to some refactoring)
<cwayne_> right, that's what i meant
<cwayne_> i know the specs haven't changed recently :)
<cwayne_> but ok, so if i add even a blank summary it should work then?
<Saviq> cwayne_, yeah I think so
 * Saviq checks
<cwayne_> didn't seem to work for me, hm
<Saviq> cwayne_, on that note, yeah
<Saviq> cwayne_, so there's the bug
<Saviq> cwayne_, it should work where there is summary
<cwayne_> hm, damnit
<cwayne_> ok
<Saviq> greyback, should we drop the ::started() altogether then?
<Saviq> greyback, or is there no default impl?
<ChrisTownsend> Hmm, seems I'm not getting any scopes in the scope window on the new Unity 8 desktop mode.
<ChrisTownsend> Sits there with the circle turning.
<greyback> Saviq: empty implementation in keeping with the other empty listeners in the file. Could probably remove the listener class entirely, but that for later MR IMO
<greyback> Saviq: and anyway yeah, no default impl
<Saviq> greyback, kk
<ChrisTownsend> After closing the window and letting unity8-dash restart, it's now to a window that has no scopes.  This is the unity8-dash log after restarting: http://pastebin.ubuntu.com/9489239/
<ChrisTownsend> Saviq: Any ideas? ^^^^
<Saviq> ChrisTownsend, is scope-registry running?
<ChrisTownsend> Saviq: Is "scope-registry" the name of the process?  If so, then no.
<Saviq> ChrisTownsend, it's an upstart job
<Saviq> ChrisTownsend, process is, you guessed "scoperegistry"...
<ChrisTownsend> Saviq: Yes, "scoperegistry" is running.
<Saviq> ChrisTownsend, 'gsettings get com.canonical.Unity.Dash favorite-scopes'?
<ChrisTownsend> Saviq: Output:
<ChrisTownsend> $ gsettings get com.canonical.Unity.Dash favorite-scopes
<ChrisTownsend> @as []
<Saviq> ChrisTownsend, wonder how you got there
<Saviq> ChrisTownsend, bottom swipe in the dash and add scopes to favorites
<ChrisTownsend> So it seems it's empty.  How did that happen.  I only did a dist-upgrade and this is what happened.  It was fine yesterday in the pre-window mode.
<Saviq> ChrisTownsend, you can `gsettings reset` it, too
<ChrisTownsend> Saviq: I'll try that.
<Saviq> ChrisTownsend, I just dist-upgraded my -next vm and that didn't happen, not sure how you got to that state :/
 * ChrisTownsend shrugs
<Saviq> greyback, btw, we could use a test for that sigstop... any idea how to attack that?
 * greyback thought u8 had one
<greyback> autopilot/unity8/shell/tests/test_upstart.py
<ChrisTownsend> Saviq: fyi, the reset worked, so we'll chalk it up to an anomaly for now.  Thanks for your help.
<Saviq> greyback, yeah, but that doesn't test the timing of it
<Saviq> ChrisTownsend, sure, thanks
<Saviq> greyback, we'd need to somehow add there a check that appmanager is ready when sigstop is emitted
<greyback> Saviq: hmm, would need way for AP to be notified when AppMan is created. Am not sure how to do that with AP
<Saviq> greyback, as long as we get a signal/property, we can wait for that
<Saviq> greyback, on the AppManager object, that is
<Saviq> greyback, just tell me what to wait for and I'll hack the test up
<greyback> Saviq: there is no signal emitted by AppMan on construction. Only idea I have is figuring out what its parent object will be, and listening for children being added to it to see if one is AppMan
<Saviq> greyback, it doesn't have Component.onCompleted does it
<Saviq> greyback, and it's a singleton, its parent is the plugin...
<greyback> Saviq: the qml engine might attach that property to it, I've never had that thought
<Saviq> stupid, I'll get the onCompleted of the Connections object...
<Saviq> or nothing, for that matter
<Saviq> oh ok, that's all not gonna work, AP does polling
<Saviq> so before it gets an object, the process is going to stop
<Saviq> greyback, ok, I'll have to chat with QA folk on that
<greyback> yeah, it's kinda tricky
<greyback> 34 tag(s) updated. - uh ohs, is qtmir getting infected
<mterry> If I wanted to have a tst_XXX.qml file that ran ALL tests against two different configs (like a constant _data() for each test function), is there an easy way to do that without actually specifying the _data() methods?
<dandrader> mterry, that's for you: https://code.launchpad.net/~dandrader/unity8/unifyLightDMMocks/+merge/244593
<Saviq> mterry, other than making the _data() a wrapper returning some common data set, not that I know of
<dandrader> mterry, I thing you could create a separate component inheriting from UnityTestCase and instantiate it twice you your tst_Foo.qml
<dandrader> s/thing/think
<Saviq> dandrader, I think he wants to share the _data between different test_ functions, too
<dandrader> mterry, like MyTestCace { foo: "this" } MyTestCase { foo: "that" }
<dandrader> Saviq, he wouldn't use the _data feature in that case, but would achieve the same result
<mterry> dandrader, but wouldn't I have to specify each test_ function twice?
<dandrader> mterry, the "foo" property in the example would be the config you want all tests in the TestCase to use
<mterry> dandrader, sure sure but say I have a test like test_foo().  Wouldn't I have to put that inside both MyTestCase objects?
<dandrader> mterry, no, you would write it only once in MyTestCase.qml
<dandrader> mterry, you would treat the testcase just like any other qml component
<mterry> dandrader, oh I see.  A very specific MyTestCase
<mterry> I was thinking you were suggesting a generic mechanism.  But that could work well yeah
<dandrader> mterry, yeah, like a ShellTestCase.qml
<dandrader> used only by tst_Shell.qml
<dandrader> mterry, since you changed the approach, you should update the commit message of https://code.launchpad.net/~mterry/unity8/power-button-on-lock/+merge/239076
<mterry> dandrader, ah yes
<mterry> dandrader, ah naive young me: "Making the GreeterContent loader asynchronous seems like an easy fix."
<dandrader> :D
<mterry> dandrader, done
<dandrader> mterry, thanks
<mterry> dandrader, and I saw your unify branch, will get to it today
<dandrader> mterry, awesome. thanks
<dandrader> mzanetti, will start working on the mouse task now. what is it exactly?
<dandrader> mzanetti, is that unity8 is not getting or forwarding mouse events to apps?
<mzanetti> dandrader: we don't get mouseMoveEvents
<mzanetti> dandrader: not even to apps only. even inside unity
<mzanetti> dandrader: to test do this:
<dandrader> mzanetti, right
<mzanetti> MouseArea { hoverEnabled: true; onMouseXChanged: print("it works!");  }
<mzanetti> dandrader: and then make it print "it works!" without clicking :)
<dandrader> mzanetti, we don't get *any* mouse events at all right? (no button presses or anything)
<mzanetti> dandrader: well, we do get that, but can't distinguish between mouse or tap I think
<mzanetti> dandrader: that's not really critical at this point in time. the mouse hovering is more important as a first step
<mzanetti> and I guess by then you'll have figured what exactly is missing
<dandrader> mzanetti, interesting. I would guess it would be an all-or-nothing for mouse events
<dandrader> mzanetti, so, I have to setup that mir+unity8 in a VM thing
<mzanetti> dandrader: interestingly I do even get mouse scroll events in the vm
<greyback> right/middle click & scrollwheel would be nice too
<mzanetti> dandrader: you can choose between a VM or just setting up a second user
<mzanetti> however, switching vt might hang your computer... so a VM is desirable from that pov
<mzanetti> otoh, the VM is slower
<mzanetti> greyback: strangely I do get those
<dandrader> mzanetti, but is it slow to be point of being unusable?
<mzanetti> greyback: two-finger scroll on a touchpad at least
<mzanetti> dandrader: no. it usable
<greyback> mzanetti: yeah I am surprised. It's not implemented in the code anyway
<mzanetti> dandrader: no. it is usable
<mzanetti> dunno :D
<greyback> it's better than the emulator :)
<mterry> dandrader, in the unify branch, the demo plugin shares some code with the liblightdm mock.  Any chance they could actually share the file?  Like have the mock version subclass the demo version or something?  Also, we've been meaning to rename the demo plugin because we are actually using it in producton now
<greyback> I'm told this works now too, if you have the 3.18 kernel: http://unity.ubuntu.com/mir/setup_kvm_for_mir.html
<dandrader> mterry, ok, I will look into it
<dandrader> mterry, so, should I rename the plugins/LightDM/demo dir to something else
<kgunn_> mterry, looks like you're having internet fun, so you prolly missed it....can greeter be made to "scroll up a bit" in the case where keyboard is covering the text box ?
<mterry> kgunn_, this is when rotated?  I thought we didn't rotate the greeter
<kgunn_> mterry, so on n7, greeter in landscape
<kgunn_> fixed
<kgunn_> can't see how many characters i've entered
<mterry> kgunn_, oh when in tablet mode?
<kgunn_> right
<mterry> curious
<mterry> kgunn_, well yes the answer is we can...  would take a little work but sure -- we never ran into that before?  huh
<mterry> kgunn_, does design have opinions on how that should look?  (like just shift everything up?  rotate name up in list?  something else)
<kgunn_> mterry, yeah, ppa:unity-team/demo-stuff on vivid n7 shows the example
<kgunn_> mterry, no input from design...more about having something workable for mwc
<mterry> kgunn_, ah ok
<mterry> kgunn_, so this is relatively high priority
<mterry> kgunn_, is there a bug?
<kgunn_> mterry, only on the team punch list...not on lp
<kgunn_> https://docs.google.com/a/canonical.com/spreadsheets/d/140Icn5zcZwMvg1SONrwRKXYip-Pie7jtbEARpWwgxfw
<mterry> kgunn_, I'll make one and assign to me
<kgunn_> ack
<kgunn_> mterry, wait.... dandrader|lunch might have fixed this?
<mterry> kgunn_, he was doing rotation work...  I don't recall him mentioning a fix for this, but that would be a nice bonus!
<kgunn_> mterry, yeah...hmmm, dunno what changed, but i can see the text box....looks like he resized the osk ?
<mterry> kgunn_, dandrader|lunch: well https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1401951
<ubot5> Launchpad bug 1401951 in unity8 (Ubuntu) "[greeter] Password entry isn't visible when OSK appears in tablet mode" [Undecided,New]
<mterry> kgunn_, I guess mark in progress then?  His branch is cleared to land if I recall
<kgunn_> ack
<willcooke> Saviq, heyhey - can you tell me the magic incantation to get wm working?  I have to modify Shell.qml ?
<tsdgeos> greyback: not thrilled about it, but seems to work https://code.launchpad.net/~aacid/qtmir/create_observer_sooner/+merge/244622
<greyback> willcooke: 	gsettings set com.canonical.Unity8 usage-mode Windowed
<willcooke> Saviq, scratch that.  Just works
<willcooke> thx greyback
<tsdgeos> greyback: will gladly accept architectural suggestions
<greyback> tsdgeos: will have a look, thanks
<seb128> willcooke, greyback, Saviq: I updated ubuntu-settings to set that key on desktop, should work out of the box with vivid from today
<seb128> on desktop-next
<greyback> seb128: ah nice
<willcooke> seb128, \o/
<seb128> willcooke, I mentioned it early on #ubuntu-desktop btw, but I guess you didn't follow the channel today :-)
<seb128> willcooke, feeling better btw?
<willcooke> seb128, not really, but rickspencer3 is a slave driver :)
<seb128> lol
<kgunn_> mzanetti, so should seb at a toggle for windowed vs full screen shell mode ?
<mzanetti> kgunn_: where?
<kgunn_> in system settings
<kgunn_> just thinking...maybe a user might wanna override
<mzanetti> hmm... not sure we want that
<kgunn_> back to hypoth-generator
<mzanetti> yeah... I guess it would a good task to figure what we want the user to be able to change
 * greyback eow
<greyback> o/
<Saviq> o/
#ubuntu-unity 2015-12-07
<vila> goood morning all !
 * vila facepalms, wrong channel ;) 
<tsdgeos> Saviq: do you run proposed?
<tsdgeos> Mirv: do the Qt 5.5 packages contain the debian/patches/add_qdeclarative_playlist.patch patch?
<Mirv> tsdgeos: yes, although only to the extent it has been upstreamed. I'm waiting for the approvals in upstream for the rest.
<Mirv> so eg moveItem is missing
<tsdgeos> Mirv: Saviq was complaining that he didn't get Playlist for example :S
<Mirv> tsdgeos: it should be no worse than Qt 5.4 on xenial, since there was no landing of the latest features in xenial anyway
<Mirv> tsdgeos: so the patch is now this upstream http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/tree/debian/patches/Added-new-playlist-QML-type.patch?h=ubuntu from August
<Mirv> tsdgeos: I think though that because the media-hub etc haven't landed on xenial in a long time, the QML Playlist patch is "too new" as media-hub would possibly be using the obsolete API features (also gone from vivid-overlay now)
<Mirv> vivid-overlay is where Jim has switched to the approved upstream API + additions he's upstreaming, while xenial is stuck with the legacy API since there has been no landing
<tsdgeos> that's bad
<tsdgeos> we're supposed to be able to develop on xenial
<seb128> things are not supposed to not land in the current serie
<seb128> the packages from the ppa should be copied over to xenial
<Mirv> tsdgeos: yeah, there was no good options since xenial is outdated anyhow. now that the silo 009 finally landed to vivid-overlay, I think you could ask Jim to handle xenial next
<tsdgeos> Mirv: also the imports are different
<tsdgeos> vivid+overlay package exports the new classes as part of 5.4
<tsdgeos> and the xenial as 5.6
<tsdgeos> not nice either
<tsdgeos> or at least http://anonscm.debian.org/cgit/pkg-kde/qt/qtmultimedia.git/tree/debian/patches/Added-new-playlist-QML-type.patch?h=ubuntu does
<Mirv> tsdgeos: ok, I don't know about what has been landed in vivid+overlay, I've just tried to push very hard for upstreaming to avoid similar problems that we had with audio role
<tsdgeos> not sure what xenial does
<Mirv> tsdgeos: the git is what's now in xenial (and in upstream)
<tsdgeos> yes but if we start lying the version the code was introduced in a distro patch
<Mirv> tsdgeos: two weeks ago I diff:d the vivid+overlay landing and asked for upstreaming the remaining features that were neither in xenial Qt 5.4 nor in upstream
<tsdgeos> we can't change that version in the next release
<tsdgeos> and pretend we never introduce the feature earlier
<tsdgeos> how am i again supposed to maintain compatibility if the things under me change
<Mirv> tsdgeos: can you file a bug and assign that to Jim? I try to help where I can, but he needs to know what is still to-do.
<Mirv> he's now done a good job switching vivid-overlay to "almost upstream", but xenial is totally unworked currently
<Mirv> for any next new multimedia feature, it'd be nice to revert the current landing process "1. vivid-overlay, 2. xenial, 3. upstream (rejected)" to "1. upstream (accept), 2. xenial, 3. vivid-overlay" as it should be.
<Mirv> the former happened with audio overlay and also with playlist except that we're still stuck in the point "1." partially
<Mirv> audio role, I mean
<Mirv> tsdgeos: if you want me to do something with the existing options, the choices are current near-upstream API but media-hub have not seen xenial landings, or the now obsolete API that is compatible with what's in xenial but incompatible with vivid-overlay. the latter is what was there before the Qt 5.5 landing.
<tsdgeos> Mirv: i'll open a bug and see how we can proceed with this mess :/
<Saviq> tsdgeos, no, I installed silos 12 + 59 (which is ~equivalent to running proposed today)
 * Saviq reads uo
<Saviq> *up
<Mirv> tsdgeos: thanks
<tsdgeos> Saviq: you installed those silos on phone or pc?
<tsdgeos> don't think it matters i guess
<Saviq> tsdgeos, both
<Saviq> ok so we're fooked, can't land inline audio anyway
<Saviq> grrr
<Saviq> tsdgeos, you filing a bug?
<tsdgeos> yeah i will
<Saviq> tsdgeos, ok, let me know I'll escalate
<tsdgeos> Saviq: will take a bit want to flash the phone and check a few things first
<Saviq> ack
<deenlee> o_O
<tsdgeos> Saviq: does the bug description make sense to you? https://bugs.launchpad.net/ubuntu/+source/qtmultimedia-opensource-src/+bug/1523407
<ubot5> Ubuntu bug 1523407 in qtmultimedia-opensource-src (Ubuntu) "Playlist support in vivid+overlay and Xenial is different/non compatible" [Undecided,New]
<Saviq> tsdgeos, while the description makes sense, I wonder what would the correct solution be... I've a feeling when we're backporting features from future, we should only export them at the version it's ultimately going to land at... otherwise we'll have to carry a patch forever, exporting at more than one version
<tsdgeos> hmm
<tsdgeos> yeah, that's what probably makes more sense, i agree
<tsdgeos> Saviq: want me to assign that bug to Jim?
<Saviq> tsdgeos, I'll take care
<tsdgeos> oki
<Saviq> Mirv, what do you think ââ?
<tsdgeos> mzanetti: Saviq: need your input in https://code.launchpad.net/~aacid/unity8/drag_with_quicklist/+merge/279420 as what you think the scope of the MR is
<Saviq> tsdgeos, yeah fine with me, was wondering that myself
<mzanetti> need to test it to see the issue
<Saviq> mzanetti, it's just that there's no fade-{out,in} of the two quicklists
<mzanetti> ah ok...
<mzanetti> don't touch that yet
<mzanetti> the quicklist will get new visuals
<mzanetti> tsdgeos, ^
<tsdgeos> k
<Saviq> tsdgeos, in that case I'm moving all the audio-card-unrelated MPs into silo 22 and give silo 4 back to PaweÅ
<tsdgeos> ok
<tsdgeos> we were so close :/
<Mirv> Saviq: I'm not sure with regards to the declared versions - was tsdgeos' async image loading feature done in any better way? I mean, what happens with that when we hit 5.6 proper.
<Saviq> Mirv, you drop the patch
<Saviq> Mirv, and everything Just Works
<Saviq> Mirv, assuming the backport is actually API-compatible with upstream, which your "upstream first" approach should ensure, right?
<Saviq> Mirv, ultimately, all's fine when we do this with "private" APIs that we can control the use of
<Mirv> Saviq: yes the async image loading was certainly backported only after tsdgeos had upstreamed it. I just was asking if there's anything from there for Jim to learn, how to handle the backports from 5.6/5.7.
<Mirv> the current qtmultimedia proposals Jim is trying to get upstreamed will go to Qt 5.7 so we will live with backports for a while.  https://codereview.qt-project.org/#/q/project:qt/qtmultimedia,n,z
<Saviq> Mirv, I *think* the async image providers were kinda different in that they're not directly used by apps usually
<Saviq> Mirv, so we get the dpkg dependency chain we want
<tsdgeos> yeah it's not even exported to QML
<tsdgeos> so it's indeed a bit different in that regard
<Saviq> well, that doesn't mean they can't compile against it, but yeah, more care is needed anyway
<Saviq> for anything that's exposed to apps, public API that we want to commit to, we need to have a plan going forward
<Mirv> Saviq: right, so these multimedia feature are probably the only ones we've contributed as really new public facing features
<Saviq> Mirv, the other one comes to mind are multimedia roles
<Saviq> Mirv, while not meant for public consumption on our platform, still it's API we've published
<Saviq> and had to do #ifdefs and other hutzpahs around
<Mirv> Saviq: I missed one "s" but I meant these multimedia features, audio roles and playlist
<Mirv> Saviq: which is why I said that the next multimedia feature would be nice on the track of 1. upstream (accepted) 2. xenial 3. vivid-overlay - but even with that there would need to be a plan on how to handle the actual backport, the core of the tsdgeos's bug.
<Saviq> Mirv, agreed, and we seem to agree that this should be exported into QML as the version it will end up on in the long run
<Saviq> Mirv, only way we can drop the patch after we get to that version, 'innit? otherwise we'd need to keep a patch porting it back to 5.4/5.5 or whatnot
<Mirv> Saviq: yes, your comment #1 in that bug is correct
<cimi> tsdgeos, do we have a silo with all filters?
<tsdgeos> cimi: yes
<tsdgeos> let me find it
<tsdgeos> cimi: https://requests.ci-train.ubuntu.com/#/ticket/506
<tsdgeos> but status doesn't look good :S
<tsdgeos> give it a try
<tsdgeos> pawel is out today it seems
<tsdgeos> ah yeah he needed to go to the embassy
<cimi> tsdgeos, this seems like a simple approve, anything I am missing? https://code.launchpad.net/~aacid/unity8/thread_warning/+merge/279276
<tsdgeos> cimi: i'd say no, but it's my code D:
<tsdgeos> i mean the point of the RR is someone else thinking of something i may have nto tought
<cimi> indeed, so seems fine for me :)
<mzanetti> cimi, hey, wanna test/review this? https://code.launchpad.net/~mzanetti/unity8/launcher-updates/+merge/278567
<cimi> mzanetti, sure
<cimi> mzanetti, I read was wip, I can go
<tsdgeos> mzanetti: dednick: Saviq: do we have any bug about "press indicators bar to go back to live call not working"?
<tsdgeos> i'm looking at the code and seems it broke at some point
<tsdgeos> onPressedChanged in __showDragHandle doesn't seem to trigger with pressed = true
<Saviq> tsdgeos, don't think we've a bug
<tsdgeos> ok, i'll try to reproduce the thing on the meizu and present MRs about it
<tsdgeos> basically i just have to call and swipe the phone app to not be the focused on, right?
<tsdgeos> or there's something else needed for that to be supposed to work?
<dednick> tsdgeos: hm. havent seen it. maybe some of the work ltinkl was doing on desktop indicators may have broken it. i havent done much in there in ages
<dednick> tsdgeos: thats it. just unfocus phone (eg open dash) and it should sho
<ltinkl> hmm, might be me yes :/
<ltinkl> tsdgeos, ping me if you find something ood
<davmor2> ltinkl: found something ood for you https://demonsrun.files.wordpress.com/2013/09/planet-of-teh-ood.png
<ltinkl> :)
<dandrader> greyback, something I've been wanting to do for a long time now https://code.launchpad.net/~dandrader/qtubuntu/loggingCategory/+merge/279629
<greyback> dandrader: nice!!!
<jhodapp> tsdgeos, what's the issue?
<tsdgeos> jhodapp: xenial code is different from vivid code
<jhodapp> tsdgeos, yeah, we're working on porting to GStreamer 1.6.x for both codebases and then we can dual land everything media
<tsdgeos> dandrader: ltinkl: it works for some reason I read the code like it wouldn't but testing shows it works
<tsdgeos> jhodapp: i see
<ltinkl> tsdgeos, good
<dandrader> tsdgeos, missing context
<dandrader> tsdgeos, what's that about?
<tsdgeos> dandrader: it wanted to say dednick, sorry
<dandrader> right. the good old autocomlete issue :)
<dednick> huh :)
<tsdgeos> we need to architecture teams in a way in which only a given letter for a team member :D
<tsdgeos> dednick: the call hint thing, it works fine
<dednick> hehe
<dednick> tsdgeos: ok.
<dednick> yeah. get rid of duplicate people rather than changing names.
<ltinkl> tsdgeos, just got an idea, now that the UITK has its own native bottom edge component, why not use it in dash?
<dednick> meh. silo out of space again...
<dednick> mzanetti: ^
<ltinkl> tsdgeos, it's nice that it's clickable here, but then I can't swipe it with my finger :)
<ltinkl> tsdgeos, the AddressBook app has it correct, it works with both things
<tsdgeos> ltinkl: sounds good, i'm doing something similar with the DirectionalDragArea -> SwipeArea
<tsdgeos> ltinkl: open a bug or a trello card
<tsdgeos> ltinkl: or do a branch :D
<ltinkl> tsdgeos, yea, will do something :)
<mzanetti> dednick, ack, pinged the trainguards
<tsdgeos> dandrader: what do you think of https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/swipeAreaPressedSignal/+merge/279780 ?
<mterry> Anyone else seeing the latest rc-proposed image not booting?
<dandrader> tsdgeos, need to add a test
<tsdgeos> dandrader: sure, was just asking about the general idea
<tsdgeos> looks ok?
<dandrader> tsdgeos, think so. still downloading the branch to take a better look
<tsdgeos> k
<dandrader> tsdgeos, this web diff kinda crappy
<tsdgeos> will add the test
<tsdgeos> dandrader: is this http://bazaar.launchpad.net/~aacid/ubuntu-ui-toolkit/swipeAreaPressedSignal/revision/1734 the kind of test you wanted?
<dandrader> tsdgeos, yeah
<jhodapp_> tsdgeos, btw, you can also track the syncing between vivid+overlay and xenial in this silo: https://bugs.launchpad.net/ubuntu/+source/qtmultimedia-opensource-src/+bug/1523407
<ubot5> Ubuntu bug 1523407 in Canonical System Image "Playlist support in vivid+overlay and Xenial is different/non compatible" [High,Confirmed]
<jhodapp_> tsdgeos, wrong link, one sec
<jhodapp_> https://requests.ci-train.ubuntu.com/#/ticket/751
<tsdgeos> jhodapp_: makes sense ahving this link in the trello card?
<jhodapp_> tsdgeos, absolutely if it's not there already
 * tsdgeos checks
<jhodapp_> it is
<tsdgeos> :)
<jhodapp> tsdgeos, any other issues that are blocking this landing that you're aware of?
<tsdgeos> jhodapp: no, it seemed to work good enough in vivid+overlay
<jhodapp> tsdgeos, excellent news
<jhodapp> tsdgeos, after we sync gstreamer versions, we'll be able to dual land just about everything in the media stack
<tsdgeos> awesome :)
<jhodapp> which will avoid this issue for the future
<mterry> Saviq, I saw that my wakelock fix MPs were marked superceded -- there was a new branch needed?  some bug fix or something?
<Saviq> mterry, conflict with multiSurfaceApp
<mterry> ah
<Saviq> mterry, so yeah, you might wanna look at the diffs if I broke something
<Saviq> when resolving
<mterry> ah I'm sure it's fine, but sure I'll look
<tsdgeos> dandrader: have a sec?
<dandrader> tsdgeos, yep
<tsdgeos> dandrader: so the new Swipe area doesn't have sceneDistance property just distance, is there any easy way to port a code that is using one to the other? I'm specially strugging with the EdgeDragEvaluator of DragHandle
<tsdgeos> seems like the distance is reset while the sceneDistance continues to grow (if testing with DDA)
<dandrader> tsdgeos, IIRC, SwipeArae::distance == DirectionalDragArea::scenedistance
<tsdgeos> hmmm
<tsdgeos> ok i'll triple check
<enes> halp unity8 wont load
<enes> on ubuntu 15.10
#ubuntu-unity 2015-12-08
 * lpotter does a happy dance
<Saviq> lpotter, congratz? :)
<lpotter> :) thanks
<Saviq> cimi, need to un-rebase https://code.launchpad.net/~cimi/unity8/shadow-ubuntu-store-icon/+merge/279588
<Saviq> lpotter, welcome back, then?
<lpotter> yep. but not until January
<Saviq> nice
<cimi> Saviq, pushing in a sec
<sil2100> Saviq: you want me to force merge silo 14 so that the commits are in the stable branch?
<Saviq> sil2100, I'll take care, thanks
<Saviq> sil2100, oh, I can't
<Saviq> sil2100, yeah, please merge
<sil2100> Saviq: ok :)
<Saviq> mzanetti, we didn't get any design concept for the internal screen "control panel" did we?
<mzanetti> Saviq, I got something from paty now
<mzanetti> saviq, not really official by design, but looks professional enough :)
<mzanetti> let me forward it
<mzanetti> saviq, not all of it makes sense, but she's on hols this week
<Saviq> mzanetti, ack
<seb128> Saviq, "control panel" being settings?
<Saviq> seb128, yeah
<seb128> Saviq, mpt did that some months ago, see Display on https://wiki.ubuntu.com/SystemSettings
<seb128> but yeah, that's only for the pocket pc and probably assuming you don't change resolution on the phone
<seb128> so no internel screen
<Saviq> ack
<Saviq> greyback, which thread would you say is blocking here http://paste.ubuntu.com/13823412/
 * Saviq thinking #1
<Saviq> can't find dbg syms for lttng though
<greyback> Saviq: "info threads" please
<mpt> Saviq, what does the internal screen need settings for?
<greyback> Saviq: is that on shutdown?
<greyback> looks more like a startup hang
<greyback> thread2 looks strange
<greyback> ah, I've seen seens the mock papi sensors backend causing trouble like this
<Saviq> greyback, that's on startup
<Saviq> greyback, http://pastebin.ubuntu.com/13823540/
<mzanetti> gaaaah! cursor gone
<greyback> Saviq: I suspect thread2, blocking thread1
<Saviq> greyback, ack
<Saviq> mterry, hey, looks like we've test failures in your branches http://pastebin.ubuntu.com/13823824/
<mterry> Saviq, huh...
<mterry> ok am looking
<Saviq> mterry, not necessarily your branch, maybe some interaction with the others in silo
<Saviq> mterry, https://code.launchpad.net/~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-022 is the branch
<mterry> Saviq, th
<mterry> x
<Saviq> greyback, bug #1523926 fwi
<Saviq> w
<ubot5> bug 1523926 in platform-api (Ubuntu) "Dummy sensor backend can block" [Undecided,New] https://launchpad.net/bugs/1523926
<mterry> Saviq, yeah looks like a variable got renamed in one of the other branches.  Will change in my branch and ping you in a sec
<Saviq> mterry, ack
<mterry> ah.. but I need your branch not mine
<mterry> Saviq, done.  lp:~unity-team/unity8/fix-wakelocks is updated
<Saviq> mterry, tx
<then4116_> Ahoy
<then4116_> I'm trying and failing to edit a launcher. Specifically, I want VLC to start in fullscreen, and play a certain stream
<then4116_> the following works from the shell:
<then4116_> vlc rtsp://user:password@hostname:554/path/media.amp?resolution=1280x720\&videocodec=h264 -f
<then4116_> but I can't seem to put it in a launcher
<then4116_> never mind
<dandrader> dednick, around?
<dednick> dandrader: whats up?
<a1fa> which file is the main unity config?
<nicomachus> hi! do you guys do any support here?
<a1fa> my unity config is so screwed up, i dont even get wm out of it
<a1fa> i removed .config/unity and .config/compiz-1
<a1fa> what else do i ened to remove
<a1fa> dconf --reset org/compiz worked
<a1fa> i had some gtk 3.0 css files as left overs
#ubuntu-unity 2015-12-09
<Saviq> Mirv, hey, any progress on Qt migration?
<Mirv> Saviq: a pkg-kde-tools upload from Kubuntu broke half of the autopkgtests, so the night was pretty much wasted. otherwise it was sounding promising yesterday evening with me and xnox removing possibly the last blockers - even though the Qt migration is now mixed with poppler transition and s390x architecture transitions
<Mirv> Saviq: unfortunately the xenial is ever moving target...
<Saviq> Mirv, ack
<Saviq> Mirv, silos 12+59 still good enough for testing things on top, though>
<Saviq> ?
<Mirv> Saviq: should be yes (for phone)
<Mirv> Saviq: latest qtbase changes are just test and s390x fixes
<Mirv> (in proposed)
<Saviq> Mirv, why the qtmir-gles change btw? the added dependency on libqt5test5? plain qtmir doesn't have that?
<Saviq> is it because of the -gles dependencies?
<Mirv> Saviq: some autopkgtest cmake error was seen that seemed like missing test library: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/q/qtmir-gles/20151207_224906@/log.gz - even though it doesn't show up in normal recompilation
<Mirv> Saviq: so I did a blind upload based on that error and then it seemed fixed https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/q/qtmir-gles/20151208_213113@/log.gz (until this pkg-kde-tools broke it again but that's another story)
<Mirv> Saviq: not really sure of the real cause, but the failure was only seen with qtmir-gles. some of the -gles packages earlier have needed more hand-guiding apt than the normal packages.
<Saviq> Mirv, ack
<Mirv> Saviq: hey btw I'm not sure what's the level of interest but I'm quite far with Qt 5.5 backport to vivid-overlay at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+packages
<Mirv> Saviq: not for landing but if anyone is interest in even giving a thought if it's a possibility one day.
<Saviq> Mirv, ack
<Saviq> tsdgeos, mzanetti, rc-proposed/silo22 has listviewforreviews, but Telegram preview still blocks for a long time when I first try to scroll... ideas?
<mzanetti> hmm, really
<mzanetti> was quite smooth for me when I tried in the review
 * mzanetti tries
<mzanetti> Saviq, while you're on rc-proposed. is authenticator working for you?
<mzanetti> it locks up for me when I click on the "generate pin" button
<mzanetti> indeed, tg reviews locking up here too
<tsdgeos> Saviq: no ideas
<mzanetti> much longer than when I tested that branch
<tsdgeos> let me flash it
<Saviq> mzanetti, yeah, auth works
<mzanetti> dafuq
<mzanetti> it happened to me already a month ago
<mzanetti> noone else complained
<mzanetti> then it recovered
<mzanetti> now it locks up again for me
<Saviq> tsdgeos, mzanetti, yeah when I tested the preview in silo 4 before, it was good, too
<Saviq> it's like something else made it worse
<Saviq> gah
<Saviq> aaargh why do I have silo 4
<Saviq> tsdgeos, as you were, citrain'ed wrong silo
<Saviq> mzanetti, â
<tsdgeos> Saviq: and mzanetti?
<mzanetti> ?
<Saviq> good question, mzanetti, apt-cache policy unity8?
<mzanetti> 8.11+15.04.20151126-0ubuntu1
<mzanetti> update in the queue
<Saviq> mzanetti, that's from silo 22?
<mzanetti> gaaah
<mzanetti> I thought it would be in rc-proposed
<mzanetti> released already, I mean
<Saviq> mzanetti, ok so yeah, as you were, my bad
<Saviq> biab
<pete-woods> mzanetti / Saviq: hey. was hoping for some QML advice. I've cooked up a quick app to do VPN connection editing
<pete-woods> one of this things I want to do is have a (apparently complicated) combo box
<pete-woods> I can't get the ubuntu one to behave itself
<mzanetti> pete-woods,
<pete-woods> I've had no trouble with the QtQuick one
<pete-woods> http://paste.ubuntu.com/13856153/
<mzanetti> have a snippet of code I could test?
<pete-woods> mzanetti: is the full file http://paste.ubuntu.com/13856197/
<pete-woods> if I try and use Ubuntu's OptionSelector, the layouts don't work
<pete-woods> it stays 1 "widget" high
<pete-woods> instead of expanding
<pete-woods> tbh I don't really want it to expand the whole view at all
<pete-woods> I just want it to hover over the top
<pete-woods> like a normal combo box
<pete-woods> (like the QtControls one does)
<mzanetti> we're talking about "Virtual device type" right?
<pete-woods> yeah
<mzanetti> ack. gimme a few
<pete-woods> there's other funky stuff like if you stick an OptionSelector in a Row element, you get an infinite loop
<pete-woods> but it at least doesn't crash with RowLayout
<pete-woods> I'd be happy using QtQuick controls
<pete-woods> but it's not installed on the phone
<pete-woods> apologies also that the connection object has an absolute crap ton of properties
<pete-woods> it seems like we avoid all these widgets in the ubuntu system settings app
<pete-woods> and have a whole page with a listview in it
<pete-woods> instead of a combo box
<mzanetti> yeah...
<pete-woods> maybe I need to do the same
<mzanetti> pete-woods, one option would be this: http://paste.ubuntu.com/13856360/
<mzanetti> (not sure if you have a design that says you need to use the other)
<pete-woods> mzanetti: no design here
<pete-woods> this is just a hacked up thing to show my QML bindings work to QA
<pete-woods> (and also to have a bit of a practise with QML)
<pete-woods> I have other combo boxes that have a lot of options in, btw
<pete-woods> this one just happens to have two
<pete-woods> I think what I really need to do is make everything into clickable columns
<pete-woods> flickable
<pete-woods> like they do in the settings app
<pete-woods> and stop the manual layout stuff
<pete-woods> oh, you've done something with z
<pete-woods> I guess that puts it on the top, or something
<mzanetti> pete-woods, this is with OptionSelector: http://paste.ubuntu.com/13856449/
<mzanetti> I agree it's not nice... the OptionSelector is known to be quite bad
<mzanetti> pete-woods, well, I did use the z:2 because the popup for the combobox would otherwise be behind the items below
<mzanetti> which I'd say is a bug in the SDK
<pete-woods> right now I don't have the experience with QML or the brain space to take on bugs like that
<pete-woods> but if your fix works then that's fantastic :)
<mzanetti> yeah, I guess a report for the SDK guys would be a good start :)
<mzanetti> in your layout I think the ComboButton option looks better
<mzanetti> yeah, you could also drop the manually added text
<mzanetti> and put everything in a phone-style column
<mzanetti> dunno.
<pete-woods> if I'd known what I was doing, I've have used the phone style column from the start
<pete-woods> hmm, combobox needs a lot of massaging
<pete-woods> it doesn't close when you pick an item
<greyback> tsdgeos: having network issues?
<tsdgeos> greyback: yeah :/
<mterry> ltinkl, are you using clang or something instead of gcc?   (am I?  /me checks)
<mterry> Just curious why I didn't see the warnings
<ltinkl> mterry, it's OK, scratch that... I don't see any warnings
<mterry> Oh good
<ltinkl> mterry, I reverted the change
<mterry> ltinkl, about the translations in your diff -- did you say a bot did that automatically?  I didn't think the bot ran on non-trunk branches
<ltinkl> mterry, ye... it came as a surprise to me as well but it must have run somehow
<ltinkl> mterry, the updated PO files contain the newly added strings (which I reverted since then so it should return back to normal, hopefully)
<mterry> revno: 2035
<mterry> committer: LukÃ¡Å¡ Tinkl <lukas.tinkl@canonical.com>
<mterry> branch nick: oobe
<mterry> timestamp: Mon 2015-12-07 15:14:40 +0100
<mterry> message:
<mterry>   update POT
<mterry> ltinkl, ^
<ltinkl> mterry, that's POT, not PO
<Saviq> ltinkl, ltinkl, we're updating .pot now in the train
<Saviq> *translations* get pushed to trunk directly by LP
<ltinkl> mterry, I only updated the template so that the translators could do their work once this has been merged
<Saviq> ltinkl, no need to do that btw â
<ltinkl> Saviq, ye OK but still... how did the translations end up in a non-trunk branch?
<mterry> ltinkl, they come from your merges.  But you shouldn't have a diff from that
<ltinkl> Saviq, you still need to update the _template_ right?
<mterry> ltinkl, I'm doing (bzr log po/ia.po)
<Saviq> ltinkl, no, template is now updated automagically on release
<ltinkl> Saviq, that is too late
<Saviq> ltinkl, no it's not, people can't translate before anyway (not via LP at least)
<ltinkl> Saviq, it means the moment you release the stuff with new strings you still have not up-to-date translations
<mterry> ltinkl, translators aren't seeing your branch before it lands in trunk anyway...
<Saviq> ltinkl, and avoids conflicts
<mterry> ltinkl, we have a string freeze
<ltinkl> ok
<ltinkl> still doesn't explain how the new translations landed in a non-trunk branch
 * ltinkl is puzzled
<mterry> ltinkl, also I still am not sure how you're out of sync with translations -- but maybe do a bzr pull in a trunk branch and copy all the po files over to get back in sync
<ltinkl> mterry, yeah, guess I'll do that... then we'll rely on the bot to do the merge again, once it lands in trunk
<mterry> ltinkl, or do a bzr revert -r for a trunk revision, if you can untangle the bzr mess
<Saviq> ltinkl, fwiw http://bazaar.launchpad.net/~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-022/revision/2096 this is what the bot does after it merges all branches and such
<ltinkl> Saviq, so it lands the translations and _then_ updates the POT file?
<mterry> ltinkl, no it updates POT file, we release
<ltinkl> ah ok
<mterry> ltinkl, then a separate bot periodically updates translations
<Saviq> ltinkl, not translations, translations are put on top to trunk directly
<mterry> directly to trunk
<ltinkl> I see, ok :)
<mterry> ltinkl, so can you ask the ofono folks if they know if that mcc table exists anywhere already, and if not, where might be a good place to add it?
<mterry> I bet some other component will want it at some point
<mterry> System Settings for example?
<ltinkl> mterry, sure, any idea who do I talk to?
 * mterry wracks his brain...   tiagosh?  I can't remember who all works on it today
<mterry> ltinkl, ^
<ltinkl> mterry, pushed the trunk translations, the diff now looks much better :)
<mterry> Looked him up on directory, his title is "Telephony & Messaging Engineer" so that sounds right  :)
<mterry> ltinkl, nice
<mterry> :)
<ltinkl> mterry, still doesn't fit but well... half of the size gone
<mterry> ltinkl, hah, I'll take what I can get
<Saviq> hmm hmm, greyback, dandrader, I've noticed a few times now with silo 22 that an app surface is all black until I interact with the phone, I'm thinking fillMode has an issue, wdyt?
<greyback> Saviq: would be likely culprit. Anything printed in the unity8.log?
<Saviq> qtmir.surfaces: MirSurface[0xc1bc68,"messaging-app"]::dropPendingBuffer() dropped=0 left=2 - failed to upate texture
<Saviq> not sure that's it though
<Saviq> as it was dialer this time
<Saviq> qtmir.surfaces: MirBufferSGTexture: bind() called but there's no mir buffer to bind to
<Saviq> greyback, how's that look â?
 * Saviq tries to repro
<greyback> dandrader: ^^ you wrote that code, any ideas
<greyback> I personally think it's a mir problem, there should never be a situation where there's no buffer available after first frame posted
<tsdgeos> dandrader: https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/fixSwipeAreaPrivateLeak/+merge/280039
<Saviq> greyback, in other news, https://code.launchpad.net/~saviq/qtubuntu/wrap-sort/+merge/279778 please?
<Saviq> greyback, and corresponding https://code.launchpad.net/~phablet-team/qtubuntu/gles-sync/+merge/279779
<ltinkl> tsdgeos, why not make UCSwipeAreaPrivate a QScopedpointer instead?
<tsdgeos> ltinkl: why make it a QScopedPointer?
<ltinkl> tsdgeos, if it is already a QObject, then ye, it makes sense what you did; I thought it wasn't
<tsdgeos> ltinkl: if it wasn't a QObject I could not do what i did
<Saviq> mzanetti, double-check https://code.launchpad.net/~unity-team/qtmir/surfaceItemFillMode/+merge/279757 for me please? it's just a resubmission
<Saviq> greyback, same for https://code.launchpad.net/~unity-team/qtmir/multiSurfaceApp/+merge/279759 please
<Saviq> dandrader, don't see an approval on https://code.launchpad.net/~dandrader/unity8/multiSurfaceApp/+merge/279112 or the ones it supersedes?
<Saviq> or https://code.launchpad.net/~dandrader/unity8/surfaceItemFillMode/+merge/279010
<Saviq> tsdgeos, you were having a look at https://code.launchpad.net/~saviq/unity8/in-train-pot-update/+merge/279100 - others agree it's fine
<dandrader> Saviq, how common is tha black window issue
<Saviq> dandrader, seen it 3-4 times now
<tsdgeos> Saviq: sure, want me to top approveÂ¿?
<Saviq> tsdgeos, yes please
<mzanetti> Saviq, want me to test it again?
<Saviq> mzanetti, no, rather just sanity-check the diff
<mzanetti> Saviq, ok. done
<Saviq> dandrader, so yeah, it does look like the bind() message is related, IIUC before we'd bind anyway, unless built with asserts?
<Saviq> obviously no steps to repro :/
<Saviq> greyback, so wdyt â? while I understand it's a Mir issue, the result of https://code.launchpad.net/~unity-team/qtmir/surfaceItemFillMode/+merge/279757#diff-line-58 is that we're getting black
<dandrader> Saviq, greyback I was getting this black frames issue all the time after merging trunk in fillModes weeks ago, after having that branch lying around for quite a long time. turned out to be a small detail in the merge (aka bad merge)
<Saviq> where before we'd just go "meh, let's bind anyway"
<dandrader> Saviq, greyback hopefully it's something similar again
<greyback> dandrader: have you time to look into it? Or should I?
<dandrader> greyback, you would be the safest option. I only have a couple of hours till EOW
<greyback> ok
<Saviq> greyback, thanks, IMO that's blocking silo 22 now
<greyback> Saviq: what device you testing on, in case it's more easily repro-ed on that
<Saviq> greyback, only seen on krillin
<greyback> Saviq: ok
<Saviq> greyback, will start AP on mako and monitor unity8.log
<Saviq> oh fun, stopped unity8 mid-rotation :)
<Saviq> greyback, grepping through unity8.log I can see a few dozen of those messages on either krillin or mako
<greyback> hrmph
<greyback> this displeases me
<Saviq> and yeah already got 3 of those after having started u8 ap tests
<Saviq> can't confirm it's ending up black, but reading the code it has to, doesn't it
<Saviq> as the texture's bound to 0
<Saviq> so it's like hasBuffer() is lying?
<Saviq> since everything is fine if we ignore its output?
<dandrader> Saviq, can't reproduce it on N7
<Saviq> dandrader, yeah I wasn't able to find steps to repro, but the bind() message gets printed relatively often
<Saviq> greyback, the app lifecycle ap tests seem to be a semi-reliable way to see the bind() msg, not necessarily black app, though
<Saviq> but that's likely because I don't notice it, not that it's not there
<greyback> Saviq: ack, have got it myself
<Saviq> josharenson, ok, so it seems to be as simple as that: cmake -DCMAKE_BUILD_TYPE=Release and it won't build
<Saviq> josharenson, we're building Debug by default
<josharenson> Saviq: yup can confirm
<Saviq> josharenson, now that doesn't sound like a valid situation though
<josharenson> it breaks
<Saviq> /methinks it warrants a bug against the toolchain
<josharenson> agreed
<Saviq> josharenson, so according to doko (our toolchain expert) this might very well happen
<Saviq> hmm clearing one thing up
<Saviq> josharenson, doko asked for us to file a bug anyway to clear this up, I'll try and create a minimal project that shows the issue tomorrow
#ubuntu-unity 2015-12-10
 * josharenson is all ears
<josharenson> ack
<Saviq> moin
<Saviq> tsdgeos, linker Q... given libraries A and B, B referencing a symbol in A, would you expect an "undefined reference to..." error to depend on what flags you build *B* with?
<tsdgeos> Saviq: yep
<tsdgeos> not all linking makes the linker complain about missing symbols
<tsdgeos> sometimes it goes for "ok maybe we get that later"
<tsdgeos> i think
<Saviq> tsdgeos, case in point: Josh's greeter links to liblightdm-qt5-3, builds fine everywhere, except on xenial when CMAKE_BUILD_TYPE=Rel*
<Saviq> when it fails to find QLightDM::SessionsModel::roleNames(), which, btw, is not implemented in there, but SessionsModel inherits QAbstractItemModel
<Saviq> so that's what it relies on elsewhere
<tsdgeos> weird
<Saviq> separate point is that it uses deprecated setRoleNames
<tsdgeos> are we sure that's not a dirty builddir or something?
<Saviq> yes
<Saviq> tsdgeos, https://code.launchpad.net/~josharenson/unity8/sessions-model/+merge/278081/comments/707133 is where the failure first happened, then I managed to track it down to build type
<Saviq> it fails in all builds on xenial there with "undefined reference to `QLightDM::SessionsModel::roleNames() const'"
<Saviq> but builds fine on vivid, and when CMAKE_BUILD_TYPE=Debug
<tsdgeos> maybe lightdm-qt is actually broken in xenial?
<tsdgeos> is that the lightdm we build or the real thing?
<Saviq> the real thing, built from lp:lightdm
<Saviq> tsdgeos, fwiw readelf shows the QAbstractItemModel::roleNames symbol
<Saviq> which ~makes sense since that's where it needs to come from, as QLightDM::SessionsModel does not implement it at all
<Saviq> so yeah, well, a separate question altogether is whether it works or not (and that it should be updated to non-deprecated roleNames())
<Saviq> but that seems to be a behaviour change at least between gcc 4.9 and 5.0 or something
<Saviq> and I'm not totally sure which one's wrong :)
<tsdgeos> that's weird yeah
<Saviq> FWIW readelf on vivid shows the same symbols
<tsdgeos> so this is only the session-chooser branch?
<Saviq> sessions-model, yes, there's new code where Josh actually makes use of more of the QLightDM implementation
 * Saviq makes a minimal example and files a bug against gcc
<tsdgeos> Saviq: about setRoleNames it works fine from what i can see in the code
<tsdgeos> hmm, but i had built the session-chooser branch
<tsdgeos> i guess because i did a dewbug build?
 * tsdgeos checks
<Saviq> tsdgeos, yeah the default build is debug, try with ./build.sh Release
<tsdgeos> Saviq: yeah can confirm, it's really weird, can't figure it out either what could be wrong
<Saviq> tsdgeos, ok /me filing a toolchain bug
<tsdgeos> yeah we'd need someone with more knowledge to have a look really
<Saviq> greyback, what do you say we undo that one change in Daniel's branch for now, it wasn't necessary for fillMode to work was it?
<Saviq> greyback, or at least modify it to put out the warning but still behave as before
<Saviq> tsdgeos, the plot thickens, http://pastebin.ubuntu.com/13889040/ builds fine regardless
<tsdgeos> Saviq: interesting
<greyback> Saviq: modification would be possible, just lines 278-296 of the diff actually implement the feature
<greyback> I've still not figured out root cause
<Saviq> tsdgeos, d'oh!
<tsdgeos> Saviq: what's wrong?
<Saviq> tsdgeos, most likely something along the lines of http://paste.ubuntu.com/13889709/
<tsdgeos> so the mocks are breaking stuff
<tsdgeos> might be
<Saviq> confirming now
<Saviq> tsdgeos, yeah, that + a missing CMAKE_CURRENT_BINARY_DIR for the .moc, makes it build
<Saviq> sessionbackend test fails, but that's an issue I'll leave to Josh
<tsdgeos> Saviq: it's weird that only happens on release though :S
<Saviq> tsdgeos, we do enable -Werror on release, but not in debug - while weird, it might make the difference (will confirm)
<Saviq> greyback_, so wdyt, unblock silo 22 by going back to original behaviour of ignoring hasBuffer() for now?
<greyback_> Saviq: it's what I'm testing now
<Saviq> greyback_, ah koolz, tx
 * Saviq looks sideways at all the branches will have to rebase
<Saviq> tsdgeos, so yeah, only difference in the g++ command seems to be -O2 -DNDEBUG, I say the mocks get the symbol optimized away
<tsdgeos> probably
<Saviq> so it works in debug, even if linking against the wrong .so, but not in release
<Saviq> and it "works", by chance, simply
<Saviq> and in vivid it might not have been optimized away because with gcc 4.9 but is in xenial with 5.0
 * Saviq happy it's not a toolchain issue, and that he's not completely dumb
 * Saviq deserves food
<mzanetti> wheee! I'm back
<Saviq> @unity, dednick: standup
<mterry> ltinkl, btw I rebuilt the oobe silo this morning
<ltinkl> mterry, great thx
<mzanetti> Saviq, there is an "Echo" option in mumble
<mzanetti> it was set to "Mixed". I've set it to "Disabled" now. let's see how that goes :D
<mzanetti> echo -> disabled
<mzanetti> makes total sense
<Saviq> mzanetti, and that's not echo cancellation?
<mzanetti> it probably is
<mzanetti> but setting it to anything else than "disabled" doesn't seem to help either
<mzanetti> so...
<Saviq> mzanetti, I think you were talking with Daniel about app resizing, the only artifact I can see now is that when resizing vertically, stuff jumps up/down, as if it was anchored to bottom left corner instead of top left?
<mzanetti> hmm
<Saviq> ok so maybe I'm wrong and you didn't talk about this, will have a chat when he's back
<mzanetti> not this...
<mzanetti> Saviq, but it's been ages since I tested/reviewed this stuff
<mzanetti> iirc I did test that
<mzanetti> might be a bad merge after the review
<Saviq> mzanetti, so you mean you didn't see that behaviour?
<Saviq> mzanetti, can you still check in silo 22?
<Saviq> I won't block on that anyway as it's a big improvement, but we'll need to follow up
<Saviq> so anyway, no need for you to test really
<Saviq> mzanetti, â
<tsdgeos> Mirv: any idea why the ubuntu-ui-toolkit package didn't migrate to main from proposed yet?
<mzanetti> Saviq, ack (had to reboot)
<Saviq> tsdgeos, DON'T!...
<Mirv> tsdgeos: see any other channel like #ubuntu-devel. britney did interesting trade of keeping it in proposed due to s390x build issues. working on it.
<Saviq> tsdgeos, britney is software, fwiw ;)
<tsdgeos> ok
<Saviq> tsdgeos, it's Qt 5.5, new poppler *and* new architecture all at the same time :)
<mzanetti> Saviq, so you mean the content of the surface being jittery?
<Saviq> mzanetti, yes, but more that its top-left corner isn't stab;le
<mzanetti> Saviq, still content? or windeco itself?
<Saviq> mzanetti, still content, say "System settings" in settings app
<mzanetti> Saviq, ack, confirmed. will follow up on it
<Mirv> Saviq: and new apt...
<Mirv> which uncovered regressions in aptdaemon/python-apt/...
<Mirv> all in a nice big bundle
#ubuntu-unity 2015-12-11
<traccart> um.. last update removed unity8-desktop-session-mir package
<traccart> ^^ 16.04
<duflu> traccart: What happens if you try to put it back?    sudo apt-get install unity8-desktop-session-mir
<tsdgeos> traccart: xenial?
<tsdgeos> yeah the current status is a bit borked
<tsdgeos> the new toolkit hasn't landed yet
<tsdgeos> so stuff is a bit "on the edge"
<tsdgeos> apt wants me to remove unity8 too :D
<duflu> Such is the dependency graph
<duflu> Gets out of hand some times
<tsdgeos> yep
<duflu> Sadly lots of large package dependency graphs are probably avoidable. One or two removals from them can make a dramatic difference. So developers really should treat package dependencies with more caution
<traccart> duflu, tsdgeos yep 16.04 if i add unity8 session it removes something else :))
<traccart> either way i get a broken unity8
<Saviq> traccart, yes, you'll need to wait some time for this to get resolved or get a package or two from proposed
<traccart> i'll wait :D
<traccart> for snappy muhahaha
<Saviq> traccart, https://requests.ci-train.ubuntu.com/#/ticket/771 this is where the underlying cause is being handled
<traccart> i see, thanks Saviq
<tsdgeos> cimi: the bug in vivid-overlay preventing the filters stuff seems to have landed, could you give it a final review?
<tsdgeos> cimi: it just landed, so you'll need a dist-upgrade, is not in the image yet
<cimi> tsdgeos, ok
<cimi> tsdgeos, can I use silo 54?
<tsdgeos> cimi: i think it should be fine, anything wrong?
<tsdgeos> pstolowski: ââ
<pstolowski> cimi, sure you can. no promise though about it, we were not able to test end-to-end yet
<maikeul> hi
<maikeul> i have issue running Xmir on an ubuntu phone, the mir connection is rejected by the server and I just cannot find a log or indications on how to allow this.
<sil2100> Trevinho: hey!
<Trevinho> sil2100: hi
<sil2100> Trevinho: I was looking at publishing silo 11 for you, but I would like for a small change before we go on that would require a rebuild
<sil2100> *like to ask
<Trevinho> sil2100: ok, sure
<sil2100> Trevinho: so, the thing that worried me is this merge - not content wise, but how the train handled it:
<sil2100> https://code.launchpad.net/~unity-team/unity/python3-ready/+merge/276746
<sil2100> Trevinho: because you touched the changelog, the train basically did not include the commit message of this change in the end changelog
<sil2100> Trevinho: meaning there's an undocumented change now
<sil2100> Trevinho: could you take this branch, do a dch -i in it, paste the commit-message as part of the new changelog entry and try to rebuild unity?
<sil2100> Trevinho: since in cases where you touch the changelog, you need to explicitly write the commit message for the merge inside the changelog
<sil2100> Otherwise the train assumes you did that and doesn't really do it for you
<Trevinho> sil2100: what's
<Trevinho> sil2100: sorrry it was a mistake that "what's"... :-D
<sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-011-2-publish/1/artifact/unity_xenial_packaging_changes.diff <- and in the end package you can see that the mention of changing to python3
<sil2100> Is missing
<sil2100> (damn, I have issues typing today)
<sil2100> ;p
<sil2100> Another issue, but that's a nitpick and I guess we can ignore it, is in bamf:
<greyback> Mirv: hey, I'm getting a qtcreator crash on startup on vivid+overlay, here's a backtrace: http://pastebin.ubuntu.com/13927939/
<sil2100> Trevinho: https://ci-train.ubuntu.com/job/ubuntu-landing-011-2-publish/1/artifact/bamf_xenial_packaging_changes.diff <- the train suddenly decided to change the 0replaceme in the changelog to a version number ;p ;p
<Trevinho> oh, nice :-D...
<Trevinho> mh, I guess I can fix both
<sil2100> Trevinho: would be nice to fix that but not required, it's just a nitpick
<sil2100> I'm more concerned with the unity one :)
<sil2100> Trevinho: just remember that to fix it in bamf, you need to modify the changelog and remove the 0replaceme (or rename to something like 0-replaceme etc.) and then add the commit message to the changelog manually
<sil2100> Trevinho: but as I said, this is something we can even fix later
<Trevinho> oh.... well, no ok I'll fix it later then :-D
<Mirv> greyback: it's the same that kenvandine reported for system-settings. not deeemed critical as it's desktop only, and started with OTA 8.5 hotfix. you can install https://requests.ci-train.ubuntu.com/#/ticket/761 for a fix.
<greyback> Mirv: perfect, thanks
<sil2100> Trevinho: anyway, thanks!
<Trevinho> sil2100: thank you!
<Trevinho> sil2100: poackage is building,,..
<bregma> maikeul, you will need to add '-mir APPID' to the XMir command line or else the Mir server will reject the connection
<bregma> APPID is a valid app-id
<maikeul> thanks, how do you know about APP-Ids ?
<bregma> maikeul, the app-id generally matches the .desktop file name of an application
<tsdgeos> cimi: dednick: what do you think of https://code.launchpad.net/~aacid/ubuntu-settings-components/standarizeImports/+merge/280303 ?
<cimi> tsdgeos, we should indeed now
<cimi> tsdgeos, however we need to update the APIs if there are ubuntushape and such...
<tsdgeos> cimi: do we really need to update the APIs? there otld ones also work, no?
<cimi> tsdgeos, it works even without updating I think, but we should anyway...
<tsdgeos> cimi: i see tst_ files
<tsdgeos> but how do i run them?
<cimi> if there is a button and we bump to uitk 1.3 and such, we can
<tsdgeos> make check and make test do not do much
<tsdgeos> s/much/anything
<tsdgeos> cimi: also if you see i have not chagned any ubuntu.components
<tsdgeos> just qtquick and ubuntu.compoonets.listitem
<tsdgeos> so any ubuntushape is not changed
<cimi> tsdgeos, yeah, I would change it though too
<cimi> since we use 1.3 in shell
<cimi> and everywhere else
<tsdgeos> you would change what?
<cimi> uitk to 1.3
<tsdgeos> it is already there
<cimi> ah cool
<tsdgeos> it can not be changed to itself :D
<cimi> :D
<cimi> must forgot we did update months ago maybe :)
<cimi> ok so it's a no brainer for me
<cimi> tsdgeos, we need the checklist in the description
<tsdgeos> cimi: which checlist?
<tsdgeos> unity8's? or there's one for ubuntu-settings-componetnts?
<cimi> tsdgeos, https://wiki.ubuntu.com/Process/Merges/Checklists/Ubuntu-Settings-Components
<tsdgeos> k tx
<tsdgeos> cimi: i only need to test the indicators, right? or there's something else i need to test?
<cimi> just indicators I think
<cimi> there is a test file
<cimi> example
<cimi> qmlscene something.qml in the tree
<cimi> or unity8 indicators
<tsdgeos> k
<Trevinho> sil2100: I think you can publish that now :-)
<ChrisTownsend> Hey guys, any guesses when things will be straight in the archive so apt will no longer want to remove unity8 in xenial?
<tsdgeos> ChrisTownsend: i think https://requests.ci-train.ubuntu.com/#/ticket/771is it
<tsdgeos> https://requests.ci-train.ubuntu.com/#/ticket/771
<ChrisTownsend> tsdgeos: Ah, ok, that's the culprit.  Thanks!
<Saviq> ChrisTownsend, oh, was it you that unity8 locked up for without gstreamer registry?
 * Saviq vaguely remembers trying to debug that with someone... and it could've been you
<ChrisTownsend> Saviq: I think that was me.
<Saviq> ChrisTownsend, good news: not just you
<ChrisTownsend> Saviq: lol, good
<maikeul> bregma: thanks, I still had the issue and i finally found out that the issue was with the default software of the phone. I reflashed it and now everything works fine
<Saviq> ChrisTownsend, it seems today it's 100% reproducible: delete the registry file, you're stuck
<Saviq> ChrisTownsend, so that's actually a good thing :)
 * Saviq in the process of filing bug
<ChrisTownsend> Saviq: My question is, why is the registry file being removed????
<Saviq> ChrisTownsend, it might never have been there
<Saviq> ChrisTownsend, or needs updating
<Saviq> ChrisTownsend, something of the sort
<bregma> it shouldn't need to be there, it's just a cache
<ChrisTownsend> Saviq: Hmm, ok.  Well, it seems if there is a bug in the Unity8 desktop, I'll find it:)
<Saviq> ChrisTownsend, good going!
<bregma> ChrisTownsend is *the* unity 8 desktop usere
<ChrisTownsend> bregma: The only one, right?:)
<bregma> I suspect
<bregma> everyone else just install it, brings it up, says "OK, cool" and moves on
<bregma> distro-hoppers
<ChrisTownsend> lol
<Saviq> ChrisTownsend, bug #1525285
<ubot5> bug 1525285 in qtmultimedia-opensource-src (Ubuntu) "/usr/bin/unity8:6:__GI_ppoll:ppoll:gst_poll_wait:exchange_packets:plugin_loader_free" [Undecided,New] https://launchpad.net/bugs/1525285
<ChrisTownsend> Saviq: Thanks, that is indeed the issue I ran into back when.
<Saviq> ChrisTownsend, do you recall when that was? like 2 weeks ago at least, right?
<Saviq> ChrisTownsend, and you didn't, by any chance, have the Qt 5.5 packages installed? :)
<Saviq> was that even xenial?
<ChrisTownsend> Saviq: Hmm, seemed longer than that.  I'll look through my chat logs.
<Saviq> tx
<ChrisTownsend> Saviq: Oct. 26
<Saviq> ChrisTownsend, ack, almost two months, then
<ChrisTownsend> Saviq: Yep, and I'm pretty sure I had Wily on that machine then.
<Saviq> jhodapp, it was ChrisTownsend back thenÂ â, almost two months, likely with wily still
<jhodapp> Saviq, ok, I do remember discussing something about a deadlocked Unity8 on startup...seems this is the same thing and person
<Saviq> jhodapp, might very well be, a bit more detail hopefully
<Saviq> jhodapp, I wonder if this is specific to a certain plugin
 * Saviq tries to remove gst-plugins.* packages one by one
<jhodapp> Saviq, I believe it was if I remember correctly, but my memory is hazy on this
<Saviq> or would you say not worth it?
<Saviq> jhodapp, ok, trying
<jhodapp> no I think it would be worth trying
<sil2100> Trevinho: thanks, let me take a look agian :)
<maikeul> does this error rings a bell for you : 'error securing buffer...' when running an X11 app (see http://pastie.org/private/n1gdprpgngyaoqhowfdzla )
<maikeul> same with -mir or -desktop_file_hint when running Xmir
<Saviq> jhodapp, down to good and base, still hanging
<Saviq> not gonna remove those, might not recover ;P
<Saviq> owait, dpkg -r to the rescue
<jhodapp> :)
<Saviq> jhodapp, no plugins, still hanging
<jhodapp> Saviq, wow
<jhodapp> Saviq, it might very well be the QtMultimedia and GStreamer integration
<Saviq> jhodapp, well, ok, there's still some plugins that are not gstreamer1.0-plugins*
<Saviq> jhodapp, trying to get rid of those too
<jhodapp> k
<Saviq> ! progress
<Saviq> jhodapp, hah! clutter plugin seems to be the culprit
<jhodapp> Saviq, oh wow
<jhodapp> Saviq, did it change recently then?
<jhodapp> we should file that upstream then
<Saviq> jhodapp, only we'd have to convince them that's their issue ;)
<jhodapp> :)
<Saviq> jhodapp, https://launchpad.net/ubuntu/+source/clutter-gst-3.0 not much going on
<Saviq> jhodapp, but it's difficult to say when this happened, since the registry updates fine outside of the unity8 session, at which point unity8 session won't hang either
<Saviq> since the registry won't need updating
<jhodapp> Saviq, yeah
<jhodapp> Saviq, looks like this was the latest gst related source file to change: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/clutter-gst-3.0/wily/view/head:/clutter-gst/clutter-gst-video-sink.c
<jhodapp> Saviq, it's possible the regression is in this change: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/clutter-gst-3.0/wily/revision/7#clutter-gst/clutter-gst-video-sink.c
<Saviq> jhodapp, /me installing wily version
<jhodapp> k
<Saviq> jhodapp, hangs as well
<Saviq> jhodapp, I'll try the other wily versions
<jhodapp> Saviq, ok, I wonder if Unity8 creates just the right scenario for clutter to hang that maybe upstream has never seen
<Saviq> jhodapp, we're not using clutter at all, that might be it :D
<jhodapp> ha
<jhodapp> ok
<Saviq> jhodapp, even the earliest wily version has the same issue
<jhodapp> wow
 * Saviq checks clutter 2.0
<jhodapp> Saviq, that was quite a large change to clutter for that first version
<jhodapp> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/clutter-gst-3.0/wily/changes?filter_file_id=cluttergstvideosink.-20150614041526-zq0eiljaby1bo65k-95
<jhodapp> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/clutter-gst-3.0/wily/changes?filter_file_id=cluttergstvideosink.-20150614041526-zq0eiljaby1bo65k-95
<jhodapp> oops
<Saviq> jhodapp, well, we'd have to compare with 2.0
<Saviq> but that's no longer there in xenial
<Saviq> owait
<jhodapp> agreed
<jhodapp> Saviq, look at line 53: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/clutter-gst-3.0/wily/revision/1#clutter-gst/clutter-gst-plugin.c
<Saviq> yay
<jhodapp> Saviq, this would happen when the plugin is loaded via the registry
<Saviq> nice one
<jhodapp> thanks, there's a good chance that's it
<Saviq> jhodapp, let me compile without that def
<jhodapp> ok
<Saviq> jhodapp, check out line 2093 http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/clutter-gst-3.0/wily/revision/1/clutter-gst/clutter-gst-playback.c#clutter-gst/clutter-gst-playback.c
 * Saviq says the threads call should be protected with that
<jhodapp> Saviq, yeah
<Saviq> there's more instances like that
<jhodapp> Saviq, so we would no longer have CLUTTER_WINDOWING_X11 be true with Unity8 right?
<Saviq> jhodapp, that's my thinking
<Saviq> jhodapp, I mean, we don't
<jhodapp> Saviq, can you put a #error in there to double check?
<Saviq> jhodapp, but it's only the _check_windowing... that checks runtime
<Saviq> the other is build time
<Saviq> which is obviously wrong
<jhodapp> ok
<Saviq> because it goes "if built with X11 support, means you're running under X11"
<jhodapp> exactly
<jhodapp> what if we still had the build time requirements satisfied
<jhodapp> for X11
<Saviq> jhodapp, that's where the additional check comes in
<Saviq> jhodapp, http://paste.ubuntu.com/13935011/
<jhodapp> Saviq, what's that from?
<jhodapp> Saviq, are we missing that?
<Saviq> jhodapp, that's my patch... unfortunately not enough it seems
<Saviq> it might be we're actually passing that runtime check, too
<jhodapp> indeed
<jhodapp> you already tried commenting out XInitThreads() completely?
<Saviq> not yet
<jhodapp> ok
<Saviq> trying that now
<jhodapp> ok
<Saviq> jhodapp, hmm that this code was wrong I've almost no question, but that doesn't seem to be enough unfortunately
<jhodapp> Saviq, that sucks
<jhodapp> I think we're on the right trail though
<Saviq> jhodapp, FWIW we have a bug that they might actually accept... running gst-inspect-1.0 hangs in vt (without X11)
<jhodapp> Saviq, ah a very good point
<sil2100> Saviq: hey! A quick question - do you have any knowledge about the ubuntu-application-api3-examples package?
<Saviq> sil2100, little, greyback might be better, but let's try
<greyback> Depends on the question :)
<sil2100> greyback: so my question is very simple - do we need it in our images? Since the xenial touch seeds have it included
<greyback> sil2100: no reason that I can think of
<sil2100> I'm doing some minor cleanup removing some api2 leftovers, was wondering if I should add it to vivid as well
<sil2100> Ok
<sil2100> greyback: thanks, good enough for me ;)
<greyback> np
<Saviq> jhodapp, can you confirm these steps please
<Saviq> - log in on vt (with no graphical session)
<Saviq> - rm ~/.cache/gstreamer-1.0/registry.x86_64.bin
<Saviq> - gst-inspect-1.0
<Saviq> - behold
 * Saviq can't store in LP for some reason
<jhodapp> Saviq, sure
<jhodapp> Saviq, seems to have completed successfully for me
<Saviq> jhodapp, oh hm, wonder if there's something else that makes this go wrong
<jhodapp> Saviq, might be, I'm running wily
<Saviq> ChrisTownsend, ltinklcan you guys check those steps â?
<Saviq> that's enough to exercise the deadlock (which happens in the clutter gst plugin for me)
<Saviq> jhodapp, OTOH http://tronche.com/gui/x/xlib/display/XInitThreads.html says it will go ack/nack, maybe it doesn't need the wrapping check
<Saviq> which would ~explain that it doesn't help us
<jhodapp> Saviq, yeah, the compile time check is practically worthless as well
<Saviq> jhodapp, it is, on WIN32 ;)
<jhodapp> :)
<a1fa> is it me, or is unity blocking arbitrary mutli touch?
<a1fa> "Unity reserves to itself gestures with 3 and 4 gestures making impossible to TouchÃ©gg make use of it.
<a1fa> is there a config toggle to disable unity gestures, or are we still stuck having to compile it/remove it from source?
<greyback> a1fa: you referring to unity7? If so, I don't know how to turn that off, aside from not using the unity plugin in compiz
<a1fa> heh
<a1fa> the only thing i am missing from unity at this point is "swipe left, swipe right" integration with chrome
<traccart> ah unity7
<traccart> nope
<a1fa> looks like touchegg can takeover 2 finger gestures
<a1fa> if you disable all synclient options
<a1fa> -_-
<a1fa>  but then you loose ability to scroll in unity
<a1fa> -_-
#ubuntu-unity 2015-12-12
<McIntireEvan> Anyone have experience with the Hint class? Im trying to understand what arg1, arg2, and arg3 are supposed to be but Im not having much luck
#ubuntu-unity 2016-12-12
 * mterry hugs tsdgeos
<tsdgeos> :)
<tsdgeos> you have to land it before Sawicz comes back from the holidays ^_^
<mterry> heh
<mterry> dednick: which silo are you working on?
<dednick> mterry: i've just put all the menu stuff in 2291
<mterry> dednick: is that like a mega silo situation or just your stuff silo?  (i've got a branch I want to stick in the next silo, but I hadn't thought we'd got one yet)
<dednick> mterry: that's just my stuff at the moment.
<mterry> k
<dednick> should probably see if there is a current "next realease" one though.
<mterry> Maybe I'll start the silo for landing after 2150 and 2160
<mterry> We've got quite a queue already
<dednick> mterry: well the menu work needs to land so...
<dednick> if you want to add to it.
<mterry> dednick: I didn't want to junk up your testing silo, but I could if ya wanna use it for that
<dednick> mterry: it's not really a testing silo. i intend that to be the landing on for menus.
<mterry> ok
<mterry> dednick: ok added mine
<ltinkl> mterry, I believe the miral silo is slated to be the next one
<ltinkl> mterry, https://bileto.ubuntu.com/#/ticket/2160
<mterry> ltinkl: it is, I mentioned 2160 above, but I'm trying to plan the NEXT next one  :P
<ltinkl> mterry, ah :)
<mterry> greyback, dandrader: fyi I published silo 2150 a little while ago; when it lands you'll want to rebase your miral branches on trunk and we can rebuild 2160 for landing
<dandrader> mterry, already did
<dandrader> mterry, just didn't hit the "build" yet as 2150 still hasn't really landed
 * dandrader anxious to get 2160 in
<mterry> :)
#ubuntu-unity 2016-12-13
<mterry> Does anyone know why xvfbtestPreview in silo 2150 would segfault?  It's holding up our migration to release pocket in zesty
<mterry> greyback, dandrader: ^ relevant to you
 * dandrader looks
<greyback> mterry: no idea. /me tries to repro locally
 * mterry also tries locally
<dandrader> mterry, any useful log?
<mterry> No
<mterry> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/i386/u/unity8/20161213_162531_a0c3e@/log.gz
<mterry> Search for "error 2"
<mterry> Or xvfbtestPreview
<mterry> It passes all tests
<mterry> Then it segfaults
<Saviq> not just that one, there's like a dozen segfaults
<mterry> Both amd64 and i386 fail
<Saviq> 10, actually
<mterry> Right you are
<Saviq> and yeah, both amd64 and i386, so not random
<Saviq> something must've changed between silo and proposed, since we're green in automated
<Saviq> I mean comparing these logs might be helpful https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2150-excuses/2016-12-07_23:50:01/2150_zesty_excuses.html
<mterry> Saviq: wait aren't you on vacation?
<Saviq> ish
<mterry> get outta here
<Saviq> promised to keep an eye out
<mterry> ah
<Saviq> anyway, it's in your hands so no need for me
<mterry> :)
<greyback> "Qt: Session management error: Could not open network socket" <- was this always printed on the console while running tests? (I get it locally, it's not printing on the server)
<greyback> so far, tests are running ok locally
<greyback> might be something in proposed breaking it
<mterry> greyback: I don't recognize the error...  But yeah I bet proposed is the trigger
 * mterry is still updating his zesty system, haven't used it for a bit since I've worked on u8 snap in xenial
<greyback> QT_LOGGING_RULES=*=false needed for tests, as they're so noisy
<mterry> ok I do get the segfault on proposed
<greyback> mterry: what segvs? xvfb?
 * greyback not had luck with his chroot
<mterry> greyback: yeah it seems to only segfault with xvfb in the mix
<mterry> But I'm not sure it's xvfb itself
<mterry> I'm trying to isolate which package upgrade triggers it
<mterry> stacktrace is in libgcc code, so something might need a rebuild against latest gcc
<mterry> it's libmesa
<greyback> oh man
<mterry> rebuilding it to see if it just needs a rebuild against latest gcc and everything.  If that doesn't fix it, I'm out of my depth and Mirv seems out for the holidays
<mterry> I suppose we could drop it from proposed in worst case
<dmj_s76> Trevinho: I've had a chance to test the new unity hdpi scaling factor code on a wider range of hardware now, and think there are some cases where it doesn't do quite the right thing.
<dmj_s76> It does do the right thing for 15" 1080P displays and 15" 4K displays, but forces non-integer scaling by default on 17" 4K displays and 14" 1080P displays.
<dmj_s76> At least with existing toolkits, non-integer scaling tends to look somewhat wrong.
#ubuntu-unity 2016-12-14
<dmj_s76> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1649736
<ubot5`> Ubuntu bug 1649736 in unity (Ubuntu) "unity picks poor hidpi scale factor defaults" [Undecided,New]
<Trevinho> dmj_s76: mh, intresting, can you please try to debug to see what's the correct value? Unfortunately I've not such wide hardware to test, so... it's not easy for me
<Trevinho> andyrock: too ^^^^
<andyrock> rounding to integer makes sense to me
<mterry> dandrader|afk, greyback: ok 2150 is landing, will be able to start 2160 for realz in a few seconds
<greyback> mterry: nice work, thank you
<mterry> mesa is still a problem, looks like someone just pushed u8 through anyway -- so it may hit your autopkg test runs
<mterry> greyback: the branches in 2160 need updating
<mterry> 2150 merged to trunk, should be fine to merge now
<greyback> mterry: yep known, dandrader is on it
<dandrader> mterry, qtmir there needs mir 0.25, but silo https://bileto.ubuntu.com/#/ticket/2180 still stuck
<mterry> ah cool
<dandrader> maybe I was too proactive :)
<cimi> pstolowski, josharenson I created a silo 2302 for https://code.launchpad.net/~josharenson/unity-scopes-shell/fix-overview-results-sorting/+merge/313075 pawel, can you have a look at it too?
<pstolowski> cimi, oh, nice finding from josharenson, thanks! yes, i will take a look, but probably tomorrow
<josharenson> pstolowski: thanks
<dmj_s76> Trevinho: andyrock: Rounding to integer makes the most sense to me as well.  There are some hardware vendors that pick displays that won't be ideal (3K panels on a 15" laptop being the most obviously bad.)
<dmj_s76> However the pathological displays out there really have no good (feasible) solution: On a 3K display  2x scaling results in effectively 720p, which will be a little too big for most while 1x scaling will be a little too small.  1.5x scaling there will result in just-right size, but bad, hacky widget rendering.
<dmj_s76> We should probably not even try to know what's right for those displays, since 1x vs 2x is a matter of preference between eagle-eyes who want more space and the bifocal crowd that wants bigger widgets, and non-integer scaling rendering issues *by default* would make Ubuntu look bad and unpolished.
<dmj_s76> Trevinho: andyrock: Take 140dpi as our "ideal" like we're doing now, but round to the nearest whole integer.
<andyrock> dmj_s76: oki i'll preper a branch tomorrow
<andyrock> a good solution would be to round up just the gtk scaling to the clostest integer
<andyrock> e.g. right now if the scaling is 1.75 the gtk scaling is 1
<andyrock> 2 would make more sense
#ubuntu-unity 2016-12-15
<cimi> pstolowski, morning! any chance you had a look at josh MP? https://code.launchpad.net/~josharenson/unity-scopes-shell/fix-overview-results-sorting/+merge/313075
<pstolowski> cimi, heya, not yet, but will do today
<Bernmeister> Asked this in #ubuntu-desktop and was redirected here: I have developed a number of appindicators using Python3/GTK+3 under Unity 7.  I recently tried running those indicators using Ubuntu 16.10 in the Unity 8 session and they didn't exactly run.  Will appindicators developed in Python3/GTK+3 be supported in Unity 8?
<rvr> How can the gesture wizard be disabled in Unity8? It's annoying and I can't properly use it in qemu.
<davmor2> rvr: there is a first time run line you can add somewhere let me find it
<davmor2> rvr: touch .config/ubuntu-system-settings/wizard-has-run
<rvr> davmor2: Dave to the rescue. Thanks, dude!
<pstolowski> cimi, hey, is josh off today?
<cimi> pstolowski, it's 5:57am for him
<cimi> pstolowski, wait 1h30m or 2
<pstolowski> cimi, ah, I didn't realize, thanks
<pstolowski> josharenson, hey
<josharenson> pstolowski: hello
<pstolowski> josharenson, i've looked at your MR for shell plugin, nothing wrong with it afaict but can you help me understand where we iterated "hundreds of thousands of times" in the existing implementation?
<josharenson> pstolowski: I looked at it for a long time and couldn't figure it out myself... but I put a counter in the loop it replaced and it was iterating 130,000 times (for 17 scopes, moving item in position 16 -> 0 )
<pstolowski> huh
<josharenson> pstolowski: after a while, i decided just to sort everything :-p
<pstolowski> josharenson, this is a single for loop with a map-based lookup... shouldn't happen in theory
<josharenson> pstolowski: it wasn't hitting the increment operator because of the continue statement
<pstolowski> josharenson, that's true, i was pondering that...
<pstolowski> josharenson, but it's not obvious to me why it's so devastating in it
<josharenson> pstolowski: I'm sure there is a solution to the existing code, probably just a small off by 1 error or something...
<josharenson> pstolowski: but the output was so odd, I couldn't figure it out
<pstolowski> josharenson, one more thing... your code doesn't need the "pos + (pos > i ? 1 : 0))" kind of shift in beginMoveRows, correct?
<josharenson> pstolowski: I don't think so because it only ever moves items up...
 * josharenson should probably test it a bit more
<josharenson> pstolowski: all the reasonable edge cases that I could think of to test manually worked
<pstolowski> josharenson, ok, thanks
<pstolowski> josharenson, I've yet to test it, a little hard when i only have vivid phone/tablet
<josharenson> pstolowski: thats all I've been testing it on... built it on the device in a chroot
<josharenson> pstolowski: I can try and send you debs if you want?
<pstolowski> josharenson, that would be great1
<josharenson> pstolowski: give me a few minutes, I haven't actually tried building the packages, just been installing locally
<josharenson> pstolowski: hum debuild fails on installing libscope-harness.so.2 even though it exists and there is a .install file for it
<pstolowski> josharenson, scope harness lib is built as part of the unity-scopes-shell build
<josharenson> pstolowski: http://pastebin.ubuntu.com/23634609/
 * josharenson is trying a few things..
<pstolowski> josharenson, can you just send me the .so file?
<josharenson> pstolowski: libscope-harness?
<pstolowski> josharenson, no, the plugin
<pstolowski> from src/Unity/... after you build locally
<josharenson> pstolowski: sure one moment
<josharenson> pstolowski: sent, that was easier...
<pstolowski> josharenson, yeah.. thanks, i'll take a look at this tomorrow, it's getting late. o/
<josharenson> pstolowski: cool, thanks o/
<dmj_s76> andyrock: Think we can produce a good scaling outcome with a one line change...testing now
<Bernmeister> I have developed several Unity 7 appindicators using Python3/GTK+3.  I tried running those indicators in the Unity 8 session of Ubuntu 16.10 and they didn't exactly run.  Can someone tell me please if appindicators developed in Python3/GTK+3 be supported in Unity 8?
#ubuntu-unity 2016-12-16
<pstolowski> cimi, morning! approved https://code.launchpad.net/~josharenson/unity-scopes-shell/fix-overview-results-sorting/+merge/313075 with just one remark - would be nice to remove the extra empty line before landing
<pstolowski> cimi, btw, while testing this I found https://bugs.launchpad.net/bugs/1650494 which is unrelated to his changes (we have this issue with old code too)
<ubot5`> Ubuntu bug 1650494 in unity8 (Ubuntu) "Un-favoriting a scope after changing the order leaves gaps in Manage dash" [Undecided,New]
<pstolowski> cimi, I've added unity8 to that bug too, although I suspect it's probably shell plugin doing something wrong (no signaling changes properly or some such)
<mterry> @unity, everyone's CI jobs would have failed recently due to a non-existent 2263 silo.  I fixed our CI config to not use that anymore (it landed, PPA was deleted)
<ltinkl> mterry, thanks for that; yesterday I rebuilt manually https://code.launchpad.net/~lukas-kde/unity8/appdrawer-direct-search/+merge/313240 w/o the offending silo, it finished successfully but still no results show up in that MP, any idea?
<mterry> ltinkl: no not sure
<tsdgeos> meh
<tsdgeos> ok tx
<mterry> josharenson: lp:~mterry/unity8/simple-lightdm-mock has just the lightdm mock refactor split out
<mterry> I'm going to rebase a lot of my branches off that
<mterry> While I let the session-lightdm branch sit until I can get back to it
<mterry> Will do last minute check and proposal on Monday
<mterry> Eh, tests just finished and were good.  So here: https://code.launchpad.net/~mterry/unity8/simple-lightdm-mock/+merge/313478
#ubuntu-unity 2016-12-17
<dmj_s76> andyrock: Trevinho: I've uploaded a patch that should provide good scaling behavior.
<josharenson> mterry: just saw that, wonderful.. I have something to look forward to for Monday
#ubuntu-unity 2016-12-18
<chatter> hey guys
<chatter> allah is doing
<chatter> sun is not doing allah is doing
<chatter> to accept islam say that i bear witness that there is no deity worthy of worship except allah and muhammad peace be upon him is his slave and messenger
<danialbehzadi> Hi
<danialbehzadi> I am making an indicator for a service
<danialbehzadi> I should wait after clicking on an menu item, to let it connect to the server
<danialbehzadi> But when I use a while command, indicator doesn't response to anything
#ubuntu-unity 2018-12-11
<omarv> Hi all, help please,...I have the following issue: Xsession: unsupported number of arguments (2); falling back to the default session. It started just when I installed Deepin desktop environment (https://www.deepin.org/en), and trying to come back to 18.04 gnome desktop...any idea what is the problem and how to solve it ? thanks
