=== chihchun_afk is now known as chihchun
=== faenil is now known as faenil_
=== faenil_ is now known as faenil
=== athairus is now known as afkthairus
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
[11:47] <kalikiana_> t1mp: Ready for review https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/listsAndNameSpaces/+merge/298314
[11:48] <kalikiana_> (with, as I mentioned in Mumble, the caveat that it's not fully tested because I don't want to re-do everything here, which'll be done in the new api project anyway)
[13:00] <t1mp> kalikiana_: cool, I'll check it
[13:00] <t1mp> kalikiana_: it only checks the stuff we export to QML, right? So C++ API changes are still undetected?
[13:01] <t1mp> I'm thinking what will happen for example when(if) we rename UCAction to UbuntuToolkit::Action
[13:18] <mhall119> ahayzen: pong, sorry I lost power and with it my irssi backlog, but I see that you pinged me about a wallpaper contest
[13:18] <mhall119> I think that's a fantastic idea
[13:24] <kalikiana_> t1mp: I don't get that. Those are 3 things you mix up here. 1) UCAction, C++ class name 2) UbuntuToolkit, C++ namespace 3) Action, QML typename
[13:25] <kalikiana_> What are you referring to exactly?
[14:47] <ahayzen> mhall119, \o/ woo
[14:48] <ahayzen> mhall119, yeah basically we were thinking of a wallpaper contest to get a set of images included into the default ubuntu image, so you don't just have that single image. ... I wondered if they could be 'convergent' images that work when cropped to portrait and when output to a landscape display
[14:57] <mhall119> ahayzen: if you want to organize it, including defining rules like that, I will check on (A) prizes and (B) whether there is space on the default Ubuntu images for extra images
[15:00] <ahayzen> awesome :-) like it'd be nice even if it just the /ubuntu channel images doesn't have to be the OEM ones
[15:00] <ahayzen> ahoneybun, ^^
[15:02] <mhall119> ahayzen: let me check on space, IIRC we were pretty tight on how much more could go into the image given the partition sizes on the phones
[15:02] <ahayzen> ah yeah
[15:02] <ahayzen> would/could that not go into the user's partition though?
[15:02] <ahayzen> like ~/Pictures
[15:03] <ahayzen> i guess they are somewhere in a system folder though at the moment
[15:03] <ahoneybun> I'll help with rules, and judging
[15:04] <ahayzen> awesome :-)
[15:04] <ahayzen> mhall119, how do we organise this sortof thing? start a wiki page somewhere detailing the rules?
[15:04] <ahayzen> (assuming there is enough space on the image etc)
[15:04] <mhall119> ahayzen: usually we use developer.ubuntu.com for phone related contests
[15:05] <ahayzen> ah yeah
[15:05] <ahayzen> but i guess we could use similar rules to how the desktop one has been run
[15:06] <mhall119> yeah, using flickr to collect the entries
[15:06] <ahayzen> :-)
[15:06] <ahoneybun> yep flickr is great that at
[15:29] <svij> ahoneybun: ahoneybun: you may also want to talk to nhaines for ideas/rules etc., since he runs the desktop wallpaper contest
[15:35] <t1mp> kalikiana_: do I mix it up?
[15:35] <t1mp> kalikiana_: the components.api used to have UCAction, and now it has Action. So in the MR it goes from C++ to QML name?
[15:39] <ahoneybun> svij: good point ahayzen
[15:39] <ahayzen> yeah good idea
[15:40] <kalikiana_> t1mp: "Used to" after the namespace MR broke it you mean? This is exactly what fixed.
[15:40] <t1mp> kalikiana_: my question was: Does it only check the QML API?
[15:40] <t1mp> because there used to be C++ class-names in there, and now only QML.
[15:41] <t1mp> hmm.. that is strange though. UbuntuToolkit is the C++ namespace and Action is the QML component name
[15:42] <kalikiana_> t1mp: Let's take an example. "Ubuntu.Components.Action 1.3 1.0 0.1 UbuntuToolkit::UCAction: QtObject" The C++ class name is at the end of the list of exported QML types and versions. We do that because the C++ class leaks into Autopilot introspection - we don't actually track C++ API.
[15:46] <t1mp> kalikiana_: the MR has in many places stuff like: +    property UbuntuToolkit.Action action
[15:47] <t1mp> so it has CppNameSpace.QmlComponentName
[15:47] <kalikiana_> Yes
[15:47] <t1mp> if we track QML API, why do we have the CPP namespace?
[15:47] <t1mp> it should be Ubuntu.Components.Action
[15:47] <t1mp> UbuntuToolkit does not exist in QML
[15:48] <t1mp> I think eventually we should track cpp api too. So we would have both UbuntuToolkit::UCAction and Ubuntu.Components.Action
[15:48] <t1mp> but maybe in separate files
[15:57] <kalikiana_> t1mp: Pushed a fix https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/listsAndNameSpaces/+merge/298314
[15:59] <t1mp> kalikiana_: nice, thanks.
[15:59] <t1mp> kalikiana_: do we not need the namespace on the right-hand side of the : for QML API?
[15:59] <t1mp> kalikiana_: for example now we have Ubuntu.Components.Pickers.Dialer 1.3: StyledItem in the MR
[15:59] <t1mp> should that be Ubuntu.Components.Pickers.Dialer 1.3: Ubuntu.Components.StyledItem
[15:59] <t1mp> or is that useless?
[16:02] <kalikiana_> t1mp: That'd be an enhancement... in theory it could be useful if the parent is from another module, so I might say, iff it came from another module the parent should be shown
[16:02] <kalikiana_> (Rule of thumb is usually, include what's necessary, avoid redundancy)
[16:02] <t1mp> Ubuntu.Layouts.Layouts 1.0 0.1 ULLayouts: Item
[16:03] <t1mp> kalikiana_: Item comes from the QtQuick module
[16:03] <kalikiana_> Right. So in theory it's ambiguous and should probably say QtQuick.Item
[16:09] <t1mp> Ubuntu.Components.ListItems.Empty 1.3: AbstractButton
[16:09] <t1mp> kalikiana_: ^ also that one. AbstractButton is in Ubuntu.Components, not in Ubuntu.Components.ListItems
[16:09] <kalikiana_> Yes
[16:09] <t1mp> perhaps it is the easiest to list the full import
[16:09] <t1mp> or namespace
[16:10] <t1mp> how do we call it in QML?
[16:10] <kalikiana_> Nothing is easy here. :-)
[16:10] <kalikiana_> Type system is everything but
[16:10] <kalikiana_> t1mp: QML has no namespaces
[16:10] <t1mp> ok, maybe not the easiest. But always listing the full namespace is the least ambiguous
[16:11] <t1mp> ok, maybe not the easiest. But always listing the full import string is the least ambiguous
[16:11] <t1mp> like that then?
[16:11] <t1mp> how do you call the prefix for the Component  name?
[16:12] <kalikiana_> that's the module name. you import either all classes by their name or using "as" with a custom prefix (which looks like a namespace in C++ does)
[16:13] <kalikiana_> but essentially the types are dumped freeform into the typesystem
[16:15] <kalikiana_> for example "import Ubuntu.Components" is the module, if there's a conflict with another module, your problem
[16:15] <t1mp> ah, ok module name then :)
[16:15] <kalikiana_> I'd never call it a namespace because it really doesn't work like one
[16:17] <kalikiana_> t1mp: Mind filing a bug for including the name of the module of parent classes?
[16:17] <t1mp> sure
[16:18] <kalikiana_> Thanks
[16:19] <t1mp> huh, Ubuntu.Layouts.Layouts 1.0 0.1 ULLayouts: Item is correct?
[16:19] <t1mp> I didn't notice ULLayouts before
[16:19] <t1mp> yeah it is ULLayouts.
[16:20] <ahayzen> mhall119, i wonder if there isn't enough space, if we could create a click or zip file that the user could download a 'pack' of photos which is then imported into the settings app ... as a fallback plan
[16:20] <t1mp> kalikiana_: perhaps we should show the namespace for the C++ parents?
[16:21] <t1mp> kalikiana_: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1596601
[16:21] <ubot5> Launchpad bug 1596601 in ubuntu-ui-toolkit (Ubuntu) "Show the module of the parent component in components.api" [Undecided,New]
[16:23] <t1mp> kalikiana_: another one,
[16:23] <t1mp> -    readonly property UbuntuToolkit.QQuickMimeData data
[16:23] <t1mp> 246	+    readonly property MimeData data
[16:24] <t1mp> kalikiana_: MimeData is not in a module/
[16:24] <t1mp> ?
[16:24] <t1mp> also the newData() function after that
[16:26] <kalikiana_> t1mp: MimeData comes from Ubuntu.Components - although it's perfectly possible it's not there because it was hard to do
[16:27] <kalikiana_> (I probably wouldn't have seen a need to include if it's the same module, but I don't think it was a very specific decision to do or avoid)
[16:39] <t1mp> kalikiana_: there are more issues, I commented on https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/listsAndNameSpaces/+merge/298314
[16:41] <kalikiana_> t1mp: The syntax hasn't changed at all. If it *looks* confusing that's not a bug or regression in the context of this branch.
[16:42] <kalikiana_> t1mp: Re "<UbuntuToolki>" list parsing. That's exactly what I'm fixing.
[16:43] <kalikiana_> t1mp: the description of AlarmModel.get used to be this before the namespaces came into the picture, thus no regression "function UCAlarm* get(int index)"
[16:45] <kalikiana_> You found a bug, though: "signal dragDirectionChanged(UCBottomEdge direction)" is not fixing the regression.
[16:46] <kalikiana_> why is the module name missing here? -> it was never there ;-)
[16:46] <kalikiana_> "function QQuickMimeData* newData()" is also not a regression
[17:07] <kalikiana_> t1mp: So in summary, you found 2 genuine bugs (regressions caused by namespaces they weren't fixed), I recorded the reasoning in a comment and will investigate.
[17:56] <t1mp> kalikiana_: okay, thanks.
=== kalikiana_ is now known as kalikiana
=== afkthairus is now known as athairus
=== salem_ is now known as _salem