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