[08:12] <Saviq> Mirv, hey, do you think there will be a rc2 of Qt 5.2?
[08:13] <Saviq> Mirv, also, do you have branches for all the packages in qt5-beta2 somewhere?
[08:22] <tsdgeos> Saviq:
[08:22] <tsdgeos> Hi all,
[08:22] <tsdgeos> We have new packages available for your testing & verification in http://download.qt-project.org/snapshots/qt/5.2/5.2.0/2013-12-09_204/
[08:23] <tsdgeos> subject: Qt 5.2 final candidate packages available
[08:23] <Saviq> tsdgeos, right ;)
[08:23] <tsdgeos> doesn't look like there'll be an RC2
[08:23] <Saviq> tsdgeos, "final candidate" sounds very much like rc2 ;D
[08:24] <tsdgeos> maybe
[08:24] <tsdgeos> i just think it's packages we'll flip the switch tomorrow if noone complains about
[08:24] <tsdgeos> and not a more formal RC2
[08:24] <tsdgeos> but i'm still not at 100% :D
[08:24] <Saviq> tsdgeos, ;)
[08:24] <tsdgeos> so may not be reading it correctly
[08:25] <Saviq> tsdgeos, good news, at least, is that both crashes we've encountered (unity-api and my test with JSON parsing)
[08:25] <Saviq> tsdgeos, are gone with release
[08:25] <Mirv> Saviq: no formal rc release I think (http://download.qt-project.org/development_releases/qt/5.2/). all packaging is under https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging
[08:25] <tsdgeos> Saviq: awesome
[08:26] <Mirv> Saviq: that's great news.
[08:26] <Saviq> Mirv, seen there's a "final candidate" tarballs around?
[08:26] <Mirv> Saviq: tsdgeos: I have set around 50+ recipe builds to qt5-beta2, a lot of build failures in some packages, at least something has changed regarding running tests (opengl tests are tried to be run in gsettings-qt on builders)
[08:27] <Mirv> Saviq: sure, there are tarballs, but no rc release tarballs
[08:27] <Saviq> Mirv, right, only snapshots
[08:28] <Mirv> Saviq: yeah, date coded snapshots which all are called "final candidate builds"
[08:28] <Mirv> Saviq: it seems the patched qtdeclarative is now there, so I'm clicking rebuild for unity-api
[08:28] <Saviq> Mirv, next time we need to make it so we have a recipe just following the release branch ;)
[08:28] <Saviq> Mirv, cool
[08:29] <Mirv> Saviq: the problem with automated Qt packaging is that during development the files tend to change all the time in at least qtbase/qtdeclarative, so *.install files are outdated, and same goes for symbols files (which I've now mostly temporarily removed simply until final release)
[08:30] <Saviq> Mirv, yeah, I know, just a dream there :)
[08:30] <Mirv> Saviq: I'll probably cc: you later today with my tinkerings around the opengl es on x86..
[08:30] <Saviq> Mirv, great, thanks
[08:31] <Saviq> tsdgeos, there's like 6 newer builds in here http://download.qt-project.org/snapshots/qt/5.2/5.2.0/ - does it go regardless of the lack of changes?
[08:31] <Saviq> tsdgeos, i.e. is 204 that you linked different from 209 do you think?
[08:32] <tsdgeos> hmm
[08:33] <Saviq> no commits in qtdeclarative at least since 5.12
[08:33] <tsdgeos> i guess they might change
[08:34] <tsdgeos> no idea how to find out which one though
[08:35] <tsdgeos> other than git logging
[08:39] <tsdgeos> Cimi: did i convince you in https://code.launchpad.net/~aacid/unity8/search_history_pointer_correct_pointer_position ?
[08:40] <tsdgeos> Cimi: also do you have time for https://code.launchpad.net/~aacid/unity8/dash_show_home_no_index/+merge/197714 ?
[08:40] <Saviq> Mirv, segfault :/
[08:40] <Saviq> Mirv, built fine here yesterday with that patch...
[08:43] <Mirv> so it seems :(
[08:46] <Saviq> Mirv, hum
[08:46] <Saviq> Patch correct_geometry_for_2x_pixmaps.patch does not apply (enforce with -f)
[08:46] <Saviq> Mirv, that's on freshly branched lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
[08:46] <Saviq> Mirv, how could it build, then...
[08:47] <Saviq> Mirv, <facepalm>
[08:47] <Saviq> Mirv, it's only the packaging branch :)
[09:05] <Mirv> Saviq: yes, that's still how all Qt packaging is handled also in Debian :) wget .orig.tar.xz from qt5-beta2 PPA
[09:05] <Saviq> Mirv, yeah, never did much with merge-style packaging
[09:05] <Saviq> Mirv, but managed my way around it
[09:06] <Mirv> Saviq: btw regarding qtwebkit 5.2, add_experimentalDevicePixelRatio.patch is again disabled since it didn't apply.. I guess rsalveti or someone should look at it
[09:07] <Mirv> Saviq: interesting. there was an autobuild of webbrowser-app in qt5-beta2 with the latest 5.2 fix, and it seems it also segfaults on i386 and armhf, but not on amd64 when running tests
[09:07] <Saviq> Mirv, right, sounds like unity-api then
[09:15] <Saviq> Mirv, aah, so it never segfaulted on amd64 did it?
[09:15] <Saviq> Mirv, I'm on amd64 <facepalm/> :/
[09:17] <Saviq> Mirv, anyway - you might find http://bazaar.launchpad.net/~unity-team/kubuntu-packaging/qtdeclarative-opensource-src-5.2-rc2/revision/95 useful - the patch conflicted with the 209 snapshot, so once there's a proper release, that patch should apply fine
[09:23] <Mirv> Saviq: :) yep, never segfaulted on amd64.
[09:23] <Mirv> thanks for that, I'll fetch that already so that I don't forget about it, because maybe I won't build another qtdeclarative until the final is out
[09:24] <Saviq> Mirv, cheers
[09:24] <Mirv> merged and pushed
[09:30] <Saviq> mzanetti, pushed a fix to new-scopes-integrate-card
[09:31] <Saviq> mzanetti, apparently 38/2 != 18.5, but 19!
[09:31] <mzanetti> :D
[09:31] <mzanetti> Saviq: cheers. will give it another run
[09:31] <mzanetti> ah... wait
[09:31] <mzanetti> did you see the other one?
[09:32] <Saviq> mzanetti, looking
[09:32] <Saviq> mzanetti, that you mean https://code.launchpad.net/~saviq/unity8/new-scopes-integrate-card/+merge/197930/comments/459628 ?
[09:32] <Saviq> mzanetti, that's what I just fixed
[09:32] <Saviq> mzanetti, doesn't segfault when passing...
[09:32] <mzanetti> yip. all passing here
[09:32] <mzanetti> Saviq: ok. good to go I'd say
[09:32] <Saviq> mzanetti, hit it!
[09:33] <mzanetti> Saviq: happroved
[09:33] <Saviq> mzanetti, thanks /me merges
[09:34] <nic-doffay> Saviq, got any tasks floating around?
[09:35] <Saviq> nic-doffay, yeah, review https://code.launchpad.net/~bfiller/unity8/fix-password-autocaps/+merge/198319 please?
[09:35] <nic-doffay> Saviq, cool
[09:35] <Saviq> nic-doffay, test on the phone please
[09:35] <nic-doffay> Saviq, yep
[09:36] <mhr3> there's no default implementation of qhash for strings?
[09:36] <mhr3> as in std::string
[09:37] <Saviq> mhr3, I'd imagine they want QString...
[09:38] <Saviq> tsdgeos, feelin' better btw?
[09:38] <tsdgeos> yeah
[09:38] <tsdgeos> not 100%
[09:38] <tsdgeos> but rest really helped
[09:38] <mhr3> Saviq, they do, but i dont
[09:38] <tsdgeos> mhr3: then define your qHash operator for std::string
[09:38] <Saviq> ↑
[09:38] <Saviq> that just wraps it into QString ;)
[09:38] <tsdgeos> lol
[09:38] <tsdgeos> slow++
[09:39] <mhr3> think i'll just go for std::map
[09:39] <Saviq> or that
[09:39] <mhr3> oh wait, there's unordered_map now
[09:40] <mhr3> that should have the algorithmic complexity as qhash, no?
[09:40] <mhr3> the same*
[09:40] <Saviq> mhr3, card integration landed
[09:40] <tsdgeos> mhr3: yeah
[09:41] <Saviq> mhr3, yeah sounds sane
[09:41] <mhr3> Saviq, coolio, lp:unity8? :)
[09:41] <Saviq> mhr3, weell now let's not get ahead of ourselves ;)
[09:41] <mhr3> Saviq, would be nice to get it in there ;)
[09:41] <Saviq> mhr3, there's too many FIXMEs in there still
[09:41] <Saviq> mhr3, that need to go before getting into trunk
[09:41] <tsdgeos> Saviq: want me to add the code for the case in which you change the width of a column in a vJournal with items on it and so i need to force resize on them?
[09:42] <tsdgeos> or we're not planning to do that and i can leave a TODO?
[09:42] <mhr3> Saviq, so chop, chop, fix them ;P
[09:42] <Saviq> tsdgeos, I think it'd be good, as we might scale the window without refreshing the model
[09:42] <tsdgeos> ok
[09:43] <tsdgeos> doing
[09:43] <Saviq> mhr3, s/icon/art/ anyone?
[09:43] <mhr3> Saviq, got it in a branch, but adding real tests in the same branch... so it's... "fun"
[09:43] <Saviq> mhr3, OMG REAL TESTS?
[09:44] <mhr3> RIGHT?!
[10:00] <Saviq> mhr3, btw, so if you export the FORCE_NEW_SCOPES=1, Unity 0.1 becomes the same as Unity 0.2?
[10:01] <mhr3> Saviq, pretty much, yea
[10:01] <Saviq> mhr3, so if we wanted to merge new-scopes into unity8, how could we differentiate between the two when selecting a renderererererer?
[10:02] <Saviq> mhr3, we could just go for .hasOwnProperty("template") or so
[10:02] <mhr3> Saviq, well the new scopes give you the an object for category.renderer, old ones just a string :)
[10:03] <Saviq> mhr3, yeah, which should not be "renderer" btw, but "template" :P
[10:03] <mhr3> Saviq, i thought it wouldn't like undefined
[10:03] <Saviq> mhr3, it can deal fine with undefined
[10:03] <mhr3> but sure, if a bit of code is added to handle it
[10:03] <Saviq> mhr3, or we can make it deal with it
[10:03] <Saviq> mhr3, yeah, that
[10:04] <mhr3> Saviq, but yea, the ultimate idea is to have all the code sitting in trunk but disabled by default
[10:05] <mhr3> makes dev on it easy
[10:05] <Saviq> mhr3, I'm just worried that will hold us back too much
[10:06] <Saviq> mhr3, like the above ↑ you'd name it template, but didn't want to break old stuff, so went for renderer
[10:06] <mhr3> right
[10:06] <mhr3> there are pros and cons
[10:06] <Saviq> mhr3, and then we'll build all kind of bolierplate code to make it work both ways
[10:06] <mhr3> as always :)
[10:06] <Saviq> and then after we flip the switch we'll have to rip that all out again
[10:07] <mhr3> Saviq, ultimately in unity8 pretty much all the changes will be limited to the new card renderer
[10:07] <Saviq> mhr3, that is true, but that's the thing - we could rip out half of the code there already
[10:08] <mhr3> this renderer <> template snafu doesn't sound like a big deal
[10:08] <Saviq> mhr3, sure, that's just one example
[10:08] <greyback> Mirv: hey, are the QtQuick Controls packaged in the Qt5.2 PPA?
[10:09] <mhr3> Saviq, imo the cost of keeping compability with both isn't that high
[10:09] <mhr3> at least not right now
[10:09] <mhr3> things will get more fun once we do previews and stuff
[10:10] <mhr3> for me it's the classical let's not diverge from trunk unless we have to
[10:11] <Saviq> mhr3, yeah of course - but that's what I mean is holding us back, for which I'm not sure we have time - or want it to
[10:12]  * tsdgeos finds a bug in the verticalJournal implementation
[10:12] <tsdgeos> damn unittests!
[10:13] <mhr3> Saviq, i can work eitherway really, it's a have-a-look-dear-manager feature :P
[10:14] <Mirv> greyback: no, sorry. raising on my todo list.
[10:14] <mhr3> Saviq, so if you want to do gutting of code from the branch, feel free to
[10:15] <mhr3> Saviq, i don't think that's worth it, will just complicate merging
[10:15] <greyback> Mirv: it's not critical for me, so no need to re-prioritize just for me
[10:15] <mhr3> i mean, it should be right before merging to trunk
[10:18] <Mirv> ok, only slightly notching it up then ;)
[10:23] <dednick> mhr3: ping
[10:23] <mhr3> dednick, pong
[10:25] <Saviq> mhr3, yeah
[10:26] <dednick> mhr3: howdy. just looking back into the dee thing i left off. I agree with not linking having a new base class.
[10:26] <dednick> mhr3: although i may have to change the DeeModelface if we want to do it properly
[10:27] <dednick> mhr3: so that we can get the multiplexer from the filter model backend.
[10:27] <mhr3> dednick, what do you have in mind? cause yea, i'm not sure what would be the nice way to do it
[10:28] <mhr3> dednick, also, how was capetown?
[10:28] <dednick> mhr3: nice and warm. although i was only there for 2 days. Hiked table mountain.
[10:30] <mhr3> dednick, oh? just 2 days? did the city frighten you or something? :)
[10:31] <dednick> mhr3: hehe. no, just had other places to go :) Want to spend more time there next time around though. Really good climbing on table mountain.
[10:32] <mhr3> did you do actual climbing there as well?
[10:32] <dednick> mhr3: no, just some hiking.
[10:32] <Saviq> Mirv, .install updates for qtdeclarative: http://bazaar.launchpad.net/~unity-team/kubuntu-packaging/qtdeclarative-opensource-src-5.2-rc2/revision/97
[10:34] <mhr3> dednick, will want some more tips, heading there as well in a month ;)
[10:34] <tsdgeos> Saviq: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1371/?#showFailuresLink still happening?
[10:34] <Saviq> tsdgeos, that's new actually
[10:34] <tsdgeos> is it?
[10:34] <Saviq> tsdgeos, if you look at the videos
[10:34] <Saviq> tsdgeos, unity8 never shows up
[10:34] <tsdgeos> ok
[10:34] <Saviq> tsdgeos, https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1371/artifact/results/autopilot/artifacts/
[10:34] <tsdgeos> may be that i broke something in the merge
[10:35] <Saviq> tsdgeos, I don't think so, seen that for other branches yesterday
[10:35] <dednick> mhr3: awesome. you going for sprint?
[10:35] <mhr3> dednick, yep
[10:35] <tsdgeos> Saviq: ah
[10:35] <Saviq> tsdgeos, "init: unity8 main process (11206) killed by TERM signal"
[10:35] <Saviq> tsdgeos, is what ends up in .xsession-errors
[10:35] <Saviq> tsdgeos, no idea where that comes from :/
[10:36] <tsdgeos> Saviq: so we're crashing again?
[10:36] <Saviq> tsdgeos, TERM, not crashing
[10:36] <Saviq> tsdgeos, and there's no .crash file around
[10:36] <tsdgeos> right
[10:36] <Saviq> tsdgeos, it's like it's killed before it really starts
[10:36] <tsdgeos> Cimi: so what comment would you add?
[10:36] <tsdgeos> Cimi: are you going to ask for a comment in all the lines that do something right?
[10:36] <dednick> mhr3: lucky! You must hike up a route called India Venster. book through http://www.hiketablemountain.co.za/ . They are really nice guides.
[10:37] <Saviq> greyback, ↑
[10:37] <tsdgeos> because i am a bit against literate programming tbh
[10:37] <Mirv> Saviq: thanks
[10:37] <Saviq> mhr3, you staying past the sprint?
[10:38] <mhr3> Saviq, nope, but will be there the whole weekend before it
[10:38] <Saviq> mhr3, cool, we're staying a few days past with greyback
[10:39] <mhr3> Saviq, and arriving on sunday?
[10:39] <Saviq> mhr3, yes
[10:39] <greyback> mhr3: yep
[10:39] <dednick> can I come?
[10:39] <dednick> :)
[10:39] <dednick> its cold here
[10:39] <mhr3> i'm flying there on friday, so should have most of saturday and whole sunday free
[10:40] <mhr3> a few more designers are doing that as well
[10:41] <RAOF> You guys have *another* sprint?
[10:41] <Saviq> RAOF, design one
[10:41] <Saviq> RAOF, we're just there to say NO
[10:42] <Saviq> from time to time
[10:42] <RAOF> :)
[10:42] <Saviq> and get fired
[10:42] <RAOF> All of the things we saw last week looked perfectly fine from Mir's point of view (ie: they didn't involve us doing anything different ☺).
[10:42] <RAOF> As the people implementing them you may have other ideas :P
[10:43] <Saviq> RAOF, yes, there's kgunn that will be saying NO for you guys ;)
[10:46] <mhr3> nice summary :)
[10:48] <mhr3> dednick, the link looks good, will check it out :)
[10:48] <mhr3> dednick, anyway back to dee, i was thinking about something like - http://paste.ubuntu.com/6550461/
[10:49] <mhr3> dednick, the nice thing about it, is that the usage of a FilterModel is just an impl detail
[10:50] <mhr3> and there could even be a "demultiplex-changeset" property
[10:50] <mhr3> default TRUE
[10:53] <mhr3> the not-so-nice thing is that doing things a bit more lazily would need more thought
[10:54] <mhr3> so for example the impl wouldn't keep a filtermodel unless you called _get_bin for it yet
[10:54] <mhr3> s/yet//
[10:55] <Cimi> tsdgeos, link to bugreport
[10:55] <Cimi> tsdgeos, on that line
[10:55] <tsdgeos> Cimi: why do you want a link to a bugreport that has nothing to do with the code?
[10:55] <tsdgeos> the code is not a workaround
[10:55] <tsdgeos> the code is correct code that works by itself
[10:56] <tsdgeos> sure it happens that the old code should have worked and does not
[10:56] <tsdgeos> and that is a bug
[10:56] <Cimi> tsdgeos, ah
[10:56] <tsdgeos> but the new new code is correct
[10:56] <tsdgeos> as i already mentioned in the comment i made
[10:56] <Cimi> ok so don't add comment
[10:56] <Cimi> I thought was a workaround
[10:58] <seb128> Cimi, hey, could you review/ack the change on https://code.launchpad.net/~larsu/overlay-scrollbar/hide-scrollbars-before-unmapping/+merge/197415 ?
[10:59] <Cimi> seb128, I wasn't a fan of that but I'll have a look
[10:59] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/search_history_pointer_correct_pointer_position/+merge/197423/comments/457546
[10:59] <seb128> Cimi, if you are not a fan please find another way to fix bug #1086494, those warnings are annoying
[10:59] <seb128> Cimi, thanks
[10:59] <Cimi> seb128, yeah will think about it
[10:59] <seb128> Cimi, thanks
[11:00] <Cimi> seb128, it's weird
[11:00] <Cimi> seb128, dunno why mapped children should be mapped if parent is mapped :-\
[11:01] <Saviq> mzanetti, what we talked about yesterday https://qt.gitorious.org/qt/qtdeclarative/commit/75a6f86f685f1a5ce6cb91212641fe446a37be2e
[11:01] <seb128> larsu, ^
[11:01] <Cimi> seb128, if that's the warning, you should unman not hide
[11:01] <Cimi> *unmap
[11:01] <mzanetti> Saviq: nice one :)
[11:01] <Saviq> mzanetti, we need a qmltryrunner that does that
[11:02] <seb128> Cimi, well, I'm running larsu's fix for a week and it made those warning go away without side effect
[11:02] <seb128> but maybe
[11:02] <seb128> I'm not picky on the solution
[11:02] <Cimi> seb128, hide unmaps and change visible flag as well
[11:02] <nic-doffay_> Saviq, is this still the same write issue as before? (Getting this on run_on_device -s) W: Not using locking for read only lock file /var/lib/dpkg/lock
[11:02] <seb128> I just want gedit to stop spamming stdout
[11:02] <Cimi> seb128, unmaps just unmaps but does not change visible gtk flag
[11:02] <Saviq> nic-doffay_, very possible, did you make your device writable?
[11:02] <seb128> ok
[11:02] <Cimi> seb128, better to use unmap if possible
[11:02] <seb128> let's way for larsu to comment
[11:03] <seb128> he understand those stuff better than me
[11:03] <larsu> Cimi: unmap is not enough, you'd also need to unrealize
[11:03] <nic-doffay_> Saviq, no I assumed that step wouldn't be required...
[11:03] <mzanetti> Saviq: you mean exporting the QTestRootObject?
[11:03] <nic-doffay_> What's the command?
[11:03] <larsu> Cimi: that's what the warning is about
[11:03] <Saviq> nic-doffay_, it alwaysis
[11:03] <Saviq> nic-doffay_, building unity8 on the device requires installing packages on the phone - so you need writable
[11:03] <Saviq> mzanetti, yeah
[11:04] <Saviq> mzanetti, although... that might mean the tests will actually run under qmlscene, too ;)
[11:04] <mzanetti> Saviq: hmm... but shouldn't happen in the QtTest import?
[11:05] <Saviq> mzanetti, oh well, right
[11:05] <Saviq> mzanetti, it's interesting why they'd do it in the runner and not the plugin indeed
[11:05] <Cimi> larsu, it's about map, not realize
[11:06] <mzanetti> Saviq: not sure what I'm missing... but I think this commit does it in QtTest
[11:06] <mzanetti> so I'm not sure why exactly it fails
[11:06] <mzanetti> unless we have a version where this commit is just not in yet
[11:06] <Saviq> mzanetti, we do
[11:07] <Saviq> mzanetti, right, so... more investigation to be had
[11:09]  * Saviq finds it confusing that libqt5declarative5 comes from qtquick1....
[11:09] <larsu> Cimi: I think it complains about realize when only unmapping and remapping (I vaguely remember trying that first)
[11:09] <larsu> Cimi: feel free to fix it differently, but I don't want to spend more time on it, as the solution I proposed seems to work fine
[11:09] <seb128> larsu, Cimi: bug #1086494 (the title has it)
[11:09] <larsu> and makes seb128 happy :)
[11:10] <dednick> mhr3: why are there void func pointers on the end of interfaces in dee?
[11:10] <larsu> seb128: ya, I think I tried unmapping-only first and then it complains about realize
[11:10] <dednick> mhr3: is it byte alignment?
[11:10] <Saviq> /food
[11:10] <mhr3> dednick, it's for extending the interface without having to break the abi
[11:11] <seb128> larsu, +1 on not spending more time on it, that solution works, if Cimi has a better one I guess you are fine commenting on it though?
[11:11] <dednick> mhr3: ah, so add a function and remove a void?
[11:11] <mhr3> dednick, yep
[11:11] <dednick> mhr3: smartypants
[11:11] <Cimi> seb128, larsu I just don't see the point why we should change visible gtk flag for that
[11:11] <mhr3> dednick, seen the pastebin?
[11:11] <Cimi> I guess we can play with realise and map as well
[11:12] <mhr3> dednick, that wouldn't need changes to DeeModel itself
[11:12] <Cimi> if we call unrealise, we call unmap
[11:12] <seb128> Cimi, can you propose a patch with what you describe?
[11:12] <larsu> Cimi: okay, please do that, then
[11:13] <dednick> mhr3: ah, no i hadnt seen it.
[11:13] <Cimi> seb128, can do later
[11:13] <seb128> thanks
[11:13] <mhr3> dednick, so stop ignoring me! :P
[11:14] <nic-doffay_> Saviq, yeah it's working now, that's weird though because usually I haven't had any write issues after a flash.
[11:15] <dednick> mhr3: so basically just keep a static map of backend->Demultiplexer?
[11:16] <mhr3> dednick, not exactly, this allows you to even have multiple demultiplexers on top of the same model
[11:17] <mhr3> dednick, and you'd get the individual FilterModels by calling the _get_bin() method
[11:17] <mhr3> dednick, eh yea, i'm missing self ptr in the get_bin()
[11:21] <dednick> mhr3: um, so how do we use the same demultiplexer across multiple filter models if it's not using the same one for the given backend?
[11:23] <dednick> since we're not exposing DeeDemultiplexer to unity anymore that is.
[11:23] <mhr3> dednick, since the usage of FilterModel is just an impl detail, it's up to the Demultiplexer itself to ensure that the models(bins) have proper data
[11:24] <mhr3> dednick, and eh, the idea is that the Demultiplexer itself would be a public class in the lib
[11:25] <mhr3> but it's a generalized data demultiplexer, not just a changeset-* signals demultiplexer
[11:25] <dednick> mhr3: so we're still creating the demultiplexer in unity?
[11:25] <mhr3> yes
[11:26] <mhr3> and using it to get the per-category models using its get_bin()
[11:26] <dednick> mhr3: then what is the point of changing it? who cares if it's generalised?
[11:27] <mhr3> it's just an idea
[11:27] <dednick> mhr3: "on the other it's very specific functionality which is now exposed as a base dee class" :)
[11:28] <dednick> mhr3: i thought the idea was not to expose.
[11:28] <mhr3> splitting data from one model into multiple is a valid use case
[11:28] <mhr3> and the demuliplexer seems like a correct way to do it
[11:29] <mhr3> what i didn't like about the previous approach is that it was too loose - just demultiplexing the signals, and having to manually "tag" each model that should use it
[11:30] <dednick> mhr3: i c
[11:31] <mhr3> dednick, that all being said, maybe you have a better idea with the change to DeeModel? i'm not sure what exactly you want to do there
[11:31] <dednick> mhr3: i'm still unclear as to how the FilterModel knows it has a demultiplexer if it isn't told.
[11:33] <mhr3> dednick, fwiw the usage of filtermodel is optional, it's up to the demultiplexer to split the data, it could just as well create new DeeSequenceModels and maintain the rows itself (using the bin_func)
[11:33] <mhr3> of course that would be silly and expensive :)
[11:34] <mhr3> but the point remains, the split is up to it, not necessarily the submodel
[11:35] <mhr3> and since this will be inside dee, you could just add internal methods to filtermodel
[11:54] <dednick> mhr3: i'm still confused... How would we create the demultiplexer in unity (using dee_multiplexer_new) and have the BinFunc in dee if it's internal to FilterModel.
[11:54] <dednick> mhr3: you are very confusing...
[11:55] <mhr3> dednick, would be easy with a whiteboard, how come you're not at the office?
[11:55] <mhr3> and how come i'm not at the office? :P
[11:56] <mhr3> dednick, the bin func is something the user of the demult has to provide
[11:56] <mhr3> otherwise it'd be pretty useless
[11:56] <dednick> mhr3: right. but then what are the internal methods in FilterModel?
[11:56] <dednick> mhr3: because i'm lazy
[11:57] <dednick> maybe i'll just leave this and come in tomorrow
[11:57] <mhr3> dednick, dunno really what the internal method would be, whatever is needed to make it work :)
[11:58] <mhr3> afaict it might not even be necessary to add an internal method
[11:58] <dednick> mhr3: lol. ok
[11:59] <mhr3> dednick, but agreed, let's postpone till tomorrow
[11:59] <mhr3> i'll have a deeper look at it meanwhile :)
[12:07] <nic-doffay_> Saviq, want to top approve this? The fix is working for me.
[12:07] <tsdgeos> errrrr
[12:07] <Saviq> nic-doffay_, sure, can you add a "needs-ap-test" to the bug pleaes
[12:07] <Saviq> please, even
[12:07] <tsdgeos> un errrr
[12:07] <Saviq> tsdgeos, ?
[12:07] <Saviq> tsdgeos, -
[12:13] <Saviq> dednick, added more data to https://bugreports.qt-project.org/browse/QTBUG-34351
[12:13] <Saviq> dednick, btw, there's "provide missing info" at the top, that changes the status back from NEEDINFO to REPORTED
[12:13] <Saviq> dednick, it might slip through the cracks otherwise
[12:14] <dednick> Saviq: ah. thanks
[12:15] <Saviq> dednick, btw, https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343 is correct still, is it? meaning we haven't decided on anything that would make this not needed?
[12:17] <tsdgeos> Cimi: mzanetti: we broke the delegateRange stuff when merging the dashrenderer stuff
[12:17] <Saviq> dednick, only question there - will this work fine with encoding? as in does g_date_time_format cough up UTF8 - and if so, shouldn't we go for QString::fromUtf8?
[12:17] <Cimi> delegaterange?
[12:17] <mzanetti> meh
[12:18] <tsdgeos> delegateCreationBegin
[12:18] <mzanetti> really?
[12:18] <tsdgeos> yep
[12:18] <tsdgeos> it's assigned in the wrong direction
[12:18] <tsdgeos> never gets to the filter grid
[12:18] <Saviq> :/
[12:19] <tsdgeos> i guess i'll go over all the changes from that merge
[12:19] <tsdgeos> because it's broken lots of things
[12:19] <tsdgeos> so a post review won't hurt
[12:19] <Saviq> tsdgeos, list down what test could be added please
[12:19] <dednick> Saviq: my opinion is that it's the correct way to do it. But yes, should be using fromUtf8
[12:20] <tsdgeos> Saviq: it's hard to test what test could be added
[12:20] <tsdgeos> because the test would be "make sure the item of the list gets that assigned"
[12:20] <tsdgeos> and that is happening
[12:20] <Saviq> tsdgeos, I understand
[12:20] <tsdgeos> is just that the item is not correctly passing that to its children
[12:20] <tsdgeos> which is an implementation detail
[12:20] <Saviq> tsdgeos, just when going over it again - try to see if there's anything else worth testing
[12:20] <tsdgeos> i.e. we could not have had that test before the change because the change is that introduced it
[12:20] <Saviq> tsdgeos, not necessarily that particular thing
[12:21] <tsdgeos> sure
[12:21] <Saviq> larsu, dednick, where does the time format come from, btw? locale? are the choices hardcoded in the indicator?
[12:22] <Saviq> larsu, I mean for the datetime indicator, sorry for the lack of context
[12:23] <larsu> Saviq: don't know, let me check
[12:23] <Saviq> nic-doffay_, you can add tags to bugs, just below the description
[12:24] <Saviq> nic-doffay_, this way you can then find all of them with that tag by: https://bugs.launchpad.net/bugs/+bugs?field.tag=needs-ap-test
[12:24] <larsu> Saviq: ugh, right now datetime sends a string :(
[12:24] <larsu> containing the time itself
[12:25] <Saviq> larsu, do you know about the messaging indicator then?
[12:25] <Saviq> larsu, I'm looking at https://code.launchpad.net/~nick-dedekind/unity8/StrFTimeFormatter/+merge/192343
[12:26] <larsu> Saviq: messaging indicator sends unix timestamps
[12:26] <Saviq> larsu, and the format?
[12:26] <larsu> Saviq: I don't think they send it
[12:27] <Saviq> hrmpf /me is lost
[12:27] <larsu> why?
[12:27] <Saviq> why would we need the TimeFormatter then
[12:27] <Saviq> instead of using Qt's internal formatting based on locale
[12:27] <Saviq> as well, I assume LC_TIME is what it's for
[12:28] <larsu> ya, it changes the time when the timezone changes
[12:28] <larsu> also (in the future (maybe)) when coming back from suspend
[12:28] <Saviq> larsu, sure, but that has nothing to do with the formatting
[12:28] <Saviq> larsu, as long as we take the timestamp
[12:28] <Saviq> and format it according to LC_TIME
[12:28] <Saviq> that should do
[12:29] <Saviq> dednick, thoughts ↑?
[12:29] <Saviq> if nothing gives us an explicit time format
[12:29] <dednick> larsu: datetime sends x-canonical-time & x-canonical-time-format
[12:29] <nic-doffay_> Saviq, cool
[12:29] <larsu> Saviq: you want the time string to change when the timezone changes
[12:29] <larsu> this is all that the Timeformatter thing does
[12:29] <dednick> which is unit time
[12:30] <dednick> *unix
[12:30] <larsu> dednick: ah, datetime doesn't send strings anymore? It does on my desktop...
[12:30] <Saviq> dednick, right, so I'm trying to find out where does the format string come from :)
[12:30] <dednick> larsu: i mean for appointments
[12:30] <Saviq> dednick, if it comes from locale
[12:31] <Saviq> and well - if it doesn't... shouldn't it?
[12:31] <dednick> Saviq: it's hardcoded
[12:32] <dednick> Saviq: in appointments
[12:33] <dednick> Saviq: well, appointments have this funky format where it can be daily, or single, and changes based on proximity to event.
[12:33] <Saviq> dednick, right, I'm just wondering if it's the right thing to do
[12:34] <Saviq> dednick, the proximity thing should be system-wide
[12:34] <Saviq> dednick, so SDK-ish
[12:34] <dednick> Saviq: i'm sure design would tell us if it wasnt. :)
[12:34] <dednick> it's same i desktop
[12:34] <Saviq> dednick, wherever you wanted "human readable time", you'd just use a time formatter from the SDK
[12:34] <Saviq> dednick, and tell it to do smart things
[12:35] <Saviq> dednick, doing it in the indicator seems weird
[12:35] <larsu> Saviq: ya, I could totally see this being in the sdk
[12:35] <Saviq> dednick, we should just get a timestamp from them
[12:35] <dednick> Saviq: right. so basically what this thing is, but without the format string
[12:35] <Saviq> dednick, well, more, if we said it's meant to be smart about formatting
[12:35] <Saviq> dednick, and do "yesterday" / "tomorrow" and such
[12:37] <dednick> Saviq: sure.
[12:37] <Saviq> dednick, but it really feels like the indicators should just cough up timestamps
[12:37] <Saviq> dednick, and let the UI decide what's best for each use case
[12:38] <Saviq> dednick, btw, we had something doing the smart thing for the people scope
[12:38] <Saviq> dednick, pure JS
[12:38] <dednick> Saviq: yeah, i think i did mention that before. But it's being used in desktop as well, so we cant really get right of it easily.
[12:38] <dednick> s/right/rid
[12:38] <Saviq> dednick, well, we can just ignore it :)
[12:42] <larsu> dednick: what do you mean? We should always port towards using timestamps only
[12:42] <larsu> and I think datetime is the only one left
[12:43] <dednick> Saviq: what would we do about the format gsettings? they're @ com.canonical.indicator.datetime . It applies to both time label & calendar entries.
[12:44] <Saviq> dednick, it feels weird to have it only for the indicator
[12:44] <Saviq> dednick, it should be a system-wide setting
[12:45] <larsu> Saviq: afaik, this is not possible, as different places in the ui want to refer to times differently
[12:45] <Saviq> larsu, yeah, that, why?
[12:45] <Saviq> larsu, I think other than it being "long", "short", "human-readable" etc.
[12:46] <Saviq> larsu, which can be derived from locale, AFAICT
[12:46] <larsu> Saviq: don't remember. I think it was mpt who told me at some point
[12:46] <larsu> or another designer...
[12:46] <Saviq> larsu, but nothing should explicitly chose a time format...
[12:47] <Saviq> mpt, hey, we're pondering on why would you want different time formatting in different places - other then referring to those formats by descriptive names like "long", "short", "human-readable" etc.
[12:48] <dednick> Saviq: because we dont want the time to be "Now"
[12:48] <dednick> :)
[12:48] <dednick> hey Saviq, what is the time? reply: "now"
[12:49] <Saviq> dednick, that's why I'm saying - a few different formats, but not arbitrary ones
[12:49] <Saviq> dednick, but derived from the locale
[12:49] <Saviq> mpt, is it really necessary for things to come up with arbitrary time formats? doesn't that result in inconsistency in the UI? and make it confusing when you need/want to change this - changing the time global time formatting would not affect, say, the indicator
[12:50] <Saviq> dednick, I mean TimeFormatter { timestamp: 123456; format: "short" }
[12:50] <Saviq> dednick, instead of  TimeFormatter { timestamp: 123456; format: "hh:mm" }
[12:50] <Saviq> dednick, as hh:mm is not locale-independent
[12:52] <dednick> Saviq: right, well i didnt mean abritrary. but there was no central place to get this global thing from. I agree.
[12:52] <dednick> But for the time indicator, it's using a label for the widget, which i guess is going to have to change to a timestamp.
[12:53] <Saviq> dednick, oh yes
[12:53] <Saviq> dednick, fortunately it can, just by adding a new prop - while keeping the other for desktop
[12:53] <Saviq> dednick, actually BUT
[12:53] <Saviq> dednick, the label should not be coming from the indicator at all, should it...
[12:54] <Saviq> dednick, we just need to know it's the current time
[12:54] <Saviq> dednick, so that indicator does not need to send up new stuff at all
[12:54] <dednick> Saviq: well we need it for desktop unless we port that as well.
[12:54] <Saviq> dednick, yeah, what I'm saying - we can just leave the indicator be
[12:54] <Saviq> dednick, but ignore what it's coming up with
[12:54] <Saviq> dednick, and just format the time ourselves
[12:55] <dednick> Saviq: you mean to use QTime::getCurrentTime or whatever?
[12:55] <Saviq> dednick, and not even get the current time from the indicator - as why would we
[12:55] <Saviq> dednick, yeah
[12:55] <dednick> Saviq: we use it to sync time on greeter as well.
[12:56] <dednick> but i guess that can just be QTime as well.
[12:56] <Saviq> dednick, only thing we might need from the indicator is the timezone
[12:56] <Saviq> dednick, and well, we need https://blueprints.launchpad.net/ubuntu-ui-toolkit/+spec/time-component, too
[12:56] <dednick> Saviq: we sort that out in the formatter
[12:57] <dednick> Saviq: the tz i mean
[12:57] <Saviq> dednick, the only thing the indicator gives us right now, is timely updates without the above component
[12:57] <Saviq> dednick, yeah ok
[12:57] <Saviq> aaanyway
[12:57] <Saviq> that's a bigger task
[12:59] <dednick> Saviq: should we put the formatter in toolkit then?
[12:59] <Saviq> dednick, ultimately, yes - not in the state it's in atm probably
[12:59] <Saviq> dednick, it needs to be much more complete
[12:59] <dednick> Saviq: yay. wont take months to get through
[13:00] <Saviq> dednick, so *while* we care about time formats from the indicators, we'll merge your things, but I'll be filing bugs against projects
[13:00] <Saviq> this may even be a blueprint, FWIW
[13:00] <dednick> ok
[13:01] <Saviq> dednick, so, UTF8?
[13:01] <dednick> Saviq: yeah, changing now
[13:01] <mzanetti> kgunn: Why "Opinion"? https://bugs.launchpad.net/bugs/1240939
[13:05] <mpt> Saviq, I don’t understand the premise of the question. What things are coming up with arbitrary time formats?
[13:05] <Saviq> mpt, the datetime indicator has a gsetting, for one
[13:06] <Saviq> mpt, the events coming from the messaging indicator send them up, too, depending on the time proximity of the event
[13:07] <Saviq> dednick, larsu, do you know they have those formats hardcoded for events, or are they constructed based on the locale ↑↑?
[13:08] <mpt> Saviq, is there a way to implement the settings shown in <https://wiki.ubuntu.com/TimeAndDate?action=AttachFile&do=view&target=settings-clock.png> that is better than using a gsetting?
[13:09] <dednick> Saviq: it's definately generated manually.
[13:10] <Saviq> mpt, well, datetime indicator is slightly trickier, as it's more about user preference rather than locale
[13:10] <Saviq> mpt, and yeah we can have those settings without actually trying to come up with a datetime string
[13:10] <larsu> Saviq: the messaging indicator uses relative times. The strings for time periods are translated normally
[13:11] <larsu> there's nothing in the locale that can help us there
[13:11] <larsu> datetime is a different matter
[13:11] <larsu> charles might know why we're not using locale there
[13:11] <Saviq> larsu, well, for human-readable you still want the same resolution
[13:11] <Saviq> larsu, so saying, "tomorrow" is not enough
[13:11] <larsu> maybe because we want to be able to change it dynamically?
[13:12] <Saviq> larsu, but for "tomorrow, 12:00am", you need the locale
[13:12] <larsu> Saviq: the same resolution as what?
[13:12] <Saviq> larsu, the human-readable thing usually needs to carry as much information as "a format"
[13:12] <Saviq> if you have "2013.12.11 12:00am", you can't just convert that into "tomorrow"
[13:12] <Saviq> you need "tomorrow, 12:00am"
[13:12] <Saviq> so that's where locale comes into play as well
[13:13] <larsu> the messaging menu uses relative times
[13:13] <Saviq> larsu, isn't "tomorrow" relative?
[13:13] <Saviq> what would it do with the 12:00am?
[13:13] <larsu> I mean relative as in "24 hours ago"
[13:13] <Saviq> sure, and past that, it's going to be yesterday
[13:13] <larsu> no
[13:14] <Saviq> 36 hours ago?
[13:14] <larsu> it does "days ago!
[13:14] <larsu> "days ago"
[13:14] <Saviq> well, it might be fine for messages
[13:14] <Saviq> it's not for events
[13:14] <larsu> right, and that's what my original point was: every ui component needs it a bit differently
[13:15] <larsu> so having a few gsettings might not be enough
[13:15] <Saviq> larsu, doesn't mean it needs to deal with all of it internally
[13:15] <larsu> but then, ianad
[13:15] <Saviq> larsu, we just need a flexible enough time formatter
[13:15] <larsu> which is what the MR is about, no?
[13:15] <Saviq> not if it deals with arbitrary time formats
[13:15] <Saviq> which it does
[13:16] <Saviq> coming with the events
[13:16] <dandrader> does the battery indicator icon turn to "charging" (that lightning bolt) when you plug your Nexus 10 to your pc's usb port?
[13:16] <dandrader> with me it happens only when I plug to the actual charger
[13:16] <mpt> Saviq, as I recall, ted used a datetime string so that geeks could, if they wanted to, use a datetime format that wasn’t represented by the checkboxes. I don’t really mind one way or the other, as long as the checkboxes work.
[13:17] <Saviq> dandrader, no, might be it's not getting enough umph
[13:17] <Saviq> mpt, right, sure, we can leave the gsetting option there, but I'm after a generic solution here
[13:18] <dednick> Saviq: pushed fromUtf8 change
[13:18] <mpt> Saviq, what do you mean by a generic solution?
[13:19] <dandrader> Saviq, but I suppose it still charges, albeit slowly, right?
[13:19] <Saviq> dandrader, possible both ways, really
[13:19] <Saviq> mpt, that app authors can just use a simple-as-possible API for displaying time in their apps - one that's consistent with what the user chose as their locale
[13:20] <Saviq> mpt, or their preferred time format
[13:20] <Saviq> mpt, instead of everyone and their mother inventing a time format just-right for their usage
[13:20] <Saviq> mpt, that completely disregards any locale/user-preference there might be
[13:21] <seb128> Saviq, you want to standardize stuff like "display the current month as part of the time"?
[13:21] <seb128> that feels weird
[13:21] <Saviq> seb128, no
[13:22] <seb128> gettext/the locale should already give you a 24/12 format adapted to your locale
[13:23]  * Saviq needs to write this down
[13:23] <Saviq> seb128, I'm after: user selects a locale or their preferred time formatting in the settings app
[13:23] <seb128> Saviq, yeah, you need some concrete examples I think
[13:23] <seb128> Saviq, like "display the month with the time" (what the indicator currently have)
[13:23] <Saviq> seb128, everywhere where there's time displayed, it will adhere to the user-selected preference above
[13:24] <Saviq> seb128, datetime indicator is very specialized
[13:24] <seb128> or if not what preferences do you see?
[13:24] <mpt> Saviq, as I understand it, problems with the GNU locale system include (1) not being overridable in a way that works across apps, (2) not updating instantly in every app, and (3) not standardizing either relative dates (e.g. “Yesterday”) or relative times (e.g. “2 minutes ago”). Maybe Qt/QML fixes some of those? A new API might fix the others.
[13:24] <seb128> we don't have any "time format preference" atm
[13:24] <Saviq> seb128, yeah, we just use locale - but we might let people select a different format than the locale comes up with, right?
[13:24] <mpt> Saviq, oh, and (4) requiring everyone to use the Gregorian calendar.
[13:25] <Saviq> mpt, (1) not sure why? you can override LC_TIME and assuming everything uses locale (as opposed to arbitrary format strings), all should work
[13:25] <seb128> Saviq, how different? I never felt the need to change my time format, just wondering how common/useful that is
[13:25] <Saviq> mpt, (2) yeah, that's a problem
[13:26] <Saviq> mpt, (3) that's exactly something I'd like to solve on the SDK level
[13:26] <Saviq> mpt, (4) yeah... can't help you there...
[13:26] <Saviq> seb128, people that want their phone in US English, but can't read 01/01/2013, for example
[13:26] <seb128> Saviq, looking to my android, it doesn't seem they have a time format preference
[13:27] <seb128> that seems a geeky usage (and it's date, not time)
[13:27] <Saviq> seb128, doesn't matter, really - if we just say your selected locale is your time format, that's fine, too
[13:27] <Saviq> seb128, everything I was talking about applies
[13:28] <Saviq> seb128, in the N9 I have separate "Language" and "Regional format" selection
[13:29] <Saviq> seb128, and can change 12h vs. 24h separately
[13:30] <mpt> Saviq, (1) for example if I’m CTO on a military base and I want 24-hour time everywhere, there’s no radio button I can toggle that will set it in LibreOffice and Thunderbird and XChat. If that’s *only* because there isn’t a GUI for it, rather than because the underlying setting doesn’t exist or because some of those apps would ignore it, then wonderful. :)
[13:31] <seb128> Saviq, right, so basically you want to create a "get_time()" that calls e.g strftime with the right parameter, depending of a gsettings config (e.g "show 24 hours" would use %R)
[13:32] <Saviq> seb128, yeah, something like that
[13:32] <Saviq> seb128, the app developer should never know
[13:32] <Saviq> seb128, they should just say "I want the long date-time format", "I want the short time format", "I want the human-readable date-time format", "I want the human-readable time format"
[13:33] <seb128> seems like a JDI thing then? e.g we need a bug with a list of options to support and somebody to write the code
[13:33] <seb128> or was there something to discuss?
[13:33] <Saviq> seb128, JDI?
[13:33] <Saviq> ah Just Do It
[13:33] <Saviq> YOLO
[13:33] <seb128> just do it
[13:33] <seb128> ;-)
[13:34] <seb128> well, you just listed 4 cases
[13:34] <Saviq> seb128, yeah, this grew from "indicators should not give up time formats" to a more generic "GNU locale is bad" conversation ;)
[13:34] <Saviq> seb128, sure, there's more
[13:34] <Saviq> seb128, much more
[13:34] <seb128> soon you are back to having strftime and % options :p
[13:34] <mpt> Saviq, (3) I would be keen to review or contribute to that API design. It’s bothered me for about seven years.
[13:34] <Saviq> mpt, will
[13:34] <mpt> I could help collect use cases, for example.
[13:34] <Saviq> mpt, that would be fantastic
[13:35] <Saviq> mpt, let me file a blueprint
[13:35] <mpt> ok
[13:44] <Saviq> mpt, https://blueprints.launchpad.net/ubuntu-ui-toolkit/+spec/time-formatter
[13:47] <nic-doffay_> dandrader, any idea when this is ready  to land? https://code.launchpad.net/~dandrader/unity8/runningAppsEndClose/+merge/196257
[13:47] <nic-doffay_> dandrader, nm
[13:47] <nic-doffay_> merged already.
[13:48] <dandrader> nic-doffay_, not only merged, but also released as well :)
[13:49] <nic-doffay_> dandrader, haha yeah I shot off those questions while reading the diff :P
[13:50] <nic-doffay_> dandrader, can I use it to fix this: https://bugs.launchpad.net/unity8/+bug/1213034
[13:50] <dandrader> nic-doffay_, to remove focus from the text input field?
[13:50] <mzanetti> Saviq: what do I need to do in order to make an application show up? Context: I dropped Stage.qml and trying to reimplement it
[13:51] <Saviq> mzanetti, "show up"? you need to focus it
[13:51] <mzanetti> Saviq: so it is started, I get ApplicationManager.focusedApplicationIdChanged(). but I don't see it on the screen
[13:51] <Saviq> mzanetti, you also need to hide the dash I think
[13:51] <mzanetti> mhm... /me tries
[13:52] <Saviq> mzanetti, IIRC the shell is always on top of apps (only way we can get the launcher on top of apps)
[13:52] <dandrader> nic-doffay_, using the PressedOutsideNotifier seems a bit of an overkill for that. I think what we need is to make the dash background or something take/accept input focus when touched
[13:52] <nic-doffay_> Saviq, ^
[13:52] <mzanetti> Saviq: right... I thought something like this. just didn't find the place in the old Stage where that happens. will search more
[13:52] <Saviq> dandrader, well, it's not just about the dash
[13:53] <Saviq> dandrader, but say you pull the launcher in, pull the panel in
[13:53] <Saviq> dandrader, and that's exactly what we need - see, here's an area where I'm at (and my popover)
[13:53] <Saviq> dandrader, if you touch anything else, I want to unfocus
[13:54] <dandrader> Saviq, hmm, right. so you want to lose focus regardless, even if noone else is interested in it
[13:54] <Saviq> dandrader, yes
[13:55] <dandrader> Saviq, nic-doffay_  therefore having it working differently than a traditional text entry field when using a mouse
[13:55] <dandrader> where is loses focus only once another focusable widget is clicked
[13:55] <Saviq> dandrader, yeah, because we want to hide the OSK
[13:55] <Saviq> dandrader, so it's more about that than the mouse
[13:56] <Saviq> dandrader, as soon as you've stopped typing - you don't want the OSK
[13:56] <Saviq> dandrader, and to bring it back - you want an action from the user on the field they want to type in
[13:57] <dandrader> Saviq, is this behavior specific for this search text entry or is it for any text entry in general?
[13:57] <Saviq> dandrader, probably not specific for us, no
[13:57] <Saviq> dandrader, not even for the "we have a drop-down" case, since that component should be available in the SDK, too
[13:58] <dandrader> Saviq, I'm asking because there's (or might be) this case where you want to vertically scroll your ui without unfocusing the text entry.
[13:59] <Saviq> dandrader, not sure - could be a prop on the text entry, FWIW
[13:59] <Saviq> dandrader, the OSK is something you usually want to get rid of
[13:59] <Saviq> dandrader, when looking at other things
[14:00] <Saviq> dandrader, just 'cause it takes a lot of screen real estate
[14:00] <Saviq> dandrader, what usecase do you have in mind?
[14:01] <tsdgeos> Cimi: i remerged https://code.launchpad.net/~aacid/unity8/dash_show_home_no_index/+merge/197714
[14:02] <dandrader> Saviq, just recalling how it worked witht the N9 when on a web page, for instance. you're typing on a text entry but could peek up or down the page for some information relevant to what you're typing. then the next char you type make the page scroll back to have the focused text entry on screen again
[14:02] <Cimi> ok
[14:03] <Saviq> dandrader, right, but OTOH it hides when typing in the address bar - as soon as you touch the history
[14:04] <dandrader> Saviq, so, in that case, hiding the vkb (i.e. unfocusing the text entry) is not right or wrong, I think. But it's a design decision that should be consistent throughout the system
[14:04] <dandrader> "that case" meaning my example use case
[14:05] <Saviq> dandrader, right, care to file a bug against ubuntu-ui-toolkit and ubuntu-ux?
[14:06] <dandrader> Saviq, to ask about the "when to unfocus" behavior?
[14:06] <Saviq> dandrader, it probably is basically about "what area do I consider being «in focus» for my text field"
[14:06] <Saviq> dandrader, yeah, for the dash it's definitely search entry + search history
[14:07] <Saviq> dandrader, but for a website it might be the whole website
[14:07] <Saviq> dandrader, it might be indeed a case by case thing
[14:09] <dandrader> Saviq, will file the bug
[14:10] <Saviq> dandrader, thanks, please provide a few use cases as you can think of, that justify one or the other behavior
[14:10] <Saviq> dednick, you need to merge trunk into the formatter
[14:11] <Saviq> Cimi, when you see a failure like https://code.launchpad.net/~aacid/unity8/dash_show_home_no_index/+merge/197714/comments/459831
[14:11] <Saviq> Cimi, don't auto-re-approve - it's usually an issue - either a conflict or whitespace
[14:12] <Cimi> Saviq, I approved again because albert merged trunk
[14:12] <Saviq> Cimi, oh
[14:12] <Saviq> Cimi, it wasn't there in the list of comments
[14:12] <Saviq> Cimi, interesting
[14:13] <Saviq> Cimi, sorry, reapproved
[14:13] <Cimi> Saviq, your automatic launchpad bot is failing :P
[14:13] <Saviq> Cimi, yeah, that's 'cause lp is failing - there should be a comment listing the new revision :P
[14:19] <dednick> Saviq: thanks. will check now
[14:20] <Saviq> mzanetti, you said something about haptic feedback / vibration? did you read about it coming, somewhere?
[14:21] <mzanetti> Saviq: my galaxy nexus vibrates on every touch since the last flash
[14:21] <mzanetti> trusty-proposed that is
[14:21] <Saviq> hm interesting
[14:22] <Saviq> mzanetti, wonder if it's something low-level that got enabled
[14:23] <nic-doffay_> Saviq, so I'm assuming I should hold off on that then?
[14:23] <mzanetti> Saviq: I thought so... weird thing is, it doesn't do any more. but no clue what I did
[14:23] <nic-doffay_> re the keyboard dismissal...
[14:23] <Saviq> nic-doffay_, no, please implement locally
[14:23] <Saviq> nic-doffay_, if/when we get it from the SDK, we'll just use it
[14:23] <Saviq> nic-doffay_, but let's have it in the mean time
[14:23] <Saviq> mzanetti, lol
[14:24] <nic-doffay_> Saviq, cool
[14:24] <mzanetti> Saviq: well, I'm sure it did on friday when I last flashed
[14:24]  * mzanetti flashes again
[14:31] <Saviq> mzanetti, tsdgeos, /me and greyback|lunch have a meeting over standup
[14:31] <mzanetti> greyback|lunch: o/
[14:31] <Saviq> mzanetti, tsdgeos, and nic-doffay_ can't speak, so he put his stuff in the doc
[14:32] <Saviq> tvoss, mtg?
[14:32] <mzanetti> greyback: what's the difference between ApplicationManager's focusedApplicationIdChanged() and focusRequested() signals?
[14:32] <tsdgeos> Saviq: standup?
[14:32] <tvoss> Saviq, https://plus.google.com/hangouts/_/canonical.com/application
[14:32] <greyback> mzanetti: focusRequested is when for some reason Mir changes the focused application in a way that shell wasn't responsible - e.g. an application started not by shell
[14:33] <greyback> mzanetti: that signal is listened to by shell so that shell can decide if that new focus decision is correct or might need over-riding
[14:33] <mzanetti> greyback: it's missing in unity-api
[14:34] <greyback> mzanetti: it doesn't belong there really. It's a hack. It should go away once Mir looses the concept of focus
[14:34] <mzanetti> greyback: huh? you mean the shell is responsable for it
[14:34] <Saviq> greyback, https://plus.google.com/hangouts/_/canonical.com/application
[14:35] <mzanetti> anyways. ok. it means I have to keep it for now I guess... thanks
[14:40] <dednick> Cimi: you in office tomorrow?
[14:41] <Cimi> afternoon
[14:42] <tsdgeos> sorry internet broke
[14:42] <tsdgeos> standup finished i guess?
[14:42] <mzanetti> tsdgeos: no prob
[14:43]  * mzanetti goes to pick up his car from the service... bbiab
[15:06] <tsdgeos> collapsing still broken ^_^
[15:06]  * tsdgeos hides
[15:12] <kgunn> mterry: yo
[15:12] <mterry> kgunn, hello!
[15:12] <kgunn> mterry: got time in about 15 min to chat with me and greyback ?
[15:12] <mterry> k
[15:12] <kgunn> greyback: ?
[15:14] <kgunn> dednick_: meant to say ....welcome back
[15:14] <dednick_> kgunn: thanks!
[15:16] <dandrader> Saviq, nic-doffay_ https://bugs.launchpad.net/ubuntu-ux/+bug/1259596
[15:17] <Saviq> dandrader, cheers
[15:19] <dandrader> Saviq, nic-doffay_ regardless of the decision, I'm thinking that it would be best if the unfocus action is taken not by the text entry itself but by the entity that has given focus to it in the first place (the input handling logic?). Otherwise we might get some race conditions: E.g. user taps outside focused entry onto yet another focusable item.
[15:21] <dandrader> not sure if this centralized approach is actually doable, though
[15:22] <dandrader> as we might end up having to change code in QQuickWindow ....
[15:26] <Saviq> dandrader, I don't even think if it's that complicated
[15:27] <Saviq> dandrader, all the use cases I can come up with, it's actually the text area itself that knows whether it makes sense for it to be focused when you tap outside of it (or outside of an area)
[15:34] <greyback> kgunn: am there
[15:39] <dandrader> Saviq, right, because the item itself sets its focus property to true (in hope of getting activeFocus) when pressed. Thus it would just set it back to false upon "pressed outside", letting the activeFocus go to someone else
[15:42] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/more_filter_fixes/+merge/198427
[15:42] <dandrader> Saviq, but I believe that approach (focused item unfocusing itself) won't work if we are to implement the "do not unfocus if it's a content scroll" case
[15:42] <dandrader> but, anyway, let's wait to see what's the desired behavior
[15:52] <dednick_> Saviq: getting a "Could not determine plugin installation dir" error building trunk
[15:54] <tsdgeos> dednick_: dist-upgrade ?
[15:54] <tsdgeos> you need the new scopes-shell thingie
[15:54] <tsdgeos> dednick_: you're on trusty?
[15:55] <dednick_> tsdgeos: no,
[15:55] <dednick_> hm. maybe i should upgrade..
[15:55] <tsdgeos> dednick_: i'm not sure we support non trusty nowadays
[15:55] <tsdgeos> mhr3: is the unity-scopes-shell released for non trusty?
[16:00] <mhr3> tsdgeos, nope, only trusty
[16:00] <mhr3> tsdgeos, it's buildable on saucy, but you'd need to build all the dependencies as well
[16:00] <tsdgeos> dandrader: there you go, you need some trusty-ness
[16:00] <tsdgeos> err
[16:00] <tsdgeos> dandrader: that was for dednick but he left and tab-completion decided to autocomplete to you, sorry :D
[16:01] <dandrader> tsdgeos, np
[16:01] <Saviq> dednick_, ./build -c
[16:02] <dandrader> anyone has success shutting down Nexus 10 for good?
[16:03] <dandrader> for me it just reboots when I try to shut it down
[16:03] <Saviq> dandrader, hold power until it dies - should turn it of
[16:03] <Saviq> dandrader, otherwise, hold all three
[16:03] <Saviq> dandrader, and choose POWER OFF
[16:04] <dandrader> Saviq, ok, thanks
[16:13] <dednick> ahhh. how do I update to 14.04?! my update manager not picking it up
[16:14] <tsdgeos> anyone knows what's broken with otto? https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1382/console
[16:16] <dednick> tsdgeos: how do you upgrade to 14.04?
[16:16] <tsdgeos> dednick: i did it the manual way
[16:16] <tsdgeos> replace saucy  for trusty in /etc/aot
[16:16] <tsdgeos> apt
[16:16] <dednick> tsdgeos: ah...
[16:17] <dednick> i can see that ending in tears..
[16:22] <tsdgeos> it was pretty easy back when i did it
[16:22] <tsdgeos> but it was just at the start of the cycle
[16:22] <tsdgeos> so there were very few changes at that time
[16:22] <cwayne> sudo do-release-upgrade -d
[16:22] <cwayne> but disable extras first, i kept 404'ing on extras for trusty
[16:24] <dednick> cwayne: thanks!
[16:25] <cwayne> dednick: np :)
[16:36] <Saviq> dednick, do-release-upgrade -d
[16:36] <mhall119> Saviq: FYI, Kaleo has the work item to detect keyboard & mouse: https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-apps-convergence
[16:36] <Saviq> ↑↑ that
[16:36] <Saviq> mhall119, yup
[16:36] <mhall119> I assume everything in the SDK is available to Unity 8
[16:37] <Saviq> mhall119, yeah of course
[16:37] <Saviq> mhall119, we're pushing stuff up from unity8 into the SDK where it makes sense
[16:37] <mhall119> cool, I'll try and find out when that will be implemented then
[16:38] <tsdgeos> guys, i'm going to take a bit early EOD, not feeling too well atm
[16:38] <tsdgeos> see you tomorrow
[16:41] <Saviq> mzanetti, traceback from crashing unity-api test: http://paste.ubuntu.com/6551990/
[16:44] <mzanetti> Saviq: that's a good one :)
[16:45] <Saviq> mzanetti, yeah, but 95 steps...
[16:45] <Saviq> we don't get as much in unity8 alone ;)
[16:46] <Saviq> well, with 5.2 we probably do, then ;)
[16:48] <mhr3> mzanetti, you wanted more tests - https://code.launchpad.net/~mhr3/unity-scopes-shell/scopes-ng-tests/+merge/198437
[16:49] <mhr3> Saviq, ^ has your role changes too
[16:49] <Saviq> mhr3, cool
[16:54] <mhall119> Saviq: trying to load CMakeLists.txt in Ubuntu SDK, I get the following error when trying to configure cmake:
[16:54] <mhall119> CMake Error at CMakeLists.txt:64 (message): Could not determine plugin installation dir.
[16:54] <mhall119> do I need to add some Arguements to get it working?
[16:54] <mhr3> Saviq, oh and i was supposed to ask which renderer is likely to come next
[16:55] <mhr3> Saviq, as supported in the category templates
[17:02] <Saviq> mhr3, by renderer you mean grid/carousel etc.?
[17:02] <mhr3> Saviq, yep
[17:03] <Saviq> mhr3, carousel, probably, then v. journal
[17:04] <mhr3> thx
[17:10] <Saviq> mzanetti, here's another one - seems to be racy
[17:10] <Saviq> http://paste.ubuntu.com/6552106/
[17:10] <mzanetti> Saviq: same test?
[17:10] <Saviq> mzanetti, yes, stripped down
[17:11] <Saviq> mzanetti, http://paste.ubuntu.com/6552115/
[17:12] <mzanetti> Saviq: hmm... it's at the end of the test when cleaning up?
[17:12] <Saviq> mzanetti, yeah
[17:14] <nic-doffay_> Saviq, currently the inverse mouse area in the PageHeader dismisses the search box and activates whatever was pressed. Is this desired behaviour?
[17:15] <Saviq> nic-doffay_, not sure, ideally it should block the tap, but allow for swiping... which is trickier somewhat
[17:17] <nic-doffay_> Saviq, yeah I def think it should block the tap.
[17:17] <Saviq> nic-doffay_, +1
[17:18] <nic-doffay_> Saviq, there's still the issue of the swipe though and differentiating the touch inputs...
[17:18]  * greyback to the airport
[17:18] <Saviq> greyback, fly safe
[17:20] <nic-doffay_> gl greyback
[17:22] <mhall119> Saviq: any idea what I'm doing wrong in QtCreator?
[17:22] <Saviq> mhall119, not if you don't tell me what's happening :)
[17:23] <mhall119> CMake Error at CMakeLists.txt:64 (message): Could not determine plugin installation dir.
[17:23] <mhall119> pasted 30 minutes ago :-P
[17:23] <mhall119> when opening CMakeLists.txt and at the dialog to configure cmake
[17:24] <mhall119> Saviq: http://ubuntuone.com/54blhOH0aIf6WnBtt3PPBr
[17:27] <Saviq> mhall119, you don't have the build deps installed :)
[17:27] <Saviq> mhall119, ./build-s
[17:27] <Saviq> erm
[17:27] <Saviq> ./build -s
[17:27] <mhall119> build -s gives:
[17:27] <mhall119> Note, selecting 'qtdeclarative5-unity-notifications-plugin' instead of 'unity-notifications-impl'
[17:27] <mhall119> E: Unable to locate package unity-plugin-scopes
[17:27] <nic-doffay_> dandrader, any thoughts on using your component to differentiate between touches and swipes?
[17:27] <Saviq> mhall119, you not on trusty are you?
[17:27] <mhall119> no, on saucy still
[17:27] <Saviq> mhall119, we only support trusty atm...
[17:27] <Saviq> mhall119, we could do a ppa with the other bits
[17:27] <Saviq> that are unavailable on saucy
[17:28] <mhall119> if we can do a PPA, that would be best
[17:28] <mhall119> docs currently say only saucy is supported
[17:28] <Saviq> mhall119, right, outdated... sorry
[17:29] <mhall119> I'll fix the docs, how long would it take to get a PPA to let it work with saucy?
[17:29] <Saviq> mzanetti, whatever I do in the test, it has a different crash :/
[17:29] <Saviq> mhall119, it's probably just the above package alone
[17:29] <Saviq> mhall119, and it should Just Build™
[17:29] <mzanetti> Saviq: :/ it might help to start locking the dtor of the singleton.
[17:30] <Saviq> mzanetti, hmm interesting, Qt should manage the dtion of singletons
[17:31] <mzanetti> Saviq: yeah. well... seems something is accessing it while/after dtion, or maybe it's deleted twice, C++ and QML context
[17:32] <dandrader> nic-doffay_, you mean PressedOutsideNotifier? I don't think it's a good idea.  This thing of differentiating between touches and swipes sounds like the kind of problem that gesture cancellation solves. like what the Flickable does when it detects a swipe and therefore sends a TouchCancel to the item inside it that received the press
[17:33] <dandrader> and grabs the touch from the child item that got the press event
[17:35] <dandrader> nic-doffay_,  but I would need to dive into the problem to come up with a more solid opinion
[17:35] <mhall119> Saviq: where can I find that one package?
[17:35] <Saviq> mhall119, lp:unity-scopes-shell
[17:36] <nic-doffay_> dandrader, that's what I figured too just judging by the name of your class.
[17:36] <nic-doffay_> Saviq, your thoughts?
[17:36] <mhall119> Saviq: no binary I can install?
[17:37] <Saviq> mhall119, it's there in trusty
[17:37] <Saviq> http://launchpad.net/ubuntu/+source/unity-scopes-shell
[17:37] <Saviq> mhall119, nothing for saucy atm
[17:38] <mhall119> I'll try installing that one
[17:38] <mhall119> with any luck, I won't completely break everything
[17:42] <mhall119> Saviq: ok, build --setup is happy now, but I still can't get cmake working within QtCreator
[17:42] <mhall119> same error
[17:42] <Saviq> mhall119, that's probably because qtcreator tries to pick up the wrong cmakecache
[17:43] <Saviq> mhall119, make sure you point it at the right build dir
[17:43] <Saviq> i.e. unity8/builddir
[17:43] <mhall119> ./builddir/ right?
[17:43] <mhall119> yeah, tried that, same error still
[17:43] <Saviq> mhall119, if you go there
[17:43] <Saviq> mhall119, in that dir
[17:43] <Saviq> and go cmake ..
[17:43] <Saviq> mhall119, does that work?
[17:44] <mhall119> FWIW, ./build gives the same error in the terminal
[17:44] <mhall119> mhall@mhall-thinkpad:~/projects/Ubuntu/unity8/builddir$ cmake ..
[17:44] <mhall119> -- Could NOT find Lcov (missing:  LCOV_EXECUTABLE GENHTML_EXECUTABLE)
[17:44] <mhall119> -- Could NOT find gcovr (missing:  GCOVR_EXECUTABLE)
[17:44] <mhall119> CMake Error at CMakeLists.txt:64 (message): Could not determine plugin installation dir.
[17:44] <mhall119> -- Configuring incomplete, errors occurred!
[17:44] <Saviq> mhall119, right, it's ./build that installs the deps
[17:44] <Saviq> mhall119, try ./build -c, it might've cached something
[17:44] <mhall119> The following packages will be REMOVED: unity8-build-deps
[17:45] <mhall119> is that okay?
[17:45] <Saviq> mhall119, yeah, that means you can't install some of the build deps
[17:45] <Saviq> mhall119, try interrupting that
[17:45] <Saviq> mhall119, and apt-get -f install to get more info
[17:46] <mhall119> -f install dosn't give me anything more, just that it's going to try and remove it
[17:46] <Saviq> mhall119, ah, new libunity-api-dev, too
[17:46] <Saviq> mhall119, https://launchpad.net/ubuntu/+source/unity-api
[17:47] <Saviq> mhall119, let me go through that tomorrow on a clean system, will put stuff into a ppa
[17:48] <mhall119> ok, let me know when you're done and I'll test it out again
[17:48] <mhall119> thanks Saviq
[17:52] <mhall119> Saviq: for now I've updated the docs to say it's 14.04 only, I'll update them again with instructions for 13.10 that uses the PPA
[17:52] <Saviq> mhall119, can you please put a unity8 branch that updates the same in CODING for ~unity-team?
[17:52] <Saviq> mhall119, so that we don't diverge
[17:53] <mhall119> Saviq: sure thing, give me a couple minutes
[17:54] <Saviq> mhall119, I'll put my changes / updates there as well
[17:56] <mhall119> Saviq: https://code.launchpad.net/~mhall119/unity8/update-CODING-to-1404/+merge/198443
[18:01] <Saviq> mhall119, cheers