Simon McVittie made 5 (and actually his 5 first ever) nice commits regarding how Gnome Shell was managing CSS. These will bring some minor performance improvements. He also fixed a bug that delays Gnome Shell Calendar to open for first time.
Use pre-split element classes and pseudo-classes to optimize matching | #687465
In my testing this cuts the longest time to dispatch(), when showing the calendar menu for the first time, from 604 to 442 milliseconds, while reducing additional_selector_matches_style() from 32% to 13% of CPU time used.
Keep similar theme nodes so we don’t have to recompute CSS so often | #687465
Because we calculate and cache CSS properties once per StThemeNode, and only a certain set of attributes can affect the CSS properties, it’s advantageous for as many widgets as possible to share a single StThemeNode. Similarly, if a widget changes state and then changes back (e.g. gaining and losing the :hover pseudo-class), it should ideally get its original StThemeNode back again when it returns to the old state.
Here, I’m using the StThemeContext as the location for a cache. StThemeNodes are currently never freed: this seems OK for Shell’s usage (a finite number of IDs, classes, pseudo-classes and types).
Friends of Gnome Campaign
It has been around one year since the last Gnome campaign for Accessibility that Gnome raised $20k. So the discussions begin for a new campaign.
Juanjo Marin proposes about WebKit2GTK+
I think that what we need to make a FoG campaign for WebKit2GTK+ is a super feature that makes the difference for GNOME, even better if you can use in several parts of the desktop. Maybe Tobias Mueller idea of Privacy and Security can be this super feature.
Oliver Prost is more specific to Web:
Some features I come to think about that would be exiting to users are (not only including WebKit2GKT+)
Work With Theme Authors
This is something it really does worth to read.. Mike (a Gnome App Dev) opens a bug (#687752) about the incompatibilities between GTK versions. The discussion then goes to Gtk-List. Emmanuele gives some reasoning behind that and Otte makes an analysis about the state of GTK3.
(Important disclaimer: I am now stating the de-facto situation, not the situation I wish for. But I think naming – and accepting – the status quo is an important first step.)
GTK 3 at this point really is just the GNOME toolkit. There is absolutely zero involvement from anyone else. Neither XFCE nor LXDE nor Windows or OS X developers take any interest in pushing the toolkit forward – apart from occasional bug reports and patches. All features are prototyped, coded and maintained by GNOME developers. So in its current state I would call GTK a part of GNOME. It’s worth pointing out that this was basically the same situation with GTK 2.
The first conclusion from that is that it is (and has been for a few years) a bit disingenuous if people say “we’re not using GNOME, we’re just using GTK”. XFCE, LXDE, Mate etc (even Unity) are just different panels and apps built on top of technologies driven and developed by GNOME developers. (You could include not just GTK but also glib, Cairo, NetworkManager, and probably even X, GStreamer and systemd to an extent in those technologies.)
Where this all gets interesting is the transition in mentality and behavior (for lack of a bettter word) of the GNOME development community in the transition from GNOME 2 to GNOME 3. GNOME 2 development was a steady process with a clearly defined goal. Almost everything was static. As such, nothing ever really got different. If anything, it gained more features or changed a default value. Sure, occasionally there was a hickup, but in general everything was obvious. If I had to describe it with an image, I’d use http://i.imgur.com/TXzZh.jpg GNOME 3 is (it didn’t start out to be, but quickly transitioned into) an experiment. People don’t know how GNOME is gonna look in 3 years. Or even what hardware it’s going to run on. What are the minimum system requirements? Nobody knows. Goals, design, code and APIs keep changing all the time. The obligatory image I’d use to describe it is http://i.imgur.com/ysSK3.png
Now what does that mean for you or me working with GNOME 3 (or GTK 3)? It means they can’t rely on things staying the same or having a stable base to build on.
Things keep changing. You can’t just write something for 3.0 (be it an application, a shell plugin or a GTK theme) and expect it stay working that way forever. Instead you need to constantly improve on your work. There’s one important thing to note about this however. If you participate in this process – like a bunch of applications do – you get two things:
(1) You get the help of the GNOME developers. People are generally interested in your use cases and want to make your life easier and better.
(2) You get to influence the direction of development. You can request features that you are missing and can expect help to get them implemented.
However, you also lose your independence to do whatever you want and you get to compromise on your vision. Which is why at this point in time I’d advocate against Mozilla, Libreoffice, XFCE or LXDE to switch to GTK 3. They value their independence from GNOME too much.
Now what does that mean for theme developers? And how can we improve the situation? I don’t know really. An important step is agreeing that what I’ve written above is the status quo and communicating that. I think that would help a lot of people (both the people developing on top of GNOME/GTK 3 and the regular haters that comment on all the articles appearing about it). It would also set the expectations right about what you’re going to get into. It’s not just about changing 5 colors and 3 settings in a gtkrc file anymore to get a new theme that’ll work until eternity.
I think what we shouldn’t do though (and you seem to be advocating it in your mail) is care too much about backwards compatibility. Sure, it’s nice to be backwards compatible where we can. But no, we shouldn’t try too hard. That slows us down too much and then we can’t experiment quickly anymore. And so far, that’s what we want. Backwards compatibility is a huge time sink.
This is all well and good. It’s certainly not where we (read: I) would like to be, but it’s a pretty accurate summary at this point.
I would disagree with you on backwards compatibility, slightly. I think we shouldn’t try too hard, but we also now have a clear goal for theme authors: standard CSS. We should obey the goals of the standards, and follow their guidelines about vendor prefixes. When we implement CSS features, we should try to implement them to the letter of the spec, not half-ass it, and if it’s not ready, put a vendor prefix behind it.
That’s a guarantee I think we can make for now, which should help signify to theme authors that their work is as volatile as CSS itself.
Obviously, we won’t be able to make this guarantee everywhere: the margin/padding/border scenario is a gigantic mess, and it’s this weird hybrid box system that some things respect but others don’t. I’m fine with breaking this between releases, as long as what we release is moving towards the CSS standard in what we implement.
You should read all the threads to have a more complete view. Personally I don’t find backward compatibility so important. Breaking API is quite usual in Web Apps Development (that is the 90% of devel worldwide?), and none is complaining. Rails,(Node, Joomla etc) breaks API every 3 months, but I don’t see people to yelling at Rails forums :)
*** Same day (that’s yesterday) Otte committed about 2 dozens patches in GTK :)
This is one bad new. Gnome Videos App won’t come -at least in 3.8. Bastien Nocera confirmed that he will evolve Totem into Gnome Videos rather than writing a new application from scratch.
I guess that Totem will have a facelift in 3.8 release, but any patch hasn’t arrived yet.
JHBuild is maybe the most active module in Gnome at the moment. Everyone is committing on it. You can get the latest Gnome easy without harming your system. My advice is to install it to a new user account, so always have a Gnome upstream account. You can read more about JHBuild in Gnome Live.
Ooh, although JHBuild developed originally for Gnome many 3rd party projects are using it. Is the easiest way to build software over unstable libraries.
New lessons, new students. One of the most successful Gnome Projects. Gnome University will teach you C and it will introduce you in Gnome development. Experience in C isn’t required and you can join at any time. You will get more info in a previous post or in Gnome Live.