| === 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_ | ||
| kalikiana_ | t1mp: Ready for review https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/listsAndNameSpaces/+merge/298314 | 11:47 |
|---|---|---|
| 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) | 11:48 |
| 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:00 |
| t1mp | I'm thinking what will happen for example when(if) we rename UCAction to UbuntuToolkit::Action | 13:01 |
| 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:18 |
| 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:24 |
| kalikiana_ | What are you referring to exactly? | 13:25 |
| ahayzen | mhall119, \o/ woo | 14:47 |
| 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:48 |
| 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 | 14:57 |
| 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:00 |
| 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:02 |
| 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:03 |
| 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:04 |
| ahayzen | ah yeah | 15:05 |
| ahayzen | but i guess we could use similar rules to how the desktop one has been run | 15:05 |
| mhall119 | yeah, using flickr to collect the entries | 15:06 |
| ahayzen | :-) | 15:06 |
| ahoneybun | yep flickr is great that at | 15:06 |
| svij | ahoneybun: ahoneybun: you may also want to talk to nhaines for ideas/rules etc., since he runs the desktop wallpaper contest | 15:29 |
| 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:35 |
| ahoneybun | svij: good point ahayzen | 15:39 |
| ahayzen | yeah good idea | 15:39 |
| 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:40 |
| t1mp | hmm.. that is strange though. UbuntuToolkit is the C++ namespace and Action is the QML component name | 15:41 |
| 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:42 |
| t1mp | kalikiana_: the MR has in many places stuff like: + property UbuntuToolkit.Action action | 15:46 |
| 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:47 |
| 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:48 |
| kalikiana_ | t1mp: Pushed a fix https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/listsAndNameSpaces/+merge/298314 | 15:57 |
| 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? | 15:59 |
| 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:02 |
| 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:03 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| kalikiana_ | but essentially the types are dumped freeform into the typesystem | 16:13 |
| 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:15 |
| kalikiana_ | t1mp: Mind filing a bug for including the name of the module of parent classes? | 16:17 |
| t1mp | sure | 16:17 |
| kalikiana_ | Thanks | 16:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| t1mp | kalikiana_: another one, | 16:23 |
| t1mp | - readonly property UbuntuToolkit.QQuickMimeData data | 16:23 |
| t1mp | 246+ readonly property MimeData data | 16:23 |
| t1mp | kalikiana_: MimeData is not in a module/ | 16:24 |
| t1mp | ? | 16:24 |
| t1mp | also the newData() function after that | 16:24 |
| kalikiana_ | t1mp: MimeData comes from Ubuntu.Components - although it's perfectly possible it's not there because it was hard to do | 16:26 |
| 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:27 |
| t1mp | kalikiana_: there are more issues, I commented on https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/listsAndNameSpaces/+merge/298314 | 16:39 |
| 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:41 |
| kalikiana_ | t1mp: Re "<UbuntuToolki>" list parsing. That's exactly what I'm fixing. | 16:42 |
| 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:43 |
| kalikiana_ | You found a bug, though: "signal dragDirectionChanged(UCBottomEdge direction)" is not fixing the regression. | 16:45 |
| kalikiana_ | why is the module name missing here? -> it was never there ;-) | 16:46 |
| kalikiana_ | "function QQuickMimeData* newData()" is also not a regression | 16:46 |
| 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:07 |
| t1mp | kalikiana_: okay, thanks. | 17:56 |
| === kalikiana_ is now known as kalikiana | ||
| === afkthairus is now known as athairus | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!