=== tgm4883_ is now known as tgm4883
=== chihchun_afk is now known as chihchun
=== chesedo- is now known as chesedo
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[10:41] <t1mp> kalikiana: happroved https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/hideTheDelegate/+merge/316545
=== chihchun is now known as chihchun_afk
[11:41] <kalikiana> oSoMoN: There's no regression test...
[11:43] <oSoMoN> kalikiana, for https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/revision/2171 you mean?
[11:44] <kalikiana> oSoMoN: Yep
[11:45] <oSoMoN> kalikiana, all I know is that this made the browser regress, I don’t have time to spare to write a standalone reproducer
[11:47] <kalikiana> I see. I'll have a look at exactly what's happening. Especially a tiny extra condition like that, not even a one-line, looks like it's gonna break all the time if we can't figure out why it broke
[11:49] <oSoMoN> kalikiana: agreed. I had a very quick look at the code and tried to understand where that "window" variable came from, but couldn’t figure it out in the 1min30 I spent on it. Thought it might be the Window.window attached property, but in that case why it’s not expressed as "Window.window" is puzzling
[11:50] <oSoMoN> or maybe a property of the MainView or some such, which the browser app doesn’t use?
=== _salem is now known as salem_
[12:03] <daker> kalikiana or t1mp https://code.launchpad.net/~daker/ubuntu-ui-toolkit/fix.1664758/+merge/317307
[12:26] <kalikiana> oSoMoN: it's a context property actually, set during initialization of Ubuntu.Components - in QML you don't normally have access to the window component if the root item isn't a Window (subclass), so this is the only non-app-specific way to get to it. It might be time to look for the root item being a Window first, as apps are (hopefully) moving to MainWindow (or Window) and we need to kill context properties anyway.
[12:27] <kalikiana> daker: Looking
[12:40] <oSoMoN> kalikiana, in webbrowser-app the root item is a QtObject that instantiates Windows
[12:41] <oSoMoN> kalikiana, so there seems to be a case where this context property is null
=== chihchun_afk is now known as chihchun
[13:03] <kalikiana> oSoMoN: Actually I lied. "window" is the focussed window, not simply the root item. So there can be a race condition and it's not necessarily the same window later on.
[13:04] <oSoMoN> ok, but in that case the regression in webbrowser-app is observable even when there’s only one browser window
[13:06] <kalikiana> oSoMoN: Sure, there's still a race defining the very first window, and you are probably running into the point where "QGuiApplication::focusWindow()" is returning nullptr, which we can't do anything about.
[13:07] <kalikiana> Even if it was a property on a singleton, it would be null initially
[13:07] <oSoMoN> got it, so if we can’t do anything about it, adding guards to verify that 'window' is not null is the way to go, right?
[13:09] <kalikiana> oSoMoN: Yeah. And if in your case the root item is an object, we probably have no alternative options for finding the current window
[13:10] <kalikiana> I would've suggested that normally
[13:10] <oSoMoN> kalikiana, is there a way for the app to inform the toolkit what the current window is?
[13:10] <oSoMoN> (i.e. a way to set that context property)
[13:11] <kalikiana> oSoMoN: Well, Qt will do that, and regardless it is racy by design because it is null until *someone* updates it
[13:12] <kalikiana> QGuiApplication to be precise
[13:12] <kalikiana> Unless you are somehow side-stepping that
=== JanC_ is now known as JanC
=== chihchun is now known as chihchun_afk
=== jdstrand_ is now known as jdstrand
=== salem_ is now known as _salem