| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === chihchun_afk is now known as chihchun | ||
| === rpadovani_ is now known as rpadovani | ||
| === chihchun is now known as chihchun_afk | ||
| === davmor2_ is now known as davmor2 | ||
| === diddledan__ is now known as diddledan | ||
| === chihchun_afk is now known as chihchun | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| t1mp | kalikiana: do you agree with me adding foregroundColor and backgroundColor to ActionBarStyle? https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1597774 | 14:05 |
|---|---|---|
| ubot5 | Launchpad bug 1597774 in ubuntu-ui-toolkit (Ubuntu) "Give ActionBar a configurable foreground and background color in the style" [Undecided,New] | 14:05 |
| kalikiana | t1mp: Will the color be used for the overflow menu as well? Or will there be a separate style for that? | 14:15 |
| kalikiana | It makes sense to me, but it'd be good to consider the long term plans | 14:16 |
| t1mp | kalikiana: yes, could be used for the overflow menu | 14:19 |
| t1mp | wait, I forward you an e-mail with a video | 14:19 |
| t1mp | kalikiana: I mailed you a video for the toolbar design | 14:20 |
| t1mp | it has icon scrolling, no toolbar. That's what I'm working on now. | 14:20 |
| t1mp | and if it works well, maybe this pattern will be used in other places also.. so there may be a small chance that it'll replace the overflow panel. | 14:20 |
| t1mp | kalikiana: I could implement it for the actions that are directly in the actionbar now, and later extend it to the overflow | 14:22 |
| kalikiana | t1mp: Right, in that use case there's no overflow. My thought was more precsely that the ActionBarStyle applies to both kinds of action bar, and one of them has overflow. And for example once we have an Action that can be active/selected/checked it could use colors in either the bar or the overflow. In other words, do we re-use the same style, or do we duplicate the properties? | 14:31 |
| kalikiana | Since the overflow is a part of another component it's not obvious how you'd access its StyleHints. | 14:34 |
| t1mp | kalikiana: right. It is in the OverflowPanel. We should make that configurable too somehow | 14:49 |
| t1mp | kalikiana: the overflow panel might have (slightly) different colors than the ActionBar itself | 14:51 |
| t1mp | so if we want properties to configure that, we'd need to add more properties in addition to the foregroundColor and backgroundColor | 14:51 |
| t1mp | kalikiana: but perhaps just to the style in the theme, not in Styles since the ScrollingActionBarStyle has no overflow | 14:52 |
| t1mp | and if the overflow would disappear in the future, we have those unused properties there | 14:52 |
| t1mp | kalikiana: we also have defaultNumberOfSlots, overflowIconName, overflowIconSource and overflowText which would be useless if we drop the overflow panel. | 14:53 |
| t1mp | femma: hello :) | 14:53 |
| t1mp | femma: do you have an opinion on that^? | 14:53 |
| t1mp | kalikiana, femma: I propose to add the foregroundColor and backgroundColor to the ActionBarStyle now, but not to add properties for configuring the overflow.. yet. | 14:53 |
| t1mp | kalikiana: or do you know of a request for that from app developers? | 14:54 |
| kalikiana | t1mp: It's needed for selectable actions, and also section headers, in the overflow | 15:19 |
| kalikiana | That's not new, I'm just bringing it into this context since you're working on the style. | 15:20 |
| kalikiana | Right now that's not going to be dropped, rather the opposite, we need apps to use it once it can support all use cases. | 15:21 |
| kalikiana | t1mp: That's bug 1594281 btw | 15:24 |
| ubot5 | bug 1594281 in ubuntu-ui-toolkit (Ubuntu) "Can't override overflow menu delegate in ActionBar" [High,Confirmed] https://launchpad.net/bugs/1594281 | 15:24 |
| t1mp | oh, right. | 15:25 |
| t1mp | kalikiana: I'm working on a separate style ScrollingActionBarStyle mainly. | 15:26 |
| t1mp | kalikiana: I think we should wait here to see what design says | 15:26 |
| t1mp | which features the overflow should have | 15:26 |
| t1mp | maybe we'll need to expose the full OverflowPanel for the ActionBar, and probably introduce an OverflowPanelStyle too. | 15:26 |
| t1mp | I'm not sure how we can expose that though as part of the style. If we could have something like StyleHints { panel.foregroundColor: "green" } etc that would be cool. | 15:27 |
| t1mp | hmz.. but ActionBar won't always have a style with an panel. | 15:28 |
| t1mp | only the current default ActionBarStyle has it, but the scrolling one won't. | 15:28 |
| t1mp | kalikiana: perhaps we need a separate component for the scrolling ActionBar? | 15:28 |
| t1mp | the thing that we call 'toolbar'... | 15:28 |
| t1mp | but it has the same API, just a different UX/style. | 15:29 |
| t1mp | well we have that with the CheckBox and Switch too. So I guess it is ok to have two components. | 15:29 |
| kalikiana | t1mp: s/won't/doesn't right now/ considering it almost looks like tabs now, which could easily grow a button showing all items ;-) | 15:30 |
| t1mp | kalikiana: what do you think of an ActionBar and Toolbar component? | 15:30 |
| kalikiana | t1mp: I don't agree right now that they are distinct components. | 15:31 |
| t1mp | kalikiana: you imagine an ActionBar that has scrolling AND a panel? | 15:31 |
| t1mp | kalikiana: CheckBox and Switch are different components too | 15:31 |
| t1mp | kalikiana: the styles will need different API. Specifically, the ActionBarStyle needs properties for configuring the panel, and the toolbar does not. | 15:32 |
| kalikiana | t1mp: Well, CheckBox and Switch are identical. The styles are different. | 15:32 |
| kalikiana | Pretty much the same as we have with the action bars | 15:32 |
| t1mp | kalikiana: yes, that's what I meant. But it means that we will have a Toolbar component | 15:33 |
| t1mp | even though the implementation will be Toolbar: ActionBar { styleName: "ToolbarStyle" } | 15:33 |
| kalikiana | t1mp: As I said the "toolbar" almost looks like notebook tabs and could theoretically have a menu button as well. I don't see why that would never happen. | 15:33 |
| t1mp | it is a scrolling list of action items | 15:34 |
| kalikiana | So? | 15:34 |
| kalikiana | If you have 100 maybe you don't want to scroll. | 15:34 |
| t1mp | if it'll have an overflow then we should have just one ActionBar component that can have both scrolling and an overflow | 15:35 |
| t1mp | kalikiana: so, I'll propose for now, | 15:35 |
| t1mp | kalikiana: add foregroundColor and backgroundColor to Styles/ActionBarStyle. Those properties will be useful in any case, | 15:35 |
| t1mp | kalikiana: implement the toolbar only as a separate style in the theme (ScrollingActionBarStyle). No changes (yet) in ActionBar API or in Styles/ActionBarStyle. | 15:36 |
| t1mp | kalikiana: then we and the designers can use the toolbar for a while and see how well it goes, and they can then see if we will unify the ActionBar and toolbar, or they will diverge more. | 15:36 |
| t1mp | perhaps indeed maybe we'll end up with an ActionBar that can have overflow and scrolling at the same time. | 15:37 |
| t1mp | so that means if apps want to use the toolbar, they'll have to put ActionBar { styleName: "ScrollingActionBarStyle" }. | 15:38 |
| t1mp | kalikiana: hmm.. seems like we need 'labs' for the theme ;) | 15:38 |
| kalikiana | t1mp: Hmmm what would happen if we removed the style? Would it fallback to the default ActionBarStyle? | 15:40 |
| kalikiana | In that case it wouldn't be so bad | 15:40 |
| kalikiana | But I don't know off head what'll happen | 15:40 |
| t1mp | if we just remove it it will break I think. But we can easily create ScrollingActionBarStyle that basically links to ActionBarStyle if needed | 15:41 |
| t1mp | kalikiana: right, they have the same functionality, but different UX. | 15:41 |
| t1mp | kalikiana: if the scrolling actionbar becomes super popular it would even be possible to make that the default style and then all headers will have the scrolling | 15:41 |
| kalikiana | t1mp: Sure. My thought was, if we consider this an experimental UX design, and it's not in the public Styles API, and it ends up being dropped, falling back to a regular ActionBar wouldn't break apps. | 15:42 |
| kalikiana | If it's a Toolbar component aliasing ActionBar it's about the same pain as a style alias. | 15:43 |
| kalikiana | Assuming we wind up maintaining it anyway | 15:43 |
| kalikiana | t1mp: So... if we only have a different style, we still end up making it public API, which means it makes no difference in the end. | 15:44 |
| t1mp | why we make it a different API? | 15:45 |
| kalikiana | t1mp: Public, not different. | 15:46 |
| t1mp | only the styles in Styles/ are stable. We can change the APIs in Themes that are not in Styles | 15:46 |
| t1mp | anyway the API can be the same, except for the styleName | 15:46 |
| kalikiana | t1mp: You said it yourself, we'd end up with an alias for the style if we dropped it. | 15:46 |
| t1mp | yes | 15:47 |
| kalikiana | t1mp: The only alternative would be, if it was possible to give a styleName that can fallback to the default if it's missing. | 15:47 |
| t1mp | for the app developer the result would be the same as when we create an alias style | 15:48 |
| kalikiana | Yes | 15:48 |
| kalikiana | t1mp: I'd say let's go Switch style, it's easier for app devs. | 15:50 |
| t1mp | with Switch style you mean introduce a Toolbar component? | 15:59 |
| kalikiana | Yes | 16:00 |
| kalikiana | Same component, different style | 16:00 |
| t1mp | you mean a new component that inherits from the other component. | 16:00 |
| t1mp | for me, same component different style is ActionBar { styleName: "ScrollingActionBarStyle" } while new component is Toolbar { } | 16:01 |
| t1mp | note that if we have a new component we also need to introduce a new ComponentStyle to configure the colors | 16:01 |
| === chihchun is now known as chihchun_afk | ||
| t1mp | kalikiana: I could add the new Toolbar component to Ubuntu.Components.Labs | 16:03 |
| kalikiana | t1mp: That would be nobody can use it right now. Is that what you want? | 16:04 |
| t1mp | they could use it from labs | 16:05 |
| kalikiana | No released app can use Labs. | 16:05 |
| t1mp | then how do we properly test new components? | 16:06 |
| kalikiana | With test cases... | 16:08 |
| kalikiana | If you want to release an app regardless of API changes you must bundle. | 16:08 |
| kalikiana | t1mp: Labs is defined as, can and will break at any time, ergo you can't use it in the stable release of an app. | 16:10 |
| t1mp | actually, | 16:11 |
| t1mp | we have the Toolbar component | 16:11 |
| t1mp | which combines two ActionBars (one for the delete button, and the other one with multiple actions on the right side) | 16:12 |
| t1mp | hmm | 16:12 |
| t1mp | we can just keep that Toolbar, and set the style of the ActionBar that is on the right. | 16:12 |
| t1mp | so the app developer does not even have to set the styleName | 16:12 |
| t1mp | that's basically the Toolbar that we discussed here, but a slightly less thin layer over the ActionBar because it contains the ActionBar, not inherits from it. | 16:13 |
| t1mp | it mimics the API that we have for the PageHeader. | 16:13 |
| t1mp | sorry I forgot about this Toolbar component. | 16:14 |
| t1mp | so I don't need to change any API. Just add the foregroundColor and backgroundColor to the ActionBarStyle. | 16:14 |
| t1mp | and when you're using Toolbar, you will automatically get the scrolling instead of overflow. | 16:14 |
| ahoneybun | ahayzen: I have pictures that I could summit to that contest! | 16:20 |
| t1mp | kalikiana: so I can introduce the ScrollingActionBarStyle (same API as ActionBarStyle), and use that by default in the Toolbar that already exists. | 16:21 |
| ahayzen | ahoneybun, \o/ | 16:21 |
| ahoneybun | I took them on the OPO so legally I can summit them | 16:21 |
| ahoneybun | I have rights on them | 16:21 |
| ahoneybun | right? | 16:21 |
| kalikiana | t1mp: Okay, even simpler | 16:22 |
| t1mp | kalikiana: ok. I'll work on that. I'll first have an MR to add the color properties to ActionBarStyle and a second MR that adds the ScrollingActionBarStyle in the theme and that updates Toolbar to use it. | 16:23 |
| ahoneybun | ahayzen: I'm thinking https://www.flickr.com/photos/44748317@N08/27572569546/in/album-72157669534030306/ | 16:23 |
| ahoneybun | this one | 16:23 |
| kalikiana | t1mp: Sounds good | 16:23 |
| ahayzen | ahoneybun, awesome :-) | 16:23 |
| t1mp | flickr puts ads inbetween the photos now :s | 16:25 |
| t1mp | oh what has become of this world? ;) | 16:25 |
| t1mp | wtf.. and my flickr account disappeared | 16:29 |
| t1mp | I didn't use it for a year or so and I was planning to quit it.. but it is strange that it disappears without contacting/warning me about it. | 16:29 |
| ahoneybun | odd | 16:33 |
| ahoneybun | UT does not scale nicely | 16:35 |
| ahoneybun | wallpapers anyway | 16:35 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| ahoneybun | ahayzen: your mainView.location way does work | 18:02 |
| ahoneybun | but I can't get it to do what I want | 18:02 |
| ahayzen | ahoneybun, \o/ .... /o\ | 18:02 |
| ahoneybun | XD | 18:02 |
| ahoneybun | ahayzen: http://pastebin.ubuntu.com/18185579/ | 18:03 |
| ahoneybun | that's the issue | 18:03 |
| ahoneybun | onClicked needs to set the mainView.location | 18:04 |
| ahayzen | onClicked: { mainView.location = model.id } or model.name or something? | 18:04 |
| ahoneybun | let's see | 18:05 |
| ahoneybun | no wait | 18:05 |
| ahoneybun | locationModel.selectedIndex = index | 18:05 |
| ahoneybun | that picks from the List | 18:05 |
| ahoneybun | I've changed the index thing | 18:06 |
| ahayzen | yup you have like two listmodels IIRC | 18:06 |
| ahayzen | so you could either put one in the mainview instead, or whenever you set the index, ensure that your location property is updated | 18:06 |
| ahayzen | and then make sure it reads the location when it starts | 18:07 |
| ahoneybun | mm | 18:07 |
| ahoneybun | never is simple here with QML | 18:07 |
| ahayzen | heh | 18:07 |
| ahayzen | i would probably have one central ListModel for your locations inside the mainview | 18:07 |
| ahoneybun | well the locationModel is needed to display the API output | 18:08 |
| ahoneybun | I don't want it in the mainview | 18:08 |
| ahoneybun | keep this in the Settings.qml | 18:08 |
| ahayzen | isn't the other page reading from the locations as well? | 18:08 |
| ahoneybun | I can't just have it onClicked and that gets set to mainView.location? | 18:08 |
| ahoneybun | I've removd it | 18:09 |
| ahayzen | yeah you can do that | 18:09 |
| ahayzen | ah ok | 18:09 |
| ahoneybun | I want to keep the main.qml clean of that | 18:09 |
| ahayzen | maybe just do ... onClicked: { mainView.location = model } | 18:09 |
| ahoneybun | use settings.qml to search and set the location then the main.qml will display that | 18:09 |
| ahayzen | and make sure the property in the mainview is like ... property var location; | 18:09 |
| ahayzen | then you'll be able todo mainView.location.name or mainView.location.id etc to get the current one | 18:10 |
| ahoneybun | well you put it as string but I can change it | 18:10 |
| ahayzen | then in the settings page you need it to set the correct selectedIndex when it loads | 18:10 |
| ahoneybun | !!! | 18:11 |
| ahoneybun | well that worked | 18:11 |
| ahayzen | \o/ | 18:12 |
| ahoneybun | mm it is not storing it for the next launch | 18:12 |
| ahoneybun | will need a way to tell the user to go to settings | 18:12 |
| ahoneybun | so city and zip code search works this way | 18:13 |
| ahoneybun | sweet | 18:13 |
| ahayzen | yeah to store it...you'll need to put that location property inside a Settings {} object as we tried before | 18:14 |
| ahoneybun | mm | 18:14 |
| ahayzen | but remember you have something already called Settings so rename the import to like QtSettings | 18:14 |
| ahoneybun | well using a new zip will kinda limit api calls | 18:14 |
| ahayzen | https://developer.ubuntu.com/api/apps/qml/sdk-15.04.5/Qt.labs.settings.Settings/ | 18:15 |
| ahoneybun | popey: your site is down | 18:15 |
| ahayzen | but do like "import Qt.labs.settings 1.0 as QtSettings" ... and then QtSettings {} | 18:15 |
| ahoneybun | in the Settings.qml | 18:15 |
| ahoneybun | ? | 18:16 |
| ahoneybun | oh | 18:17 |
| ahoneybun | mm QtSettings cannot be used as a type | 18:18 |
| ahoneybun | ahayzen: I might have to start making a Icon finally lol | 18:20 |
| ahayzen | hehe :-) | 18:20 |
| ahayzen | ahoneybun, i mean to store your mainView.location you could use the Qt.labs.settings for that... anyway gotta run | 18:20 |
| ahoneybun | thanks | 18:21 |
| ahoneybun | mm my Nexus 7 does not want to work with the SDK | 18:31 |
| ahoneybun | but the N4 does | 18:31 |
| ahoneybun | seems it is not adding the Kit right | 18:32 |
| ahoneybun | mhall119: ping | 19:49 |
| ahoneybun | https://github.com/ahoneybun/uCycle/blob/master/uCycle/uCycle.png | 19:49 |
| ahoneybun | ^ | 19:49 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
