| === 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_ | ||
| 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 | 13:07 |
|---|---|---|
| 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) | 14:09 |
| === chihchun is now known as chihchun_afk | ||
| === JanC is now known as Guest28478 | ||
| === JanC_ is now known as JanC | ||
| kalikiana | t1mp: Commented | 16:57 |
| 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:39 |
| 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 | 18:40 |
| 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:22 |
| 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:23 |
| kalikiana | t1mp: Yes. What if someone creates a theme with distinct button colors? | 19:24 |
| t1mp | defaultDelegate: Button { color: "pink"; action: modelData } | 19:24 |
| kalikiana | t1mp: That's in the app, not the theme. | 19:25 |
| t1mp | that's in the theme | 19:25 |
| t1mp | in ActionBarStyle | 19:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| kalikiana | t1mp: Very clear example: high contrast theme with black and white buttons. | 19:31 |
| 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:32 |
| kalikiana | t1mp: Also disabled | 19:33 |
| t1mp | I still don't understand what you try to accomplish | 19:35 |
| t1mp | with only black and white as colors you cannot have different values for foreground/background/pressedBackground/disabledForeground | 19:36 |
| 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:38 |
| kalikiana | If the app uses black or white as a foreground color it won't be usable | 19:39 |
| 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:40 |
| kalikiana | So right now we're restricting themes to do what the default theme needs | 19:41 |
| t1mp | ok, right. | 19:42 |
| 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:43 |
| t1mp | *it | 19:44 |
| 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:45 |
| 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:46 |
| t1mp | and also buttonForegroundColor and pressedButtonForegroundColor... | 19:47 |
| kalikiana | I'd love to suggest a grouped property alas objects aren't allowed here. | 19:47 |
| t1mp | kalikiana: so how can we avoid that? | 19:48 |
| kalikiana | We need *some* way to distinguish sub components eventually. | 19:48 |
| t1mp | how do we do grouped properties? | 19:50 |
| kalikiana | property Object button: Object { property color foreground } | 19:51 |
| kalikiana | Except that's not supported by Stylehints | 19:52 |
| 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:53 |
| 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:54 |
| 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. | 19:55 |
| ahoneybun | anyone good with dealing with a lot of json? | 20:42 |
| kalikiana | ahoneybun: What does that mean? 1GB of data? Or 10000 rows in a model? | 21:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!