=== hggdh_ is now known as hggdh === broder_ is now known as broder [06:58] mzanetti, around? [07:00] morning folks [07:02] hey tsdgeos, slept well? ;) [07:02] * Saviq got up around 6am again... [07:02] tsdgeos, I need a second pair of eyes lp:~unity-team/+junk/shell-interfaces [07:03] tsdgeos, I'm bootstrapping the "separate project for shell-facing interface definitions" [07:03] Saviq: yeah no stupid hours wake up here [07:03] * tsdgeos branches [07:03] tsdgeos, my current issue is "Unable to handle unregistered datatype 'Source*' for property 'MockModel::source'" [07:04] even though the plugin registers the type :/ [07:05] * Saviq back in 15 [07:26] Saviq: seems you're hitting the "moc doesn't know C++" case [07:27] Saviq: http://paste.kde.org/~tsdgeos/739586/ gets me past that registration error [07:28] want a MR push for that? [07:28] want a MR/push for that? [07:29] tsdgeos, nah, that's fine [07:29] tsdgeos, thanks [07:30] Saviq: still fails with [07:30] FAIL! : qmltestrunner::test_singletons(Model.source) Model.source should be writable [07:30] Loc: [/home/tsdgeos_work/phablet/shell-interfaces/build/modules/TestUtil/Verifier.qml(74)] [07:30] but i guess that's another thing [07:30] tsdgeos, that's fine, yeah [07:31] tsdgeos, any other comments on that? [07:31] got confused with too many things named the same :D [07:31] mhm [07:31] still haven't look at it in depth [07:31] give me 10 min more [07:31] sure [07:45] Saviq: btw i "improved" the isInstanceOf thing, did you see it? [07:45] tsdgeos, no [07:45] Saviq: have a look, it works for "qmltypes" now too [07:46] tsdgeos, same branch? [07:46] Saviq: it's in master :D [07:46] right ;) [07:46] and it should go away from there [07:46] well not master [07:46] unity/phablet [07:46] or whatever [07:46] yeah [07:47] Saviq: want me to have a look at that Verifier.qml too? [07:47] tsdgeos, sure [07:50] tsdgeos, and how does "Hud: Support having toolbar items enabled/disabled." describe the changes to the test utils? :P [07:50] obvious, ain't it? [07:51] i know, complain to the approver [07:51] I will [07:51] when he decides to show up [07:51] it basically grew up organically as part of needs for that feature [07:52] and we all know it's not the right thing to do [07:52] but most of the times it's a pain to split stuff into more MRs [07:54] and Mr Judge, that's all i have to say in my defense :D [07:59] Saviq: where the "if (writable) {" in the writable func come from? [08:00] tsdgeos, it shouldn't be there probably [08:01] ok, everything makes kind of sense, the few comments are [08:01] you should probably assign values 1 and 2 to HintEnum enums to make clear it's bitwise enums and next should be 4 and not 3 [08:02] in modules/TestUtil/Verifier.qml " obj is the object on" -> " object is the object on" [08:03] as previously said got a bit confused we have to "Source" QML types (even if with different URIs) [08:03] and I'm not a fan of long nested namespaces, but that's personal i guess :D [08:04] ok MockSource it's going to be [08:05] as for namespaces... I could do either, but this seems to be a preference in the Unity APIs team, so let's go with that [08:05] thanks for the other comments [08:06] :) [08:13] tsdgeos, any way to convince QFlags to work with strongly-typed enums? [08:13] i.e. "enum class { ... }" [08:14] that's c+11 enums, right? [08:14] yeah [08:14] it works for Q_ENUMS [08:14] but flags die [08:14] haven't played much with those [08:15] but does it make sense for flags? [08:15] i mean if it's strongly typed [08:15] what do you assign the result to? [08:16] here he is [08:16] greyback, you get a slap on the wrist for r650 [08:17] * tsdgeos plays a bit with enum class [08:17] Saviq: why? What did I miss? [08:17] greyback, there's no mention of changes to TestUtil in the commit msg [08:18] tsdgeos, that's a good question, but well, you can use any enum as flags, it's mostly about comparison and passing them around [08:18] so that if your argument is of type SomeFlag, you can only use SomeFlags to provide that argument [08:18] not any int [08:19] Saviq: i mean http://paste.kde.org/~tsdgeos/739664/ doesn't work [08:19] Saviq: okay. My bad [08:19] since there's no strongly typed enum for the or of the two strongly typed enums [08:19] tsdgeos, right [08:20] i guess you could store it into an int if you define the | operator? [08:21] tsdgeos, and/or explicitly provide all combinations ;) [08:21] which kind of beats the purpose [08:21] yep [08:22] tsdgeos, the failure you got is "Cannot assign QObject* to unity::notifications::Source*" [08:22] when trying to assing MockSource to MockModel.source :/ [08:22] ? [08:22] no, never got that [08:22] you did - the failed test [08:22] ah [08:23] I wonder if I need to expose the Source in the Mocks, too... [08:23] which kind of makes sens [08:23] you can't assign a QObject* to a Source* [08:23] though you are not [08:23] so yeah some more exporting missing around i guess [08:23] yup [08:25] yup [08:25] works [08:25] I should probably name the virtual classes something special [08:25] so that you can register them without polluting the scope [08:25] i.e. ModelInterface etc. [08:27] and then I can have an abstract base plugin that registers them [08:29] yep [08:32] btw after using the BB10 phone as my main phone for a few days, i like how they implemented the vertical toolbar [08:32] this way they can provide tooltips on icons [08:32] looks weird at first [08:32] but then makes sense [08:33] tsdgeos, so instead of the toolbar at the bottom you get them vertically at the left? [08:33] or? [08:34] you have the "regular" toolbar at the bottom [08:34] with 3 icons + text [08:34] and then you have the "extra actions" toolbar vertically (that appears i.e. after long pressing in an email) vertically [08:34] and then it first only shows icons [08:34] but if you hover over it shows text [08:34] let me show a few screenshots [08:35] sounds complicated ;) [08:35] I wonder how would that go with user testing :D [08:37] so [08:37] default mail view https://www.box.com/s/n0rmsfzx6yplrajasux8 [08:38] after long pressing an email https://www.box.com/s/6wdyy9o065okcmh03w59 [08:38] how do you "hover" with a touchscreen? [08:38] greyback: put the finger on top of the icon :D [08:38] after putting my finger on top on an icon because i have no clue what it means https://www.box.com/s/meonqun0x1d03gkygg4f [08:38] tsdgeos: so long press [08:38] no [08:38] ? [08:38] greyback: no, press without release [08:39] can you guys see those urls? [08:39] yep, tho why it needs flash to show a png is beyond me [08:39] lol [08:40] so all that time you keep your finger on the screen (no release) [08:40] ah no [08:41] you do long press on the email [08:41] and then the side bar appears [08:41] at that stage you can release the finger [08:41] and the side bar stays [08:41] you can either dismiss it by pressing on the "empty" area [08:41] or use the longpress to scrub amongst the icons for tooltips [08:41] ok, and if you press on the sidebar icon, it shows the "tooltip", and it only fires on release? [08:41] or directly click an icon if you know what it does [08:42] yep [08:42] if you are fast enough (i.e regular press) you don't get the tooltip [08:42] i think it's smart enough [08:42] not saying we should get inspiration in it [08:43] ok. That's not too dissimilar to what we're trying with the launcher [08:43] good stuff then :-) [08:49] although I must say it's relatively ugly [08:49] it tries to be clean [08:49] but then there's things that make me squint [08:50] like the envelope icon, which if I didn't know it was an envelope I'd have a hard time understanding what it is [08:50] the fadeout elide... I think /me no like [08:51] Saviq: well, you're reading email :D [08:51] what you expect it to be :D [08:51] that's not to say I like our apps, our phone app is just as ugly at the moment [08:52] fade instead of ... makes sense in the sense it's much more space friendly [08:52] adding ... kills lots of space [08:52] while fade kills less [09:03] sure, but is ugly, IMO ;) [09:03] but what do I know [09:04] won't comment regarding uglyness :D [09:20] pstolowski: hi! Do you know if the 100scopes unity got rid of the irritating regression when pressing enter when the results are still loading? [09:20] pstolowski: the one you mentioned to me during the sprint [09:22] sil2100: hey! mhr3 told me there is a workaround commited but not yet released in the ppa [09:22] pstolowski: excellent - it's on unity's side or somewhere else, do you know? [09:22] sil2100: unity [09:23] Since I've been asked to get things merged in and auto-releasing this week [09:23] pstolowski: thanks! [09:23] brb [09:24] sil2100, pstolowski, it's not committed yet, andyrock started to work on a branch, but it's not done yet [09:25] mhr3: thanks for clarification [09:26] Saviq: i see why we have the get() thing in the proxymodel [09:26] to mimic the QML ListModel element [09:27] tsdgeos, is that a good reason? [09:28] well there is the big problem in that the QML ListModel and QAbstractListModel stuff doesn't have the same API [09:28] even both are valid "model" things [09:28] like pete-woods was complaining in #ubuntu-touch one has count and the other has not [09:29] yeah, and we do mimic that as well in the proxy [09:29] so i guess the intention was to make the proxy have an api closer to QML ListModel [09:29] yeah, but then that causes issues when other QALMs don't do that [09:29] right [09:29] when you expected count to be there [09:29] but there is not [09:29] it's a bit of a mess tbh [09:29] indeed [09:30] anyway i'll see who is using that get() [09:30] ListModel should have the exact same api QALM has [09:33] i guess is too late for that [09:35] hmmm [09:35] Saviq: can you look at updateLensesViewType in Dash.qml [09:35] i am wondering how that works [09:35] tsdgeos, it doesn't [09:36] ok that makes more sense :D [09:36] tsdgeos, I have a branch that makes it work [09:36] but then it crashes somewhere in glib [09:36] i was wondering how doing anything to a local var made any change globally [09:36] tsdgeos, it's supposed to tell lenses "you're visible / you're hidden / home is visible" [09:37] for them to react accordingly (i.e. update their models) [09:38] ook [09:38] tsdgeos, I can give you my branch if you want ;) [09:39] Saviq: well, i only got there because i was having a look at the get() users [09:39] and that uses it [09:39] yeah I know [09:39] that call is ignored in smart scopes, so i'd say forget about it [09:39] Saviq, tsdgeos ^ [09:39] mhr3, yeah I know, didn't want to spend time on it [09:40] mhr3, is there a new way to tell scopes "you're displayed"? [09:40] mhr3, so that they can update their models if needed? [09:40] Saviq, send them a search() request [09:40] mhr3, right ;d [09:40] simples :D [09:40] * Saviq likes simples [09:41] Saviq, btw who will work on the shell part of the update? [09:42] mhr3, probable me & greyback [09:43] mhr3, but it's you guys that will take over the QML bindings and update them - we need to talk about the APIs at some point [09:43] Saviq, cool, just asking cause we're pretty much ready for it to happen, don't expect any more changes to unitycore [09:44] Saviq, that was my understanding, you surprised when you said you'll do it this time :) [09:44] grr [09:44] Saviq, that was my understanding, you surprised when you said you'll do it this time :) [09:45] mhr3, that's not the "shell part" though, is it ;) [09:45] oh, so that's the "but" [09:45] mhr3, we'll need a primer on the new Unity APIs [09:45] s/Unity/Scopes/ [09:46] and as I understand it pstolowski already has a working example [09:46] so that will probably be a base for the new QML bindings [09:46] stuff from the previous implementation (unity-2d / lp:unity/phablet) should only be carried over carefully [09:47] Saviq, might be simpler at this point to keep using unitycore, and as you know scopes will change again, and with that change the dbus api will probably change too, so at that point we can get rid of unitycore [09:48] mhr3, k [09:48] if there's not so much changes [09:49] Saviq: https://code.launchpad.net/~aacid/unity/fix_spacing/+merge/162947 [09:49] pstolowski, or do you think it'll be simpler to go without unitycore right away ^? [09:51] Saviq: and dee-qt has a get(row) too [09:52] may want to have a look at that too later [09:52] or not [09:53] Saviq: I wouldn't call the code I have 'a working example', the goal was to have a simple ui that is able to fire off a search query with new backend, so what I have is a qml app that supports only one dbus call (search, using qtdbus) and displays the resulting model [09:54] tsdgeos, right back at you https://code.launchpad.net/~saviq/unity/phablet.newlines-at-end-check/+merge/162948 [09:54] pstolowski, got it [09:56] mhr3, Saviq: +1 for keeping unitycore for now [09:59] http://pastebin.ubuntu.com/5644194/ oO [09:59] lol [10:00] -0 != +0 [10:00] :D [10:00] * tsdgeos sees how the PhD in Math appropiately leaves the room [10:01] stupd JS [10:02] tsdgeos, lol [10:02] tsdgeos, "0" != 0 [10:02] true that [10:03] Saviq, one more thing - i had trouble building the phablet branch, for some reason it didn't want to build hud, seen such issue? [10:03] Playing with Mir is fun, occasionally you screw up and lock yourself out of your whole machine :) [10:03] mhr3, we've had some issues, but current trunk should work [10:03] greyback, ;) [10:04] Saviq, hm, it annoyed me too much and i created a jhbuild moduleset to build it all :) [10:04] mhr3, yeah, we'll be rid of the ./build_unity script soon [10:04] Saviq: I have cursor working on desktop now. I still think it'd be useful to be able to run shell in X, so I intend to add logic to detect the platform on run-time and do the right thing. Approve? [10:05] tbh now that People lens is out for now... maybe we should just ignore it [10:05] Saviq, yey! it's a mess :P [10:05] greyback, yeah, for sure [10:05] Saviq: ok good. Proceeding.. [10:05] greyback, maybe two separate executables? [10:06] Saviq: let me see. I'm uncertain yet how big the if{} blocks will end up being. [10:07] greyback, k [10:07] greyback, would be useful to be able to run shell-in-mir from your desktop, should that work? [10:07] greyback, or do you need to be on a VT to run it? [10:08] Saviq: I think VT is needed, but I agree that would be nice. I'll look into it [10:08] greyback, should be a case of telling Mir which VT to use, no [10:08] ? [10:09] Saviq: probably yes. But I need to learn how [10:17] greyback, you want to talk to alf or raof for those questions [10:18] tvoss: will do [10:20] did we lose the fake music player? [10:21] tsdgeos, looks like it [10:23] ;( you can't pass JS objects from QML to C++ [10:23] as in {name: "value"} [10:26] not as a variantmap? [10:40] tsdgeos, nope, it comes back as QObject(0x0) [10:40] tsdgeos, it probably only lives in the JSEngine [10:40] Saviq: but a variantmap is not a QObject [10:40] tsdgeos, hmm, checking [10:40] i mean if the function in c++ accepts a QVariantMap [10:40] yeah, checking [10:42] tsdgeos, "Unknown method parameter type: QVariantMap*" [10:43] yeah [10:43] tsdgeos, works [10:43] not via pointer [10:44] nice :-) [10:45] Saviq: so there's only 1 place where the get() function is used and works (there are 2 other places were we use it but the code is wrong :D) [10:45] nice [10:45] the place is in passing down the selected video when clicking the video [10:45] i guess we can just make the "clicked" signal pass up the needed info and be done? [10:46] probably [10:46] * Saviq bbl [11:03] Trevinho: could you define the regression potentials for the raring bamf SRU bug fixes? === _salem is now known as salem_ [11:40] Saviq: so https://code.launchpad.net/~aacid/unity/remove_qsortfilterproxymodelqml_get/+merge/162955 is what i got [11:40] opinions? === salem_ is now known as _salem === _salem is now known as salem_ [11:57] tsdgeos, just so we're clear, that function did not do nothing [11:57] tsdgeos, lens was a pointer to the actual lens object [11:57] tsdgeos, and so setting viewType on it would set it there [11:58] Saviq: you sure? [11:58] tsdgeos, yes [11:58] filteredLenses is a SortFilterProxyModel [11:58] so the get() there is the QVariantMap one [11:58] lens can't be a Lens* [11:58] tsdgeos, it was working, that I'm sure of ;) [11:58] ok [11:58] i'll have a look later [11:58] lunch ready [11:59] * greyback agrees, goes for lunch === greyback is now known as greyback|lunch [12:00] slangasek: should I reject the proposal then? Or did you want to take bits of it and propose them ? [12:16] Saviq, does shell support the annotated icons already? [12:16] mhr3, if you mean those with prices on them - no [12:16] ie the ones shopping uses - an icon with a text+category icon overlay [12:17] Saviq, and what's the plan there? we used gicon for those [12:17] mhr3, we can do gicon [12:17] mhr3, s/can do/are doing/ [12:18] Saviq, well but the annotated icon is our custom thing that just implements gicon interface [12:18] i'm just wondering how does that into the qml-only world [12:18] fit into* [12:19] mhr3, I expect two icon uris (or names) - one for the actual icon, one for the overlay [12:19] mhr3, and we overlay them in the shell [12:19] yep, that's how it works :) [12:20] mhr3, so if you pass as those two uris, we're fine - we just need to handle it over here [12:20] s/as/us/ [12:21] ok, so you don't care about the actual serialization format, which makes it our problem [12:22] mhr3, I'd expect it to be one of the cases of "this kind of renderer needs an overlay icon, hey scope, you need to provide that!" [12:24] hmm, we didn't really do it based on the renderer, might think about that [12:24] mhr3, yeah, so for me that's a different renderer type [12:24] mhr3, but [12:25] mhr3, it might be a generic thing, too [12:25] mhr3, i.e. "if there's a price and an icon, overlay a price ribbon" [12:25] if we deem it common enough [12:27] yea, that's what we have now, and therefore i'm not liking the less generic approach [12:29] mhr3, it just depends - if we're to support that in all of the renderers, then we should keep it generic [12:29] mhr3, but if it's only there in 30% of them, then requesting a "*WithRibbon" renderer might make more sense [12:30] mhr3, I'm generally of the opinion that there should be as little "generic" things as possible [12:30] already we have image-only renderers (video / music carousels) [12:31] mhr3, and looking at places scope we might have some text-only ones [12:31] so that really suggests to me the only really generic thing is the uri for the item [12:31] as the identifier [12:32] but that also suggests that the results scope gives you should be more tied to the category renderer and i'm not sure i like that [12:33] there's a compromise to be had, that's for sure [12:33] but we need to define a list of fields per-category renderer anyway [12:34] obviously there's a worry "what if the scope does not support that data?" [12:34] indeed [12:35] so what can we do... [12:35] required and optional fields? [12:35] so if a scope requests a certain renderer for a category that requires field A, B and C, but the scope only supports A and B [12:36] will we just leave the category out? [12:36] we can't for the life of us come up with all the possible fields [12:36] are the fields really required? can't we have a reasonable default? [12:36] depends on the renderer [12:37] but what would be the default name for a contact? [12:38] I dunno, I'm just sure we'll end up with a "I wish we had that field in the list from the get go" [12:39] when we want to support something new, but because none of the scopes know about it, they won't support it [12:39] truth is it's like that either way [12:39] yea, i see your point [12:39] so if we define a list of supported fields that we don't use initially [12:40] scope authors might implement it just because they can [12:40] not necessarily looking at the current renderer implementation [12:40] but how do we come up with that list [12:40] i don't think that will ever be the case, you can't forsee the future [12:40] sure, we might add to the list [12:40] but clearly the schema needs to be as dynamic as possible === greyback|lunch is now known as greyback [12:41] yeah, that's for sure [12:41] but that means that renderers should implement the "oh this field is missing, let's ignore this result" [12:42] you're thinking per-result... that could potentially work [12:43] and the master scope could be smart when aggregating [12:43] even if the first result didn't fill all the required fields [12:43] there might be another one that will provide it [12:43] but then... we might end up with a required-per-scope (like the price) [12:44] and required-once (like the contact name) [12:44] and optional (like the avatar) [12:44] that gets complicated... [12:44] indeed [12:45] tell me again, can scopes define categories or is it just the master scope? [12:45] they can [12:45] and if the child scopes can, who decides on the renderer? [12:46] scope that's on top [12:46] so the one that's currently rendered, basically [12:46] yep [12:46] mornin' guys [12:46] most usually that's going to be the master scope [12:46] but when you dig in [12:46] it might change... yep [12:46] k [12:47] then it has to be dynamic [12:47] because if a scope author says he wants renderer A for a category [12:47] but a master scope says they want to use C now [12:47] even though initially they used B [12:47] yikes [12:47] hey kgunn [12:47] or simply the binding can try to give it to you in a more specialized way, yet the scopes will have to be more generic [12:48] yeah the scopes can't really assume what data they give up [12:49] btw shouldn't default values be per-scope... [12:49] maybe not [12:49] or it probably depends on the field [12:49] some of them might be shell-side (default avatar) [12:50] other might be scope-side [12:50] so what we have now [12:55] greyback: got it all running on an arm device now :) ? [12:56] kgunn: not yet. I want to improve the desktop experience a bit more first. But hope to attack it today [12:57] greyback: voss shared a video of it w cursor...pretty sweet [12:57] greyback: just hoping the snappy-ness stays on arm (vs intel desktop) [12:57] kgunn: and much easier to use when you know where the cursor is :) [12:57] kgunn: yep, me too. === cyphermox_ is now known as cyphermox [13:03] tsdgeos, can you review this one? https://code.launchpad.net/~dandrader/unity/phablet_fixUtilsPluginTests/+merge/162789 [13:03] sure [13:03]