[07:17] larsu, hi, looks like bamf_application_get_desktop_file is returning the desktop-id now instead of "A string representing the path to the desktop file." as documented [07:21] Trevinho, hi, was this really the intention here? ^-- https://bazaar.launchpad.net/~unity-team/bamf/trunk/revision/606 [08:41] ricotz: certainly not. I'll look into it aftre breakfast [08:41] thanks for the pointer [08:58] Cimi: ping [08:59] Cimi: unping [09:11] hmmm [09:11] i can't get released qtmir to build [09:11] http://paste.ubuntu.com/9933243/ [09:12] any idea why would that happen?¿ [09:12] Saviq: ↑ ? [09:12] did we release a new unity-api without the corresponding qtmir? [09:12] huuh [09:13] tsdgeos, what versions of qtmir-{desktop,android} and libunity-api-dev do you have? [09:14] ah wait, maybe my libunity-api-dev is old [09:14] 0.4.4+15.04.20150115-0ubuntu1 and 7.94+15.04.20141205-0ubuntu1 here [09:15] 7.95 [09:15] coming from nowehere [09:15] probably i installed that manually [09:15] meh [09:15] i'll reinstall back [09:17] tx [09:18] tsdgeos, looks like Gerry's initial surface geometry [09:18] yep [09:19] i had been reviewing that [09:19] yup [09:19] forgot about it [09:56] uh oh [09:57] the evil arm linker breaks connect by function pointer is back :/ [10:00] ricotz: oh... that seems wrong indeed [10:04] Trevinho: really, the API is weird... but it's documented like this, so let's fix it [10:04] * larsu looks into it [10:26] Saviq: hey. we have a strange issue in the shell [10:27] Saviq: Loaders don't seem to destroy their items when they're released [10:27] just one? [10:27] otp [10:27] foo [10:27] ooh shiny :D [10:36] ricotz: how can I reproduce this? bamf's dbus interface still returns the path to the desktop file [10:36] * larsu assumes that's the same as the API, but could be wrong [11:02] larsu, i am connecting to BamfMatcher.view_opened and calling on the given BamfView, if is a BamfApplication, get_desktop_file which returns the application_id for at least nautilus and gedit here [11:03] larsu, not sure if it is the same since the lib is doing some caching too [11:05] larsu, happens on the dbus interface too for gedit which gives "org.gnome.gedit" [11:07] larsu, you realize you are using the desktop_files glist in your commit [11:08] larsu, test it with nautilus which is the vivid version here too [12:23] mzanetti, can you elaborate? [12:23] Saviq: http://paste.ubuntu.com/9935405/ [12:24] Saviq: basically, if a gsettings is involved in the expression for a loader source, it won't destroy the old component when creating a new one [12:24] although I'm quite sure I've seen this already before we had the usageModeSettings, in the very first iteration of the ShellRoation stuff [12:25] where it loaded first the phonestage, and then the tabletstage and never destroyed the phonestage [12:25] can't repro if I use a button to trigger things for example... [12:25] maybe GSettings does something odd with the QQmlParserStatus it inherits from... atm I'm still quite lost what's going on [12:26] Saviq: note that it even breaks if the loader source is only based on an intermediate property [12:26] mzanetti, in the qml you gave me (+ import Ubuntu.Components 1.1) I get correct destruction and creation? [12:27] yeah, set the timer interval to 0 [12:27] or enable any other of the lines with the comment // This does NOT destroy the component [12:27] ok now I see [12:27] son only if I use an intermediate property, and then a timer with interval >= 1 to set that it starts working [12:28] s/son/so/ :D === MacSlow is now known as MacSlow|lunch [12:29] mzanetti, I know we expected it, but does a Loader actually advertise it deleting the old object? [12:29] yes, I think so... docs say "causes the item to be released" [12:29] I wonder if it's a gc problem [12:30] released != deleted [12:30] behavior is still the same if I export QV4_MM_AGGRESSIVE_GC=1 [12:31] Saviq: also, it I use a timer to toggle between PhoneShell and DesktopShell, it destroys things correctly [12:31] so not an issue of the content of the loaded item [12:31] yeah, calling gc() doesn't help either [12:36] mzanetti, changing active or making asynchronous doesn't do, either [12:36] wonder if using source instead of sourceComp would [12:36] nope [12:36] we're using source in Shell.qml [12:37] I've already changed Desktop/PhoneStage.qml to be simple rectangles [12:37] no difference [12:37] in any case, looks like a Qt bug, even when triggered by our GSettings (would be good to find a way to repro without our stuff) [12:37] yeah.. [12:37] that's what I tried... failing so far [12:37] tsdgeos, you got 5.4 installed? [12:39] I wonder if it recycles the old object [12:39] Saviq: looking at memory usage, it doesn't seem so [12:39] no, a new address every time [12:40] switching between staged/windowed mode with 1 running app windoe leaks about 3MB each time [12:40] * Saviq tries 5.4 [12:46] ricotz: indeed. I must have been testing with the wrong branch or so. Fix is at lp:~larsu/bamf/fixup-gtk-application-matching [12:47] mzanetti, Qt 5.4 doesn't help either [12:47] :/ [12:48] Saviq, might be something weird happening on the scope sides [12:48] Cimi, what might? [12:49] Saviq, I tried this code http://paste.ubuntu.com/9936347/ [12:49] Saviq, with pawel branch [12:50] what I am doing, when I receive a open signal from the store, I open the new scope and start a timer to close the old one [12:50] when the old one is closed, the scope that was opened from the store goes away, scopeItem.scope is null [12:51] Cimi, what is "scopeThatOpenedScope"? [12:51] Cimi, why not oldScope.closeScope(oldScope)? [12:53] Saviq, scopeThatOpenedScope is the app scope [12:53] Saviq, when you open the store [12:54] Cimi, why do you need it? [12:54] Saviq, because this is what we did in dash.qml [12:55] Saviq, when the temp scope closes, the scope that opened the temp scope closes the temp scope [12:55] Cimi, ok, I see it now [12:56] Saviq, oldScope.closeScope(oldScope) seems to work btw [12:56] Saviq, but looks weird [12:57] scope closing itself? [12:57] committing suicide :D [12:57] Cimi, yeah, this whole openScope/closeScope thing is misarchitected, really [12:58] every scope that opens another scope has a set of temp scope objects it opened... meh [12:59] Cimi, I think I know why you lose the new scope - it's because its 'parent' is deleted [13:00] Cimi, because it's the store scope that opens the new scope, then you close the store scope, and the new scope goes away with it [13:00] pstolowski, ↑ [13:00] this is a mess :/ [13:00] it's Scopes that should have open/goto, not Scope [13:01] Saviq, yeah it is what I thought [13:02] Saviq, parent deleting children [13:02] Cimi, yup [13:02] we'd have to add a stack of temp scopes on top of the dash (which was kind-a the plan at some point) [13:03] Saviq, yeah [13:04] Saviq, short term fix? oldScope.closeScope(oldScope) ? [13:04] but I'm not sure we want to dig into this that far while we don't know the overall direction [13:04] Cimi, no, that's leaking [13:04] Cimi, that's basically NOOP [13:04] Cimi, we need to talk with the plugin folks on how to get this working in the short term [13:10] larsu: about that branch.... [13:10] larsu: you need to free the app_id in any case now [13:11] but... [13:11] I've another concern, as you're now pulling the first .desktop file in list [13:11] while the logic should be similar to what we do afterwards with desktop_class... [13:12] larsu: well, actually I guess we could use the same code, but using app_id if class_name is not defined, or using both first come first served [13:14] Trevinho: ooh right, thanks. [13:15] Cimi, maybe have a look at how our SDK copes with stacks these days (esp. in relation to transitions), maybe it's not going to be that difficult to implement that our sode [13:15] side [13:15] Trevinho: not sure what you mean with "using the same code". Is class_name the same thing as app_id? [13:15] biab [13:15] larsu: no, but... You still need to parse all the .desktop files in list, filtering-out the ones that have ha defined class name that is different to the window (if it has one) [13:17] Trevinho: that can happen? [13:17] Let's talk about that tomorrow :) [13:17] * larsu fixes the memleak in the meanwhile [13:18] larsu: yes, as someone could hack its .desktop files... or chromium web-apps does that [13:18] so could do wine [13:18] Trevinho: I do that for gnome-terminal, and it works just fine [13:18] Saviq, oh, that's indeed an issue [13:18] Trevinho: got an irssi profile with a launcher item and separate thing in alt-tab etc [13:19] Saviq, and moving all that to Scopes seems like the only solutions. I'm not sure about implications of that without actually digging more into it [13:19] yeah, I know... I just don't want risk that there will be cases where there are desktop files matching for the same app id but with different classes... [13:21] rihgt [13:22] Saviq: you aware of anything else we use that's a QQmlPropertyMap? === MacSlow|lunch is now known as MacSlow [13:40] Saviq: i do, need something or alrady fount out? [13:43] mzanetti: gsettings-qt uses qqmlpropertymap (sorry if you already talked abuot that - I didn't find it in the immediate scrollback) [13:43] larsu: that's the root of the evil :) [13:44] larsu: nah, just kidding. I have a very weird issue when a GSettings is involved [13:44] but not sure yet if it's really caused by that [13:44] larsu: if you're interested: http://paste.ubuntu.com/9935405/ [13:46] can't repro the issue by implementing my own QQmlPropertyMap :( [13:49] mzanetti: qqmlpropertymap has broken gsettings-qt a couple of times now. I wouldn't be surprised... [13:51] I'm at a hackfest right now. Will try to have a look later in the train [14:19] larsu: is there anything threaded going on in QGSettings? [14:21] tsdgeos, yeah, found out already [14:21] oki [14:22] dandrader, if you could have a look with your touch input hat on - bug #1415902 [14:22] bug 1415902 in unity8 (Ubuntu) "Bottom edge can get stuck part way exposed" [Undecided,New] https://launchpad.net/bugs/1415902 [14:46] Saviq, yeah, that's an interesting case [14:46] larsu, great [14:46] Saviq, can't say anything without debugging first though [15:56] Saviq, shall we plan a meeting with pawel? [15:57] Cimi, yeah, please do, not sure I need to be there, I think you guys know what's going on [15:57] but let me know if you need me [15:57] Saviq: larsu: tsdgeos: adding "Qt::QueuedConnection" here fixes it: http://bazaar.launchpad.net/~system-settings-touch/gsettings-qt/trunk/view/head:/GSettings/gsettings-qml.cpp#L138 [15:57] Saviq, ok [15:57] currentThread() seems to be the same in both cases though [15:58] pstolowski, can we have a chat tomorrow morning on this issue? [15:58] mzanetti, I'd say that's basically what Timer { interval: 1 } did [15:58] yeah, sort of [15:58] bad thing is, I don't understand why yet [15:58] the variables seem all be ok. there don't seem any multiple threads involved [15:58] yeah, it'd be nice to know what's going on there [15:59] I've tried to reproduce it spinning the event loop here and there, but nothing [15:59] mzanetti, it's like the event loop misses a tick to drop the old object because something else is happening [15:59] also interesting: [15:59] so yeah, I'd be +1 to add this workaround with a linked bug and a FIXME [16:00] and investigate more sometim [16:00] e [16:00] if I do usageModeSettings.usageMode = "Windowed" from qml, which, afaict, does the same code path, it still works [16:00] Cimi, sure, please also invite pete-woods [16:00] only if the trigger really comes from the backend side it's broken [16:01] Saviq: I'll wait till larsu have a chat about it before applying the workaround. maybe he knows about something that explains it. [16:01] something's broken with my english now [16:01] Cimi, we have standup 8:30~9:00 your time, so any time after that is fine [16:01] * mzanetti takes a break [16:03] pstolowski, ok [16:03] 9:30 my time? [16:04] Cimi, ok [16:05] pstolowski: I would say that I know very little about QtGSettings [16:05] pete-woods, it's not about this [16:05] pete-woods, different topic :) [16:06] ah! [16:06] pete-woods, i'll fill you in [16:44] kgunn: so my branch(es) caused your phone to not boot? [16:45] kgunn: oh I'm reading the silo output now [16:46] josharenson: yeah, just a double check those are the right branches correct? [16:46] kgunn: yeah they are, I just merged the unity8 one w/ trunk... not sure if that would help [16:46] kgunn: I can send you a deb if you would like [16:46] josharenson: i'll rebuild and try after lunch [16:46] ok [16:48] josharenson: feel free to host your local debs somewhere too [16:48] kgunn: ack === alan_g is now known as alan_g|EOD [19:00] I'm working on getting logout/reboot/shutdown to work in Unity 8. I was thinking that we should probably do the same thing that Unity 7 does when one clicks Logout and Shutdown from indicator-session, at least for now. Does anyone have an opinion about that? [19:01] For example, in Unity 7, if you click "Logout", you get a dialog that asks if you want to Lock or Logout. For "Shutdown", you get a dialog that asks if you want to Reboot or Shutdown. [19:03] Saviq: kgunn: Any opinions? ^^^ [19:05] Doing what I propose will also keep us from having to hack up indicator-session to support Unity 8. [19:53] ChrisTownsend: sorry, for the delay [19:54] for sure, i agree, shutdown should bring up [19:54] kgunn: No worries. [19:54] the notification that we have [19:54] on unity8 [19:55] kgunn: Right. What I mean is that in Unity 7, if you click "Shut Down" in the indicator-session menu, you get a dialog that says either "Reboot" or "Shutdown". Should we make Unity 8 do the same, at least for now? If not, then we are going to have to hack up indicator-session some to separate out Reboot and Shutdown. [19:56] ChrisTownsend: yeah, what i meant was, we have the notification (dialog) that has that...altho, it's only fired on long power keypress [19:56] i suppose it needs some wire for the session-indicator menu select event [19:57] as well as long power keypress [19:57] kgunn: This is for desktop. [19:57] right i'm with you [19:57] kgunn: Ok, just making sure. [19:57] kgunn: Right now, Reboot and Shutdown dialogs are separated in Unity 8 unlike Unity 7. [19:57] i guess one thing that's different, is we have no "logoff" [19:58] kgunn: There is a Log Out. [19:58] * kgunn needs to play with the latest unity8 desktop :) [19:59] ChrisTownsend: are you going to brussels ? [19:59] kgunn: I have an MP to fix Log Out properly though. [19:59] kgunn: Yep [19:59] good [19:59] kgunn: We can discuss more then. Just throwing this out there to think about. [19:59] ChrisTownsend: it's a good point [20:00] i suppose on a desktop, you might just want to power down on long power press? [20:00] vs mobile where you get the dialog... [20:00] i mean if you hold long enough it just powers off anyway [20:00] kgunn: Hmm, well, right now I'm only concerned about clicking "Log Out" and "Shut Down" in the indicator-session pull down menu. [20:01] right [20:01] just thinkin' ahead [20:01] kgunn: Ah, righ, I see. [20:01] *right [20:57] josharenson: ok, finally got around to testing silo 8, it boots... [20:57] kgunn: :-) [21:05] josharenson: ok...so try this, lock your phone/screen on, hit power button so screen comes back on [21:05] ok [21:06] josharenson: then...hold the power button [21:06] for enough time that you think [21:06] the power dialog will come on...just before, hit low volume [21:06] do a couple of times [21:06] at least once see if you can get the dialog to happen [21:06] this is what i was doing....and i can get the screen to stay on [21:07] permanently [21:07] kgunn: gotcha... I have an idea [21:07] kgunn: thanks for testing this btw [21:08] josharenson: i'll see if i can get it to do it not on the lock screen....tried only a little on dash [21:08] josharenson: intersting, i can just touch the screen, that's enough to restart the unity8 inactivity timer...and it will turn off the screen [21:09] kgunn: probably being restart in some other code [21:09] restartred* [21:09] * josharenson spells bad [21:13] josharenson: ok, while phone unlocked, hold power key for maybe longer then normal, but before the pwr dialog appears, hit vol key down, power up, then vol up.... [21:13] and it should likely be stuck on [21:18] testing a patch [21:19] guys, you know codes are cheating? [21:40] kgunn: pushed a fix... I took about 10 screenshots and was never able to make the screen stay on... [21:52] josharenson: so rebuild ? [21:52] yes [21:52] kgunn: USC is small enough to build on the device if thats easier for you [21:53] kgunn: or ill host a deb if I can get it to build [21:54] Saviq: whatchyou talkin' bout willis ? [21:54] kgunn, up, down, down, down, A, B, A, down [21:54] :-p fixes all bugs [21:55] in case they didn't have Different Strokes in Poland https://www.youtube.com/watch?v=Qw9oX-kZ_9k [22:03] kgunn: https://www.dropbox.com/s/rfseuqe49a5kk8s/unity-system-compositor_0.0.5%2B15.04.20150108.2-0ubuntu1_armhf.deb?dl=0 [22:04] kgunn: brb doctor's appt, but that _should_ fix the bug [22:04] ack [23:43] kgunn: any luck? [23:44] josharenson: sorry, loaded it...hadn't tried, will right now [23:56] josharenson: this is looking pretty good.... [23:56] kgunn: hooray [23:56] as easy as i could repro....i can't seem to here [23:57] kgunn: the issue seemed pretty clear [23:57] i'll hammer a bit more [23:57] but yeah...looks good [23:57] kgunn: same