[09:42] <tvoss> mzanetti, you fine if I answer to your latest reply publicly. Seems like you only sent it to me instead of the list
[10:10] <tsdgeos> Saviq: damn, my 5 lines patch fixes https://bugreports.qt-project.org/browse/QTBUG-30730 and https://bugreports.qt-project.org/browse/QTBUG-34617 but not https://bugreports.qt-project.org/browse/QTBUG-34651
[10:10] <tsdgeos> i'll have a look at that one too
[10:17] <mzanetti> tvoss: oh... yeah, that wasn't intentionally
[10:18] <tvoss> mzanetti, ack, can you resend publicly, will answer then
[10:19] <mzanetti> tvoss: done
[10:25] <Saviq> tsdgeos, oh interesting...
[10:25] <tsdgeos> yeah
[10:25] <tsdgeos> similar but not same thing
[10:25] <Saviq> tsdgeos, 1 != 1?...
[10:25] <tsdgeos> yep
[10:25] <tsdgeos> kind of
[10:25] <Saviq> it probably tries to compare the wrapper against the object or something?
[10:25] <tsdgeos> yeah
[10:26] <tsdgeos> need to find out a comparison that works and then fix this one to go there too :D
[10:26] <Saviq> ;)
[10:51] <dednick> Cimi: ping
[10:57] <tsdgeos> woa, adding a debug in qv4runtime_p.h wasn't a good idea :D its recompiling almost everything :S
[11:14] <dednick> Cimi: https://bugs.launchpad.net/unity8/+bug/1250815
[11:36] <Saviq> mhr3, any reason why lp:unity-scopes-shell source package is unity8-plugin-scopes? why can't it be the same name?
[11:37] <Saviq> mhr3, also, qtdeclarative5-foo-plugin is the preferred name for QML plugins
[11:37] <Saviq> mhr3, OTOH we might want a different naming, 'cause it's meant to be installed in a different import path...
[11:38] <Saviq> didrocks, thoughts ↑? where should we install plugins directed at the shell?
[11:38] <Saviq> and whether to change the package naming scheme?
[11:38] <Saviq> Mirv, I'd like your opinion, too ↑
[11:39] <didrocks> the source package needs to match the project name
[11:39] <didrocks> for non confusing reason :)
[11:39] <didrocks> are those only unity8 plugins?
[11:39] <didrocks> it's not in the standard QML import path?
[11:40] <Mirv> Saviq: the preferred naming is actually qtdeclarative5-foo0.1, as decided by kenvandine & co, so that also the install path contains the API version specific path - see for example qtdeclarative5-friends0.2
[11:40] <Mirv> Saviq: the idea is that one can co-install older API package as well, for example than that was released with 13.10
[11:40] <didrocks> (I decided that one actually :p)
[11:41] <Saviq> didrocks, yeah, we want to put them on a unity8- (well, shell-) specific path
[11:41] <Saviq> didrocks, so that apps don't have access there
[11:41] <didrocks> maybe it shouldn't follow that naming scheme then
[11:41] <Mirv> didrocks: oh, I never figured out how the decision process went, I only heard the end result :)
[11:41] <didrocks> Saviq: will it follow your virtual unity-apis versions?
[11:41] <Saviq> didrocks, yes
[11:42] <didrocks> so I would say unity8.<APIversion>-<plugin-name>-plugin
[11:42] <didrocks> hoping that one day we can make 8 and API version matching :)
[11:43] <Saviq> didrocks, there's no one global API version, though...
[11:43] <Saviq> didrocks, or what is that APIversion meant to be?
[11:44] <Saviq> didrocks, I mean scopes have different API version than notifications, for examlpe
[11:44] <Saviq> as we didn't want people to have to bump if changes were unrelated
[11:44] <didrocks> Saviq: well, as long as you are backward compatible
[11:44] <didrocks> we should really use semantic versionning
[11:45] <didrocks> and "integrating with the shell" is just one version
[11:45] <didrocks> being scope or integration with the launcher or indicators
[11:45] <Saviq> didrocks, yeah, we're not backwards compatible, remember? ;P
[11:46] <didrocks> Saviq: I know… ;)
[11:46] <Saviq> didrocks, what would APIversion be, then? unity-api version number?
[11:47] <didrocks> when do you think you will ensure backward compatibility?
[11:47] <didrocks> that can maybe help shaping the versioning
[11:57] <Saviq> didrocks, backwards compatibility of Unity8 with older API versions?
[11:57] <Saviq> didrocks, not until 16.04 :P
[11:58] <Saviq> didrocks, those are not APIs public enough that it warrants backwards compat for quite some time
[12:01] <mhr3> Saviq, i knew the naming will be the primary thing of discussions :)
[12:01] <mhr3> anyway, i don't care, just tell me what to change it to
[12:02] <mhr3> didrocks, but we'll need to push the scopes plugin as a separate pkg to the distro
[12:02] <mhr3> ideally asap :)
[12:03] <mhr3> Saviq, though i guess we should bump unity8 minor/micro version
[12:04] <mhr3> and then make the scopes plugin break unity8 << that_version
[12:04] <Saviq> mhr3, yeah probably
[12:10] <didrocks> Saviq: so I would say, let's version it to 0 and handle the breakage manually
[12:11] <didrocks> everytime you break the API, you Breaks: all components << version
[12:11] <Saviq> didrocks, so, unity.0-scopes-plugin in that instance?
[12:11] <Saviq> (I wouldn't want to put the 8 in there)
[12:11] <didrocks> Saviq: unity0 then
[12:12] <didrocks> no .
[12:12] <Saviq> didrocks, Mirv how about the path where we install shell-facing plugins?
[12:12] <didrocks> Saviq: same concept to me?
[12:12] <didrocks> all unity0- something
[12:12] <didrocks> then, the patch itself
[12:12] <didrocks> path*
[12:13] <mhr3> "unity0-scopes-plugin"
[12:13] <didrocks> should be libexec I guess
[12:13] <mhr3> looks wrong :P
[12:13] <Saviq> yeah, /me no likes either :/
[12:13] <didrocks> mhr3: yeah, we need to prepend
[12:13] <didrocks> something
[12:13] <didrocks> -scopes- is the name of the extension, right?
[12:13] <mhr3> also the plugin seems pretty redundant
[12:14] <mhr3> qtdeclarative-unity0-scopes
[12:14] <didrocks> mhr3: no
[12:14] <Saviq> didrocks, we need a common /usr/lib/*/unity/qml, or similar, path where those will get installed
[12:14] <didrocks> mhr3: that sounds like it's an official qt things
[12:14] <mhr3> didrocks, we already have dozens of qml plugins like that that aren't official
[12:15] <didrocks> Saviq: yeah, sounds good to me (unversionned or unity0 until we have something)
[12:15] <didrocks> mhr3: yeah, but it's a plugin of a shell
[12:15] <didrocks> not a qt plugin for using without the shell
[12:15] <mhr3> well you wanted a prefix :)
[12:15] <didrocks> not that one :p
[12:16] <didrocks> or unityplugin0-scope ?
[12:16] <mhr3> fine with me
[12:16] <didrocks> unity-plugin0-scope? (putting the API version next to plugin)
[12:16] <Saviq> +1
[12:17] <mhr3> what if the plugin supports multiple versions of the api?
[12:17] <didrocks> mhr3: it's unrelated from a packaging perspective
[12:17] <mhr3> ok
[12:17] <didrocks> unity-plugin21-scope can provides unity-plugin20-scope
[12:17] <didrocks> mhr3: ^
[12:18] <mhr3> ok, renaming to unity-plugin0-scopes
[12:18] <didrocks> hum, in fact, we're wrong
[12:18] <didrocks> mhr3: you are not providing the plugin
[12:18] <didrocks> unity8 is
[12:18] <didrocks> so unity8 needs to provides unity-plugin0
[12:18] <didrocks> and you plugin is just unity-plugin-scopes
[12:18] <didrocks> your*
[12:18] <didrocks> you won't have plugin of your plugin, right? :)
[12:18] <mhr3> hm?
[12:19] <mhr3> ah, i see what you mean
[12:19] <didrocks> will the scopes plugin won't have backward compatibility for the scopes?
[12:19] <didrocks> so, basically, do you provide an API in it?
[12:20] <mhr3> no
[12:20] <didrocks> or is it just an extension like "show battery level"
[12:20] <didrocks> ok, so you don't need to version in
[12:20] <didrocks> you just need to dep on unity-plugin0
[12:20] <didrocks> which will be provided by unity8
[12:20] <Saviq> huhuh?
[12:21] <mhr3> this last part is huh indeed
[12:21] <Saviq> didrocks, that package will provide the binary plugin
[12:21] <didrocks> ok, I think there is an inception effect :)
[12:21] <didrocks> ah ok
[12:21] <didrocks> so yeah, versioning is needed
[12:21] <didrocks> it will provide an API to scopes?
[12:22] <Saviq> didrocks, no
[12:22] <Saviq> didrocks, it's the shell side of it
[12:22] <mhr3> it will implement interface defined in lp:unity-api, used by unity8
[12:22]  * didrocks is lost by what you with "will provide the binary plugin"
[12:22] <Saviq> didrocks, will provide the plugin unity8 will use to talk to scopes
[12:23] <Saviq> didrocks, not the APIs scopes will use
[12:23]  * didrocks is probably dumb, but not seeing the difference in those 2 statements
[12:24] <didrocks> if the plugin implements the code for unity8 to talke to scopes
[12:24] <didrocks> it's exposing/creating the API for scopes, right?
[12:24] <Saviq> no
[12:24] <Saviq> it's the shell side of that transaction
[12:24] <Saviq> the scope side of that transaction will come from lp:unity-scopes-api
[12:25] <mhr3> and it will actually dep on libunity-scopes-api... soon
[12:25] <didrocks> ah, so basically, this plugin will only decide "this is how I render/handle the signals I'm getting through unity-scopes-api"
[12:26] <Saviq> didrocks, scope → unity-scopes-api → unity-scopes-shell → unity8
[12:26] <didrocks> yeah, so that's what I told
[12:26] <Saviq> didrocks, yeah, you can think of this as a shell-facing QML wrapper of unity-scopes-api
[12:26] <didrocks> unity8 as a private API for its plugins
[12:26] <didrocks> which isn't unity-scopes-api
[12:26] <didrocks> has*
[12:27] <didrocks> so unity8 should provides a unity-plugins0 package
[12:27] <didrocks> that the unity-scopes-shell will depend on
[12:27] <Saviq> didrocks, there is nothing like that ;(
[12:27] <mhr3> not really private, it's defined in unity-api
[12:27] <Saviq> or well, in that sense
[12:28] <mhr3> or... will be :)
[12:28] <Saviq> unity-api defines the APIs unity8 consumes
[12:28] <didrocks> ok, so all will be exposed in unity-api?
[12:28] <mhr3> the problem is that there's no compile/link dependency there
[12:29] <Saviq> didrocks, unity-api just provides headers
[12:29] <Saviq> didrocks, interfaces
[12:29] <Saviq> we will probably make a .so of them soon-ish
[12:29] <didrocks> right, and that's the interface that the unity-scopes-shell will use?
[12:29] <Saviq> didrocks, will expose
[12:29] <Saviq> didrocks, unity8 will use
[12:30] <didrocks> so there is no need for yet-another-versioning? We have through unity-api what unity8 version the unity-scopes will be compatible with
[12:30] <Saviq> didrocks, yes
[12:30] <didrocks> and so unity-plugin-scopes is enough
[12:30] <Saviq> yay
[12:31] <didrocks> (and we can name all those plugins unity-plugin-*)
[12:31] <Saviq> didrocks, +1
[12:31] <mhr3> damn it, if i didn't put the 8 there i'd have it already right :P
[12:31] <didrocks> ok, nice :)
[12:31] <Saviq> lol
[12:31] <didrocks> heh mhr3 :)
[12:33] <Saviq> mhr3, rename the source, please, too
[12:34] <mhr3> Saviq, pushed
[12:34] <Saviq> mhr3, and make it Provides: unity-scopes-impl, unity-scopes-impl-0
[12:34] <mhr3> k
[12:35] <Saviq> mhr3, and then in the lp:unity8 part, Depends: unity-plugin-scopes | unity-scopes-impl, unity-scopes-impl-0
[12:36] <Saviq> mhr3, and the version bump and Breaks: you mentioned
[12:37] <mhr3> eh
[12:37] <mhr3> dpkg-source: error: source package has two conflicting values - unity-scopes-shell and unity-plugin-scopes
[12:37] <mhr3> are you sure src pkg can be different to the binary pkg name?
[12:38] <didrocks> mhr3: it means you changed in either debian/control or debian/changelog but not in both place
[12:39] <tsdgeos> Saviq: this one is a bit more complicated https://codereview.qt-project.org/#patch,all,71155,3 let's see how it goes
[12:39] <mhr3> didrocks, i have to use the src pkg name in changelog?
[12:40] <Saviq> tsdgeos, lol, so the original code was isEqual() { return false; }? :D
[12:40] <mhr3> yea.. ok
[12:40] <Saviq> mhr3, just the last entry
[12:40] <mhr3> there's just one :)
[12:40] <tsdgeos> Saviq: well, there's lots of classes that reimplement the isEqual
[12:40] <tsdgeos> it just doesn't hit them if you're comparing singletons
[12:41] <Saviq> tsdgeos, mhm
[12:41] <tsdgeos> that's why i'm not sure it's the best place to do it
[12:41] <tsdgeos> but here it works
[12:41] <tsdgeos> let them comment :D
[12:42] <didrocks> mhr3: in the top one, yeah
[12:46] <mhr3> didrocks, since both unity-plugin-scopes and unity8-private provide the same file, do i add Breaks to unity-scopes-shell, or Conflicts/Replaces needed too?
[12:47] <didrocks> mhr3: the files are getting removed from unity8-private, right?
[12:47] <didrocks> so we need to uninstall it?
[12:47] <mhr3> didrocks, yea, latest version of unity8-private won't have them
[12:48] <didrocks> mhr3: Breaks/Replaces in that case
[12:48] <didrocks> on the version << unity8-private without that file
[12:48] <mhr3> thx
[12:48] <didrocks> yw!
[12:48]  * didrocks goes for a run
[12:48] <Cimi> seb128, if I run system settings on the desktop, I don't have wifi... do you?
[12:50] <mhr3> didrocks, if you could check once you're back http://bazaar.launchpad.net/~unity-team/unity-scopes-shell/trunk/view/head:/debian/control
[12:51] <mhr3> Saviq, ^ you too
[12:52] <Saviq> Cimi, network uses different indicator backends
[12:52] <Saviq> Cimi, on desktop it's nm-applet, not indicator-network
[12:52] <seb128> Cimi, I have it just fine
[12:52] <seb128> Saviq, the package depends on indicator-network so it should be there
[12:52] <Cimi> mmm
[12:53] <Saviq> seb128, right, if you have two network indicators, yeah
[12:53] <Cimi> no wifi here on system settings
[12:53] <Cimi> trusty
[12:53] <seb128> is indicator-network running?
[12:53] <seb128> did you restart your session since you installed it?
[12:53] <Saviq> mhr3, I don't think you need -dev-tools build-dep, though
[12:53] <Cimi> no
[12:54] <seb128> so restart the session
[12:54] <Saviq> seb128, so 1980's solution! ;D
[12:54] <Saviq> Cimi, seb128 restarting unity-panel-service should be enough, no?
[12:54] <seb128> restart unity-panel-service
[12:55] <seb128> Saviq, snap :p
[12:55] <Saviq> :)
[12:55] <mhr3> Saviq, qmlplugindump
[12:55] <Saviq> mhr3, ah
[12:55] <Cimi> seb128, ok works now, but I have two
[12:55] <Saviq> Cimi, yes, expected
[12:55] <Cimi> on unity
[12:55] <Cimi> how can I remove one?
[12:55] <Cimi> blacklist in unity?
[12:55] <mhr3> Saviq, but i wouldn't be surprised if something was missing/extra, didn't try to build it on clean chroot
[12:56] <Saviq> Cimi, you'll lose functionality
[12:56] <seb128> can you stop complaining? :p
[12:56] <Saviq> mhr3, let me
[12:56] <mhr3> Saviq, thx
[12:56] <Saviq> seb128, me? :D
[12:56] <seb128> you can edit /usr/share/unity/indicators/com.canonical.indicator.network and delete the desktop profile
[12:56] <seb128> Saviq, no, Cimi
[12:56] <mhr3> Saviq, as there's no ci for it yet, you can push fixes directly to trunk ;)
[12:56] <Saviq> seb128, ah yeah, no, he can't ;)
[12:57] <seb128> Saviq, seems so ;-)
[12:57] <Cimi> Saviq, I'm half polish :)
[12:57] <Saviq> Cimi, indeed, that would explain things
[12:57] <seb128> Cimi, btw can you spend some time to fix the GTK themes before the LTS? they have some issues/stuff not looking right on new widgets
[12:58] <Cimi> seb128, saw that
[12:58] <Cimi> seb128, was actually thinking of doing an ubuntu touch theme
[12:59] <seb128> Cimi, LTS is not about doing new stuff, it's about polishing what we have and shipping a solid product...
[12:59] <seb128> Cimi, thanks for looking at those bugs/fixing the issues
[12:59] <Cimi> seb128, depends when polishing is more work
[12:59] <seb128> I doubt fixing a few bugs is that much work
[13:00] <mhr3> seb128, then you didn't do gtk theming :)
[13:00] <seb128> mhr3, don't get me started ... can we have a working dash for the LTS? ;-)
[13:01] <mhr3> seb128, we don't?
[13:01] <seb128> mhr3, for some value of "working" I guess
[13:02] <seb128> mhr3, I still get the "no result found" empty dash issue several time a week
[13:02] <mhr3> hmm, i still don't know what's causing that
[13:02] <seb128> still no idea of what info I could provide to help debugging it?
[13:03] <mhr3> seb128, steps to reproduce
[13:03] <seb128> "use the dash"
[13:03] <mhr3> works fine... not a bug :P
[13:05] <seb128> mhr3, http://ubuntuone.com/0RPwctnL0nRftR9hWFTMuS
[13:06] <seb128> mhr3, I clear the text by pressing "esc"
[13:07] <Saviq> dednick, any steps to repro bug #1243146 ?
[13:07] <Saviq> mhr3, you need qt5-default
[13:07] <seb128> mhr3, also my homescreen only lists apps, not files atm ... is that normal?
[13:07] <Saviq> mhr3, let me add
[13:08] <mhr3> seb128, do you have online sources on?
[13:08] <seb128> mhr3, yes
[13:08] <mhr3> wonder if that would make difference
[13:08] <mhr3> hm, so do i
[13:08] <dednick> Saviq: it's pretty random
[13:09] <mhr3> seb128, as for files, check if the category is enabled
[13:09] <seb128> mhr3, oh, fun
[13:09] <seb128> mhr3, only "help" is enabled in the filters, that's why my dash is empty
[13:09] <dednick> Saviq: have a message in the indicator expanded and clear them all.
[13:09] <seb128> mhr3, if I enable applications it works
[13:10] <mhr3> solved, yey! :)
[13:10] <seb128> mhr3, is the smart server trying to be too smart and telling my dash to disable apps?
[13:10] <seb128> mhr3, well, it's not happening on session start/by my doing, I didn't even know we had filter in the homescreen
[13:11] <mhr3> no, empty search filters are remembered
[13:11] <mhr3> and i think there's a bug somewhere where it saves incorrect state of those
[13:11] <mhr3> pstolowski, ^
[13:12] <Saviq> dednick, thanks
[13:21] <mhr3> pstolowski, maybe, search for "foo" (which takes a while), change filters while it's in progress and quickly press esc can make it confused?
[13:29] <pstolowski> seb128, as mhr3 said, the only way it can disable apps is when user manually de-selects apps in the filter while the search string is empty. if it happens on any other interactions, then this is a bug
[13:29] <pstolowski> seb128, if you find any way to reproduce it, then please include the output of 'gsettings get com.canonical.Unity.Lenses home-lens-default-view' in the bug report
[13:29] <seb128> pstolowski, hey, there is a bug then...
[13:30] <seb128> pstolowski, ok, the issue is that I've not been able to find obvious steps to reproduce, but I run into that several time a week
[13:30] <seb128> the dash is not empty all the time, and not on session start, so I doubt it's a buggy config
[13:30] <seb128> it happens a some point during the day
[13:31] <seb128> pstolowski, in that case the filter had "help" only selected
[13:31] <pstolowski> seb128, but when it's gone, it's gone for good, until you enable it back via filters?
[13:31] <seb128> pstolowski,  http://ubuntuone.com/0RPwctnL0nRftR9hWFTMuS is what happens from an user view
[13:32] <seb128> pstolowski, I just noticed, thanks to mhr3, that the homescreen has filters and that only "help" was selected
[13:33] <pstolowski> seb128, and you're hitting esc on that screencast?
[13:33] <seb128> pstolowski, yes
[13:34] <seb128> easiest way to clean the text entry
[13:36] <pstolowski> seb128, can you report it?
[13:36] <seb128> pstolowski, sure, is there enough info in that description to make an useful bug?
[13:37] <seb128> pstolowski, I never reported it because I don't know how I land in the buggy state and mhr3 always said he didn't have enough info/a clue how to debug
[13:37] <mhr3> i think there are two bugs actually
[13:38] <mhr3> one that makes the home scope save an odd state of the filters for empty searches (not requested by the user)
[13:38] <mhr3> and another where you're getting results you shouldn't be
[13:38] <mhr3> so for example you should have never seen app results if they're disabled
[13:39] <mhr3> yet you somehow do from time to time
[13:39] <mhr3> (with empty search string)
[13:39] <seb128> right
[13:40] <seb128> seems like doing "one" -> esc was giving me a view ignoring the filters
[13:40] <mhr3> yet i can't reproduce that here
[13:40] <Saviq> mzanetti, reject https://code.launchpad.net/~unity-team/unity8/fix-1238232/+merge/191424 ?
[13:41] <mzanetti> Saviq: imo yes
[13:41] <Saviq> mzanetti, please do
[13:41] <mzanetti> ajmitch: done
[13:42] <mzanetti> Saviq: ^
[13:42] <mzanetti> sorry ajmitch
[13:54] <Saviq> mhr3, pushed tweaks to debian/control - builds in chroot now
[13:59] <mhr3> Saviq, great, thx a lot
[13:59] <mhr3> didrocks, now we just need to push it in t :)
[13:59] <mhr3> well... once the unity branch is merged
[14:03] <Saviq> tsdgeos, yay, we got +1 on the bugs :D
[14:03] <tsdgeos> yeah
[14:03] <tsdgeos> i've been wondering were tronical was
[14:03] <tsdgeos> been trying to reach him on irc to no avail
[14:04] <tsdgeos> i randomly remember someone telling me he is/was on paternal leave
[14:04] <tsdgeos> but may be a different guy it was about
[14:05] <tsdgeos> mzanetti: what's the units.gu(5) in  lp:~mzanetti/unity8/fix-switching-previews-positioning  ?
[14:05] <mzanetti> tsdgeos: yeah. that sucks. it's the height of the section header. Is there a way to get to it?
[14:05] <tsdgeos> mzanetti: category header?
[14:05] <tsdgeos> should be possible
[14:06] <tsdgeos> let me see
[14:07] <tsdgeos> mzanetti: can't you just use sectionDelegate.height?
[14:08] <tsdgeos> ah no it's a qqmlcomonent
[14:08] <tsdgeos> damnit
[14:08] <Saviq> tsdgeos, yeah, you can't get to the delegate
[14:08] <Saviq> tsdgeos, mzanetti, only thing I can think of: use a prop on the *view
[14:09] <Saviq> dednick, we need https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 so that we support non-qt time format strings?
[14:10] <tsdgeos> mzanetti: are you trying to do with that, is it something regarding the clipping of the top section header?
[14:10] <pstolowski> seb128, sorry, I was itm. yes, I think whatever you described so far is enough for a bug report, it's important we don't forget about it and try to repro
[14:11] <mzanetti> tsdgeos: with what exactly? the header height?
[14:11] <seb128> pstolowski, ok, I'm going to file it in a bit
[14:11] <tsdgeos> mzanetti: yep, i see you have that max in there
[14:11] <mzanetti> tsdgeos: I make sure the split for the openEffect doesn't happen at the top where the content could be hidden by the header
[14:11] <tsdgeos> right
[14:11] <tsdgeos> ok
[14:12] <mzanetti> tsdgeos: let me add a comment in all places where I use the 5 grid units
[14:12] <tsdgeos> we either need a context property that chaneges all the time (to not actually change)
[14:13] <tsdgeos> or introduce the idea of "i promise i'll be well behaved" and just have one value
[14:13] <tsdgeos> or not sure :D
[14:13] <tsdgeos> but that units.gu(5) looks to fragile tbh
[14:13] <tsdgeos> too
[14:13] <mzanetti> yes. I agree
[14:16] <dednick> Saviq: yeah, i think it's the alarm indicator that gives time format in gdatetime (strftime)
[14:17] <mzanetti> tsdgeos: such a context property would be per delegate, right?
[14:17] <Saviq> dednick, any idea why it wouldn't give up a preformatted string?
[14:17] <Saviq> dednick, same as we expect translated strings and such...
[14:17] <tsdgeos> mzanetti: we can see how to expose it
[14:17] <tsdgeos> one per delegate
[14:17] <tsdgeos> or one just for the top section delegate
[14:18] <tsdgeos> but yeah one per delegate makes sense
[14:18] <dednick> Saviq: tz changes
[14:18] <dednick> possibly
[14:18] <mzanetti> tsdgeos: just like the other section.* properties probably
[14:18] <mzanetti> section.headerHeight
[14:18] <Saviq> dednick, well, wouldn't the indicator service know?
[14:19] <tsdgeos> mzanetti: we don't really have secion. properties but yes
[14:19] <tsdgeos> we have "section" and "delegateIndex"
[14:20] <tsdgeos> mzanetti: do oyu want to have a look at it?
[14:21] <mzanetti> tsdgeos: on it
[14:21] <didrocks> mhr3: what's going to dep on unity-scopes-impl-0? (priority should be optional btw and I prefer libs just after just after priority)
[14:21] <dednick> Saviq: it would then have to repoll all the calendar events from the source when a change occurs. Plus I think it's better that the view decides how to display the data. I don't even think the dackend supplying the format is right...
[14:21] <Saviq> dednick, top-approve https://code.launchpad.net/~aacid/unity8/noModelInSignal/+merge/194672 ?
[14:22] <Saviq> dednick, right, it feels weird to get the format string from the backend
[14:23] <dednick> Saviq: yeah.. i know, we will probably override it anyway at some point.
[14:24] <dednick> Saviq: Do you know when CI is going to be back?
[14:26] <Saviq> dednick, like... last Tuesday...
[14:26] <Saviq> dednick, there were issues, guys are working day/night to get everything back
[14:27] <dednick> Saviq: but there's no jenkins approve right? because services are down...
[14:27] <dednick> ?
[14:27] <Saviq> dednick, yes
[14:28] <dednick> So how does CI work with no jenkins?
[14:28] <Saviq> dednick, does it?
 Saviq: Do you know when CI is going to be back?
[14:29] <Saviq> dednick, I meant it was supposed to be back Tuesday
[14:29] <Saviq> dednick, but it's not :)
[14:29] <dednick> oh.. right :)
[14:30] <tsdgeos> guys i need someone to review/topApprove this too https://code.launchpad.net/~aacid/unity8/lvwph_bad_header_position_1240118/+merge/193200
[14:32] <tsdgeos> Saviq: standip?
[14:33] <tsdgeos> kgunn: ↑↑
[14:33] <Saviq> crap
[14:33] <Saviq> greyback, got that cron script yet? ;P
[14:33] <greyback> :)
[14:35] <dednick> tsdgeos: Just testing your branch now
[14:36] <greyback> mterry: how usable is nested mir right now? Can it be used inside xmir?
[14:37] <mterry> greyback, yeah I think so.  There are some u-s-c branches that need to land for Touch, but I don't think they'd affect desktop+xmir
[14:38] <mhr3> didrocks, unity8 deps on the impl-0
[14:38] <didrocks> mhr3: but the scope plugin deps on unity-api-impl-0
[14:38] <didrocks> which is implemented by unity8
[14:38] <didrocks> seems like a circular dep to me
[14:38] <greyback> mterry: hmm, there instructions anywhere on how to do it?
[14:39] <mhr3> didrocks, no it doesn't, it provides it
[14:39] <mterry> greyback, with xmir, I don't know.  I believe in current trusty, it'd be as simple as installing unity-system-compositor?
[14:40] <greyback> mterry: ok. Might play around with it this evening
[14:40] <mhr3> didrocks, well, it provides unity-scopes-impl, it will build-dep on unity-api-dev at some point in the future
[14:41] <didrocks> mhr3: and what will dep on the unity-scopes-impl?
[14:41] <mhr3> didrocks, unity8 does :)
[14:42] <mhr3> it's not the deps that are circular, this discussion is :P
[14:43] <didrocks> mhr3: but both are going to depend on libunity-api0, right?
[14:43] <mhr3> didrocks, probably, yes
[14:44] <mhr3> if we find some actual code to put in there
[14:44] <didrocks> I think there is something fuzzy in the way you handle the deps TBH
[14:44] <mhr3> it might end up header-only pkg
[14:44] <mhr3> didrocks, fuzzy in what way?
[14:45] <mhr3> didrocks, it's simple, unity8 deps on scopes-impl, scopes-plugin provides it
[14:45] <mhr3> that's all that matters right now
[14:45] <didrocks> mhr3: you expect to have other packages providing scopes-impl?
[14:45] <mhr3> hm
[14:46] <mhr3> i don't think so, but one binary pkg could provide different versions
[14:46] <mhr3> s/different/multiple/
[14:47] <didrocks> and you expect different unity8 which can be installed in parallel?
[14:47] <didrocks> and supporting different versions?
[14:47] <Saviq> didrocks, no
[14:47] <didrocks> so I don't think this -impl is needed
[14:47] <mhr3> well ultimately Saviq wanted it this way, he'll know why :)
[14:47] <Saviq> didrocks, if you applied that logic we wouldn't need it anywhere
[14:48] <Saviq> didrocks, until someone else did another implementation
[14:48] <didrocks> Saviq: well, maybe that was a mistake, but on the other pieces, you told me that you would see other implementations
[14:48] <didrocks> being compatible with unity8
[14:48] <didrocks> here, it doesn't seem to be the case from my question ^
[14:48] <Saviq> didrocks, sure, that's the idea - doesn't mean *we* would provide them
[14:49] <Saviq> didrocks, there could be a mock -impl
[14:49] <Saviq> didrocks, used for ap tests
[14:49] <dednick> tsdgeos: you getting that crash in test?
[14:49] <tsdgeos> yep
[14:49] <didrocks> ok, so we will have multiple implementations
[14:49] <didrocks> and so, it makes sense in that way :)
[14:49] <dednick> tsdgeos: ok. cool. thought i might be going crazy
[14:49] <didrocks> (even a mock is just an implementation)
[14:49] <Saviq> didrocks, good :)
[14:49] <tsdgeos> dednick: i'm pretty sure i wasn't
[14:49] <tsdgeos> but now i am
[14:50] <tsdgeos> so that's eough :D
[14:50] <dednick> hehe
[14:54] <dednick> Cimi:
[14:54] <dednick> Cimi: ping
[14:55] <Cimi> dednick, pong
[14:55] <dednick> Cimi: you got my bug I see. have you checked it out?
[14:55] <didrocks> mhr3: did you change on my other (small) requests?
[14:55] <Cimi> not yet back
[14:55] <dednick> back wherE?
[14:58] <dandrader> tsdgeos, wjat
[14:58] <dandrader> tsdgeos, in qt, what's dev branch as opposed to stable branch?
[14:58] <tsdgeos> 5.3
[14:58] <dandrader> hmm
[14:59] <mhr3> didrocks, oh the priority? fixing
[15:01] <mhr3> didrocks, not sure what you meant with the other thing... Build-Deps should be directly after Prio?
[15:01] <didrocks> mhr3: Prio, Section, Build-Deps
[15:02] <mhr3> didrocks, pushed
[15:02] <didrocks> mhr3: <3 thanks!
[15:04] <mhr3> sil2100, how are looking on the capnp and zmqpp front?
[15:04] <dednick> yikes. app scope is scary
[15:04] <dednick> the view i mean
[15:04] <sil2100> mhr3: capnp is in universe already, zmqpp is ready in my PPA - Ken was to make a review of it and *maybe* sponsor ;)
[15:05] <sil2100> mhr3: while zmq3 is in the archive already
[15:27] <mhr3> sil2100, awesome, do we bother you to setup ci and autolanding and stuff for the new scopes lib then?
[15:27] <sil2100> mhr3: which one it will be?
[15:28] <mhr3> sil2100, lp:unity-scopes-api
[15:28] <sil2100> mhr3: once all the infra is back, I'll take care of doing that stuff ;)
[15:29] <mhr3> sil2100, great
[15:29] <mhr3> so now i'll just bother kenvandine to sponsor zmqpp :)
[15:31] <kenvandine> hey mhr3
[15:31] <kenvandine> sil2100, oh... sorry forgot to sponsor that :)
[15:32] <mhr3> that was quick :)
[15:32] <mhr3> thx kenvandine :)
[15:33] <sil2100> kenvandine: I updated it a bit, fixing some stuff :)
[15:33] <sil2100> kenvandine: now the debian/watch file is more correct and the build-deps are better
[15:33] <sil2100> kenvandine: there is a package built out of it in ppa:sil2100/ppa if you want to check
[15:33] <sil2100> kenvandine: thanks! :)
[15:34] <sil2100> kenvandine: (I'll create lp:zmqpp/ubuntu once you give a green light)
[15:35] <mhr3> didrocks, unity8 is now seeded in default trusty images? it seems to bring lots of the phone-only stuff
[15:36] <mhr3> or well.. stuff that was meant phone-only
[15:36] <didrocks> mhr3: hum, it shouldn't, where do you see it seeded?
[15:37] <mhr3> didrocks, i'm assuming cause thomas mentioned that there's mediascanner and related stuff in T
[15:39] <didrocks> mhr3: they are in T, but universe, I think they are not seeded
[15:39] <didrocks> unity8 as well is in universe
[15:39] <didrocks> so very very very very… (very?) few chance it's in the iso
[15:39] <didrocks> or there is a big bug
[15:39] <mhr3> didrocks, hmm, i'll follow up with thomas then
[15:47] <dednick> graaa. my phone wont start after a flash :(
[15:54] <kenvandine> sil2100, mhr3: sponsored, it's in NEW now
[15:54] <sil2100> kenvandine: waaaa!
[15:54] <sil2100> kenvandine: thank you!
[15:55] <kenvandine> n[
[15:55] <kenvandine> np
[15:55] <mhr3> yey, thx kenvandine
[15:56] <mhr3> Saviq, didrocks, could we do the transition to the separate scopes plugin tomorrow or... since it won't be possible to do that automatically?
[15:58] <didrocks> mhr3: better to transition once CI is back
[15:58] <didrocks> mhr3: can you file that in the landing ask? so that we don't loose it from sight
[15:58] <mhr3> didrocks, but CI won't be able to test nor merge that
[15:58] <didrocks> why?
[15:58] <didrocks> we'll need to land your packages
[15:58] <didrocks> which is cu2d/daily release
[15:58] <mhr3> didrocks, cause it's a new pkg that replaces part of old pkg?
[15:58] <didrocks> which is down as well due to ci
[15:59] <didrocks> yeah, we need to land unity8 + scope
[15:59] <mhr3> exactly
[15:59] <mhr3> so it needs to be done manually, no?
[15:59] <didrocks> well, it will be done with cu2d
[15:59] <Cimi> dednick, what shall it do?
[15:59] <Cimi> dednick, the carousel?
[15:59] <mhr3> didrocks, hm, ok, i guess i underestimated it :)
[16:00] <didrocks> :)
[16:00] <Cimi> on click and hold
[16:00] <didrocks> mhr3: just write in the landing ask please ;)
[16:00] <didrocks> otherwise, I'll forget for sure
[16:00] <mhr3> didrocks, i don't think i have perms for that
[16:01] <didrocks> mhr3: ask thostr_ then, he's a specialist
[16:01] <mhr3> heh, k
[16:01] <mhr3> thostr_, could you? landing ask to land updated unity8 + unity-scopes-shell
[16:01] <mhr3> needs to be done in sync, cause the latter replaces part of the former
[16:02] <didrocks> unity-scopes-hell :)
[16:02] <mhr3> didrocks, you should be glad we still manage to provide you with some challenges! :)
[16:03] <didrocks> hehe!
[16:06] <Saviq> mzanetti, for you https://code.launchpad.net/~mzanetti/unity8/music-preview/+merge/193803/comments/450347
[16:07] <Saviq> mhr3, so it doesn't have to be done in sync
[16:07] <Saviq> mhr3, because until you upgrade unity8, nothing will pull the new package in
[16:08] <mzanetti> Saviq: thanks
[16:08] <mhr3> Saviq, right, that actually makes sense :)
[16:17] <dednick> Cimi: when i click on a result on the carousel, nothing happens....
[16:18] <dednick> so should probably either open a preview, or activate the result presumably
[16:46] <tsdgeos> dednick: that crash is nasty :-S
[16:46] <tsdgeos> dednick: the listview seems it's not getting deleted  when the parent goes away
[16:47] <tsdgeos> and then all kind of funky stuff happens
[16:56] <dednick_> tsdgeos: did you get the reply?
[16:57] <mhr3> according to my irc he didn't :)
[16:57] <dednick> tsdgeos: hm. sounds like  problem i've seen before. Is the listview deleted during a glib callback? eg. dee ?
[16:58] <tsdgeos> dednick: hmm
[16:58] <tsdgeos> does look like
[16:58] <tsdgeos> why?
[16:59] <dednick> anything that is deleted by calling deleteLater from an interal glib callback will not be deleted.
[17:00] <tsdgeos> hmmmm
[17:00] <tsdgeos> lil check
[17:01] <mhr3> ehm, that sound like it would introduce lots of problems
[17:01] <dednick> tsdgeos: i found it with delegates being deleted from a listview
[17:01] <dednick> mhr3: yeah...
[17:01] <mhr3> dednick, but i mean random crashing all the time, and we do not see that... fortunately
[17:02] <mhr3> cause afterall any external event is reported via a glib callback
[17:02] <mhr3> well... lots of them anyway
[17:02] <dednick> well it was in the indicators, but i fixed it. Dont know how dee-qt works
[17:02] <mhr3> dee-qt will emit q-signals from within callbacks
[17:03] <dednick> mhr3: not problem with external events. It's only if we pick up through a callback directly
[17:04] <mhr3> dednick, so how does the call stack have to look like for it to be an issue?
[17:04] <dednick> mhr3: https://bugreports.qt-project.org/browse/QTBUG-32859
[17:08] <dednick> mhr3: tbh, i'm supprised we don't see problems with dee
[17:09] <mhr3> well, dee is not using timeout nor idle sources
[17:09] <mhr3> but i still don't fully get why that is a problem
[17:09] <dednick> mhr3: using g_signal
[17:10] <dednick> mhr3: it's to do with the qt event loop
[17:10] <mhr3> yea, but i don't understand the interaction that causes the issue
[17:15] <mhr3> dednick, hm, so if glib dispatches a source directly without qt knowing about it, deleteLater() doesn't work?
[17:16] <mhr3> ...if you call it from inside that dispatch
[17:16] <mhr3> is that right?
[17:17] <seb128> mhr3, pstolowski: oh, I had open a bug about that back then: https://bugs.launchpad.net/ubuntu/+source/unity-scope-home/+bug/1223933
[17:17] <dednick> mhr3: not only a source. any async callback that goes through the gmainloop.
[17:17] <mhr3> async callback is an idle source ;)
[17:18] <mhr3> but that is... really bad
[17:19] <dednick> mhr3: a gaction callback is a idle source ?
[17:20] <mhr3> i'm not into gactions really, but they sound like dbus signals and dbus signals are delivered via idle sources
[17:20] <dednick> mhr3: ok. then yes :)
[17:21] <dednick> mhr3: and yeah, it's bad. I've looked at the dee code, and it looks like it just goes directly from glib to qt.
[17:21] <mhr3> indeed, it responds to dbus signals :)
[17:21] <mhr3> so again idle sources
[17:21] <dednick> yup
[17:22] <mhr3> maybe someone who likes compiling qt should add some debug code in deleteLater and figure out how bad are we talking about
[17:23] <mhr3> but tsdgeos ran off :P
[17:25] <dednick> mhr3: what's really bad is when it happens during an infinite animation. It never ends. So cpu stays at 100%.
[17:25] <dednick> which is what was happening in indicators
[17:25] <pstolowski> seb128, ack, thanks, will try to repro
[17:26] <mhr3> dednick, well sounds like we should come up with a real patch
[17:26] <seb128> pstolowski, thanks, same here
[17:26] <mhr3> dednick, not just workarounds like you did with indicators
[17:27] <mhr3> and upstream qt apparently doesn't care
[17:27] <dednick> mhr3: yeah, i was meaning to look into it, but never got there...
[17:28] <dednick> then forgot...
[17:28] <mhr3> dednick, wondering now what was it that you were complaining about yesterday :P
[17:28] <dednick> heh
[17:29] <mhr3> dednick, but yea, talk to tsdgeos about it tomorrow, he likes patching qt :)
[17:30] <dednick> mhr3: aiight
[17:33] <mhr3> seb128, thanks for updating it
[17:33] <seb128> mhr3, yw ;-)
[17:54] <mhr3> dednick, https://bugreports.qt-project.org/browse/QTBUG-18434?focusedCommentId=173857&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173857
[17:54] <mhr3> scary
[17:56] <dednick> mhr3: heh, nice find
[17:56] <mhr3> dednick, it's actually linked from your bug :)
[17:56] <dednick> dednick: i'm not even sure it's possible to patch. It's a pretty fundimental issue
[17:56] <dednick> talking to myself again
[17:57] <mhr3> well, their stance is - anything like this should be posted to qt event loop
[17:57] <dednick> yeah
[17:57] <mhr3> but that'd be massively expensive for things like dee
[17:58] <mhr3> so i think we should just write a downstream patch
[17:58] <dednick> which is probably their way of saying its really diffucult to fix...
[17:58] <mhr3> while trying to not break too much stuff :)
[17:58] <dednick> mhr3: no need to post, can just send.
[17:58] <mhr3> dednick, is there a difference?
[17:58] <dednick> post is async
[17:59] <mhr3> ah
[17:59] <mhr3> yea, send would work
[17:59] <mhr3> still, quite a lot of patching though
[17:59] <dednick> yeah.. it was a pain just for the unitymenumodel.
[18:00] <mhr3> indeed, that's why i'd rather go the nasty downstream patch route
[18:02] <mhr3> anyway.. eod, cyas
[18:02] <dednick> i dont think it can be fixed. the only way i could think is pushing the g_main_loop and using another context, but it doesnt work for g_idle.
[18:02] <dednick> mhr3: ^ thats for qt patch i mean
[18:03] <dednick> mhr3: using pushing the g_main_context_push_thread_default i mean.
[18:04] <mhr3> everything's hackable
[18:04] <dednick> mhr3: heh.
[18:04] <dednick> mhr3: ok, i'm off too
[18:05] <dednick> mhr3: you in office tomorrow?
[18:05] <mhr3> dednick, yea, for the afternoon ;)
[18:05] <dednick> mhr3: :) ok
[18:05] <mhr3> got meeting at 8, no way i'd get to the office so early :)
[22:39] <veebers> robru: ping
[22:48] <Saviq> veebers, hey, just a ping about https://code.launchpad.net/~veebers/unity8/ap_make_use_of_helpers_in_tests/+merge/191575 so you don't forget ;)
[22:48] <veebers> Hi Saviq
[22:48]  * veebers looks
[22:49] <veebers> Saviq: ugh, that one slipped through my fingers somehow :-\ I'll get that updated and sorted today. Thanks for that
[22:49] <Saviq> veebers, cheers
[22:49] <veebers> Saviq: also fyi, it looks like I was too slow getting another of my MRs reviewed: https://code.launchpad.net/~veebers/unity8/update_ap_tests_ready_for_py3/+merge/194655 vs https://code.launchpad.net/~robru/unity8/autopilot-py3k/+merge/195128
[22:50] <Saviq> veebers, yeah, just saw that
[22:50] <Saviq> veebers, that's 'cause it's marked WiP ;)
[22:50] <veebers> Saviq: ugh, d'oh. My bad again :-|
[23:02] <Saviq> veebers, robru, lp:~veebers/unity8/update_ap_tests_ready_for_py3 seems to work fine, lp:~robru/unity8/autopilot-py3k complains:
[23:03] <Saviq> Traceback (most recent call last):
[23:03] <Saviq>   File "/home/michal/dev/canonical/unity8/repo/tests/autopilot/unity8/shell/tests/__init__.py", line 111, in setUpClass
[23:03] <Saviq>     if "start/" in output:
[23:03] <Saviq> TypeError: Type str doesn't support the buffer API
[23:03] <Saviq> for each test
[23:03] <Saviq> so please guys fight amongst each other which one should be merged ;)
[23:03] <veebers> Saviq: :-)
[23:03] <veebers> robru: that would be due to the subprocess call needing: universal_newlines=True