wip/apocalypses/apocalypse-1
hi everyone; • executive summary (for those who know what I'm talking about already): after spending the last 2 weeks testing it with any random piece of code I could come up with, I feel confident enough to land the apocalypse-1 branch into master. I could not port complex, multi-dependency application code like St and gnome-shell — mostly because of -Werror usage and all-or-nothing porting — but I can definitely help out with the porting process. porting would also allow giving feedback on the API before the 3.4 freeze, so please: give as much feedback as you can *now*, because complaining *later* will not do much to endear you to me. • longer explanation (for those who don't know what I'm talking about): the wip/apocalypses/apocalypse-1 is the translation into API of the first Apocalypse document that has been on the wiki for more than a month: http://wiki.clutter-project.org/wiki/Clutter/Apocalypses/Apocalypse1 it details how I want to transition the Actor API from 1.x to 2.x, and introduces a series of API additions and deprecations that anyone dealing with Clutter has to be aware of. the transition can be broken down into various pieces: - All children API is in ClutterActor the Actor class has API to add, remove, and replace child actors, as well as iterate and mutate the list of children. this API was already there internally, but now it has been extended and exposed. the old set_parent(), unparent(), and reparent() API has been deprecated, as well as raise(), raise_top(), lower(), and lower_bottom(). the API has been cleaned up as well, so it's more rational and less of a copy of gtk+'s bad patterns. ClutterActor's API for iterating over the children list is DOM-like, and should allow you to efficiently track first/last children, insertion, appending, prepending, and other things that with the current API require a copy of a GList and an iteration over it. - ClutterContainer only deals with the children properties API add, remove, foreach, raise, lower, and sort_depth_order are deprecated vfuncs; Container will provide a default implementation for those vfuncs, which defer to the Actor API. - Implementing Actor and Container ClutterActor implements the ClutterContainer interface by default. if you have an actor that implements the Container interface most likely you can drop every custom Container vfunc implementation and the actor class will behave exactly the same. - Actor can be instantiated the base Actor class now knows everything there is to know about its children, so there is no need for it to be abstract any more; a ClutterActor instance behaves like a ClutterGroup by default, and if you don't override the paint() virtual function (or if you chain up) the default implementation of it will automatically paint the Actor's children. the ClutterGroup API has been deprecated — the type, sadly, is needed for ClutterStage. - Layout managers given that ClutterActor implements ClutterContainer, it's now possible to defer any Actor that has children to use a LayoutManager instance. this means that ClutterBox has been deprecated. - Subclassing ClutterActor all the changes above allow you to avoid subclassing ClutterActor except in special circumstances — essentially only if you have a special paint sequence. it is strongly recommended to chain up to the newly added default implementation of the paint() virtual function — though it's still entirely possible to just implement iteration over the children using the Actor API. there are other additions in the branch, like the background color property for each Actor (which allows us to deprecate ClutterRectangle); the margin properties; and the horizontal and vertical alignment for children. all in all, ClutterActor should become more rational, more easily usable out of the box, and reduce the amount of subclassing needed to make Clutter work. again, feedback from application developers is most welcome, but please: read the wiki first. ciao, Emmanuele. -- Emmanuele Bassi, Intel Open Source Technology Center ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: wip/apocalypses/apocalypse-1
On 01/10/2012 12:13 PM, Emmanuele Bassi wrote: - Implementing Actor and Container ClutterActor implements the ClutterContainer interface by default. if you have an actor that implements the Container interface most likely you can drop every custom Container vfunc implementation and the actor class will behave exactly the same. Good to see that implementing the container stuff on CallyActor made sense. Thanks for update also CallyActor code. Once the branch is merged I will try to remember to remove the container implementation notes, as they would become obsolete. - Actor can be instantiated the base Actor class now knows everything there is to know about its children, so there is no need for it to be abstract any more; a ClutterActor instance behaves like a ClutterGroup by default, and if you don't override the paint() virtual function (or if you chain up) the default implementation of it will automatically paint the Actor's children. the ClutterGroup API has been deprecated — the type, sadly, is needed for ClutterStage. I guess that the same applies to CallyGroup. Right now I could reduce/nuke most of that implementation, but I would require to keep CallyGroup type to avoid a ABI breakage (as right now CallyStage is a CallyGroup). Right? - Subclassing ClutterActor all the changes above allow you to avoid subclassing ClutterActor except in special circumstances — essentially only if you have a special paint sequence. it is strongly recommended to chain up to the newly added default implementation of the paint() virtual function — though it's still entirely possible to just implement iteration over the children using the Actor API. there are other additions in the branch, like the background color property for each Actor (which allows us to deprecate ClutterRectangle); the margin properties; and the horizontal and vertical alignment for children. all in all, ClutterActor should become more rational, more easily usable out of the box, and reduce the amount of subclassing needed to make Clutter work. Is there any tentative list with the ClutterXXX planned to be deprecated? BR -- Alejandro Piñeiro Iglesias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: UI design
On 01/09/2012 04:29 PM, Benjamin Otte wrote: Hey, Here's another discussion point I want people to think about before the hackfest. This time it's not so much about API in a direct way but more about a guiding principles for the kinds of APIs we want to provide. The short question is this: Who gets to decide how an application looks? This question is aimed at theming and the question of graphic design[1] and not at intersection design[2]. The way I see it, there is two extremes to this: A) The application decides on the theme B) The platform decides on the theme C) the user decides on the theme. Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: UI design
On Tue, Jan 10, 2012 at 08:16:53PM +0100, Stefan Sauer wrote: On 01/09/2012 04:29 PM, Benjamin Otte wrote: Who gets to decide how an application looks? This question is aimed at theming and the question of graphic design[1] and not at intersection design[2]. The way I see it, there is two extremes to this: A) The application decides on the theme B) The platform decides on the theme C) the user decides on the theme. D) External constraints define the look. So you like dark pink background. Does it mean the PDF viewer should try to give the viewed documents dark pink background? Such question might sound silly in case of PDF viewers but I develop mainly scieng apps and here the boundary between controls and content is often much fuzzier. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: UI design
On Tue, Jan 10, 2012 at 2:25 AM, Benjamin Otte o...@gnome.org wrote: 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. (sorry for late reply ;-)) Yes that is a good point, when you write a GTK+ application for a dedicated device, of course you control the platform so essentially this distinction is moot. 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. Ok here is a good example of a problem we need to solve and I think I have a decent idea of the direction we need to take to solve it. Essentially: we need a way to make things absolutely clear when it comes to communicating the application's needs to the theme. One problem IIRC was that GTK+ theme had been overriding explicitly set toolbar style, I think that the current solution is that if the user sets a toolbar style, GTK+ theme will not override it, giving application developers the opportunity to use GtkToolbar widget in different portions of their application than up at the top as what we commonly refer to now as the main application toolbar. Now it's kind of assumed that application developers should not override the toolbar style for the main application toolbar because this configuration should follow the desktop settings etc. For the case of the toolbar, this is working fine enough IMO. Now a problem we currently have in Glade/gedit, is that we absolutely need to override the padding of a GtkButton which we place into the notebook tabs with a stock rendered 'X' icon. This is a more difficult issue because GtkButton can be used in many different contexts, it's easy to say that a GtkButton which is placed into a GtkButtonBox should have a certain appearance... and then application developers have the choice to pack the button into something different than a GtkButtonBox if they need to escape the implied theming consequences, but it's completely inappropriate to say that theme writers should start to theme the GtkButton differently if it's somewhere in a notebook tab, or elsewhere. There are possibly a few approaches to address this problem: a.) Introduce some sort of role attribute on widgets which allow theme writers to base their theming on a specific role for which the widget was indented by the application developer. This is a bit undesirable because roles could quicky become too many in number and hard to control, every apps needs can be different after all. b.) We could consider white-listing specific widgets for theming, perhaps even if it only goes as far as padding and alignment white listing For instance, a GtkButton would receive the regular theme attributes but only a GtkThemedButton would be effected by spacial attributes from the theme (i.e. this would become the law for theme writers). Option b.) makes a lot of sense when it comes to composite widgets such as GtkInfoBar, GtkButtonBox children etc, then we get grey area around widgets like GtkProgressBar (again, I need to put those in notebook tabs, I dont want theme writers to muck about with the padding/alignment of progress bars in my notebook tabs, but perhaps the padding and alignment should be assigned for the progress bar which is specifically inside a GtkProgressDialog or GtkProgressWidget or GtkThemedProgressBar or such). If application developers dont want to be theme effected at all for some widgets, then they should obviously write their own derived widgets and simply implement GtkWidgetClass-draw() in their
