[09:23] <tsdgeos> mzanetti: you could reproduce the bug with the dash contents being empty until closed again on the desktop?
[09:23] <mzanetti> yes, 100%
[09:24] <tsdgeos> mzanetti: on unity7 too or just on unity8 as a session?
[09:24] <mzanetti> just unity8
[09:24] <tsdgeos> k
[09:24] <tsdgeos> so i'll have to sort that first if i'm supposed to work on the bug :D
[09:25] <tsdgeos> first back to filters
[09:25] <mzanetti> right... strange it won't work for you
[09:25] <mzanetti> tsdgeos, but yes, sooner or later you'd need to get that sorted anyways.
[09:25] <tsdgeos> actually it's very funny
[09:25] <tsdgeos> since it throws an exception once i log in inside unity8
[09:25] <tsdgeos> so unity8 and stuff is already up
[09:26] <tsdgeos> mzanetti: honestly i'm not very keen on going to debug why mir decides to throw expcetions up
[09:26] <tsdgeos> but oh well
[09:59] <mzanetti> tsdgeos, it must be some setup issue on your machine I think
[10:00] <tsdgeos> mzanetti: i don't knwo i almost removed and reinstalled everything regarding unity8 and mir yesterdya and the same
[10:00] <tsdgeos> i am not sure it may be something lib related
[10:01] <tsdgeos> but maybe
[10:01] <mzanetti> hmm
[10:01] <tsdgeos> and the exception i get is a runtime one with unity8 running already
[10:02] <tsdgeos> one would think that it it was a lib mismatch it'd fail to start altogether
[13:19] <tsdgeos> Ç/back
[13:19] <tsdgeos> wops
[13:26] <tsdgeos> do we have any MR removing this?
[13:26] <tsdgeos> ./Stages/DesktopStage.qml:166:                onVisibleChanged: console.log("VISIBLE", model.appId, visible)
[13:26] <tsdgeos> mzanetti: ↑ ?
[13:27] <mzanetti> tsdgeos, not that I know, but there's chances ltinkl has one
[13:32] <ltinkl> tsdgeos, yup, it's gone in my new decorations branch
[13:32] <tsdgeos> k
[14:08] <mterry> ltinkl, welcome back  :)
[14:09] <mterry> ltinkl, we had the meeting yesterday, only briefly talked about oobe, but looks like mostly they want spacing changes like making text lines taller -- i.e. more spacing between and trying to wrap text lines better
[14:09] <ltinkl> mterry, I explained in the review document this is not possible to do... sigh did they read it? :)
[14:09] <mterry> ltinkl, I've updated our PPA to be a bit closer to landing-ready.  I've made it vivid+xenial.  And added a couple other packages associated with my edge intro changes
[14:10] <mterry> ltinkl, oh I talked to them
[14:10] <ltinkl> mterry, cool, thanks for that
[14:10] <mterry> ltinkl, both seem possible.  What's the problem?  Don't we have a Text.lineHeight property?
[14:10] <ltinkl> mterry, they want to alter the linespacing, which isn't possible in QML
[14:10] <mterry> ltinkl, and couldn't we have an invisible Text that we know how long the label width is, so we know where to set its wrap width?
[14:10] <mterry> ltinkl, isn't that Text.lineHeight?
[14:11] <ltinkl> mterry, hmm right... maybe, will try
[14:13] <mterry> ltinkl, they also mentioned that some account screen they didn't want was still in there
[14:13] <mterry> ltinkl, but then they mentioned that there was some newish requirement to keep the "admin password" (new name for the sudo password)
[14:14] <mterry> ltinkl, I pushed back a little on that
[14:14] <mterry> ltinkl, as you can see in the email -- tried to figure out where that was coming from.  It wasn't actually coming from security team, so I dunno why it's a requirement
[14:15] <ltinkl> mterry, yeah the account screen is still there as I was waiting for the final decision whether it's still needed or not
[14:17] <ltinkl> mterry, sent an email, let's see
[14:32] <mterry> ltinkl, oh also, I had to disable tests in my branch because your branch failed them.  At the least for old imports (non-1.3), but maybe others?
[14:32] <mterry> ltinkl, though I don't think the PPA runs the full qmltest suite
[14:33] <mterry> ltinkl, let me know when you fix that and I can take out the disable line in mine
[14:38] <ltinkl> mterry, yeah the tests are not fully in shape yet
[14:38] <mterry> ltinkl, that's fine for the qmltests (mine aren't either).  But the import-checker tests runs during build
[14:38] <mterry> ltinkl, so the PPA was ftbfs
[14:38] <mterry> ltinkl, so please fjix that at least (it was from your merge from trunk)
[14:50] <ltinkl> mterry, do you remember what was it failing at?
[14:50] <mterry> ltinkl, yeah bad imports (non-1.3 / qt5.4)
[14:51] <mterry> ltinkl, make tests should show the failure
[14:51] <ltinkl> mterry, hmm it passes here
[14:53] <mterry> ltinkl, uh I meant "make test" but if that still passes...  good?  I can remove the test-comment-out-lines
[14:53] <ltinkl> mterry, hmm that doesn't, a sec
[14:53] <mterry> k
[14:58] <ltinkl> mterry, heh, interesting failure, it chokes on "import Ubuntu.Components.Popups 1.0"
[14:58] <ltinkl> mterry, the regexp is too greedy
[15:00] <mterry> ltinkl, no, your import should be 1.3
[15:00] <ltinkl> mterry, ok, that works
[15:01] <ltinkl> mterry, I thought this component wasn't bumped
[15:03] <ltinkl> mterry, alright, pushed the fixes, make test passing
[15:03] <mterry> ltinkl, nic
[15:03] <mterry> e
[18:50] <ChrisTownsend> dandrader: mzanetti: Any luck on reproducing the dual cursor on Unity 8 desktop?  bregma was just able to reproduce.
[18:50] <mzanetti> ChrisTownsend, dandrader said he couldn't. I didn't find the time to try yet
[18:50] <dandrader> ChrisTownsend, no. moved on to work on something else
[18:50] <mzanetti> let me try now
[18:51] <ChrisTownsend> mzanetti: dandrader: Ok
[18:52] <mzanetti> dandrader, hmm... interesting...
[18:53] <mzanetti> dandrader, so I started gedit, had just one cursor. then I clicked into gedit's menu, the cursor got stuck there and from the top left the second one appeared
[18:53] <dandrader> mzanetti, oh, don't do that!
[18:53] <mzanetti> dandrader, interesting thing is that the second cursor that appears is much faster than the first
[18:53] <dandrader> mzanetti, we don't support menus yet
[18:53] <mzanetti> right
[18:53] <dandrader> mzanetti, if will cause a new surface to be created to hold that menu. unity8 should blow up
[18:53] <dandrader> mzanetti,  s/if/it
[18:54] <mzanetti> ChrisTownsend, hey, if I see gedit's window decoration, does that mean it runs in libertine?
[18:54] <ChrisTownsend> I see it when I click inside the gedit window.
[18:54] <ChrisTownsend> mzanetti: No, not libertine at all.
[18:54] <dandrader> mzanetti, gedit is drawing its own window decoration I think. from window manager's point of view it's a chrome-less window
[18:55] <dandrader> mzanetti, or should I say GTK
[18:55] <dandrader> mzanetti, another todo item: support "frameless" window hint or something like it
[18:56] <ChrisTownsend> Just clicking inside the gedit window will summon the second cursor.
[18:56] <mzanetti> had to reboot :D
[18:57] <dandrader> ChrisTownsend, hmmmm.... so it's not jsut by running gedit, like the bug report said
[18:58] <mzanetti> just clicking inside the text editor doesn't get it for me
[18:58] <ChrisTownsend> dandrader: No, I think I made a comment in the bug that entering the window will cause the second cursor to appear, but I think actually clicking in the window is what triggers it.
[18:58] <mzanetti> I can select text etc, all fine
[18:58] <ChrisTownsend> mzanetti: You don't have a second cursor?
[18:59] <dandrader> ChrisTownsend, I think Unity8 developers are immune to this bug :)
[18:59] <mzanetti> ChrisTownsend, not unless I click a menu
[18:59] <ChrisTownsend> dandrader: lol, you guys!
[18:59] <ChrisTownsend> mzanetti: Hmm
[18:59] <mzanetti> I can repro it tho with the menu...
[18:59] <mzanetti> unity doesn't immediately blow up, it gets me the second cursor... doing some more clicks it eventually blows up then
[19:00] <ChrisTownsend> Actually, this time, just entering the gedit window brought up the 2nd cursor.
[19:09] <mzanetti> ChrisTownsend, could it be that it tries to open some tooltip or something?
[19:09] <ChrisTownsend> mzanetti: No, I don't think so.  I just move the regular cursor into the window and move it and then the 2nd appears.
[19:11] <mzanetti> hmpf... nope, not happening here
[19:12] <ChrisTownsend> mzanetti: I don't understand.:-(
[19:12] <ChrisTownsend> mzanetti: I also see this using Vivid+overlay.
[19:13] <mzanetti> http://i.imgur.com/HfkVqiq.jpg
[19:13] <mzanetti> I can select text with the mouse just fine
[19:14] <ChrisTownsend> mzanetti: Hmm, that kind of looks like the original cursor provided by Mir and not the new Unity8 cursor that is larger and fuzzier.
[19:14] <mzanetti> no, it's the slow one
[19:14] <mzanetti> high-dpi screen here
[19:14] <ChrisTownsend> mzanetti: Ah, ok:)
[19:15] <ChrisTownsend> mzanetti: Are you using a mouse or touchpad?
[19:15] <mzanetti> ChrisTownsend, speaking of which, can we scale gedit/gtk somehow?
[19:15] <mzanetti> touchpad
[19:15] <ChrisTownsend> mzanetti: I'm sure it can be, but I'm not sure how.
[19:15] <ChrisTownsend> mzanetti: Ok, I'm using touchpad as well.
[19:16] <mzanetti> I'm on v+o too, daniel is probably on x
[19:18] <ChrisTownsend> mzanetti: Well, I'm stumped as to why you guys don't see it, but I know of at least 4 different machines that get this issue.
[19:18] <ChrisTownsend> mzanetti: As dandrader said, I guess you guys are immune.
[19:19] <mzanetti> ChrisTownsend, how are you running it? starting a session from lightdm? unity8-desktop-session-mir?
[19:20] <ChrisTownsend> mzanetti: Yes, unity8-desktop-session-mir and using lightdm to login.  All packages from the archive.
[19:20] <mzanetti> same here :/
[19:24] <ChrisTownsend> mzanetti: Hmm, something weird.  I had my mouse over the window and was moving it slowly and didn't see the 2nd cursor.  Then as I was moving it, it showed up on the edge of the window as if it became visible all of a sudden and then stayed visible.  I wonder since you're on hi dpi if you keep moving the cursor around until the hidden cursor hits the window.
[19:28] <ChrisTownsend> mzanetti: dandrader: What code tells Mir to hide it's cursor?
[19:29] <ChrisTownsend> (I guess it's Mir cursor)
[19:29] <dandrader> ChrisTownsend, it's in qtmir
[19:29] <ChrisTownsend> dandrader: ok
[19:30] <dandrader> ChrisTownsend, it's kinda workaround. Mir is buggy when its comes to cursor visibility
[19:31] <dandrader> ChrisTownsend, grep for 1502200
[19:31] <dandrader> ChrisTownsend, (it's the bug number associated with the issue)
[19:31] <ChrisTownsend> dandrader: Ok, will do, thanks
[19:32] <dandrader> ChrisTownsend, and the fix (new api for wrapping mir cursor) is also buggy
[19:32] <bregma> I'm not on a high DPI screen when I see the second cursor
[19:33] <dandrader> bregma, screen DPI should be orthogonal to this issue
[19:33] <bregma> the supernumerarary cursor looks like a hardware cursor
[19:34] <bregma> maybe GTK is turning that on directly (it likes to take control) and Unity 8 only does software cursors
[19:35] <ChrisTownsend> bregma: I do get the issue when running X apps as well like LO and FF.
[19:36] <bregma> ChrisTownsend, on Unity 8?  Don't those apps use GTK back ends where possible?
[19:37] <ChrisTownsend> bregma: I mean in a Libertine container, although I want to be clear that Libertine is not the culprit.
[19:41] <ChrisTownsend> I think screen resolution/DPI does have an effect on when the Mir cursor actually hits the gedit window.
[19:42] <ChrisTownsend> It's not the cause of the issue, only it hides the issue from occurring.
[19:43] <ChrisTownsend> Probably something in Mir that says show the cursor over these types of windows.
[19:59] <dandrader> ChrisTownsend, thing is, mir has no idea of what's going on in the unity8 qml scene
[20:00] <dandrader> ChrisTownsend, unity-system-compositor only knows that it's (hidden) cursor is over the unity8 surface, which takes the entire screen
[20:01] <dandrader> ChrisTownsend, the hardware cursor (that little bugger that pops up) is controlled by unity-system-compositor
[20:01] <ChrisTownsend> dandrader: Ok, thanks for the explanation.
[20:04] <ChrisTownsend> dandrader: Hmm, doing a quick look through u-s-c code, I don't see any calls to hide()/show() methods for the cursor.  Would there be other method names that do the same thing?
[20:09] <dandrader> ChrisTownsend, I don't know that code. But I would think it's all in libmir itself
[20:09] <dandrader> ChrisTownsend, ie, Mir
[20:09] <ChrisTownsend> dandrader: Ok
[20:10] <dandrader> ChrisTownsend, it can be confusing. Because qtmir/unity8 uses libmir's server API, but it's in reality running as a nested server. It, from u-s-c perspective it's just a client application/surface
[20:11] <ChrisTownsend> dandrader: Yes, very confusing:)
[20:11] <dandrader> ChrisTownsend, so in the nested server code paths you have server API's calling client APIs behind the scenes to talk to unity-system-compositor
[20:12] <dandrader> ChrisTownsend, and that pretty much explains why the cursor API works so badly in a nested server
[20:12] <ChrisTownsend> dandrader: Sheesh, that's kind of messed up.
[20:13] <dandrader> ChrisTownsend, I mean, it makes sense. but must be hell to implement :)
[20:28] <ChrisTownsend> dandrader|afk: mzanetti: Rebuilding lightdm to disable "--enable-hardware-cursor=true" in it's call to unity-system-compositor no longer brings up the hardware cursor.  Not sure what the side effects of that is.
[20:31] <mzanetti> yeah... I guess if it always loads all the things this can quickly become too memory consuming
[20:31] <mzanetti> wrong chat :D
[20:32] <mzanetti> ChrisTownsend, interesting. so when you see both cursors, does it still work fine? it's just a visual thing?
[20:33] <ChrisTownsend> mzanetti: The Unity 8 cursor is the one that works, the hardware cursor does not.
[20:33] <ChrisTownsend> mzanetti: I'm going to talk to robert_ancell about removing the hack in lightdm.
[20:52] <dandrader> ChrisTownsend, interesting
[22:42] <lpotter> hello