[09:44] <tsdgeos> Saviq: so what's the plan? first land 5.2 then new-scopes?
[09:44] <Saviq> tsdgeos, yeah
[09:44] <tsdgeos> ok
[09:44] <Saviq> tsdgeos, today is review day
[09:44] <Saviq> tsdgeos, please start looking at mterry's split greeter
[09:45] <tsdgeos> so https://code.launchpad.net/~unity-team/unity8/new-scopes-cleanup-5.2 is the "top branch" we want to merge
[09:45] <Saviq> tsdgeos, I'll go through that
[09:45] <tsdgeos> ok, i'll read mterry's code
[09:49] <mhr3_> Saviq, found the cause of the card hiccup?
[09:49] <Saviq> mhr3_, not yet, let me look at it now
[09:50] <Cimi> tsdgeos, we still have fails in qmltests
[09:50] <Saviq> mhr3_, can't get it to work still ;/
[09:50] <Cimi> tsdgeos, testLauncher
[09:50] <Saviq> mhr3_, src/capnp/layout.c++:1822: requirement not met: expected ref->kind() == WirePointer::STRUCT; Message contains non-struct pointer where struct pointer was expected.
[09:50] <Cimi> I don't think the launcher is flicking
[09:50] <Saviq> mhr3_, and restarting scope registry doesn't help
[09:50] <mhr3_> Saviq, restart smart-scope-proxy & scope-registry
[09:50] <tsdgeos> Cimi: it's on you then, i'm reading mterry's code now
[09:51] <mhr3_> Saviq, policy libunity-scopes0?
[09:51] <Saviq> mhr3_, right, so not only registry now...
[09:51] <Saviq> mhr3_, yeah, that helped
[09:51] <mhr3_> ok
[09:52] <seb128> marcustomlinson, hey
[09:53] <marcustomlinson> seb128: hey
[09:53] <seb128> marcustomlinson, what do you mean by "silo: <no silo>"? you are talking about landing/CI train?
[09:54] <marcustomlinson> seb128: yeah, I assume we still haven't got a silo. That branch fixes the issue and is complete.
[09:54] <seb128> marcustomlinson, I can put a landing ask/get a silo for the hud, but the merge request is still "needs review" and CI seems unhappy
[09:54] <seb128> e.g https://code.launchpad.net/~unity-api-team/hud/lp-1288025/+merge/209449/comments/496003
[09:54] <marcustomlinson> seb128: pete-woods just commented on the MR ;)
[09:55] <seb128> oh
[09:55] <pete-woods> seb128: ci is only unhappy because there's a dependent change in libdbusmenu-qt
[09:55] <seb128> pete-woods, marcustomlinson: qt5.2 is in trusty-proposed now, so should be fine to land hud soon ;-) Is the CI being unhappy on that merge request "normal"?
[09:56] <mhr3_> whaaat? 5.2 in proposed?
[09:56] <Saviq> mhr3_, yups
[09:56] <Saviq> mhr3_, found issue
[09:56] <mhr3_> how come i didn't get a OMG! mail?
[09:56] <seb128> pete-woods, if you need a libdbusmenu-qt change/update, you should update the build-depends on the version you need at least?
[09:56] <pete-woods> seb128: I have done
[09:56] <pete-woods> it's not just a single MR
[09:57] <seb128> oh, right
[09:57] <seb128> there is a pre-require branch
[09:57] <seb128> good
[09:57] <pete-woods> yes
[09:57] <pete-woods> or three :)
[09:57] <seb128> marcustomlinson, pete-woods: thanks ;-)
[09:57] <seb128> let's hope we can land soon
[09:57] <seb128> LTS coming :p
[09:57] <pete-woods> seb128: and don't worry, I will make sure I can search for préférences :)
[09:57] <seb128> (btw you might want to change the status to "approved" if it's approved)
[09:57] <seb128> pete-woods, thanks ;-)
[09:59] <pete-woods> seb128: I can't change them to approved, as I don't have a silo yet, so no-one can test them for me
[10:00] <pete-woods> (the rules say I have to test the builds that come from the silo)
[10:00] <Saviq> Cimi, tsdgeos, there's an issue with the dynamic carousel merge, there's a few places that reference "template" directly, not through cardTool still (i.e. CardFilterGrid.qml:27)
[10:00] <seb128> pete-woods, I don't see how changing to "approved" conflicts with the silo?
[10:00] <seb128> pete-woods, there is no automerging of approved branches anymore with CI train
[10:00] <pete-woods> I understand that
[10:00] <pete-woods> but isn't it wrong to approve them until they have been tested via the silo?
[10:01] <seb128> pete-woods, on other projects (e.g indicators, settings) we use approved as the list of things that are ready to be pushed through CI train
[10:01] <seb128> your project, your call
[10:01] <Saviq> Cimi, tsdgeos, results in broken apps card when searching (i.e. install click scope, restart scope-registry, ./builddir/tools/unity-scope-tool, search in Apps → no titles)
[10:01] <seb128> I understand/use it as
[10:01] <seb128> "approved = got review, should be ready to land"
[10:01] <seb128> review the approved changes
[10:01] <seb128> put them in silo
[10:01] <seb128> then we test the silo
[10:01] <seb128> and if it's green we press the land button
[10:02]  * Saviq reverts
[10:02] <seb128> which then upload/merge back
[10:02] <pete-woods> seb128: okay, if that's how you understand the process, then I will do that in future
[10:02] <Cimi> Saviq, let me fix it instead revert
[10:02] <seb128> pete-woods, thanks, but feel free to keep your workflow if it works for you, I'm not saying mine is the only valid one ;-)
[10:03] <Saviq> Cimi, k, let me know
[10:03] <seb128> pete-woods, the main advantage with the way I described is that +activereview give you a nice overview of what is ready to be put in a silo (= the approved changes)
[10:03] <seb128> otherwise you need to keep track mentally of what got reviewed/approved
[10:04] <pete-woods> that's a good point, and I would definitely prefer to do it this way, I just got a different interpretation of the rules when I read them
[10:04] <pete-woods> but if other teams are doing this, then I am happy
[10:04] <Saviq> pete-woods, there's no rule on that
[10:04] <Saviq> pete-woods, ci train doesn't even care about LP status, if you put the MP in it, it will merge it even if it's rejected
[10:04] <tsdgeos> Saviq: hmmm i think i had fixed that
[10:04] <tsdgeos> but maybe not
[10:05] <tsdgeos> E_TOO_MANY_BRANCHES
[10:05] <pete-woods> Saviq: I understand that, I just don't like getting blamed for breaking things because I didn't follow the Process
[10:05] <Saviq> tsdgeos, doesn't look like it, at least not in branches I'm looking at
[10:05] <Saviq> pete-woods, remember the process is yours, not anyone else's :)
[10:05] <seb128> pete-woods, as said, we do it this way for indicators and settings, so feel free to do it as well, it's fine by the rules ;-)
[10:06] <tsdgeos> new-scopes-cleanup is fine
[10:06] <tsdgeos> new-scopes-cleanup-5.2 is fine too
[10:06] <tsdgeos> Saviq: which branch are you on?
[10:06] <Saviq> tsdgeos, hmm tried on cleanup, maybe didn't pull
[10:07] <Saviq> tsdgeos, nothing to pull, did you search?
[10:07] <tsdgeos> Saviq: no, but it's not referencing template directly
[10:07] <Saviq> tsdgeos, ok, that doesn't fix the issue though
[10:07] <tsdgeos> that's a different thing :D
[10:08] <Saviq> tsdgeos, sure ;) /me pulls the fix to clean-to-trunk
[10:08] <tsdgeos> Cimi: can you have a look at it?
[10:08] <tsdgeos> or shall we both?
[10:10] <Saviq> Cimi, please fix on clean-to-trunk, not -cleanup, I was hoping for cleanup to only really do test fixes...
[10:11]  * Saviq reviews cleanup so that it gets in new-scopes sooner rather than later
[10:12] <Cimi> tsdgeos, I can
[10:12] <Saviq> ah, but we need 5.2-fixes on trunk first...
[10:12] <Cimi> I'll look at both
[10:12] <Cimi> having a coffee, had insomnia last night
[10:13] <Cimi> this friday seems like a classic monday :)
[10:13] <Cimi> but we all know that engineers have best ideas when they have lack of sleep, it's out environment
[10:13] <Cimi> *our environment
[10:15] <Saviq> mzanetti, review https://code.launchpad.net/~unity-team/unity8/fix-5.2-tests/+merge/209058 please?
[10:17] <Saviq> MacSlow, qml/Notifications/Notification.qml: bad whitespace in lines 42, 48
[10:17] <Saviq> MacSlow, in modal snaps
[10:17] <MacSlow> Saviq, already fixed
[10:17] <Saviq> MacSlow, ok
[10:17] <Saviq> MacSlow, what editor do you use?
[10:18] <Saviq> ah... insensible or whatever it's called
[10:18] <Saviq> MacSlow, sounds like you need to enable whitespace checks :)
[10:18] <Cimi> mmm
[10:18] <MacSlow> Saviq, sublime... as I can't stand QtCreators text-rendering :)
[10:18] <MacSlow> Saviq, is there any way to tweak Qt-text-rendering in some way... it always looks  a bit "fuzzy"
[10:19] <Saviq> MacSlow, no idea, check out 3.0 from -proposed, maybe that's better?
[10:19] <MacSlow> Cimi, ^ maybe you know
[10:20] <Cimi> MacSlow, my guess is using other ways to render text
[10:20] <anpok> with qtquick it might use the distance maps
[10:20] <MacSlow> Cimi, sure... it using a distance-field based texturing approach... compared to gtk+'s cairo/pango one
[10:21] <Cimi> MacSlow, http://blog.qt.digia.com/blog/2012/08/08/native-looking-text-in-qml-2/
[10:21] <tsdgeos> QtCreator is not QML guys
[10:21] <anpok> I thought parts of it are qml scenes..
[10:21] <tsdgeos> the welcome screen
[10:21] <MacSlow> anpok, also regular Qt-desktop apps look like they use the same technique... text on the desktop doesn't look as crisp as in gtk+-apps
[10:22] <anpok> get bad glasses .. distance based fonts are a lot faster :)
[10:22] <MacSlow> Cimi, ah... interesting... thannks for the link!
[10:23] <Cimi> if it works, we should enable on our desktop
[10:25] <mzanetti> Saviq: yep, can do that now
[10:26] <Saviq> MacSlow, some more data here https://bugreports.qt-project.org/browse/QTCREATORBUG-9751
[10:26] <MacSlow> Saviq, thanks
[10:27] <Saviq> mzanetti, did you ever get to the behemoth 7k diff of new scopes cleanup?
[10:27] <mzanetti> Saviq: yeah, I've read through it, Albert is already fixing my comments. Still have to do the functional test
[10:28] <Saviq> mzanetti, I meant https://code.launchpad.net/~unity-team/unity8/new-scopes-cleanup/+merge/209642
[10:28] <mzanetti> ah no... that was the clean-to-trunk
[10:28] <mzanetti> no didn't get to the other yet
[10:28] <Saviq> mzanetti, ok, I might actually get on it if you don't, let's see who's first
[10:28]  * tsdgeos can't stand subpixel hinted fonts
[10:29] <tsdgeos> i want black you fool not green!
[10:29]  * Saviq slows down work to let mzanetti review the bitch...
[10:29]  * mzanetti still hopes gerry comes back soon and approves the right-edge branch :P
[10:30] <Saviq> ;D
[10:30] <Cimi> mzanetti, did you write launcher tests?
[10:30] <mzanetti> Cimi: yes
[10:30] <Saviq> let's merge right edge and new scopes on a Friday, what's the worst that can happen! ;D
[10:30]  * mzanetti doesn't see why not :P
[10:31] <Cimi> who has qt 5.0?
[10:31] <mzanetti> Saviq: worst case, we instruct people to flash the mwc image for the weekend
[10:31] <Cimi> first of all
[10:31] <tsdgeos> Saviq: shall i ask mterry to rebase his branch on top of new-scopes-cleanup-5.2? it doesn't merge cleanly there
[10:31]  * mzanetti 5.2
[10:31] <Cimi> tsdgeos, can you run testLauncher and see if it fails for you?
[10:31] <Cimi> with 5.2
[10:31] <Cimi> or mzanetti
[10:31] <tsdgeos> Cimi: new-scopes or trunk?
[10:31]  * mzanetti runs
[10:31] <Saviq> tsdgeos, maybe review against trunk for now
[10:32] <tsdgeos> Saviq: ok
[10:32] <Cimi> tsdgeos, ns
[10:32] <Saviq> tsdgeos, we have right edge that might still get in before new-scopes
[10:32]  * Saviq got a u8 crash on 5.2, let's hope it's a known sig
[10:33] <mzanetti> Cimi: trunk testLauncher passed here with 5.2
[10:33] <mzanetti> Cimi: same with launcherbackendtest and launchermodeltest
[10:34] <tsdgeos> Cimi: http://paste.ubuntu.com/7089382/
[10:34] <tsdgeos> Cimi: i think i had a look at this one, flick() doesn't seem to be flicking enough
[10:34] <mzanetti> tsdgeos: is this in xvfb?
[10:34] <tsdgeos> you may want to replace flick() with a mouse press+move+release
[10:34] <tsdgeos> mzanetti: no, regular unity7
[10:34] <mzanetti> 8 I assume, trunk?
[10:35] <tsdgeos> mzanetti: no, running 7
[10:35] <tsdgeos> mzanetti: new-scopes-cleanup-5.2 branch
[10:35] <tsdgeos> let me see what fix-5.2 says
[10:35] <Cimi> tsdgeos, ok, have the same issue with flick
[10:35] <Cimi> tsdgeos, and I was thinking of doing mouse flick indeed
[10:40] <Saviq> MacSlow, there's an "antialias" option under Text Editr / Font & Colors in QtC, not sure, though, that it would get what you want ;)
[10:41] <MacSlow> Saviq, that was enabled already :)
[10:41] <Saviq> MacSlow, yeah, I meant *disabling* it ;)
[10:42] <MacSlow> Saviq, that would make things worse... but I managed to tweak it a bit for the better already... it didn't pickup the system-wide set monospaced font
[10:42] <Saviq> MacSlow, right, it does use the default on
[10:42] <Saviq> e
[10:42] <Saviq> internal
[10:43] <MacSlow> Saviq, it's a lot better after the tweaking now
[10:47] <Cimi> btw unity7 improved loads this cycle
[10:47] <Cimi> it's faster on my slow intel card
[10:47] <Cimi> and more stable
[10:47] <Cimi> and looks better
[10:47] <Cimi> now we need to fix dash scopes that are slow :)
[10:47] <Cimi> good we have this unity in the lts
[10:50] <MacSlow> there seems to be an issue with indicator AP-tests -> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5830/console
[10:50] <MacSlow> Saviq, ^ is that to be expected?
[10:51] <Saviq> MacSlow, "NoSuchProcess: no process found with pid 8773"
[10:51] <Saviq> MacSlow, == crash
[10:51] <Saviq> MacSlow, == Qt 5.0 crash that's fixed with 5.2
[10:52] <MacSlow> Saviq, so I just have to wait this one out?
[10:52] <Saviq> MacSlow, ignore it, yeah
[10:52] <MacSlow> Saviq, all 12 notification AP passed btw :)
[10:52] <MacSlow> I hope Qt 5.2 won't affect that ;)
[10:54] <mzanetti> tsdgeos: http://paste.ubuntu.com/7089478 <-- Qt 5.2, fix-5.2-tests branch
[10:56] <Cimi> mzanetti, I have same issues
[10:56] <Cimi> mzanetti, as well as launcher
[10:56] <mzanetti> just tried the launcher again... passed :/
[10:56] <Cimi> I'm looking into launcher
[10:56] <Cimi> mzanetti, listview.flick seems to be weird
[10:56] <Cimi> mzanetti, might be that you have retina screen
[10:56] <Cimi> mzanetti, and speed flicks work on your pc
[10:57] <mzanetti> Cimi: well, I'm using unity.gu for the flicking. so it *should* not matter
[10:57] <mzanetti> but who knows
[10:57] <mzanetti> Cimi: are you sure there isn't just a waitForRendering needed?
[10:57] <Cimi> mzanetti, trying with your gu size
[10:57] <Cimi> mmm might be too
[10:57]  * mzanetti uses 18 px/gu
[10:57] <Cimi> mzanetti, which gu do you have?
[10:57] <Cimi> thx
[10:58] <Cimi> and the variable to set?
[10:58]  * Cimi forgot
[10:58] <mzanetti> GRID_UNIT_PX
[10:58] <mzanetti> tst_DragHandle failing for anyone of you? /me suspects a gu issue too
[10:59]  * Cimi tries
[10:59] <Cimi> mzanetti, works
[11:00] <Cimi> mzanetti, works with 18 :-\
[11:00] <mzanetti> launcher?
[11:00] <Cimi> yep
[11:01] <mzanetti> Cimi: guess what: DragHandle works here with 8 too
[11:01] <mzanetti> afaics :P
[11:01] <Cimi> :)
[11:01] <tsdgeos> mzanetti: weird, let me see
[11:02] <Cimi> mzanetti, which test?
[11:02] <Cimi> of draghandle
[11:02] <Cimi> tsdgeos, I'm looking at it
[11:02] <Cimi> tsdgeos, GRID_UNIT_PX=18 make testLauncher works
[11:03] <tsdgeos> Cimi: the lvwph ones too?
[11:03] <Cimi> so either listview.flick clamps values
[11:03] <Cimi> or units.gu don't work sas speed
[11:03] <mzanetti> Cimi: the flick() in the launcher only resets it to the beginning, You might just be able to increase the flick value a git and it'll work
[11:03] <Cimi> tsdgeos, not those
[11:03] <tsdgeos> Cimi: ok
[11:03] <mzanetti> this is DragHandle @18: http://paste.ubuntu.com/7089509
[11:05] <Cimi> mzanetti, looking
[11:07] <tsdgeos> mzanetti: lwph passed here
[11:08] <tsdgeos> mzanetti: is it 100% failing for you?
[11:08] <mzanetti> tsdgeos: yep, just ran it again: http://paste.ubuntu.com/7089521
[11:09] <mzanetti> this one is not GU related. fails for 8 here too
[11:10] <tsdgeos> mzanetti: yeah the test doesn't know about gus
[11:10] <mzanetti> yep..
[11:10] <tsdgeos> mzanetti: are you using xvfb-run ?
[11:10] <mzanetti> tsdgeos: no, this was all plain X
[11:11] <tsdgeos> mzanetti: does running it standalone also fails? i.e. http://paste.ubuntu.com/7089534/
[11:12] <mzanetti> tsdgeos: yeah, that's what my paste does
[11:12] <mzanetti> tsdgeos: not in a loop, but standalone
[11:12] <tsdgeos> works here :/
[11:12] <tsdgeos> i'm on the 12th run already
[11:12] <mzanetti> ah... you meant the function standalone
[11:12]  * mzanetti tries
[11:13] <mzanetti> tsdgeos: http://paste.ubuntu.com/7089545
[11:13] <mzanetti> tsdgeos: kwin/compiz ?
[11:14] <tsdgeos> don't think so
[11:14] <tsdgeos> i'd say it's resolution
[11:14] <tsdgeos> i'm basically moving the mouse and expecting stuff to happen
[11:14] <mzanetti> tsdgeos: interesting. it works in xvfb
[11:14] <tsdgeos> because the dpi there is probably different
[11:14] <tsdgeos> the one i need
[11:15] <mzanetti> tsdgeos: ah... while thie window is quite small, I still have normal fonts
[11:15] <mzanetti> http://i.imgur.com/paH4UEo.png
[11:15] <tsdgeos> looks good to me :D
[11:15] <mzanetti> ok
[11:16] <mzanetti> I could imagine the test taking less space if the fonts dpi is different
[11:16] <mzanetti> s/test/text/
[11:16] <tsdgeos> well the 0 is a bit too big
[11:16] <tsdgeos> but that is just there for you to look at, doesn't play any role
[11:17] <mzanetti> tsdgeos: you sure the header isn't smaller in height?
[11:17] <tsdgeos> mzanetti: no looks ok
[11:17] <tsdgeos> i can snapshot mine if you want
[11:18] <mzanetti> yeah, please do
[11:18]  * mzanetti curious
[11:18] <mzanetti> there must be a difference...
[11:18] <tsdgeos> http://i.imgur.com/E5x1to3.png
[11:19] <tsdgeos> it's the test that is bogus i guess
[11:19] <tsdgeos> http://paste.ubuntu.com/7089562/ probably doesn't move your high DPI at all
[11:20] <mzanetti> tsdgeos: ah. the Pageheader and sectionheader have hardcoded pixel sizes?
[11:20] <tsdgeos> ye
[11:20] <mzanetti> that explains why its correct indeed
[11:20] <tsdgeos> why wouldn't they?
[11:21] <tsdgeos> well as i said the test doesn't use gu
[11:21] <mzanetti> yeah.
[11:23] <tsdgeos> mzanetti: i'm just not sure how to make this work if indeed the pixels you have to move the mouse are indeed pixel dependant
[11:23] <tsdgeos> maybe the qpa has info about that?
[11:23]  * tsdgeos checks
[11:29] <Cimi> mzanettI, draghandle is not res independent
[11:30] <Cimi> debugging that
[11:30] <Cimi> some values I'm getting don't change
[11:30] <mzanetti> Cimi: which ones?
[11:30] <Cimi> currently
[11:30] <Cimi> dragThreshold of EdgeDragEvaluator
[11:31] <mzanetti> yeah.. I'm hunting that one too...
[11:31] <Cimi> which seems to be maxDragDistance
[11:31] <mzanetti> haven't found where it's defined
[11:31] <Cimi> that should ne res independent
[11:31] <Cimi> mzanetti, qml/Components/EdgeDragEvaluator.qml
[11:32] <tsdgeos> doesn't seem to be much in flickable that is dpi dependant or anything
[11:32] <mzanetti> Cimi: defaultDistanceThreshold: units.gu(1.5)
[11:32] <mzanetti> seems okayish...
[11:32] <Cimi> mzanetti, maxDragThreshold
[11:33] <Cimi> *distance
[11:33] <Cimi> ../qml/Components/DragHandle.qml:172:        maxDragDistance: maxTotalDragDistance
[11:33] <Cimi> ../qml/Components/Stage.qml:453:        maxDragDistance: stage.width
[11:33] <mzanetti> yeah... but: distanceThreshold: hintDisplacement > 0 ? 0 : defaultDistanceThreshold
[11:34] <tsdgeos> mzanetti: i guess you don't see the list moving at all, no?
[11:34]  * mzanetti checks
[11:34] <mzanetti> nope. frozen like an ice cube
[11:35] <mzanetti> tsdgeos: ^
[11:35] <tsdgeos> mzanetti: do the other tests also pass inside xvfb-run?
[11:36] <mzanetti> trying
[11:37] <mzanetti> tsdgeos: http://paste.ubuntu.com/7089644
[11:37] <tsdgeos> so yes
[11:38] <tsdgeos> that 0 != 0 should be randomly passing
[11:38] <tsdgeos> we have that in trunk too
[11:38] <tsdgeos> even i thought i had fixed it
[11:38] <mzanetti> is that the one you introduced the uFuzzyCompare for?
[11:38] <Saviq> /food
[11:38] <tsdgeos> mzanetti: this one and a few others with the same issue yeah
[11:39]  * tsdgeos let's it run in xvfb-run for a while
[11:39] <tsdgeos> yep, failed
[11:39] <tsdgeos> i should be able to at least make this one pass consistently
[11:40] <mzanetti> yeah... but its strange. I'm quite sure this was passing at some point here
[11:40] <tsdgeos> well it does pass
[11:40] <tsdgeos> just run it again :D
[11:40] <mzanetti> no... I mean the DPI related issues
[11:40] <tsdgeos> ah
[11:40] <tsdgeos> mzanetti: yes i think that has changed with 5.2
[11:40] <mzanetti> ah ok
[11:40] <tsdgeos> there have been some changes regarding how dpi is handled
[11:41] <tsdgeos> let's fix this one i can repro first
[11:41] <tsdgeos> and care about the others later
[11:41] <mzanetti> ack
[11:41] <mzanetti> Cimi:  any progress on the launcher or the draghandle? depending on which one you are on, I could take the other
[11:42] <Cimi> mzanetti, doing drag handle, no progress, just debugging
[11:42] <mzanetti> Cimi: ok. /me gets to the launcher
[12:05] <Cimi> is there a way in qml to see what sets what?
[12:05] <Cimi> like, what set a property width
[12:06] <mzanetti> Cimi: launcher fixed
[12:07] <Cimi> mzanetti, push in that branch
[12:07] <Cimi> mzanetti, or in fix-5.2-tests
[12:07] <Cimi> mzanetti, can you pastebin diff?
[12:07] <mzanetti> Cimi: hm... I think you can see that with the profiler...
[12:07] <mzanetti> Cimi: I've pushed to 5.2-tests
[12:07] <Cimi> ok
[12:08] <mzanetti> Cimi: diff: http://bazaar.launchpad.net/~unity-team/unity8/fix-5.2-tests/revision/751
[12:08] <mzanetti> dammit... I accidentally pushed something
[12:08] <mzanetti> reverted
[12:09] <Cimi> mzanetti, looks like a workaround
[12:09] <Cimi> mzanetti, don't get me wrong
[12:09] <mzanetti> Cimi: why?
[12:09] <Cimi> it works
[12:09] <Cimi> mzanetti, I just wanted to know why flick doesn't work
[12:09] <Cimi> :)
[12:09] <mzanetti> because it always had issues if listview Snapping is enabled
[12:10] <mzanetti> and now with 5.2. it seems not to be able to flick() over a snap position any more
[12:10] <Cimi> mzanetti, you can help me with drag handle
[12:10] <mzanetti> regardless how big the number in flick(x)  is
[12:10] <Cimi> mzanetti, basically
[12:10] <Cimi> mzanetti, if you put some fancy console.log
[12:11] <Cimi> you realise that width of those drag handle is fixed
[12:12] <mzanetti> ok
[12:31] <tsdgeos> ahhhh
[12:31] <tsdgeos> waht about make testFoo?
[12:31] <tsdgeos> Saviq: ↑↑
[12:33] <Cimi> mzanetti, there's so much logic in those tests that I'm wondering if they are correct
[12:34] <mzanetti> Cimi: what's interesting, the DragHandles window is always the same size, regardless the ps/gu
[12:34] <mzanetti> px/gu
[12:34] <mzanetti> tsdgeos: what is with make testFoo?
[12:34] <Cimi> mzanetti, it's not set
[12:34] <tsdgeos> doesn't work anymore
[12:35] <mzanetti> huh? does here (unless you really mean "make testFoo" - including the Foo)
[12:35] <mzanetti> tsdgeos: or did you mean tryFoo?
[12:35] <mzanetti> Cimi: isn't it set to 70 gu's in tst_DragHandle.qml?
[12:36] <Cimi> mzanetti, vertical showable and horizontal showable in tst_DragHandle tthey don't have anchors
[12:36] <tsdgeos> mzanetti: ah, yes that :D
[12:36] <mzanetti> tsdgeos: yeah... that's broken. we need our own QQuickView that registers qttest stuff
[12:36] <tsdgeos> mzanetti: ok, pushed a fix for the 0 != 0 thing
[12:36] <mzanetti> tsdgeos: nice, thanks
[12:37] <Saviq> tsdgeos, you mean make tryFoo?
[12:37] <tsdgeos> mzanetti: the other ones i don't know how to tackle
[12:37] <tsdgeos> Saviq: yes
[12:37] <Saviq> tsdgeos, well, it's somewhat lower prio, but yeah we need to come up with something
[12:38] <mzanetti> Cimi:     window->resize(600, 600);
[12:39] <Cimi> ouch
[12:39] <Cimi> I should have just grep
[12:39] <Cimi> xD
[12:39] <Cimi> mzanetti, that is it
[12:39] <mzanetti> haha. commented that away and guess what Totals: 10 passed, 0 failed, 0 skipped
[12:39]  * mzanetti pushes
[12:40] <tsdgeos> mzanetti: is testlistviewwithpageheadersection the only one that fails?
[12:40] <tsdgeos> i'd expect other variations of LVWPH fail too, no?
[12:41] <mzanetti> tsdgeos: lemme try
[12:41] <Cimi> mzanetti, waiting daniel to ask why resizing?
[12:41] <Cimi> http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/43.2.2
[12:43] <mzanetti> tsdgeos: http://paste.ubuntu.com/7089916
[12:43] <tsdgeos> ok
[12:43] <tsdgeos> so same thing
[12:43] <tsdgeos> the tests that move the view with mouse presses don't play nice with your dpi
[12:43] <mzanetti> Cimi: as everything still works when removing it, I assume he added it just for some testing while developing and forgot to remove
[12:43] <Cimi> ok
[12:43] <mzanetti> but yeah, lets ask him to be sure
[13:05] <Saviq> THE 5.2 HAS LANDED
[13:05] <Saviq> Mirv, kudos!!!
[13:05] <bregma> prepare yourselves appropriately!
[13:06]  * Saviq starts porting to 5.3... we should make it in time for 15.04, right?
[13:07] <mzanetti> tsdgeos: Cimi: https://code.launchpad.net/~unity-team/unity8/fix-5.2-tests/+merge/209058/comments/497520 :/
[13:07] <mzanetti> will look into it...
[13:07] <mzanetti>  /food first
[13:08] <mzanetti> yay for 5.2 :)
[13:09]  * Saviq imagines Mirv lying in a puddle of high-grade alcohol right now
[13:13] <Cimi> will we ever have those ubuntushape binding loop for propery width fixed?
[13:14] <Mirv> Saviq: :D thanks.
[13:14] <Saviq> Cimi, did you ever try? ;)
[13:14] <Cimi> Saviq, nope :D
[13:15] <Cimi> I can
[13:15] <Saviq> Cimi, then, no
[13:15] <Saviq> Cimi, did you fix the card yet?
[13:15] <Cimi> Saviq, will do now, was fixing 5.2 with mzanetti
[13:15] <Saviq> Cimi, thanks
[13:16]  * Saviq wonders who will review the 5.2-fixes branch ;D
[13:16] <Saviq> when *everyone* will have their hands in it
[13:56] <tsdgeos> mzanetti: hmmmm, all the time? or just sometimes?
[13:59] <tsdgeos> Mirv: so i can remove landing6?
[13:59] <tsdgeos> s/can/should i guess
[14:00] <Mirv> tsdgeos: what do you mean?
[14:00] <Mirv> tsdgeos: oh, yes, you don't need the PPA anymore
[14:00] <Mirv> tsdgeos: you actually get more updates from the main archives now
[14:00] <Mirv> like the two qtdeclarative patches
[14:02] <tsdgeos> Mirv: cool
[14:02] <tsdgeos> tx
[14:03] <mhr3_> Mirv, so 006 officially landed and in main now?
[14:04] <tsdgeos> mhr3_: yes
[14:05] <mhr3_> Mirv, will all those rebuild-against-5.2 branches be marked as merged?
[14:05] <Mirv> mhr3_: yep, it's now in main, in release pocket. merge & clean not yet done
[14:05] <Mirv> mhr3_: the last thing answers that, pending
[14:28] <mzanetti> tsdgeos: yes, al the time
[14:41] <Cimi> dednick, can you repeat me what you have been working on, I couldn't hear you well
[14:41] <Cimi> dandrader, ping
[14:41]  * mzanetti still didn't get the dungeon joke
[14:41] <dandrader> Cimi, pong
[14:42] <dednick> Cimi: i'll enter it
[14:42] <dandrader> mzanetti, because we will stay all day inside a windowless room regardless if it's a sunny and wonderful place outside :)
[14:42] <mzanetti> ah, got it, thanks :)
[14:42]  * mzanetti remembers the apps team conquering the terrace in oakland
[14:43] <mzanetti> we just need to be faster :D
[14:43] <dandrader> mzanetti, yeah, that was a great move
[14:44] <Saviq> apps team is going to be there the week before us
[14:44] <Saviq> so there's our chance :)
[14:46] <Mirv> mhr3_: merged!
[14:47] <Cimi> dandrader, in test DragHandle
[14:47] <Cimi> dandrader, you forced window size to 600, 600
[14:47] <Cimi> dandrader, is there a reason for that?
[14:47] <mhr3_> Mirv, yey!
[14:48] <dandrader> Cimi, just so it gets a reasonable size when running on the desktop. so it's rather arbitraty
[14:48] <dandrader> arbitrary
[14:49] <Cimi> dandrader, it breaks on high GU
[14:49] <Cimi> dandrader, mzanetti removed it
[14:49] <dandrader> Cimi, just make sure it looks good when you do "make tryDragHandle"
[14:49] <mzanetti> dandrader: trySomething is dead right now
[14:49] <Cimi> mzanetti, ^?
[14:50] <dandrader> mzanetti, why?
[14:50] <dandrader> mzanetti, due to the qt 5.2 transition?
[14:50] <mzanetti> qt 5.2 registers Qttest somewhere in qmltestrunner, and not in import QtTest any more
[14:50] <mzanetti> dunno why, but we need to patch our uQmlscene
[14:50] <dandrader> mzanetti, ah, that's easy
[14:50] <mzanetti> cool
[14:51] <dandrader> mzanetti, I mean, I hope it's easy :D
[14:51] <mzanetti> dandrader: for the resize(), If I drop it, it still looks exactly the same with GRID_UNIT_PX=8
[14:51] <mzanetti> dandrader: and on my screen, with 18 px/gu it's obviously much bigger but still looks the same and tests pass
[14:51] <tsdgeos> mzanetti: can you gdb that crash? it's weird
[14:51] <mzanetti> before it was rather tiny and buttons didn't fit any more
[14:51] <mzanetti> tsdgeos: I'll try
[14:56] <mzanetti> tsdgeos: interesting: http://paste.ubuntu.com/7090571
[14:56] <tsdgeos> mzanetti: kill landing6, dist-upgrade and rebuild?
[14:56] <mzanetti> on it
[14:58] <Saviq> mzanetti, check unity8.log, too
[14:58] <Saviq> mzanetti, grep for what()
[15:00] <Saviq> Cimi, tsdgeos, are there any newscopes-specific 5.2 fixes in cleanup-5.2?
[15:01] <Cimi> Saviq, what u mean?
[15:01] <Saviq> Cimi, is cleanup-5.2 anything more than cleanup + fixes-5.2?
[15:01] <Cimi> Saviq, yes
[15:01] <tsdgeos> Saviq: don't remember tbh
[15:01] <Cimi> Saviq, it has some new scopes fixes iirc
[15:04] <Saviq> tsdgeos, Cimi, any reason to not just merge cleanup-5.2 into cleanup?
[15:04] <tsdgeos> Saviq: not at this point that 5.2 is on main
[15:04] <tsdgeos> let's do it and kill the other branch
[15:04] <Cimi> Saviq, we were not sure we had new scope before or after 5.2
[15:04]  * Saviq does
[15:05] <Saviq> Cimi, I doubt the fixes are 5.0 incompatible, though, are they ;)
[15:06]  * Saviq dropped the branch
[15:11] <tsdgeos> Saviq: probably not, but at this stage, we will never know anymore :D
[15:11] <mzanetti> don't look back
[15:11] <mzanetti> :D
[15:13] <mzanetti> tsdgeos: switching to final and rebuilding fixed it. I suspect some weirdness 'cause I keep on switching back and forth between the refactoring of appmanager in the right-edge branches
[15:13] <tsdgeos> yeah
[15:13] <tsdgeos> cool
[15:18] <tsdgeos> mzanetti: so the only problems you can reproduce now are the lvwph due to the high dpi?
[15:19] <mzanetti> tsdgeos: still running the whole thing but so far it looks like that, yeah
[15:21] <Saviq> we got qmluitests success on 5.2, folks :)
[15:22] <mzanetti> Saviq: in jenkins?
[15:22] <Saviq> mzanetti, yup
[15:22] <mzanetti> nice.
[15:22] <Saviq> https://code.launchpad.net/~unity-team/unity8/fix-5.2-tests/+merge/209058/comments/497608
[15:22] <Saviq> tsdgeos, ↑
[15:22] <mzanetti> tsdgeos: so yeah, looks like the DPI issues in lvwph are the only ones left - non blocking for this branch I'd say
[15:22] <Saviq> only otto failed due to some dep issues
[15:23] <Saviq> another one is going http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/2499/console
[15:25] <Saviq> let's just freakin' approve and land it... I won't be able to review the other thing otherwise...
[15:25] <tsdgeos> Saviq: so what do we do, ignore the high dpi issues from mzanetti for the moment? works for me
[15:25] <Saviq> tsdgeos, yeah
[15:25] <tsdgeos> mzanetti: all yours
[15:26] <Saviq> mzanetti, push-ups? https://code.launchpad.net/~aacid/unity8/vjog_compiz_workaround/+merge/209877
[15:26]  * mzanetti does push ups
[15:26] <mzanetti> done
[15:27] <mzanetti> I'll increase to 10 next time. 5 is too easy. I keep on forgetting :D
[15:29] <Saviq> mzanetti, go exponentially, 25 next time
[15:29] <mzanetti> heh... I guess I wouldn't make the next step tho
[15:29] <Saviq> that's how you remember ;D
[15:29] <mzanetti> 25 seems really the upper limit I can do at once right now
[15:29] <Saviq> Cimi, will https://code.launchpad.net/~unity-team/unity8/carouselTool/+merge/209655 be affected by the fix your cooking? should I refrain from landing it?
[15:30] <Cimi> Saviq, shouldn't be affected
[15:30] <Cimi> give me 5 mins
[15:32] <mzanetti> Saviq: got all qml tests passing in xvfb too now :)
[15:32] <Saviq> mzanetti, awesomes
[15:33] <Saviq> mzanetti, with the fix-5.2 branch, that is?
[15:33] <mzanetti> yep
[15:34] <Saviq> elopio, please drop the submitter checklist https://wiki.ubuntu.com/Process/Merges/Checklists/Unity8 into https://code.launchpad.net/~elopio/unity8/fake_app_from_toolkit/+merge/208002 ?
[15:34] <Cimi> Saviq, remember me how to restart scope registry
[15:34] <Saviq> Cimi, "restart scope-registry" ;)
[15:35] <Saviq> Cimi, might need "restart smart-scopes-proxy", too
[15:35] <Cimi> uknown instance
[15:35] <Saviq> Cimi, start, tehn
[15:35] <Saviq> then
[15:35] <Cimi> Saviq, I think I'm missing some packages
[15:36] <Cimi> I have unity-scope-click, unity-scope-scopes
[15:36] <Saviq> Cimi, that's enough, why do you say you're missing anything?
[15:36] <Cimi> Saviq, when I run unity-scope-tool I get errors
[15:37] <Cimi> file:///home/cimi/Development/unity8/new-scopes-clean-to-trunk/qml/Dash/DashContent.qml:103: TypeError: Cannot read property 'loaded' of null
[15:37] <Cimi> etc
[15:37] <Saviq> Cimi, did you build?
[15:37] <Saviq> Cimi, try -c
[15:37] <Cimi> yes I did
[15:37] <Cimi> brand new
[15:38] <Cimi> file:///home/cimi/Development/unity8/new-scopes-cleanup-5.2/qml/ScopeTool.qml:77:31: Unable to assign [undefined] to scopes_ng::Scope*
[15:39] <mhr3_> Saviq, looks like we can forget about landing #13?
[15:40] <Saviq> mhr3_, not necessarily, we just need to flush before that...
[15:40] <Saviq> mhr3_, but since it's only our MP, I can take over indeed
[15:40] <Saviq> sil2100, hey, I can has silo for row 50?
[15:41] <mhr3_> Saviq, ok, seen some newscopes in #50, thought it's the same thing
[15:41] <mhr3_> nevermind then
[15:41] <Saviq> mhr3_, no, those are just prereqs
[15:41] <mhr3_> yea, see that now
[15:41] <Saviq> mhr3_, 'cause without that we're lost for reviewing the rest
[15:43] <sil2100> Saviq: already done ;)
[15:43] <Saviq> sil2100, nice one :)
[15:43] <sil2100> Just wait for me to copy-paste it to the spreadsheet
[15:44]  * Saviq hates the (lack of) SSO integration for the train jenkins...
[15:45] <Cimi> any hint on that error?
[15:45] <Cimi> ./build -s or -c
[15:45] <Cimi> nothing changes
[15:46] <Cimi> I upgrade
[15:46] <tsdgeos> i'm getting the same
[15:46] <tsdgeos> no scopes at all
[15:46] <tsdgeos> ah, new-scopes hasn't landed yet, no?
[15:47] <tsdgeos> i mean the backend part
[15:47] <tsdgeos> or it has?
[15:48] <mhr3_> tsdgeos, restart smart-scope-proxy && restart scope-registry
[15:49] <Cimi> mhr3_, I don't have the former
[15:49] <Cimi> mhr3_, which packlage?
[15:50] <tsdgeos> missing s
[15:50] <tsdgeos> smart-scopes-proxy
[15:50] <tsdgeos> scope-registry
[15:50] <mhr3_> whoops
[15:50] <mhr3_> sorry
[15:52] <Cimi> ok I can reproduce the bug
[15:54] <elopio> Saviq: done. I'm sorry, I always forget about it.
[15:54] <Saviq> elopio, no worries
[15:59] <mhr3_> Saviq, could we cleanup the demo ppa?
[16:00] <mhr3_> Saviq, the unity8 build there is new-scopes-cleanup based, what else needs to be rebuild?
[16:00] <mhr3_> uitk & qtubuntu still needed?
[16:02] <mhr3_> Saviq, or do you want to forget about it for now and use a landing silo instead?
[16:03] <Saviq> mhr3_, when I release the thing that's building now, I'll create a silo for new scopes
[16:04] <mhr3_> Saviq, ok, so lets forget about demo stuff
[16:06] <Cimi> Saviq, do we have carousel for apps?
[16:06] <Saviq> Cimi, no
[16:06] <Saviq> Cimi, the issue is with searching in apps
[16:06] <Saviq> Cimi, there's no title
[16:07] <Cimi> Saviq, the issue is to me apps are all attached
[16:07] <Cimi> no spacing
[16:07] <Cimi> Saviq, are we talking about the same issue?
[16:07] <Saviq> Cimi, probably not
[16:07] <Saviq> Cimi, go to click scope, search for something
[16:07] <Saviq> Cimi, no titles
[16:07] <Cimi> Saviq, do you have space between results
[16:07] <Saviq> Cimi, image
[16:07] <Cimi> ah click scope
[16:08] <Cimi> Saviq, I have found another bug then
[16:08] <Cimi> Saviq, search inside apps
[16:08] <Cimi> apps are click scope?
[16:08] <Saviq> Cimi, yes
[16:08] <Cimi> ok
[16:09] <Saviq> Cimi, so yeah, it's the same issue
[16:10] <Cimi> Saviq, it has nothing to do with carousel then
[16:10] <Saviq> Cimi, no, but your branch breaks it
[16:10] <Cimi> ah cool :D
[16:10] <Cimi> it is the undefined cardWidth
[16:11] <Saviq> probably
[16:11] <Cimi> no doubts
[16:11] <Cimi> I'm wondering where it is missing the switch to implicitWidth
[16:11] <Cimi> and where my branch breaks it
[16:12] <Saviq> tsdgeos, didn't you say you killed DashFilterGrid somewhere?
[16:12] <tsdgeos> yes
[16:12] <tsdgeos> in the seemore grid
[16:12] <tsdgeos> i think
[16:12] <tsdgeos> yep
[16:13] <tsdgeos> Saviq: i can try bringing that over to new-scopes-cleanup if you want
[16:14] <Cimi> Saviq, ok I see
[16:14] <Cimi> Saviq, https://code.launchpad.net/~unity-team/unity8/carouselTool-new-dash/+merge/209746
[16:14] <Cimi> Saviq, my guess
[16:14] <Saviq> tsdgeos, yeah, please do
[16:14] <Cimi> Saviq, the bug was always there
[16:14] <tsdgeos> Saviq: ok
[16:14] <Cimi> Saviq, but 53	-        categoryLayout: "grid"
[16:14] <Saviq> Cimi, don't explain it to me, fix it! :D
[16:14] <Cimi> Saviq, was forcing cardfiltergrid to always use grid
[16:19] <Cimi> Saviq, I need you here
[16:19] <Cimi> Saviq, for organic-grid, journal
[16:19] <Cimi> or whoever wrote this cardWidth code
[16:19] <Cimi> I can fix it for this case
[16:20] <Cimi> but will be bugged elsewhere
[16:21] <Saviq> Cimi, what do you mean?
[16:21] <Cimi> Saviq, I believe journal was never used
[16:21] <Cimi> Saviq, same thing for organic grid
[16:22] <Cimi> Saviq, cardfiltergrid contained an override of categorylayour forcing to grid
[16:22] <Saviq> Cimi, sure, they're not used yet, but they will be soon
[16:22] <Saviq> Cimi, and it's tested
[16:23] <Cimi> let me dig more
[16:23] <Saviq> Cimi,             case "grid":
[16:23] <Saviq>                 return card.implicitHeight
[16:23] <Saviq>         height: cardTool.cardHeight || implicitHeight
[16:23] <Cimi> not width
[16:23] <Saviq> hmm actually that's fine
[16:27] <Saviq> Cimi, fwiw, both Card and CardTool are tested somewhat extensively
[16:27] <Saviq> Cimi, so I'm expecting an integration (CardFilterGrid / GenericScopeView) issue
[16:29] <Cimi> Saviq, ok I confirm
[16:29] <Cimi> Saviq, old code of new scopes http://bazaar.launchpad.net/~unity-team/unity8/new-scopes/view/head:/qml/Dash/CardTool.qml
[16:29] <Cimi> Saviq, categoryLayout was never used differently than grid or carousel
[16:30] <Saviq> Cimi, not sure what you mean?
[16:30] <Cimi> Saviq, http://bazaar.launchpad.net/~unity-team/unity8/new-scopes/view/head:/qml/Dash/CardFilterGrid.qml
[16:30] <Cimi> Saviq, line 35
[16:31] <Saviq> Cimi, that's in CardFilterGrid, so this should always be grid regardless
[16:31] <Cimi> Saviq, all CardFilterGrid were forcing line 65 of cardTool
[16:31] <Cimi> Saviq, Apps was treated as grid
[16:31] <Saviq> Cimi, it is grid
[16:31] <Saviq> Cimi, it's not meant to be carousel
[16:31] <Cimi> Saviq, it says journal here
[16:32] <Saviq> Cimi, huh?
[16:32] <Saviq> journal is not implemented yet, nothing is using it
[16:32] <Cimi> Saviq, I added console.log(categoryLayout)
[16:32] <Cimi> Saviq, when doing search here
[16:32] <Cimi> and I clearly see journal
[16:32] <Saviq> Cimi, that might explain things
[16:32] <Saviq> Cimi, you're right
[16:32] <Saviq> mhr3_, bug is in click scope
[16:32] <Saviq> mhr3_, it's using journal instead of "grid"
[16:33] <mhr3_> oh?
[16:33] <mhr3_> it that how journal looks? :)
[16:33] <Cimi> we didn't implement journal yet
[16:34] <Saviq> mhr3_, journal doesn't look at all ye ;)
[16:35] <Saviq> mhr3_, it's not like it should ever use a journal, should it ;)
[16:35] <mhr3_> Saviq, sure, but you should fallback nicely ;P
[16:35] <mhr3_> but yes, it is also a bug in click :)
[16:35] <Saviq> mhr3_, well, no, I should use a journal when it's implemented
[16:36] <Saviq> mhr3_, but click should not use it ;)
[16:43] <Cimi> mzanetti, did you remove the window resize in the end?
[16:44] <mzanetti> Cimi: yes. let me check if I pushed everything
[16:44] <mzanetti> Cimi: 168	- window->resize(600, 600);
[16:44] <mzanetti> in the diff
[16:45] <Cimi> ok
[16:45] <Cimi> then we're good to go Saviq
[16:46] <Saviq> Cimi, with?
[16:47] <Saviq> mzanetti, tsdgeos, what do we do with fixes-5.2, who reviews? :)
[16:47] <Cimi> ahahah
[16:47] <mzanetti> hehe
[16:48] <mzanetti> well, I'd say if everyone approves the other's changes we grant you the right to self-top-approve
[16:48] <Saviq> ;D
[16:48] <mzanetti> where's paul?
[16:48] <mzanetti> :D
[16:52] <Cimi> hah
[16:59] <ESphynx> hey guys, is there any way not to have this damn 'Please type your command'
[16:59] <ESphynx>  useless thing pop up when I try to hit my app menus? (Alt-F)
[17:02] <Saviq> ESphynx, you mean "not" pop up? it should not anyway, there was a bug in earlier unity versions, seems reliable now
[17:02] <Saviq> ESphynx, but anyway you can change the keybinding for it in ccsm
[17:02] <ESphynx> Saviq: thanks. I'm running the latest on Trusty
[17:02] <Saviq> ESphynx, and pressing alt+f pops the hud up?
[17:03] <Saviq> ESphynx, sounds like you should file a bug
[17:03] <Saviq> ESphynx, this was supposed to be solved these days
[17:03] <ESphynx> and if pops up if I release quickly both keys but the alt first I think
[17:03] <Saviq> ESphynx, still, this should've been better now
[17:03] <ESphynx> in practice, it annoys me all the time.
[17:04] <Saviq> ESphynx, if it's not, please file a bug
[17:04] <ESphynx> Saviq: It was not as bad in Saucy
[17:04] <ESphynx> with Trusty it's aweful.
[17:04] <Saviq> ESphynx, so something definitely went wrong and we need to fix it for the LTS
[17:04] <ESphynx> please :)
[17:04] <Saviq> ESphynx, please file a bug with `apport-bug unity` then
[17:07] <ESphynx> Saviq: #1292623
[17:07] <Saviq> ESphynx, thanks
[17:07] <Saviq> mup, get to work: bug #1292623
[17:08] <ESphynx> thanks Saviq. also may I suggest another hotkey thant Alt ?
[17:08] <Saviq> ESphynx, you can change it
[17:08] <ESphynx> alt is such a meta key that yo use with anything ...
[17:08] <Saviq> ESphynx, and there's been plenty of discussion about that already
[17:08] <ESphynx> and if you change your mind you'll release it
[17:08] <ESphynx> it's just a horrible default
[17:08] <Saviq> ESphynx, how often do you change your mind when pressing alt?
[17:08] <ESphynx> quite often
[17:08] <Saviq> ESphynx, you should make your mind early! ;)
[17:09] <ESphynx> also, I still find confusing that ccsm, something not even installed by default, and part of a different project than Unity is what must be used to fix all these annoying little glitches
[17:09] <ESphynx> Shouldn't be an easy access 'Unity settings' panel ?
[17:09] <Saviq> ESphynx, but anyway, there's plenty of discussion on that in bugs on launchpad, mailing lists etc.
[17:09] <ESphynx> Saviq: probably a good hint that it should be changed!
[17:09] <Saviq> ESphynx, not if no better alternatives were presented
[17:10] <Saviq> ESphynx, there is, and actually this shortcut is in the "keyboard" menu in the standard gnome-control-center
[17:10] <ESphynx> Saviq: I like Windows key + R :P
[17:10] <Saviq> ESphynx, that's different, that's for running commands, which is under alt+f2 in unity
[17:11] <Saviq> ESphynx, check out what the hud is in https://wiki.ubuntu.com/Unity/HUD
[17:11] <ESphynx> "Alt L"? that means the Left Alt? that's confusing also
[17:11] <Saviq> ESphynx, that's the name for the key as gtk defines it, afaict
[17:12] <ESphynx> Saviq: also, why isn't the launcher just integrated in the panel that searches ?
[17:12] <ESphynx> with a modifier to search vs run maybe ?
[17:12] <Saviq> ESphynx, launcher is the vertical panel on the left, dash is what you get on super press
[17:12] <mhr3_> Saviq, oh could you add https://code.launchpad.net/~mhr3/unity8/extend-scope-tool/+merge/209955 to one of the asks?
[17:13] <ESphynx> Please type your command vs Run a command  is different?
[17:13] <Saviq> mhr3_, will do, needs review first :)
[17:13]  * mzanetti changes his mind quite often too when pressing alt. however, as that activates the application's menu its not much different than invoking the hud
[17:13] <mhr3_> Saviq, right... could you review? :)
[17:13] <Saviq> mhr3_, not before Monday ;)
[17:13] <Saviq> ESphynx, I'm polish, so it doesn't say that here
[17:14] <Saviq> ESphynx, but if that's confusing for you, file another bug please, maybe it could be improved
[17:14] <Saviq> ESphynx, the HUD searches within the application menus, has nothing to do with "commands" as you would run them in the terminal
[17:15] <mhr3_> Saviq, oh wait, i based it off new-scopes... i guess that isn't going to be merged directly, should probably rebase?
[17:15] <Saviq> mhr3_, yeah, on trunk if possible?
[17:15] <mhr3_> sure, it's isolated to the tool
[17:19] <ESphynx> Saviq: The hud sarches yes (that's what I'm saying holding a key could make it run instead), but difference between Alt and Alt-F2 is ?
[17:21] <mzanetti> Saviq: will the ScopeDelegateMapper grow again at some point or should we get rid of it?
[17:21] <Saviq> ESphynx, <Super> goes to dash, which searches in apps, files and other local and online sources, Alt-F2 runs commands as you would type them in the terminal, Alt itself searches through the currently focused app menu items
[17:21] <Saviq> ESphynx, the three have very different purposes
[17:22] <Saviq> mzanetti, I think we did already somewhere
[17:22] <Saviq> mzanetti, ah well, until we have running apps in dash
[17:22] <mzanetti> Saviq: reviewing the new-scopes-cleanup branch its shrinking, but still there
[17:22] <Saviq> mzanetti, we need *something* like it
[17:23] <ESphynx> Saviq: ohhh. *that's* what it does
[17:23] <Saviq> mzanetti, it could be reduced
[17:23] <Saviq> ESphynx, makes sense now to be on Alt, which invokes the same menus? ;)
[17:23] <ESphynx> Saviq: well now I understand why alt was chosen, but would on earth would I want to type in menu commands!!
[17:23] <ESphynx> why*
[17:23] <Saviq> ESphynx, read the wiki
[17:23] <mzanetti> Saviq: yeah, its mostly a: clickscope ? DashApps.qml : "GenericScopeView.qml"
[17:24] <Saviq> mzanetti, could be reduced to that, yeah
[17:24] <mzanetti> well... no need to nitpick on it if everything else is ok. continuing the review
[17:24] <Saviq> ESphynx, complicated apps (inkscape, gimp, and many others) have really complicated menu structures
[17:24] <ESphynx> Saviq: Also I guess my toolkit should integrate with the Unity menus just like it should with the Quartz menus :P
[17:25] <Saviq> ESphynx, "your toolkit"?
[17:25] <ESphynx> Saviq: yes I figured that's what it was intended for :
[17:25] <ESphynx> Saviq: yeah my still unknown toolkit :P
[17:25] <Saviq> ESphynx, navigating through them, especially when you're only starting, is rather tedious
[17:25] <Saviq> ESphynx, right, yeah it should integrate, usually toolkits have entry points for that now
[17:26] <ESphynx> yeah still a todo ;)
[17:26] <Saviq> mhr3_, submitter checklist please
[17:27] <mhr3_> oh.. that thing
[17:27] <mhr3_> Saviq, got the wiki link where you have those handy?
[17:27] <Saviq> mhr3_, https://wiki.ubuntu.com/Process/Merges/Checklists/Unity8
[17:28] <mhr3_> ty
[17:31] <Saviq> mhr3_, could you add a note on how to test it?
[17:31] <mhr3_> k
[17:40] <Saviq> mhr3__, thanks
[17:41] <Saviq> mhr3__, you seem to accrue _s over time ;D
[17:42] <mhr3__> eh? didn't get that
[17:42] <mhr3__> oh
[17:43] <mhr3> Saviq, blame broadcom :P
[17:43] <Saviq> mhr3, :)
[17:45] <mzanetti> Saviq: the diff for the cleanup branch contains at least 3 other branches
[17:45] <mzanetti> I guess we should land them first?
[17:58] <Saviq> mzanetti, that's what I'm doing now
[17:58] <Saviq> mzanetti, or well, we still need to wait until Monday probably
[17:59] <Saviq> mzanetti, but all the ACKed branches now are in a silo and I'm running the last tests for them
[20:49] <om26er> andyrock, there ?
[20:51] <andyrock> om26er, yeah but end of day
[20:51] <andyrock> it's urgent?
[20:52] <om26er> andyrock, no not at all, just a bug that I started noted recently, will find you monday
[20:52] <andyrock> om26er, what bug? :D
[20:52] <om26er> andyrock, with multiple open windows, quickly pressing super+w does not start spread rather dash opens :)
[20:53] <andyrock> om26er, yeah we noticed some problems with super/alt tap too
[20:53] <andyrock> we had some changes in the way with handle key grabbing
[20:54] <andyrock> om26er, i think i'm not the best one to work on it tough
[20:54] <andyrock> kind busy with lockscreen now
[20:54] <andyrock> there are some issues in the integration
[20:54] <om26er> andyrock, sure just wanted to make sure its known
[20:54] <om26er> which it clearly is :)
[22:41] <ESphynx> hey guys I think I've find another bug
[22:41] <ESphynx> if I type in my IDE (Window ... there's a long delay on the ( because it's parsing on a big file, and then the following letters end up mixed up
[22:41] <ESphynx> looks like the events are being peeked at and put back in the queue mixed up...
[22:43] <ESphynx> sorry, disregard. this happens in Cinnamon too :P