| === 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 | ||
| t1mp | kalikiana: happroved https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/hideTheDelegate/+merge/316545 | 10:41 |
|---|---|---|
| === chihchun is now known as chihchun_afk | ||
| kalikiana | oSoMoN: There's no regression test... | 11:41 |
| oSoMoN | kalikiana, for https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/revision/2171 you mean? | 11:43 |
| kalikiana | oSoMoN: Yep | 11:44 |
| 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:45 |
| 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:47 |
| 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:49 |
| oSoMoN | or maybe a property of the MainView or some such, which the browser app doesn’t use? | 11:50 |
| === _salem is now known as salem_ | ||
| daker | kalikiana or t1mp https://code.launchpad.net/~daker/ubuntu-ui-toolkit/fix.1664758/+merge/317307 | 12:03 |
| 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:26 |
| kalikiana | daker: Looking | 12:27 |
| oSoMoN | kalikiana, in webbrowser-app the root item is a QtObject that instantiates Windows | 12:40 |
| oSoMoN | kalikiana, so there seems to be a case where this context property is null | 12:41 |
| === chihchun_afk is now known as chihchun | ||
| 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:03 |
| oSoMoN | ok, but in that case the regression in webbrowser-app is observable even when there’s only one browser window | 13:04 |
| 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:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| kalikiana | oSoMoN: Well, Qt will do that, and regardless it is racy by design because it is null until *someone* updates it | 13:11 |
| kalikiana | QGuiApplication to be precise | 13:12 |
| kalikiana | Unless you are somehow side-stepping that | 13:12 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!