Go forward in time to April 2014.
- Tue 2014/Mar/25
-
Today I've released GNOME Web 3.12. This release is fantastic — the result of a collective effort of GNOME developers, designers, contributors, and of the excellence that WebKitGTK+ 2.4 provides. I've usually felt pretty excited with Web releases —result perhaps of Stockholm syndrome, you'd say— but, quite frankly, I believe that anyone who has tried Web during this development cycle will agree with me that we're reaching a milestone in user-experience and maturity of the project that is far beyond anything we've done in the past. That's why I feel particularly proud of our achievements and confident that you'll love Web, too. But enough with the preamble, let's see what's new in this release.
-
One process per tab, for improved stability and responsiveness: Ever since Web started using WebKit2, we've had an architecture that allowed us to split the application into different processes. One of these processes, the so-called Web process is the one in charge of handling the web content, and is split from the Epiphany process. The advantage of this model is that, shall the web content or bugs in the JavaScript engine cause a crash, the UI will not be affected. Unfortunately, up to Web 3.10, this one web process was shared among all tabs and windows, so that a crash caused by one page would lose you all the pages in the browser.
But since Web 3.12, and thanks to the impressive effort of the WebKit team that Carlos has led, we've moved to a different process model. One process per tab means that every tab in the browser will have its own web process, so that no unresponsive or crashing tab will have an impact on the rest of the browser. This feature is configurable, for those who might want to opt out.
-
A new and modern location/title headerbar: With the last release we started leaning in a bold direction by displaying only the location entry and getting rid of the title bar. Not everyone was immediately pleased with this choice, as for some people being able to see the page title is also important. After several rounds of design discussion, and thanks to the tireless Yosef, we finally merged a major change to the UI, which now includes a headerbar that displays the page title and location, and turns into the location entry on click or whenever the page is loading. The result is beautiful, see it by yourself!
-
The overview has been turned into an HTML page: Loren did a great job transforming the existing GtkIconView/GtkListStore- based overview into a dynamic HTML page. The advantages of this, besides serving of a good test case for UI/Web process communication and letting us getting rid of thousands of lines of code, is that the overview becomes an easily themable and animatable HTML document. Thanks to this, in no time Jakub came up with a beautiful style:
-
Most dialogs have been cleaned up and revamped: This was a result of the work started by Jon during the WebKitGTK+ hackfest. History, passwords, cookies, and other dialogs have a new face, and they all look pretty much as you'd expect from a GNOME 3.12 application.
-
The incognito mode has also received a facelift: Thanks to Jon, instead of using the dark theme variant, we now have proper theming for incognito windows.
-
Now you can configure your search engine from the preferences: Despite the popularity that DuckDuckGo has among our users, there are still people who would rather use a different search engine. Michael Catanzaro has contributed with an addition to the preferences dialog that allows users to choose the search engine they prefer, without having to resort to change their gsettings manually.
-
Many other UI improvements: including several fixes to the Downloads bar, beautiful tabs, and improved style of our about: pages.
-
And more! the gnome-shell search provider now runs in its own process, HTTPS is used by default during searches from the location entry, the user manual has been updated, and many, many, many bugs fixes, code cleanups, and other minor improvements have been made all over the place!
As you can see, Web is shinning. But this wouldn't have been possible without the effort of all the people I have mentioned already and many more. Without your patience, contributions, and above all, love for GNOME and Web, this release wouldn't be half as good as it is. Thank you all!
And to our loyal users, all that is left to say is that you can rest assured that all of this will be soon knocking at your door, when the GNOME 3.12 release sees the day later this week. We hope you'll enjoy Web and GNOME as much as we enjoyed working on it!
-
- Mon 2014/Mar/24
-
Saying that external contributions to GTK+ are not so welcome is drawing a slightly short-sighted conclusion out of more complex dynamics, as the ones that govern GTK+ development, or any complex free software project, for that matter. Nonetheless, it rises an interesting question.
The truth of the matter is that dozens of patches to GTK+ get submitted in a daily basis, the GTK+ team is rather small, and it's pretty easy for maintainers to overlook some of these contributions.
But why then is it so that GNOME developers have an easier time at getting their patches in, as Olivier points out? The simplest answer to this is that, unsurprisingly, GNOME developers are hanging around in the same communication channels as GTK+ developers, usually communicate with each other in a daily basis, even if they're not working exactly in the same codebase. This closeness makes any direct request for feedback to patches pretty straightforward. Sometimes just asking for a quick review in IRC gets your patch approved in a couple of minutes.
With this in mind, it is easy to see that anyone who considers themselves to external to GNOME will probably have a harder time getting their patches in. A humble suggestion? Hang around IRC, make yourself familiar with the people who might be able to review your patches, and don't hesitate to ask for feedback to them, specially if you think that your patches are simple to review (as the ones Olivier references). This might not work 100% of the time, but surely, not only your contributions will find an easier way in, but also you'll be helping to avoid filling bugzilla with unreviewed patches.
In a larger scale the conclusion that close communication, in the context of a software project, can improve the development process is a rather obvious one. I think one needs to keep this in mind when dealing with projects whose communication channels are open to everyone.
Go backwards in time to February 2014.