On Mon, Jan 9, 2012 at 5:40 PM, Tristan Van Berkom <t...@gnome.org> wrote: > I think the first thing we have to keep in mind is that while well-known > use cases of GTK+ are in the domain of "desktop applications" there > is a great deal of use cases that are not tied in to desktop environments > (be they, mobile desktops or laptops or other generalized personal > computing devices). > Keep in mind that those kiosk or other embedded applications themselves are the platform though. So for those cases, the distinction does not matter. It doesn't even matter if you have multiple applications if you still control the design of all of them (you can do sth like http://git.gnome.org/browse/gnome-themes-standard/tree/themes/Adwaita/gtk-3.0/gnome-applications.css to the system theme). It only gets interesting once you want to allow external developers to integrate with your platform.
> Application developers obviously have a stronger say, they can: > - augment the theme experience by adding their own css > on top of whatever is running underneath > Keep in mind that if your application wants to "extend" the desktop theme and the desktop theme can be changed by users, these extensions must work with any theme, including future themes that do not exist yet. So you must make your widget integrate well with any color, padding, size and so on. And from my experience most custom CSS already fails when using the dark theme, let alone the a11y ones. I would actually go so far as to say every call to gtk_widget_override_*() is broken if you don't control the theme. > In the end I think that application developers will always find > a way to circumvent an installed theme, so it makes no sense > to make their life harder and force desktop installed css to > be pushed into their app. > Well the problem is not that developers can't do things, the problem is how we treat developers that do those things. When we change things in themes (like we did with Clearlooks during GNOME 2.x), do we blame the application authors for their attempts to override things or do we expect the theme designers for their carelessness in not making sure that their new theme works with every override in every application, including the ones that are closed source? > Possibly not, actually it should be much easier to set hard values for > colors and borders and such without needlessly mucking about with > CSS parsing, certainly if the intended result is only "set the background > red and have a zero width border", then it should be much more > efficiently doable by calling gtk_widget_set_background() and > gtk_widget_set_border_width() directly. > The thing about providing convenience APIs is always this: If you provide the API, people will use it. The ease of something is always a good indicator about if it is expected of developers using this API to do that kind of thing. Setting the text on a label is something we expect people to do. A lot. So there is gtk_label_set_text() to do this. We however do not expect developers to set icon used for drawing the sort indicators on tree view columns. Which is why there is no gtk_tree_view_set_sort_indicator_icon() API. While it is very clear-cut for these two APIs, this question is less clear-cut for widget styling. Because if we provide a very visible gtk_widget_set_background() function, we encourage developers to use it. And for that function to work well, we need to make sure the foreground and potential borders are still visible and the widget doesn't look out of place. Because if that happens people will rightfully tell us "GTK sucks". And I cannot guarantee that this function works well (as pointed out above) if it has to work with a light theme, a dark theme or any random theme downloaded from the internet, because - for a start - I don't even know which foreground color will be used. Benjamin _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list