[13:07] <kalikiana> Kaleo: Commented here, just wondering if there's any way for QA to watch for problems here https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/enable_atlas_textures/+merge/298770
[14:09] <t1mp> kalikiana: hello :)
[14:09] <t1mp> kalikiana: I have an MR for you https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/ActionBar-colors/+merge/299052
[14:09] <t1mp> kalikiana: that is a pre-requisite for my toolbar re-write (which will have a new design with scrolling of icons)
[16:57] <kalikiana> t1mp: Commented
[18:39] <t1mp> kalikiana: thanks.
[18:39] <t1mp> kalikiana: the background color of the icons is normally the same as the bg color of the actionbar/header.
[18:40] <t1mp> kalikiana: except when it is pressed
[18:40] <t1mp> kalikiana: if I rename the pressedBackgroundColor to pressedButtonBackgroundColor, it is okay?
[18:40] <t1mp> indeed that is more clear
[19:22] <kalikiana> t1mp: Will it always be the same? It seems like an arbitrary choice based on the default theme...
[19:22] <kalikiana> t1mp: Btw ready for review https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/listsAndNameSpaces/+merge/299048
[19:23] <t1mp> kalikiana: you mean will the background of an unpressed button and the header/actionbar always be the same?
[19:23] <t1mp> the designs just show an icon. I don't want to add more properties because there are speculations that someone could have additional colors ;)
[19:23] <t1mp> but additional colors can be accomplished by setting a custom delegate instead of using the default one from the theme
[19:24] <kalikiana> t1mp: Yes. What if someone creates a theme with distinct button colors?
[19:24] <t1mp> defaultDelegate: Button { color: "pink"; action: modelData }
[19:25] <kalikiana> t1mp: That's in the app, not the theme.
[19:25] <t1mp> that's in the theme
[19:25] <t1mp> in ActionBarStyle
[19:26] <kalikiana> Well, if that's in the theme it only works depending on the color set in the app.
[19:26] <t1mp> but yeah, you could also set delegate: Button { color: "pink"; action: modelData } in the app :)
[19:26] <kalikiana> t1mp: We have no code checking that foreground and background are distinguishable here afair
[19:27] <t1mp> we don't have that anywhere
[19:27] <t1mp> kalikiana: are you proposing that we should have unit tests that check that all the components have proper color contrast?
[19:28] <kalikiana> That wouldn't help, my point is the colors can break at runtime if you can't have pairs for all values.
[19:28] <t1mp> it would be a fun exercise, but given the amount of work that it would be I think we could finish more useful stuff in that time.
[19:28] <kalikiana> We *know* what the default theme looks like, so no point in testing that.
[19:29] <t1mp> kalikiana: right. And people can mess it up by overriding the default theme.
[19:29] <t1mp> what's the problem? some people may have bad taste in colors, it is not up to us to judge that ;)
[19:31] <kalikiana> t1mp: Very clear example: high contrast theme with black and white buttons.
[19:32] <t1mp> kalikiana: ok, you'd set backgroundColor: "black"; foregroundColor: "white". But what do you want for the pressedButtonBackgroundColor?
[19:32] <kalikiana> The only way to make it work with the so far proposed values would be to ignore all the app-supplied colors.
[19:33] <kalikiana> t1mp: Also disabled
[19:35] <t1mp> I still don't understand what you try to accomplish
[19:36] <t1mp> with only black and white as colors you cannot have different values for foreground/background/pressedBackground/disabledForeground
[19:38] <kalikiana> t1mp: I didn't say exclusively black and white, I said buttons that are black and white.
[19:38] <kalikiana> The point being the foreground colors may be wrong.
[19:39] <kalikiana> If the app uses black or white as a foreground color it won't be usable
[19:40] <t1mp> maybe it is getting late, but I still don't understand what you want :)
[19:40] <t1mp> yes you can set the button background to be white in the theme, and if in the app you make the button foreground white, then you don't see anything
[19:40] <kalikiana> t1mp: Imagine enabled buttons are white on black, disabled buttons are black on white - whatever the app sets is not going to work well
[19:41] <kalikiana> So right now we're restricting themes to do what the default theme needs
[19:42] <t1mp> ok, right.
[19:43] <t1mp> so you're saying that Styles/ActionBarStyle is not flexible enough for some things that you may implement in a theme
[19:43] <t1mp> well, you could set the defaultDelegate in the theme so that you get the result you want.
[19:43] <kalikiana> Yes. It's tailored to support the default theme.
[19:43] <t1mp> but if that is a real use case then it would be handier to have a property in the style for ti
[19:44] <t1mp> *it
[19:45] <t1mp> we cannot take all possbile themes into account. What if someone wants a theme where the button background has a gradient ;)
[19:45] <t1mp> I'm not saying we should never implement what is not in the default theme. We'll have to find a balance somewhere.
[19:45] <t1mp> in this case the API will seem more consistent if we have foregroundColor, backgroundColor, buttonBackgroundColor, pressedButtonBackgroundColor
[19:46] <t1mp> hmm..
[19:46] <t1mp> but then for the header we need to make a distinction between titleForegroundColor and buttonForegroundColor too?
[19:46] <kalikiana> I'll argue the problem is that the style is a hybrid of different components. Just like having the overflow part of the component was the problem in the other discussion.
[19:46] <kalikiana> In this case it's colors of the 1) bar 2) button.
[19:47] <t1mp> and also buttonForegroundColor and pressedButtonForegroundColor...
[19:47] <kalikiana> I'd love to suggest a grouped property alas objects aren't allowed here.
[19:48] <t1mp> kalikiana: so how can we avoid that?
[19:48] <kalikiana> We need *some* way to distinguish sub components eventually.
[19:50] <t1mp> how do we do grouped properties?
[19:51] <kalikiana> property Object button: Object { property color foreground }
[19:52] <kalikiana> Except that's not supported by Stylehints
[19:53] <t1mp> right, making it available via StyleHints was part of the goal.
[19:53] <t1mp> still, in a theme you can always change the defaultDelegate to use whatever colors you want.
[19:54] <t1mp> I think I'll have to think about it tomorrow, I'm getting sleepy.. :s
[19:54] <kalikiana> As in, ignoring the app colors completely?
[19:54] <kalikiana> Or you mean the app's theme... okay, now I'm also getting lost
[19:55] <kalikiana> We can mumble tomorrow
[19:55] <t1mp> yes, the app's theme. Still in the theme you have access to all the properties that are set on the component itself.
[19:55] <t1mp> yeah, let's do that.
[20:42] <ahoneybun> anyone good with dealing with a lot of json?
[21:12] <kalikiana> ahoneybun: What does that mean? 1GB of data? Or 10000 rows in a model?