[04:47] <Akiva-Mobile> is there a terminal lens programmed yet?
[04:47] <Akiva-Mobile> or scope*
[04:47] <Akiva-Mobile> and if its not, (i'll think of programming one), is unity in a state right now that it won't be rewritten as soon as I am done developing it?
[06:02] <xnox> Akiva-Mobile: what do you mean by terminal lens? one can execute commands with alt-f2 on the desktop (unity 7) and new style scopes have like manpages references etc (unity 8)
[06:02] <Akiva-Mobile> xnox: namely to be able to observe the results
[06:03] <xnox> Akiva-Mobile: there are terminals to observe results =)))) (both on touch UI and desktop UI) not sure how security wise that will work, given that it's essentially arbitrary code-execution.
[06:04] <Akiva-Mobile> xnox: well, I'd rather have a terminal built into the dash
[06:04] <Akiva-Mobile> xnox: Which mind you, is very hard to program
[06:05] <xnox> Akiva-Mobile: the way I use dash / terminals, i prefer improvements into the terminal apps over "terminal scope". And i treat dash more of a single query/output, instead of persistent "backscroll" + multiple commands/outputs.
[06:06] <Akiva-Mobile> xnox: okay. I want a dash with an embedded terminal.
[06:06] <Akiva-Mobile> its sort of like a plugin layer
[06:06] <Akiva-Mobile> but more native.
[06:06] <xnox> Akiva-Mobile: i'd discuss it on the mailing lists first. Cause indeed it sounds non-trivial to implement and it's not clear how-to implement it best.
[06:06] <Akiva-Mobile> xnox: oh yah; I found out hard it is to do this sort of thing by trying to program a syntax highlighter
[06:07] <xnox> Akiva-Mobile: yeah, like e.g. Super+A starts apps lence, one could have Super+T to get a terminal lences. But lences don't have free-form UI to code which is needed for something like a terminal.
[06:07] <Akiva-Mobile> xnox: although I found a cute work around to do it by exploiting a record terminal command, and then doing an active sync with the text file it outputted.
[06:08] <Akiva-Mobile> xnox: I heard that, although I am not sure what it means
[06:09] <Akiva-Mobile> xnox: is it programmed in QT yet? I wonder if you could just somehow toss a qtextbrowser in there :P
[06:09] <xnox> Akiva-Mobile: no idea, i don't hack unity/dash/lenses =)
[06:10] <Akiva-Mobile> xnox: heh
[06:10] <Akiva-Mobile> xnox: I really like unity
[06:10] <Akiva-Mobile> I think a terminal lens, especially if you could do it if you could embed tty1 in there or something
[06:11] <Akiva-Mobile> would be freaking godly
[06:22] <tvoss_> good morning :)
[06:29] <Akiva-Mobile> tvoss_: morning~
[06:36] <tvoss_> Akiva-Mobile, hey there and a happy new year
[06:36] <Akiva-Mobile> tvoss_: ITS ROSH HASHANA ALREADY?!
[06:37] <tvoss_> Akiva-Mobile, was just about to add: if you happen to have celebrated the new year :)
[06:37] <Akiva-Mobile> tvoss_: you lie
[06:37] <Akiva-Mobile> >:/
[06:38] <tvoss_> nope
[08:00] <tsdgeos> hi ho folks
[08:06] <Saviq> moornin'
[08:17] <tvoss_> Saviq, morning :)
[08:18] <Saviq> tvoss_, o/
[08:18] <tvoss_> Saviq, happy arbitrary date change
[08:18] <Saviq> :)
[08:38] <tsdgeos> Saviq: answered in https://code.launchpad.net/~aacid/unity8/more_logs/+merge/198933
[08:39] <Saviq> tsdgeos, ok that's fine, thought you lost hope :)
[08:39] <tsdgeos> nah
[09:20] <jalcine> /b 13
[09:31] <mhr3> mzanetti, ping?
[09:32] <mhr3> mzanetti, anything still missing @ https://code.launchpad.net/~mhr3/unity-scopes-shell/json-overrides/+merge/199508 ?
[09:34] <tsdgeos> larsu: you aware of the gsettings-qt tests not passing in qt5.2?
[09:47] <larsu> tsdgeos: nope, thanks for letting me know (and happy new year)
[09:48] <tsdgeos> larsu: happy new year
[09:48] <tsdgeos> larsu: it's getting an assert inside qtdeclarative :-/
[09:49] <larsu> tsdgeos: the the issue that mardy fixed get merged?
[09:49] <larsu> maybe that's still the one
[09:49] <larsu> but that wasn't an assert...
[09:49] <tsdgeos> larsu: not sure, when i tried with qt5.2 from 2 weeks ago i had a different error
[09:49] <tsdgeos> larsu: the error i had as the one with bindings not working
[09:49] <tsdgeos> then i pulled and the binding thing worked but now i get an assert
[09:51] <larsu> tsdgeos: ya, that other one is marked as resolved: https://bugreports.qt-project.org/browse/QTBUG-35233
[09:51] <larsu> sigh
[09:54] <tsdgeos> think i can create a simple test case
[09:54] <tsdgeos> let me see
[10:21] <tsdgeos_> larsu: https://bugreports.qt-project.org/browse/QTBUG-35906
[10:22] <larsu> tsdgeos_: thanks a lot!
[10:22] <tsdgeos_> no worries
[10:22] <tsdgeos_> that's a pretty bad bug tbh
[10:23] <larsu> is it?
[10:23]  * larsu is not very familiar with qt's internals
[11:01] <dandrader> tsdgeos_, will start reviewing your lp:~aacid/unity8/horizontalJournal branch now
[11:01] <tsdgeos_> dandrader: cool
[11:02] <tsdgeos_> checking what's wrong with the uitests
[11:02] <tsdgeos_> meh
[11:02] <tsdgeos_> that expand_expand is creeping everywhere
[11:02] <tsdgeos_> need to add some logging to the more_logs
[11:02] <tsdgeos_> so it stops failing and then can't repro anymore ^_P
[11:10] <Saviq> ;)
[11:20] <Cimi> any code review I can do?
[11:24] <dandrader> tsdgeos_, any thoughts on having HorizontalJournal & VerticalJournal vs Journal with a direction (horizontal | vertical) property?
[11:24] <Saviq> Cimi, https://code.launchpad.net/~aacid/unity8/search_history_pointer_correct_pointer_position/+merge/197423
[11:25] <Cimi> Saviq, yeah let's go for it, I forgot to update after the chat here
[11:25] <tsdgeos_> dandrader: good question
[11:26] <tsdgeos_> i guess the property is better from the "qml user" part
[11:26] <tsdgeos_> but it may end up as a bit more convoluted code
[11:26] <tsdgeos_> Saviq: ↑↑↑ ?
[11:26] <Saviq> Cimi, you could take over https://code.launchpad.net/~macslow/unity8/fix-1257312/+merge/197740 and add the test as requested by tsdgeos_
[11:26] <dandrader> tsdgeos_, right, but more work to implement
[11:27] <Cimi> sure
[11:28] <Saviq> tsdgeos_, dandrader, not sure, tsdgeos_ can you assess how difficult / convoluted it would be?
[11:28] <Saviq> it does feel more consistent with QML views
[11:28] <Saviq> Cimi, or https://code.launchpad.net/~unity-team/unity8/unity-scope-tool/+merge/199831 could use a review
[11:28] <tsdgeos_> Saviq: well i guess i can just have two inner classes that do all the work
[11:28] <tsdgeos_> and just create/delete them as needed
[11:29] <tsdgeos_> and have the Journal just be a front-facing class
[11:29] <tsdgeos_> that just has a pointer to the existing ones
[11:29] <tsdgeos_> that should not be much work
[11:29] <Saviq> tsdgeos_, how is it for code duplication atm?
[11:29] <tsdgeos_> Saviq: there's none
[11:29] <tsdgeos_> we have a shared class with the "duplicated" code :D
[11:29] <Saviq> tsdgeos_, right, good
[11:30] <dandrader> I would say, the less API the better.  Thus one class with an extra property is better than two separate classes
[11:30] <Saviq> I agree
[11:30] <tsdgeos_> dandrader: Saviq: the problem introducing the "Journal" and then adding horizontal/vertical is that we need to find a generic enough name for stuff like rowHeight/columnWidth
[11:30] <dandrader> unless VerticalJournal and HorizontalJournal have very distinct implementations
[11:31] <tsdgeos_> since you can only set one of the other depending if you're horizontal/vertical
[11:31] <Saviq> tsdgeos_, well, you can set both, but one is ignored
[11:31] <tsdgeos_> Saviq: don't like that tbh
[11:31] <tsdgeos_> but it's a possibility
[11:31] <dandrader> hmm
[11:31] <Saviq> tsdgeos_, I think it makes more sense than trying to come up with a common name, really
[11:32] <Saviq> tsdgeos_, at least it's clear - and the docs just need to say only one is taken into account depending on direction
[11:32] <tsdgeos_> yeah
[11:32] <Saviq> tsdgeos_, otherwise we'll try and go for cellDimension or such, which will require even more documentation to be understandable
[11:33] <tsdgeos_> ok, let me finish adding all the national holidays to canonical admin, test the bugfix for the qt assert i just foind and i'll do that
[11:33] <Saviq> cheers
[11:33] <Saviq> Cimi, here's another review you might like https://code.launchpad.net/~nick-dedekind/unity8/indicator.highlight-updates/+merge/199471
[11:33] <dandrader> -1 on the "cellDimension" approach
[11:33] <Saviq> Cimi, so there's plenty to choose from
[11:33] <Cimi> ok enough now :)
[11:34] <Saviq> ;)
[11:34] <Saviq> Cimi, just claim the review when you've decided which one to go for first :)
[11:34] <Cimi> Saviq, I'll start with adding the test
[11:34] <Cimi> some 2014 coding
[11:34] <Saviq> Cimi, cool
[11:40] <dandrader> tsdgeos_, Saviq: Now I'm starting to think that having HorizontalJournal and VerticalJournal is indeed better than Journal + direction property. It will translate to less application code written. With the former you write 2 things: the component name and spacing prop (rowHeight or columnWidth). With the latter you write 3 things: component name, direction and spacing prop
[11:41] <Saviq> dandrader, it's just more consistent with QML Views, it's easier to switch, probably easier to find docs
[11:42] <Saviq> I don't think it's a huge matter, though, can go with either
[11:42] <dandrader> the problem of a property (direction) having a side effect on another one (rowHeight or columnWidth) is not nice. properties should ideally be orthogonal to each other
[11:42] <tsdgeos_> dandrader: Saviq: i guess the question is that if you'd ever programatically want to switch from one to the other
[11:43] <dandrader> Saviq, e.g. in qml you have Row and Column
[11:43] <Saviq> tsdgeos_, yeah, that's what I was thinking, but then you can use a Loader
[11:43] <Saviq> dandrader, right, that's a counter-example indeed
[11:43] <Saviq> ok, let's go for separate
[11:44] <Saviq> tsdgeos_, ↑
[11:44] <tsdgeos_> okidoki
[11:50] <tsdgeos_> Saviq: did you start a run of https://code.launchpad.net/~aacid/unity-mir/application_manager_tests/+merge/180898 ?
[11:51] <Saviq> tsdgeos_, yes
[11:51] <Saviq> tsdgeos_, looks pretty stale ;)
[11:51] <tsdgeos_> Saviq: it is
[11:51] <tsdgeos_> Saviq: i asked gerry about it
[11:51] <tsdgeos_> and he said
[11:51] <tsdgeos_> asdasgdafgsgaf
[11:51] <tsdgeos_> kind of :D
[11:52] <Saviq> testing in unity-mir is kind of like that ;)
[11:52] <tsdgeos_> for me we can kill it
[11:52] <tsdgeos_> but there may be something of value
[11:52] <tsdgeos_> it's just sad noone cared the small number of days it did compile and pass
[11:53] <tsdgeos_> there's also sadness in noone caring about https://code.launchpad.net/~aacid/platform-api/papi.rules.typo/+merge/182354
[12:02]  * greyback hears he's being talked about
[12:04] <davmor2> greyback: yeah that about not to ;)  Just accept the blame/praise and carry on :D
[12:05] <greyback> davmor2: it wasn't a direct "he should do something" comment, so yeah I went back into my cave :)
[12:09] <Saviq> tsdgeos_, I'll try and push the papi fix through today
[12:10] <tsdgeos_> cool
[12:10] <tsdgeos_> greyback: it was about https://code.launchpad.net/~aacid/unity-mir/application_manager_tests/+merge/180898 where you tell me if you want me to spend time on making it compile again or we just discard it and forget about it
[12:11] <greyback> tsdgeos_: was the main blocker the fact we couldn't figure out how to get the tests to run on Jenkins?
[12:11] <tsdgeos_> greyback: ah right
[12:11] <greyback> that's a problem we've to figure out at some stage
[12:12] <greyback> tsdgeos_: I would love if you could make another attempt
[12:13] <greyback> even just to get 1 test in there, so the whole test framework is there, and unblocks that jenkins run problem
[12:19] <tsdgeos_> greyback: ok, i'll see what i can do/who can i poke
[12:20] <tsdgeos_> dandrader|afk: answered the implicitheight comment
[12:29] <davmor2> anyone any idea why trustys lightdm password entry won't accept input from the keyboard?
[12:37] <dandrader> davmor2, If I'm not mistaken that's a known but. restarting lightdm in a VT works around it
[12:37] <dandrader> s/but/bug
[12:37] <davmor2> dandrader: ah thanks
[12:38] <dandrader> davmor2, I think mterry knows the details
[12:38] <davmor2> and logged in :)
[12:42] <dandrader> tsdgeos_, was reading the scope toolkit UX doc regarding journals
[12:43] <dandrader> tsdgeos_, so both the horizontal and vertical journals scroll vertically?
[12:43] <tsdgeos_> yep
[12:43] <tsdgeos_> it's just how the delegates get positioned that changes
[12:43] <tsdgeos_> Saviq: right? ↑↑↑
[12:43] <dandrader> I found that a bit surprising, considering their names
[12:44] <Saviq> dandrader, tsdgeos_correct
[12:44] <tsdgeos_> dandrader: well the naming is about the layouting
[12:44] <tsdgeos_> dandrader: remember the journal doesn't really scroll
[12:44] <tsdgeos_> you need to put it in a listview if you want to make it scroll
[12:45] <dandrader> tsdgeos_, but what about that "maximum two rows of cards" constraint on the horizontal journal?
[12:45] <tsdgeos_> dandrader: that's when collapsed
[12:46] <tsdgeos_> i.e. like the current grids have 2 rows vs n rows when collapsed/uncollapsed
[12:46] <dandrader> tsdgeos_, so that's implemented by the container holding that journal, not by the journal itself, right?
[12:46] <tsdgeos_> that's my idea yes
[12:47] <tsdgeos_> we just feed it a different model
[12:47] <tsdgeos_> like we do in the grid case
[12:47] <dandrader> cool, makes sense
[12:49]  * dandrader plays with "make tryHorizontalJournal"
[12:50] <dandrader> tsdgeos_, so HorizontalJournal works just like the layout of words in a paragraph?
[12:50] <tsdgeos_> yep
[12:50] <tsdgeos_> left to right
[12:51] <tsdgeos_> and leave space on right if next doesn't fit
[12:51] <dandrader> tsdgeos_, like when word-wrapping is disabled :)
[13:07] <dandrader> tsdgeos_, so in a VerticalJournal, if items in a row have all the same height it will behave just like a HorizontalJournal
[13:07] <dandrader> filling out the next row, in a left-to-right manner
[13:13] <Saviq> dandrader, yes
[13:13] <Saviq> dandrader, but in a Vertical all items have the same width - not so in a Horizontal
[13:14] <Saviq> dandrader, so they'd behave exactly the same if the items are square, for example
[13:14] <Saviq> dandrader, or at least constant width + height
[13:14] <dandrader> yes
[13:18] <Cimi> do you have both ubuntu sdk and qt 5.2?
[13:18] <Cimi> qtcreator is not installed here
[13:20] <Saviq> dandrader, one thing that might still happen in the horizontal case is that we'll stretch the delegates to fill horizontally, either all of them or just the last one
[13:21] <Saviq> dandrader, although TBH there's nothing in visual design currently that actually uses a horizontal journal...
[14:35] <tsdgeos_> lol
[14:35] <tsdgeos_> i just realized this in mumble
[14:35] <tsdgeos_> warning: The VAD has been replaced by a hack pending a complete rewrite
[14:35] <tsdgeos_> Sad panda
[14:36] <Saviq> wth is VAD? ;D
[14:36] <tsdgeos_> no clue, but it's making the panda sad it seems
[14:56] <mhr3> Saviq, mzanetti is still holidaying?
[14:56] <mhr3> Saviq, so maybe you want to give final ack to
[14:56] <mhr3> https://code.launchpad.net/~mhr3/unity-scopes-shell/json-overrides/+merge/199508 ?
[14:58] <mzanetti> Saviq: mhr3: o/ This was looking good. the only reason I didn't top-approve before xmas is because jenkins was complaining and it looked like something real
[14:58]  * mzanetti -> back to slacking off
[14:59] <mhr3> ah, no, it was the crappy qmlplugindump thing, i workarounded that in another branch
[14:59] <mhr3> which is already merge
[14:59] <mhr3> d
[15:05] <Saviq> mhr3, mzanetti ack, will look it through
[16:11]  * tsdgeos_ wondering what took CI that much time to run
[16:11] <tsdgeos_> basically the fact that i had not pushed the stuff :D
[16:37] <Saviq> tsdgeos_, oups, I think you over-did VerticalJournal...
[16:38] <tsdgeos_> did i?
[16:38] <Saviq> tsdgeos_, I think it was always meant to fill left-to-right
[16:38] <Saviq> tsdgeos_, not start at the highest possible spot...
[16:38] <tsdgeos_> errr?
[16:38] <tsdgeos_> that's not what the numbers said
[16:39] <tsdgeos_> on the screenie
[16:39] <tsdgeos_> it had numbers
[16:39] <Saviq> tsdgeos_, really? /me looks
[16:39] <tsdgeos_> and they were like i did
[16:39] <Saviq> tsdgeos_, indeed
[16:39] <Saviq> tsdgeos_, ok then, ignore me
[16:39] <tsdgeos_> for one time i read the specs... :D
[16:40] <Saviq> tsdgeos_, yeah, the numbers weren't there before and I didn't pay enough attention apparently :)
[17:02] <Saviq> tsdgeos_, got a dash_scope_on_load failure in more_logs!
[17:02] <tsdgeos_> yeay, let's see if they give anything intersting :D
[17:08] <tsdgeos_> Saviq: it seems like the scope it's not getting loaded
[17:08] <tsdgeos_> i.e. it is waiting for MockScope5 to get loaded
[17:08] <tsdgeos_> but only home.scope and MockScope1
[17:08] <tsdgeos_> get loaded
[17:08] <tsdgeos_> which is weird
[17:09] <tsdgeos_> since in the previous test
[17:09] <tsdgeos_> MockScope1, home.scope  and applications.scope
[17:09] <tsdgeos_> so i'd expect at least applications.scope to load in this one too :-D
[17:12] <mhr3> perhaps the mock is just trying too hard to simulate real scopes :)
[17:14] <Saviq> lol
[17:14] <Saviq> tsdgeos_, we don't have timestamps do we?
[17:15] <tsdgeos_> Saviq: nope
[17:15] <tsdgeos_> i'll add those
[17:15] <Saviq> tsdgeos_, maybe it's just timing again? how long are we waiting there?
[17:15] <tsdgeos_> 5 sec
[17:15] <tsdgeos_> but cimi did a branch with 10 sec
[17:15] <tsdgeos_> and we got it to fail to
[17:15] <tsdgeos_> o
[17:15] <Saviq> hmm ok
[17:16] <tsdgeos_> but yeah
[17:16] <tsdgeos_> should add timestamps anyway
[17:25] <tsdgeos_> ok, some more logs added
[17:25] <tsdgeos_> let's see what tomorrow yields
[18:37] <cwayne> mhr3, ping
[18:43] <cwayne> Saviq, mhall119 do we have a roadmap for the new unity scope api?
[19:36] <Saviq> cwayne, nothing specific that I know of, no - but the overall goal is to implement as much as possible for 14.04 (on unity8, not unity7)
[19:38] <cwayne> Saviq, so there's no documentation on for example which order scopes will be ported in?
[19:41] <Saviq> cwayne, I only know about the UI and the shell-facing API, thostr and lucio would know about the other parts
[19:43] <cwayne> Saviq, so do we expect the switchover to using the new api's by default to happen for 14.04?
[19:43] <Saviq> cwayne, that's the plan, yes
[19:45] <cwayne> Saviq, what about the renderers, do we have any idea when they'll be implemented?  (IIRC grid is done, and we're expecting Carousel soon?)
[19:45] <Saviq> cwayne, they're being done as we speak
[19:46] <Saviq> cwayne, well, maybe not right now, it's EOD after all ;)
[19:47] <cwayne> Saviq, :)  so as in, this/next week?
[19:48] <Saviq> cwayne, some should happen next week, more late Jan/early Feb
[19:48] <Saviq> cwayne, unless I delegate, at which point more should happen in between (there's the sprint in Cape Town mid-Jan)
[19:49] <cwayne> Saviq, and at that point will the scopes themselves start to be ported over?
[19:49] <Saviq> cwayne, it will happen in parallel
[19:50] <Saviq> cwayne, but again, more details on that you'll get from thostr and lucio
[19:51] <cwayne> Saviq, right, thanks.  is there any wiki or doc that you know of (even if just for the UI side?)
[19:51] <cwayne> detailing the schedule/roadmap
[19:51] <Saviq> cwayne, that was your first question, wasn't it ;)
[19:52] <cwayne> oops, it was wasn't it
[19:52] <cwayne> sorry :P