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