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:17 |
---|---|---|
ricotz | Trevinho, hi, was this really the intention here? ^-- https://bazaar.launchpad.net/~unity-team/bamf/trunk/revision/606 | 07:21 |
larsu | ricotz: certainly not. I'll look into it aftre breakfast | 08:41 |
larsu | thanks for the pointer | 08:41 |
tsdgeos | Cimi: ping | 08:58 |
tsdgeos | Cimi: unping | 08:59 |
tsdgeos | hmmm | 09:11 |
tsdgeos | i can't get released qtmir to build | 09:11 |
tsdgeos | http://paste.ubuntu.com/9933243/ | 09:11 |
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:12 |
Saviq | tsdgeos, what versions of qtmir-{desktop,android} and libunity-api-dev do you have? | 09:13 |
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:14 |
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:15 |
tsdgeos | tx | 09:17 |
Saviq | tsdgeos, looks like Gerry's initial surface geometry | 09:18 |
tsdgeos | yep | 09:18 |
tsdgeos | i had been reviewing that | 09:19 |
Saviq | yup | 09:19 |
tsdgeos | forgot about it | 09:19 |
tsdgeos | uh oh | 09:56 |
tsdgeos | the evil arm linker breaks connect by function pointer is back :/ | 09:57 |
Trevinho | ricotz: oh... that seems wrong indeed | 10:00 |
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:04 | |
mzanetti | Saviq: hey. we have a strange issue in the shell | 10:26 |
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:27 |
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 | 10:36 | |
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:02 |
ricotz | larsu, not sure if it is the same since the lib is doing some caching too | 11:03 |
ricotz | larsu, happens on the dbus interface too for gedit which gives "org.gnome.gedit" | 11:05 |
ricotz | larsu, you realize you are using the desktop_files glist in your commit | 11:07 |
ricotz | larsu, test it with nautilus which is the vivid version here too | 11:08 |
Saviq | mzanetti, can you elaborate? | 12:23 |
mzanetti | Saviq: http://paste.ubuntu.com/9935405/ | 12:23 |
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:24 |
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:25 |
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:26 |
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:27 |
mzanetti | s/son/so/ :D | 12:28 |
=== MacSlow is now known as MacSlow|lunch | ||
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:29 |
Saviq | released != deleted | 12:30 |
mzanetti | behavior is still the same if I export QV4_MM_AGGRESSIVE_GC=1 | 12:30 |
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:31 |
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:36 |
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:37 |
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:39 |
mzanetti | switching between staged/windowed mode with 1 running app windoe leaks about 3MB each time | 12:40 |
* Saviq tries 5.4 | 12:40 | |
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:46 |
Saviq | mzanetti, Qt 5.4 doesn't help either | 12:47 |
Saviq | :/ | 12:47 |
Cimi | Saviq, might be something weird happening on the scope sides | 12:48 |
Saviq | Cimi, what might? | 12:48 |
Cimi | Saviq, I tried this code http://paste.ubuntu.com/9936347/ | 12:49 |
Cimi | Saviq, with pawel branch | 12:49 |
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:50 |
Saviq | Cimi, what is "scopeThatOpenedScope"? | 12:51 |
Saviq | Cimi, why not oldScope.closeScope(oldScope)? | 12:51 |
Cimi | Saviq, scopeThatOpenedScope is the app scope | 12:53 |
Cimi | Saviq, when you open the store | 12:53 |
Saviq | Cimi, why do you need it? | 12:54 |
Cimi | Saviq, because this is what we did in dash.qml | 12:54 |
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:55 |
Cimi | Saviq, oldScope.closeScope(oldScope) seems to work btw | 12:56 |
Cimi | Saviq, but looks weird | 12:56 |
Cimi | scope closing itself? | 12:57 |
Cimi | committing suicide :D | 12:57 |
Saviq | Cimi, yeah, this whole openScope/closeScope thing is misarchitected, really | 12:57 |
Saviq | every scope that opens another scope has a set of temp scope objects it opened... meh | 12:58 |
Saviq | Cimi, I think I know why you lose the new scope - it's because its 'parent' is deleted | 12:59 |
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:00 |
Cimi | Saviq, yeah it is what I thought | 13:01 |
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:02 |
Cimi | Saviq, yeah | 13:03 |
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:04 |
Trevinho | larsu: about that branch.... | 13:10 |
Trevinho | larsu: you need to free the app_id in any case now | 13:10 |
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:11 |
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:12 |
larsu | Trevinho: ooh right, thanks. | 13:14 |
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:15 |
larsu | Trevinho: that can happen? | 13:17 |
larsu | Let's talk about that tomorrow :) | 13:17 |
* larsu fixes the memleak in the meanwhile | 13:17 | |
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:18 |
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:19 |
larsu | rihgt | 13:21 |
mzanetti | Saviq: you aware of anything else we use that's a QQmlPropertyMap? | 13:22 |
=== MacSlow|lunch is now known as MacSlow | ||
tsdgeos | Saviq: i do, need something or alrady fount out? | 13:40 |
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:43 |
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:44 |
mzanetti | can't repro the issue by implementing my own QQmlPropertyMap :( | 13:46 |
larsu | mzanetti: qqmlpropertymap has broken gsettings-qt a couple of times now. I wouldn't be surprised... | 13:49 |
larsu | I'm at a hackfest right now. Will try to have a look later in the train | 13:51 |
mzanetti | larsu: is there anything threaded going on in QGSettings? | 14:19 |
Saviq | tsdgeos, yeah, found out already | 14:21 |
tsdgeos | oki | 14:21 |
Saviq | dandrader, if you could have a look with your touch input hat on - bug #1415902 | 14:22 |
ubot5 | bug 1415902 in unity8 (Ubuntu) "Bottom edge can get stuck part way exposed" [Undecided,New] https://launchpad.net/bugs/1415902 | 14:22 |
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 | 14:46 |
Cimi | Saviq, shall we plan a meeting with pawel? | 15:56 |
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:57 |
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:58 |
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 | 15:59 |
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:00 |
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:01 | |
Cimi | pstolowski, ok | 16:03 |
Cimi | 9:30 my time? | 16:03 |
pstolowski | Cimi, ok | 16:04 |
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:05 |
pete-woods | ah! | 16:06 |
pstolowski | pete-woods, i'll fill you in | 16:06 |
josharenson | kgunn: so my branch(es) caused your phone to not boot? | 16:44 |
josharenson | kgunn: oh I'm reading the silo output now | 16:45 |
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:46 |
kgunn | josharenson: feel free to host your local debs somewhere too | 16:48 |
josharenson | kgunn: ack | 16:48 |
=== alan_g is now known as alan_g|EOD | ||
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:00 |
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:01 |
ChrisTownsend | Saviq: kgunn: Any opinions? ^^^ | 19:03 |
ChrisTownsend | Doing what I propose will also keep us from having to hack up indicator-session to support Unity 8. | 19:05 |
kgunn | ChrisTownsend: sorry, for the delay | 19:53 |
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:54 |
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:55 |
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:56 |
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:57 |
ChrisTownsend | kgunn: There is a Log Out. | 19:58 |
* kgunn needs to play with the latest unity8 desktop :) | 19:58 | |
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 | 19:59 |
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:00 |
kgunn | right | 20:01 |
kgunn | just thinkin' ahead | 20:01 |
ChrisTownsend | kgunn: Ah, righ, I see. | 20:01 |
ChrisTownsend | *right | 20:01 |
kgunn | josharenson: ok, finally got around to testing silo 8, it boots... | 20:57 |
josharenson | kgunn: :-) | 20:57 |
kgunn | josharenson: ok...so try this, lock your phone/screen on, hit power button so screen comes back on | 21:05 |
josharenson | ok | 21:05 |
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:06 |
kgunn | permanently | 21:07 |
josharenson | kgunn: gotcha... I have an idea | 21:07 |
josharenson | kgunn: thanks for testing this btw | 21:07 |
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:08 |
josharenson | kgunn: probably being restart in some other code | 21:09 |
josharenson | restartred* | 21:09 |
* josharenson spells bad | 21:09 | |
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:13 |
josharenson | testing a patch | 21:18 |
Saviq | guys, you know codes are cheating? | 21:19 |
josharenson | kgunn: pushed a fix... I took about 10 screenshots and was never able to make the screen stay on... | 21:40 |
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:52 |
josharenson | kgunn: or ill host a deb if I can get it to build | 21:53 |
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:54 |
kgunn | in case they didn't have Different Strokes in Poland https://www.youtube.com/watch?v=Qw9oX-kZ_9k | 21:55 |
josharenson | kgunn: https://www.dropbox.com/s/rfseuqe49a5kk8s/unity-system-compositor_0.0.5%2B15.04.20150108.2-0ubuntu1_armhf.deb?dl=0 | 22:03 |
josharenson | kgunn: brb doctor's appt, but that _should_ fix the bug | 22:04 |
kgunn | ack | 22:04 |
josharenson | kgunn: any luck? | 23:43 |
kgunn | josharenson: sorry, loaded it...hadn't tried, will right now | 23:44 |
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:56 |
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 | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!