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