[08:03] <tsdgeos> Saviq: answered in https://code.launchpad.net/~aacid/unity8/filtergrid_bindingloop/+merge/216147
[08:04] <Saviq> tsdgeos, tx
[08:17] <tsdgeos> Saviq: how are we doing on the landing side?
[08:18] <Saviq> tsdgeos, we ~need to wait for U to open
[08:18] <tsdgeos> we should at least get https://code.launchpad.net/~aacid/unity8/card_optimizations/+merge/213660 in so qmluitests stop failing
[08:18] <tsdgeos> ouch
[08:18] <Saviq> tsdgeos, yeah, already in a silo
[08:18] <Saviq> tsdgeos, but I don't want to SRU it
[08:19] <Saviq> don't think it's worth the pain
[08:19] <tsdgeos> ok
[08:21] <mhr3> Saviq, how can i get more debug on "QUbuntu: Could not create application instance" ?
[08:21] <Saviq> mhr3, look in unity8.log
[08:22] <mhr3> Saviq, also, good morning :)
[08:22] <mhr3> Saviq, it's not unity though, it's an app
[08:22] <Saviq> mhr3, yes, look in unity8.log why it rejected it
[08:23] <Saviq> mhr3, did you pass --desktop_file_hint?
[08:23] <mhr3> ah, it really says something :)
[08:30] <mhr3> Saviq, hm, keeps telling me that no desktop_file_hint was specified, even if i do specify it :/
[08:30] <Saviq> mhr3, full path? is it a bash wrapper by any chance?
[08:30] <mhr3> Saviq, it's.. complicated :)
[08:31] <mhr3> can try full path to it
[08:31] <Saviq> mhr3, the process which creates the Mir connection needs to have full path to the .desktop file on its command line
[08:31] <Saviq> mhr3, or be the main process launched by upstart-app-launch
[08:33] <mhr3> Saviq, is qtubuntu the one who tries to parse it out from the cmd line?
[08:33] <Saviq> mhr3, no, unity-mir is
[08:34] <Saviq> mhr3, if you wanted more output, you'd have to build unity-mir with no -DNODEBUG
[08:37] <mhr3> eek, it reads /proc/*/cmdline
[08:41] <tsdgeos> i did that i think ^_^
[08:41] <tsdgeos> on command by someone
[08:42] <Saviq> mhr3, the whole thing is eek indeed
[08:42] <Saviq> mhr3, which is why you should just build a .desktop file and launch via ual :P
[08:43] <tsdgeos> Saviq: see last comment of https://code.launchpad.net/~josharenson/unity8/doc_args/+merge/216649
[08:43] <mhr3> Saviq, and i am, but.. as i said.. complicated :)
[08:43] <Saviq> mhr3, and/or push Ted to do https://docs.google.com/a/canonical.com/document/d/1ODZjYjpMre2T-IFuFdBmzee4G0MRSsU4DbRkuZhts7o/edit ;)
[08:43] <Saviq> mhr3, yeah, I can tell you're doing something weird :P
[08:43] <mhr3> super weird ;)
[08:44] <Saviq> tsdgeos, or we could just use gettext there?
[08:44] <Saviq> OTOH translating --help? who does that :D
[08:44] <tsdgeos> Saviq: but then you need to load it there too because the loading we do in qml is too late
[08:45] <Saviq> tsdgeos, yeah I know
[08:45] <tsdgeos> Saviq: kde software does, that's why QCommandLineParser has the option
[08:45] <Saviq> tsdgeos, j/k
[08:45] <Saviq> tsdgeos, replied
[08:45] <tsdgeos> Saviq: i feel we could do with just pretending people don't and should not care about those comand line options that are kind of internal and not translate them for now
[08:46] <Saviq> tsdgeos, exactly what I said
[08:46] <tsdgeos> but not sure what's our policy and if "everything should be translatable"
[08:46] <tsdgeos> ah didn't read your comment in there
[08:46] <tsdgeos> yet
[08:51] <mhr3> Saviq, so what does ual do special that --desktop_file_hint isn't required then?
[08:51] <Saviq> mhr3, unity-mir talks to ual directly
[08:51] <Saviq> mhr3, so ual reports to unity-mir "hey, dude, there's app foo launching now, beware!"
[08:51] <mhr3> so it just tracks the pid?
[08:51] <Saviq> yup
[08:52] <mhr3> i see
[08:53] <Cimi> Saviq, ~cimi/unity8/fix-locale-tests I removed the first line in the cmake as requested
[08:53] <Saviq> Cimi, kk
[08:53] <Cimi> Saviq, the other branch is still stripping tags..
[08:56] <Cimi> Saviq, how do we want to deal with the logout? https://code.launchpad.net/~paulliu/unity8/logout/+merge/216373
[08:56] <Cimi> quitting is fine?
[08:56] <Saviq> Cimi, yes, see the related unity-mir branch, it deals with everything else
[09:17] <Cimi> Saviq, tags were stripped from the update mir variables branch
[09:17] <Saviq> Cimi, thanks
[09:36] <Cimi> Saviq, on
[09:36] <Cimi> https://bugs.launchpad.net/bugs/1309135
[09:37] <Cimi> Saviq, basically he created a rating widget with both element displayed (review text and stars) but only stars required
[09:37] <Saviq> Cimi, yeah, that should work
[09:37] <Saviq> Cimi, only requiring the stars
[09:38] <Cimi> ok
[09:38] <Saviq> Cimi, that's why it's separate to display vs. require
[09:39] <tsdgeos> Saviq: playing with run_on_device vs "installed image" i find that run_on_device seems laggier
[09:40] <Saviq> tsdgeos, CPU busy pushing text through adb?
[09:40] <tsdgeos> maybe is because we're passing the -qmljsdebugger ?
[09:41] <Saviq> tsdgeos, or that, yeah
[09:47] <mhr3> Saviq, https://bugs.launchpad.net/unity-mir/+bug/1311011
[09:48] <Saviq> mhr3, seen the FIXME there? ;)
[09:48] <Saviq> mhr3, but yeah, confirmed
[09:49] <mhr3> Saviq, nope, no fixme
[09:49] <Saviq> mhr3, well, ok, there's the thing above, says "Hack"
[09:49] <Saviq> mhr3, either way, confirmed
[09:50]  * Saviq wonders if that's still needed, actually... the oxide renderer doesn't have that in its command line...
[09:51] <Saviq> /food
[10:13] <tsdgeos> hmmm
[10:13] <tsdgeos> i'm getting the "Caught an error from create_query(): unity::scopes::TimeoutException: Request timed out after 300 milliseconds" error
[10:13] <tsdgeos> but i do have the scopes running
[10:13] <tsdgeos> any idea why that may happen?
[10:14] <tsdgeos> ok, a restart helped
[10:26] <Cimi> Saviq, if we have required only for the text, but no rating...
[10:26] <Cimi> quite weird a review without a rating
[10:57] <Saviq> Cimi, that depends on what the underlying service implements
[10:57] <Saviq> Cimi, so we need to make sure we support all the cases - even if it seems weird
[11:23] <tsdgeos> he, silly me ^_^
[11:24] <tsdgeos> Saviq: remember when i was confused because by making the filtergridcard have an async loader it should make the list scroll perfectly even if the stuff just showed up blank and loaded later but it didn't?
[11:25] <tsdgeos> well, basically i forgot to make the Card be the sourceComponent of the loader
[11:25] <tsdgeos> so the async wasn't having any effect ^_^
[11:25] <tsdgeos> now if you do that, it's peachy smooth, but feels *ultra* weird
[11:26] <Saviq> tsdgeos, heh
[11:27] <tsdgeos> Saviq: i'll put a branch for you to try, but don't think we can go that way unless we somehow control the async loading better
[11:28] <Saviq> tsdgeos, meaning that you end up with screen completely empty and that after a few seconds the item loads?
[11:28] <tsdgeos> Saviq: yeah
[11:28] <tsdgeos> i mean not "a few seconds"
[11:28] <tsdgeos> but yeah
[11:29] <tsdgeos> we can play with it
[11:29] <tsdgeos> and try to make it so that the text is always there
[11:29] <tsdgeos> but not sure how feasible it is
[11:29] <Saviq> tsdgeos, maybe a placeholder Rectangle { visible: !loader.status == Loader.Ready } would do }
[11:29] <Saviq> -}
[11:29] <tsdgeos> or a fake UShape
[11:30] <tsdgeos> :D
[11:30] <Saviq> yeah, or that
[11:30] <Saviq> but if we say "a fake UShape and title", we're down to async-loading the image ;)
[11:30] <tsdgeos> which is async already
[11:30] <tsdgeos> since it comes from network
[11:30] <tsdgeos> most of the times
[11:30] <tsdgeos> not for the local app
[11:31] <tsdgeos> s
[11:31] <Saviq> exactly, so if we can make it so that we can see a UShape and Text straight away, we need to make it so the actual Card shows them straight away ;)
[11:31] <Saviq> meaning "if it's possible to show shape + text straight away", we need to make it so that the Card does it like that
[11:31] <tsdgeos> well when i said fake UShape i meant an image that looks like an UShape
[11:31] <tsdgeos> not an UShape
[11:33] <tsdgeos> Saviq:  lp:~aacid/unity8/unity8_real_async_loader  you can see how it looks
[11:34] <tsdgeos> it's certainly smoother but awfully looking
[11:34] <Saviq> tsdgeos, kk
[11:34] <tsdgeos> i'll see how can i make it less bad
[11:39] <Saviq> tsdgeos, looks like card sizes got broken, too (see scopes scope - no margin in the middle)
[11:40] <tsdgeos> Saviq: with this patch? or without?
[11:40] <Saviq> tsdgeos, with
[11:40] <tsdgeos> ok
[12:00] <jfi> Hi,about libappindicator, is the 'guide' parameter of app_indicator_set_label supposed to work in trusty? Whatever the way I set it, it does appear to be used. I also does not understand how it can really be useful as the font is not size fixed one. I don't see anyway to change it.
[12:00] <jfi> does *not* appear to be used
[12:30] <Saviq> mhr3, is there a reason for unity8 to wait for scope-ui-starting to return?
[12:30] <Saviq> mhr3, == does scopes-shell deal fine with scope registry starting after the plugin started?
[12:31] <mhr3> Saviq, if it starts within 300ms
[12:31] <Saviq> mhr3, so, no ;)
[12:31] <mhr3> or whatever the timeout is for that
[12:32] <mhr3> might be a second
[12:32] <mhr3> Saviq, shouldn't the emit take like 20ms max?
[12:32] <Saviq> mhr3, yeah, it's fine, just adding a --no-wait to indicators, who don't care
[12:32] <Saviq> mhr3, will not add for scopes-ui-starting
[12:33] <Saviq> mhr3, also, ideas about scope tool triggering the scopes to start? should we just put an emit in tool's main()? can't think of a better solution...
[12:34] <mhr3> Saviq, hm, i find it meh cause it works fine when running through sdk
[12:34] <Saviq> mhr3, bug #1310172
[12:34] <mhr3> you seldom need to debug all *installed* scopes
[12:36] <Saviq> mhr3, sure, please comment on the bug and mark as appropriate?
[12:37] <Saviq> mhr3, maybe we can give up a better error message? maybe something in the UI?
[12:46] <seb128> jfi, try talking to tedg when he's around (he's in Texas so he might not be online yet)
[13:06] <mhr3> Saviq, i'm actually wondering why do we even install a .desktop for it
[13:06] <Saviq> mhr3, indeed
[13:17] <Saviq> mhr3, I already have a branch to drop the .desktop file
[13:46] <tsdgeos> Saviq: ping
[13:46] <Saviq> tsdgeos, wassup?
[13:46] <tsdgeos> Saviq: so i made it so the external thing is not async and what is async is the shape
[13:46] <tsdgeos> so the text is always there on creation
[13:46] <Saviq> tsdgeos, tell me
[13:46] <tsdgeos> it's not as smooth as the other way
[13:46] <tsdgeos> but it's better
[13:46] <tsdgeos> BUT
[13:47] <tsdgeos> there's the problem in which we align the header below the art
[13:47] <tsdgeos> and thus until the art is loaded the text is up and then jumps down
[13:48] <Saviq> should be solvable, though, in case we know the height before its loaded?
[13:49] <Saviq> which is the case for the app cards
[13:49] <paulliu> dandrader: hi, please re-review https://code.launchpad.net/~paulliu/unity-mir/logout/+merge/216336
[13:50] <tsdgeos> Saviq: do we? where does it come?
[13:50] <Saviq> mikenagle_, could use your input in bug #1237970
[13:50] <Saviq> tsdgeos, from CardTools
[13:50] <Saviq> =-s
[13:50] <Saviq> -s
[13:51] <Saviq> tsdgeos, or well, we get aspect-ratio in the template, and that's the aspect ratio of the space in which the art will be
[13:51] <Saviq> tsdgeos, respective to card width
[13:52] <Saviq> tsdgeos, right now it's calculated in Card itself, should probably move out to CardTool...
[13:53] <tsdgeos> Saviq: you mean updateWidthHeightBindings ?
[13:53] <Saviq> tsdgeos, yeah, in a sense
[13:54] <tsdgeos> but there we need the image to be loaded, no?
[13:54] <Saviq> tsdgeos, but we only need it to maintain the aspect ratio
[13:56] <tsdgeos> i understand what you say
[13:56] <tsdgeos> will try to make it happen D:
[13:59] <Saviq> tsdgeos, basically, as we discussed before, anything that is calculated against components[] or template[] is a candidate for moving into the CardTool
[13:59] <Saviq> at least in aprt
[13:59] <Saviq> part
[14:37] <pete-woods> larsu: hi, we're getting a strange thing happening in HUD where what appear to be invalid menu indexes are being emitted through the items-changed signal (https://errors.ubuntu.com/problem/648b0ee396d66bc960c224a5794f5c22850b51ed) see frame #12
[14:38] <pete-woods> wondered if you might have any insight
[14:39]  * larsu looks
[14:40] <pete-woods> it looks like -1 is getting converted into an unsigned int somehow
[14:40] <pete-woods> but why we'd get an index of -1 being sent over the bus, I don't know
[14:41] <pete-woods> it looks to me like the gmenu implementation internally converts -1 into the end of list index
[14:43] <larsu> pete-woods: I don't think it does... can you reproduce this error locally?
[14:43] <larsu> I would like to see the dbus message that was sent
[14:44] <pete-woods> larsu: unfortunately I'm not able to reproduce it, but the method g_dbus_menu_path_signal is directly connected to the dbus signal is it not?
[14:45] <pete-woods> I realise we can't see the other params, though :(
[14:45] <Cimi> Saviq, tsdgeos I noticed latest commits messages by albert on the card optimisation
[14:46] <Cimi> shoouldn't we keep those on max 2 lines?
[14:46] <Saviq> Cimi, yeah, that should've gone into Description
[14:46] <Cimi> ok
[14:46] <Saviq> Cimi, not max 2 lines, but something reasonable
[14:46] <pete-woods> larsu: we're planning an MR that just exits HUD in this condition and reports the application that triggered it
[14:47] <pete-woods> we're putting all the debug info we can thing of in there (menu structure, that sorta thing). is there anything specific that would help you figure out what's going on?
[14:47] <pete-woods> *think
[14:48] <larsu> pete-woods: not really. let me check with desrt
[15:13] <larsu> pete-woods: so, there are definitely some input validation issues in gdbusmenumodel. I'll fix those (or desrt might)
[15:13] <larsu> those shouldn't lead to that crash though
[15:13] <larsu> and clearly someone is sending the invalid messages in the first place
[15:16] <pete-woods> larsu: I guess I'm puzzled about how they have managed to get that message through, given that if you look at, e.g. g_menu_insert_item, it bounds the position to be between 0 and the menu length
[15:16] <pete-woods> I guess there must be a crack somewhere it has sneaked through
[15:17] <larsu> right
[15:18] <pete-woods> larsu: there are other instances where it looks like the menu index is reasonable (https://errors.ubuntu.com/problem/29678a80c8c2c42e53a74ca04751c29b8d7321d2)
[15:18] <pete-woods> but the client-side copy of the menu structure gets upset when you ask for them
[15:19] <pete-woods> I don't know if this is related or not, and could potentially be memory corruption inside HUD
[15:20] <pete-woods> investigating that case, we're simply accessing position 7 in the menu structure after being told is has been inserted, then gmenumodel asserts that we've given it an invalid index (albeit with a strange error message)
[15:22] <pete-woods> I think (though am not certain) that if you give those accessors an out of bounds index (as far as it is concerned) then you get that "code should not be reached) assertion
[15:24] <larsu> pete-woods: ya, and that makes sense I think, as there's no other way for gmenumodel to report an errror
[15:24] <larsu> basically, if you implement a gmenumodel, you need to do the bounds checking yourself
[15:25] <pete-woods> sure, it's a bit unfriendly to assert, I might prefer a null, but the thing that worries me is that we've just been instructed by the items-changed signal to access that index
[15:26] <pete-woods> it goes, hey, there's new stuff at index 7, okay gimme that menuitem at index 7 then, assert failure
[15:26] <larsu> ya, the input validation is definitely broken
[15:26] <pete-woods> sure, we could check the index range (and we will going forward), but it still makes me worry about what's going on
[15:27] <pete-woods> okay, well as long as you think there's some sanity checking that could be added there
[15:27] <pete-woods> I don't quite understand why the local copy of the menu hasn't been updated in this case, though
[15:27] <pete-woods> but maybe the input is just bad, as you say
[15:28] <pete-woods> I guess we'll have to put some logic into HUD to just block an app as soon as it starts saying "crazy stuff"
[15:28] <larsu> definitely. Especially since these apps can be untrusted
[15:28] <larsu> pete-woods: if you're interested in following the upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=728733
[15:28] <Cimi> mzanetti, Saviq autopilot test for this? https://code.launchpad.net/~paulliu/unity8/logout/+merge/216373
[15:29] <pete-woods> larsu: thanks :)
[15:29] <larsu> I'll try to fix that this week, I'm sure seb128 would be fine with a backport
[15:29] <seb128> +1
[15:38] <Saviq> Cimi, probably makes sense, yeah, I'd rather land it soon, though, so if we don't get it, we'll just file a bug that it's missing
[15:38] <Cimi> k
[16:23] <Cimi> no internet at home for me (almost)
[16:24] <Cimi> connected to a broken public ap
[19:26] <josharenson> I'm trying to make unity8 dependent on qt5 v5.2 or greater. Is the only thing I need to change the 'qt5-default' line of the debian/control file?
[19:44] <kgunn> dandrader: ^ josh's question...
[19:44] <kgunn> josharenson: might have to wait till tomorrow on that one
[19:45] <josharenson> kgunn, no problem.. I've tried changing the value to something that would cause the build/app to break (to see if that was the correct pkg), but it won't break
[19:50] <dandrader> josharenson, well, I would add a "(>= 5.2.1)" to all qt packages listed there
[19:50] <josharenson> dandrader: ok, wasn't sure they _all_ needed it or if just 1
[19:51] <dandrader> josharenson, in practice just one should do the job... but changing all is safer and seems more correct IMHO
[19:51] <seb128> josharenson, why do you want to update the depends?
[19:52] <seb128> ideally a lib that changes its abi would bump its symbol/shlibs versions and rdepends would get the correct updated depends
[19:52] <josharenson> seb128 using a feature (QCommandLineParser) that is only available in >5.2.1  If this seems unecessary/bad idea, I can use a different method
[19:53] <seb128> josharenson, you can check with Mirv tomorrow (it's too late for him at this hour I think), I'm unsure if qt uses shlibs/symbols for that api, but otherwise you just need to update the depends for the library that provides QCommandLineParser
[19:55] <josharenson> seb128, alright. it looks like the lib is in libqtcore but since I didn't see a lib with that exact name in the control file
[19:56] <seb128> josharenson, libs are sometime grouped in packages which have a different name
[19:56] <josharenson> ok
[19:56] <seb128> but ask Mirv tomorrow if you want to be sure
[19:56] <seb128> josharenson, or submit a merge request and wait for the review comment
[19:56] <josharenson> seb128, ok thanks. Do you know his timezone?
[19:56] <seb128> whoever reviews it is going to comment on what you did
[19:57] <seb128> he's early european
[19:57] <josharenson> seb128, will do... thats how I got here in the first place
[19:57] <seb128> like 6am utc to 16pm utc
[19:57] <seb128> or somewhere between those
[19:57] <josharenson> alright