PlanetGNOME

For a long time now, fellow-Gentoo’ers have had to edit /etc/asound.conf or ~/.asoundrc to make programs that talk directly to ALSA go through PulseAudio. Most other distributions ship configuration that automatically probes to see if PulseAudio is running and use that if avaialble, else fall back to the actual hardware. We did that too, but the configuration wasn’t used, and when you did try to use it, broke in mysterious ways.

I finally got around to actually figuring out the problem and fixing it, so if you have custom configuration to do all this, you should now be able to remove it after emerge’ing media-plugins/alsa-plugins-1.0.25-r1 or later with the pulseaudio USE flag. With the next PulseAudio bump, we’ll be depending on this to make the out-of-the-box experience a lot more seamless.

This took much longer to get done than it should have, but we’ve finally caught up. :)

[Props to Mart Raudsepp (leio) for prodding me into doing this.]

TLDR: GTG 0.2.9 has been released, spread the word!.

For those who don't know Getting Things GNOME yet, it is a todo manager. In fact, it is, to my knowledge, the only todo manager that :

1. has a clean and simple UI (see my French explanation to use GTG)
2. allows you to have infinite level of subtasks
3. to have the same task being the subtask of multiple parents
4. to easily classify your tasks with colours and tags
5. allows you to see only the task that can be done right now with the concept of workview
6. allows you to quickly enter a lot of tasks in a few keystrokes
7. has a DBus interface

As a result, gtg was in the Techradar's top 50 best Linux application of 2011 despite the lack of regular releases. It is probably packaged as "gtg" in your distribution so it is probably better that you try by yourself.

For the last year, I've been often asked if GTG was dead, if we planned to release something new.

This is my fault and I apologize for such a long dead time. I could explain you all the oddities GTG went through but it is not interesting. I will talk you a bit more about the solution we created when the liblarch documentation will be finished. The good news is that GTG is not dead and that we have been actively working on it in the last two years, including some wonderful GSoC.

Izidor, my GSoC student, is now the co-maintainer of GTG and released 0.2.9 today. Last week, he came from Germany to Belgium to sleep with my cat, enjoy the Frozdem (Frozen Fosdem) and, as a side effect, polish all the little details that would make 0.2.9 a rocking release.

Why 0.2.9 ? That's the bad news part! Mainly because the "backends" feature, which allows you to store/retrieve your task from an external source, is still very unstable and most of the backends had to be disabled for the release. But don't worry, we want to stick to a much shorter release cycle and bring a polished 0.3 in a few weeks. I hope I will learn from mistakes of the past.

Nevertheless, let's celebrate the first release in nearly two years. Please share the news, package GTG, report bugs, help us, follow us on G+ and spread the word.

By the way, we are looking for a communication manager/webmaster and a Django/CSS/JS hacker to work with us on a GTG web interface. If you want to join a cool project with an insane potential, contact me!

My transition from a GNOME user to a developer has been in progress for two months now. I’m enjoying the challenges, but one constant annoyance has been bothering me along my journey:

The transition from user to developer seems to assume that in between I have had time to hack Linux for 10 years.

Well, I had a total of 0 days for that. I have grown up with the pleasure of not needing to know all the mysterious commands in terminal to get my Ubuntu running. Yes, I have memorized a couple of handy ones (killall -9 the programs!) but as a whole I’m a GUI-girl. I love to make small apps for myself to use, I like coding, but still without the OPW I would have given up already. For me the stumbling block is that the leap from user to developer is huge!

The thing that prompted this post was the setup for JHBuild. I felt uncertain and there were many things I wouldn’t have dared to do without the help of a friend. My dream would be to able to concentrate to the main thing itself with necessary information available without the presumption of being a hardcore Linux hacker.

There is need for both kinds of documentation: for those who are familiar with every nook and cranny of GNOME and Linux, and for those who have just had the great idea that they could have something to give to this community. I’m working towards my dream of having the latter, and I hope my documentation efforts will make this path easier for the enthusiastic hackers that come after me!

See you soon in Brno!

One of the new configuration files systemd introduced is /etc/os-release. It replaces the multitude of per-distribution release files[1] with a single one. Yesterday we decided to drop support for systems lacking /etc/os-release in systemd since recently the majority of the big distributions adopted /etc/os-release and many small ones did, too[2]. It's our hope that by dropping support for non-compliant distributions we gently put some pressure on the remaining hold-outs to adopt this scheme as well.

I'd like to take the opportunity to explain a bit what the new file offers, why application developers should care, and why the distributions should adopt it. Of course, this file is pretty much a triviality in many ways, but I guess it's still one that deserves explanation.

So, you ask why this all?

• It relieves application developers who just want to know the distribution they are running on to check for a multitude of individual release files.
• It provides both a "pretty" name (i.e. one to show to the user), and machine parsable version/OS identifiers (i.e. for use in build systems).
• It is extensible, can easily learn new fields if needed. For example, since we want to print a welcome message in the color of your distribution at boot we make it possible to configure the ANSI color for that in the file.

FAQs

There's already the lsb_release tool for this, why don't you just use that? Well, it's a very strange interface: a shell script you have to invoke (and hence spawn asynchronously from your C code), and it's not written to be extensible. It's an optional package in many distributions, and nothing we'd be happy to invoke as part of early boot in order to show a welcome message. (In times with sub-second userspace boot times we really don't want to invoke a huge shell script for a triviality like showing the welcome message). The lsb_release tool to us appears to be an attempt of abstracting distribution checks, where standardization of distribution checks is needed. It's simply a badly designed interface. In our opinion, it has its use as an interface to determine the LSB version itself, but not for checking the distribution or version.

Why haven't you adopted one of the generic release files, such as Fedora's /etc/system-release? Well, they are much nicer than lsb_release, so much is true. However, they are not extensible and are not really parsable, if the distribution needs to be identified programmatically or a specific version needs to be verified.

Why didn't you call this file /etc/bikeshed instead? The name /etc/os-release sucks! In a way, I think you kind of answered your own question there already.

Does this mean my distribution can now drop our equivalent of /etc/fedora-release? Unlikely, too much code exists that still checks for the individual release files, and you probably shouldn't break that. This new file makes things easy for applications, not for distributions: applications can now rely on a single file only, and use it in a nice way. Distributions will have to continue to ship the old files unless they are willing to break compatibility here.

This is so useless! My application needs to be compatible with distros from 1998, so how could I ever make use of the new file? I will have to continue using the old ones! True, if you need compatibility with really old distributions you do. But for new code this might not be an issue, and in general new APIs are new APIs. So if you decide to depend on it, you add a dependency on it. However, even if you need to stay compatible it might make sense to check /etc/os-release first and just fall back to the old files if it doesn't exist. The least it does for you is that you don't need 25+ open() attempts on modern distributions, but just one.

You evil people are forcing my beloved distro $XYZ to adopt your awful systemd schemes. I hate you! You hate too much, my friend. Also, I am pretty sure it's not difficult to see the benefit of this new file independently of systemd, and it's truly useful on systems without systemd, too.

I hate what you people do, can I just ignore this? Well, you really need to work on your constant feelings of hate, my friend. But, to a certain degree yes, you can ignore this for a while longer. But already, there are a number of applications making use of this file. You lose compatibility with those. Also, you are kinda working towards the further balkanization of the Linux landscape, but maybe that's your intention?

You guys add a new file because you think there are already too many? You guys are so confused! None of the existing files is generic and extensible enough to do what we want it to do. Hence we had to introduce a new one. We acknowledge the irony, however.

The file is extensible? Awesome! I want a new field XYZ= in it! Sure, it's extensible, and we are happy if distributions extend it. Please prefix your keys with your distribution's name however. Or even better: talk to us and we might be able update the documentation and make your field standard, if you convince us that it makes sense.

Anyway, to summarize all this: if you work on an application that needs to identify the OS it is being built on or is being run on, please consider making use of this new file, we created it for you. If you work on a distribution, and your distribution doesn't support this file yet, please consider adopting this file, too.

If you are working on a small/embedded distribution, or a legacy-free distribution we encourage you to adopt only this file and not establish any other per-distro release file.

Read the documentation for /etc/os-release.

Footnotes

[1] Yes, multitude, there's at least: /etc/redhat-release, /etc/SuSE-release, /etc/debian_version, /etc/arch-release, /etc/gentoo-release, /etc/slackware-version, /etc/frugalware-release, /etc/altlinux-release, /etc/mandriva-release, /etc/meego-release, /etc/angstrom-version, /etc/mageia-release. And some distributions even have multiple, for example Fedora has already four different files.

[2] To our knowledge at least OpenSUSE, Fedora, ArchLinux, Angstrom, Frugalware have adopted this. (This list is not comprehensive, there are probably more.)

So I have been using the GNOME shell for quite some time now, and I guess like any desktop experience it has its ups and downs, but at least I think I reached a stage where my remaining quibbles with the GNOME Shell is related to how it works as opposed to irritations caused by me being used to something else. One thing I keep asking myself is if GNOME Shell has in any way made me more or less productive, my guess is that the change has been mostly productivity neutral once I got used to the new setup.

That said I have some smallish irritations with the GNOME Shell, the biggest being that the menu system feels slow, it feels distinctly slower than GNOME 2.x to click into Activities->Applications->Category to get to the application I am looking for, especially if I haven’t done so in a bit and the icons have to be pulled from disk. Also the fact that the categories is on the right side of the screen means a long mouse journey across the screen to get to the categories, and then a long mouse journey usually back towards the left side of the screen to click on the application I want. Ok, so this is not an operation I perform every 5 minutes, but still it feels a bit to laborious for what it is.

The other frustration I have is with the notification dock at the bottom of the screen, but I suspect this is mostly application issues. Like for instance gtimelog seems to have a different behaviour if you click on the text or the icon, and with the icon being so small I sometimes overshot, which causes the irritation of having to move a ‘long’ way back to due the neighbouring icon having expanded. Other small irritations includes the the Banshee icon saying ‘notify-sharp’ instead of Banshee and getting a ton of notification messages on the status bar as peoples IM client set them to offline/away etc.

Hmm, actually having written my irritations down I do feel they feel rather small and insignificant, yet if someone sees this I hope these items will be improved upon for future versions.

Also I do think that the system menu should offer shut down/restart by default, if I hadn’t seen someone mentioning it on IRC some Months back I am sure I to this day wouldn’t have realized I could press ‘alt’ to get shutdown/reboot to appear in the menu. I know there is an extension now, but it is such a basic operation that should require knowing ‘secret’ buttons getting an extension.

This past week, I've started to get back into photography a bit more (thanks, Nina!) and started taking my camera into the office with me every day to remind myself to take photos. As a result, I've taken a bunch of photographs of my co-workers in the office.

Would you like to meet the hackers?

The Founders

Most of you would probably recognize the infamous Miguel de Icaza, Xamarin's CTO:

Next up is our very own Steve Jobs, Nat Friedman, our CEO and the man who reminds us to pay attention to the details:

Another person many of you will recognize is our very own COO, Joseph Hill:

MonoDevelop Team

Well, okay, I've only got a photo of the famous Michael Hutchinson, but he's a very important player in the development of MonoDevelop.

QA Team

Next up, we have the QA team. They do their best to make sure that we, the developers, didn't break anything. When they aren't testing a specific application before a launch, they hammer away at our products and try to find weak spots in our code (but we still love them anyway!)

This is PJ, and as you can see, he's demonstrating how to QA popcorn corn cobs:

(Did it pass the test, PJ?)

Next up is Lindsey. She's been working on writing automated tests to make it less likely for releases to include regressions. Let's hope she's successful!

Release Team

Alex Corrado is the man behind the curtain. He's our head Release Team engineer and also the brilliant mastermind that started CXXI, the Mono C++ interop project that we hope to give him time to finish someday soon.

Web Team

The newest addition to our ranks (just this week, in fact!), but long-time contributor to the Mono project, is Bojan Rajković. You can see we've already put him to work (he is no doubt puzzling over some ASP.NET code on his screen).

Documentation Team

Nina is the only Cambridge resident on our Docs Team. Specifically, she hacks on our Documentation Portal. She's also the one who has encouraged me to get back into taking photographs, so she'll have to put up with me using her as a guinea pig the most. Here she is taunting me with her hot cup of Chaider:

• Even worse, slept fitfully most of the day, N. similarly ill; unpleasant really. Rallied a little in the afternoon, watched some Frozen Planet prettiness.

Talking about Secure Boot again, I'm afraid. One of the things that's made discussion of this difficult is that, while the specification isn't overly complicated, some of the outcomes aren't obvious at all until you spend a long time thinking about it. So here's some clarification on a few points.
Secure Boot provides no additional securityUntrue. Attacks against the pre-boot environment are real and increasingly common - this is a recent proof of concept, and this has been seen in the wild. Once something has got into the MBR, all bets are off. It can modify your bootloader or kernel, inserting its own code to return valid results whenever any kind of malware checker scans for it. The only way to reliably identify it is to either move the disk to another system or to cold boot off verified media. By restricting pre-OS code to something that's been signed, Secure Boot does provide enhanced security.
Secure Boot is just another name for Trusted BootUntrue. Trusted Boot requires the ability to measure the entire boot process, which gives the OS the ability to figure out everything that's been run before OS startup. The root of trust is in the hardware and a TPM is required. Secure Boot is simply a way to limit the applications that are run before the OS. Once booted, there is no way for the OS to identify what was previously booted, or even if the system was booted securely.
Microsoft are just requiring that vendors implement the specificationUntrue. Quoting from the Windows 8 Hardware Certification Requirements:

MANDATORY: No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway Signature verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not pass signature verification, they must explicitly disable Secure Boot on the target system.

Section 27.7.3.3 of version 2.3.1A of the UEFI spec explicitly permits implementations to provide a physically present user override. Whether this is a good thing or not is obviously open to argument, but the fact remains that Microsoft forbid behaviour that the specification permits.
Secure Boot can be used to implement DRMUntrue. The argument here is that Secure Boot can be used to restrict the software that a machine can run, and so can limit a system to running code that implements effective copy protection mechanisms. This isn't the case. For that to be true, there would need to be a mechanism for the OS to identify which code had been run in the pre-OS environment. There isn't. The only communication channel between the firmware and the OS is via a single UEFI variable called "SecureBoot", which may be either "1" or "0". Additionally, the firmware may provide a table to the OS containing a list of UEFI executables that failed to authenticate. It is not required to provide any information about the executables that authenticated correctly.

In both these cases, the OS is required to trust the firmware. If the firmware has been compromised in any way (such as the user turning off Secure Boot), the data provided by the firmware can be trivially modified and the OS told that everything is fine. As long as machines exist where users are permitted to disable Secure Boot, Secure Boot is not any kind of DRM scheme.
Secure Boot provides physical securityUntrue. Secure Boot does not in any way claim to improve security against attackers who have physical access, for the same reasons as the DRM case. The OS has no way to determine that the firmware's behaviour has been modified. A physically-present attacker can simply disable Secure Boot and install a piece of malware that lies to the OS about platform security. The "Evil Maid" attack still exists.
Secure Boot only defines the interaction between the firmware and the bootloader. It doesn't specify any higher policyMisleading. It's true that Secure Boot only specifies the authentication of pre-OS code. However, if you implement Secure Boot it's because you want to ensure that only authenticated code has run before your OS. If there is any way for unauthenticated code to touch the hardware before your OS starts, you can't ensure that. If an authenticated Linux kernel is booted and then loads an unsigned driver, that unsigned driver can fabricate a fake UEFI environment and then launch Windows from it. Windows would falsely believe that it has booted securely. If that authenticated Linux kernel were widely distributed, attackers could use it as an attack vector for Windows. The logical response from Microsoft would be to blacklist that kernel.

The inevitable outcome of implementing Secure Boot is that every component that can touch hardware must be signed. Anyone who implements Secure Boot without requiring that is adding no additional security whatsoever.
Only machines that want to boot Windows need to carry Microsoft's keysAgain, misleading. Microsoft only require one signing key to be installed, and the Windows bootloader will be signed with a key that chains back to this one. However, the bootloader is not the only component that must be signed. Any drivers that are carried on ROMs on plug-in cards must also be signed. One approach here would have been for all hardware vendors to have their own keys. This would have been unscalable - any shipped machine would have to carry keys for every vendor who produces PCI cards. If a machine carried an nvidia key but not an AMD one, swapping a geforce for a radeon would have resulted in the firmware graphics driver failing to load. Instead, Microsoft are providing a signing service. Vendors will be able to sign up for WHQL membership and have their UEFI drivers signed by Microsoft.

This leads to the problem. The Authenticode format used for signing UEFI objects only allows for a single signature. If a driver is signed by Microsoft, it can't be signed by anybody else. Therefore, if a system vendor wants to support off-the-shelf PCI devices with Microsoft-signed drivers, the system must carry Microsoft's key. If the same key is used as the root of trust for the driver signing and for the bootloader signing, that also means that the system will boot Windows.
This is only a problem for clients, not serversNot strictly true. While Microsoft's current requirements don't mandate the presence of Secure Boot on server hardware, if present it must be enabled and locked down as it is for clients. It's not valid for servers to ship with disabled Secure Boot support, or for it to be shipped in a mode allowing users to make automated policy modifications at OS install time.
Secure Boot is required by NISTThis is one that I've heard from multiple people working on Secure Boot. It's amazingly untrue. The document they're referring to is NIST SP800-147, which is a document that describes guidelines for firmware security - that is, what has to be done to ensure that the firmware itself is secure. This includes making sure that the OS can't overwrite the firmware and that firmware updates must be signed. It says absolutely nothing about the firmware only running signed software. Secure Boot depends upon the firmware being trusted, so these guidelines are effectively a required part of Secure Boot. But Secure Boot is not within the scope of SP800-147 at all.
It's easy for Linux to implement Secure BootMisleading. From a technical perspective, sure. From a practical perspective, not at all. I wrote about the details here.
It's only a problem for hobbyist Linux, not the real Linux marketUntrue. It's unclear whether even the significant Linux vendors can implement Secure Boot in a way that meets the needs of their customers and still allows them to boot on commodity hardware. A naive implementation removes many of the benefits of Linux for enterprise customers, such as the ability to use local modifications to micro-optimise systems for specific workloads. One of the key selling points of Linux is the ability to make use of local expertise when adapting the product for your needs. Secure Boot makes that more difficult.

ConclusionMuch reporting on the issues surrounding Secure Boot so far has been inaccurate, leading to misunderstandings about the (genuine) benefits and the (genuine) drawbacks. Any useful discussion must be based around an accurate understanding of the specification rather than statements from analysts with no real understanding of the Linux market or security.

comments

You can now get the Slides for my Mono for Game Development talk.

Or you can go straight to the resources for the talk.

• Slightly brighter, visited by a couple of Jehovah's Witnesses, with a Dan-Browne quality conspiracy theory: that the New-Testament autographs were uniformly corrupted without anyone contesting that, or writing a word about it. Justifying your translation on the basis of other people's subjective decisions (when back-translating to Hebrew), made a thousand plus years later also seems curious [sic]. Using J.BeDuhn to try to buttress quality when he condemns this too is odd.
• Slugged, sickly around; fever worse in the evening; slept fitfully.

buzztard

The first big change after releasing 0.6 was to move from svn to git. SourceForge offers git since a while, but does not provide any tips how to do the transition. Fortunately it is a popular topic though. I used svn2git for the main conversion. I fixed the author tags from svn commit messages (Patch-by:) manually using git rebase -i as I could not get a filter-branch script for it to work. A few times gitk got confused and I had to remove my .git/gitk.cache, one symptom are missing tags. I updated the enlistments on ohloh and tweaked the git hooks to have the same functionality as before.

A first code wise change was to move the bsl module into the buzztard one. It is a small module for the buzztard song-loader plugin and it is not needed if you don't want to load buzz songs. But it is small and has no further dependencies and thus it is easier to just include it. Especially as we plan to add other loaders in the coming cycle(s).

In the editor I bumped the required gtk version to get rid of some #ifdef and be able to use newer API. I replaced the ruler widgets in volume and panorama popups with with scale markers. Those look nicer and take the scale handle size into account. Unfortunately they were almost untested. I made the needed patches for gtk-2-24, gtk-3-2 and gtk-HEAD [1],[2]. I could also made workarounds for the issue for the time being. So for the time being, don't use inverted ranges on your scales and don't use an adjustment with fractions (use 0 .. 100 instead of 0.0 to 1.0).

Most of the work went in the the interaction controller. The controller assignment in the UI is a bit more discoverable (content menu not only on main widgets, but also on the label and value label). Controllers can be assigned to combo-boxes too (mapped to enums). We have controllers for note-on midi messages and the velocity that comes with it now.

The other bigger change is that we now have persistent audio sessions (right now only enabled for jack). We're basically keep the sink alive across songs and also keep it in a resource allocated state. This gives a little speedup on the playback startup, but the main motivation was to allow to configure linkage of buzztard with other jack client in qjackcontrol. This is also an enabler for transport sync support. I have landed initial support for this in gstreamer-git.

There were also a few smaller changes for user feedback on docs and new tips. The design folder got more experiments.

485 files changed, 2638 insertions(+), 2033 deletions(-)

I'd like to thank Harald Welte for his reasoned and clear blog post about GPL enforcement which I hope helps to clear up some of the confusions that I also wrote about recently.

Harald and I appear to agree that all enforcement actions should request, encourage, and pressure companies toward full FLOSS compliance. Our only disagreement, therefore, is on a minor strategy point. Specifically, Harald believes that the “reinstatement of rights lever” shouldn't be used to require compliance on all FLOSS licenses when resolving a violation matter, and I believe such use of that lever is acceptable in some cases. In other words, Harald and I have only a minor disagreement on how aggressively a specific legal tools should be utilized. (I'd also note that given Harald's interpretation of German law, he never had the opportunity to even consider using that tool, whereas it's always been a default tool in the USA.) Anyway, other than this minor side point, Harald and I appear to otherwise be in full in agreement on everything else regarding GPL enforcement.

Specifically, one key place where Harald and I are in total agreement is: copyright holders who enforce should approve all enforcement strategies. In every GPL enforcement action that I've done in my life, I've always made sure of that. Indeed, even while I'm a very minor copyright holder in BusyBox (just a few patches), I still nevertheless defer to Erik Andersen (who holds a plurality of the BusyBox copyrights) and Denys Vlasenko (who is the current BusyBox maintainer) about enforcement strategy for BusyBox.

I hope that Harald's post helps to end this silly recent debate about GPL enforcement. I think the overflowing comment pages can be summarized quite succinctly: some people don't like copyleft and don't want it enforced. Others disagree, and want to enforce. I've written before that if you support copyleft, the only logically consistent position is to also support enforcement. The real disagreement here, thus, is one about whether or not people like copyleft: that's an age-old debate that we just had again.

However, the anti-copyleft side used a more sophisticated political strategy this time. Specifically, copyleft opponents are attempting to scapegoat minor strategy disagreements among those who do GPL enforcement. I'm grateful to Harald for cutting through that ruse. Those of us that support copyleft may have minor disagreements about enforcement strategy, but we all support GPL enforcement and want to see it continue. Copyleft opponents will of course use political maneuvering to portray such minor disagreements as serious policy questions. Copyleft opponents just want to distract the debate away from the only policy question that matters: Is copyleft a good force in the world for software freedom? I say yes, and thus I'm going to keep enforcing it, until there are no developers left who want to enforce it.

One of the things that the GNOME design crew have been focusing on recently is creating a new approach to application design for GNOME 3. We want GNOME applications to be thoroughly modern, and we want them to be attractive and a delight to use. That means that we have to do application design differently to how we’ve done it in the past.

Design is always an iterative process, and the new GNOME application design approach has been steadily evolving for some time. There have been lots of design ideas and mockups, and there has been plenty of testing of prototypes and of proper implementations. This process has resulted in some design patterns being consigned to the scrapheap while others have come to have an increasingly important place in our hearts. Slowly but surely, things are starting to fall into place.

As the new GNOME 3 application design approach has stabilised, we have been able to pursue the development of more new applications. GNOME Documents and Contacts have been joined by Boxes, Web and Clocks. We also have designs in the works for many other new applications, including Mail, Videos, Chat, Photos, Calendar and more. Each of these new designs utilise the application design approach that we have been developing. We are also starting to document our new application design approach in a new version of the HIG. This will help application developers to create their own GNOME 3 apps.

In what remains of this post I’m going to try to give you a taste of the new application designs, as well as give a bit of background about why they have been designed in the way that they are.

Maximised Windows

Displaying multiple windows at the same time means that screen space isn’t used efficiently, and it means that you don’t get a focused view of what it is that you are interested in. Windows that aren’t maximised also create additional tasks for people. Often you need to adjust their size, or you have to move them around.

These are just some of the reasons why GNOME 3 applications have a particular approach to windows. In general, their primary windows will maximise by default, and they will lose their titlebars when they are maximised (smaller utility applications will not be affected by this). This will mean that the screen will be dominated by the window that you are focused on. It will also mean that the maximum amount of screen space will be devoted to useful stuff (like content).

Views

Each window of a GNOME 3 application can display different views, so that you can navigate to different parts of the app within it. Breaking up an interface into different views makes it more efficient and more pleasurable to use. It means that the content and controls that are displayed are always relevant to the task in hand, and means that superfluous interface elements are kept to a minimum.

The designs for the GNOME 3 Music app are a great example of this. It contains a view for browsing and a view for looking at a particular album, artist or playlist. Each view only contains content that is relevant to the current activity, meaning that each experience is enhanced, and that you travel through the application to the functionality that you want, rather than having it presented to you all at the same time.

Primary Toolbars

In GNOME 2, primary toolbars were like a toolboxes. They were a mixed bag, containing a variety of things that might or might not be useful to you at any given time. There was also a lack of consistency between apps, and the layout of toolbars often didn’t help you to understand their functionality. Together, this gave toolbars a high cognitive overhead and meant that they lacked visual elegance.

GNOME 3 primary toolbars are a bit different. They will only contain a few elements, and they will be much more consistent across applications, making them much easier to use. Their contents will also follow common alignment points, so they will look much nicer.

Primary toolbars in GNOME 3 also play a navigation role. They take over the job of labelling the view from the window titlebar, and they are at the top of the user interface’s hierarchy, framing content and providing key mechanisms for interacting with it. They’re object orientated.

Selections and Contextual Actions

The design pattern for making selections and acting on them is the result of a lot of work. It has been through quite a few iterations. Jimmac even created a whole series of html prototypes to help determine the best approach. There’s still one online that you can try.

Selections and contextual actions revolve around the checkmark button. Pressing it activates an overlay that allows multiple items to be selected and acted on using an overlaid toolbar.

The new design makes selecting multiple items possible without the need for a keyboard (since shift and alt modifiers aren’t required) and is touch compatible. Providing a separate space for contextual actions also guides users by providing a consistent mechanism for acting on content.

Search

Search can be an incredibly powerful tool, and it is central to GNOME 3 application design. Search will be ubiquitous and instantly available within GNOME 3 applications. If you are not editing a text field or a document, all you have to do is start typing to initiate a search.

Search will also be accessible using this nifty pull-down search design. This is a nice way of making search always available without having search boxes attached to every single grid or list of content. There are also variants of the design pattern that will allow you to use predefined filters on your content.

And more

There are many other application design patterns that we’ve been working on, including application menus, a new grid view for displaying collections of content, in-app notifications, new models for dialogs, nice full screen controls and a sidebar list pattern. Together, these provide the opportunity to create applications that efficient, modern, elegant, and a pleasure to use

The design patterns that I’ve introduced in this post aren’t the end of the story though. This new approach to GNOME application design is still evolving. We’re still testing the patterns we have come up with, and there are still missing pieces to this new application design approach. We are still investigating how to make maximised windows work well on very large screens, for example.

As the new GNOME applications develop, so will the design patterns. Everyone who is working on these new applications – both developers and designers – are helping to determine the shape of GNOME’s next generation of applications. And if you want to contribute you can also play a part.

Edit:

Judging by the comments it would seem that there is a bit of confusion about what is meant by maximising windows by default, so let me try and clarify:

1. Not all applications will use this behaviour – only those that have been designed to do so. If an app won’t work being maximised, it won’t be.
2. Although these applications will maximise by default, it will still be possible to unmaximise them. If you want to be able to view more than one window at once you will still be able to do so.
3. There will be mechanisms put in place that will adjust the behaviour to compensate for large screens. We are currently investigating a number of options here, including not automatically maximising windows on these large screens or adjusting their layout to make best use of the extra space. Everyone involved is well aware of the need to work well with large screens!

Comments on this post are now closed

Today I needed an xml diff tool. There seem to be an xmldiff and a diffxml, neither of them packaged by Fedora at the moment. I found an old src.rpm for Fedora 6 for xmldiff 0.6.8

The src.rpm doesn’t rebuild as is for various reasons: its %check stage imports unittest2, so I disabled check. Then it didn’t find debuglist.files, so I disabled building a debug package. And then it found an installed egg file which it didn’t like, so I disabled checking for installed files.

Since I’m going to forget how I did this in the future when I will need this again for some obscure reason, and because if you ever build rpms you may find this useful, here is the command that did it for me for Fedora 15:
rpmbuild --rebuild -D '%check exit 0' -D 'debug_package %{nil}' -D '_unpackaged_files_terminate_build exit 0' xmldiff-0.6.8-1.fc6.src.rpm

Now, back to comparing xml files.

Things as they are, few hackers get to work on the same project their whole life. No matter how deep one has been involved in a project, and how much effort was put in, there are many reasons why at some point one may decide to distance from it.

For different reasons, the people who have been maintaining PyGObject for the last couple of years (since the move to introspection) aren't currently using it much any more, which isn't ideal because it means they can allocate less time to maintenance and also lack the guidance of their own motivation.

Fortunately for PyGObject, a bunch of heroic hackers have stepped forward to take the responsibility of maintaining it:

• Martin Pitt
• Paolo Borelli
• Ignacio Casal Quintero
• Sebastian Pölsterl

For now I remain listed in the .doap file, but as I'm not using PyGObject myself any more (even though Collabora sponsors some of my time working on PyGObject), my involvement will be limited to occasional patches and code reviews as I find time.

My thanks and admiration to those who have maintained PyGObject in the past:

• Johan Dahlin
• James Henstridge
• John (J5) Palmieri
• Simon van der Linden
• Zach Goldberg
• Gustavo J Carneiro
• Paul Pogonyshev
• Gian Mario Tagliaretti

To end, just note that Martin is using his canonical.com address, so I assume that Canonical is sponsoring his work as maintainer upstream, so kudos to them as well.

I’ve had a number of people suggest Gwibber could use a new logo, but nobody has actually stepped up and designed anything.  Recently I had the good fortune to chat with Abi Rasheed on IRC who volunteered to help.  He has put together a couple of great concepts, and we would like to gather some feedback.

I’ve posted the concepts on the wiki, please check them out and provide some feedback.

Thanks!

 

Matthew Aslett wrote about how the proportion of projects released under GPL-like licenses appears to be declining, at least as far as various sets of figures go. But what does that actually mean? In absolute terms, GPL use has increased - any change isn't down to GPL projects transitioning over to liberal licenses. But an increasing number of new projects are being released under liberal licenses. Why is that?

The figures from Black Duck aren't a great help here, because they tell us very little about the software they're looking at. FLOSSmole is rather more interesting. I pulled the license figures from a few sites and found the following proportion of GPLed projects:

RubyForge: ~30%
Google Code: ~50%
Launchpad: ~70%

I've left the numbers rough because there's various uncertainties - should proprietary licenses be included in the numbers, is CC Sharealike enough like the GPL to count it there, that kind of thing. But what's clear is that these three sites have massively different levels of GPL use, and it's not hard to imagine why. They all attract different types of developer. The RubyForge figures are obviously going to be heavily influenced by Ruby developers, and that (handwavily) implies more of a bias towards web developers than the general developer population. Launchpad, on the other hand, is going to have a closer association with people with an Ubuntu background - it's probably more representative of Linux developers. Google Code? The 50% figure is the closest to the 56.8% figure that Black Duck give, so it's probably representative of the more general development community.

The impression gained from this is that the probability of you using one of the GPL licenses is influenced by the community that you're part of. And it's not a huge leap to believe that an increasing number of developers are targeting the web, and the web development community has never been especially attached to the GPL. It's not hard to see why - the benefits of the GPL vanish pretty much entirely when you're never actually obliged to distribute the code, and while Affero attempts to compensate from that it also constrains your UI and deployment model. No matter how strong a believer in Copyleft you are, the web makes it difficult for users to take any advantage of the freedoms you'd want to offer. It's as easy not to bother.
So it's pretty unsurprising that an increase in web development would be associated with a decrease in the proportion of projects licensed under the GPL.

This obviously isn't a rigorous analysis. I have very little hard evidence to back up my assumptions. But nor does anyone who claims that the change is because the FSF alienated the community during GPLv3 development. I'd be fascinated to see someone spend some time comparing project type with license use and trying to come up with a more convincing argument.

(Raw data from FLOSSmole: Howison, J., Conklin, M., & Crowston, K. (2006). FLOSSmole: A collaborative repository for FLOSS research data and analyses. International Journal of Information Technology and Web Engineering, 1(3), 17–26.)

comments

It is a great honor to participate this weekend on the online AltDevConf conference. This is an online two-day event

Our goal is twofold: To provide free access to a comprehensive selection of game development topics taught by leading industry experts, and to create a space where bright and innovative voices can also be heard. We are able to do this, because as an online conference we are not subject to the same logistic and economic constrains imposed by the traditional conference model.

I will be participating in the talk on Cross Platform Game Development using C# with Matthieu Laban and Philippe Rollin.

You can register here for our session on Saturday at 3pm Eastern Standard Time, noon Pacific Time, and 9pm Paris Time.

If you are located in the Paris time zone, that means that you get to enjoy the talk sipping a tasty hot chocolate with some tasty baguettes.

Dear GTK devs I’ve been encountering some problems in the current behavior of the latest versions of GtkFileChooserDialog, so just in case It is me that I don’t understand the current behavior I’ll put them here:

• Right now when we want to open a file a in gedit the Recently Used item is selected. This is a really really bad behavior in my opinion for applications like gedit or gitg where we already provide a way to go to the recently used documents and what we really want is to show the directory where the user is working as it is highly probable that will want a file or directory from the directory it is working on or from one near to that one. Please recommend us a way to get back the previous behavior so we will not have to do crazy things like listening to map and unmap signals to place the right directory to show in our specific applications.
• Another problem that I have been encountering and I don’t know if it is a new feature or a bug, is that if I click on the list view of directories and I press enter in a directory, the new directory is opened but the focus changes to the Location entry instead of keeping it in the list view. Please let me know if there is some API or a way I can use to get the previous behavior back. If it is a bug I can even provide some patches.

In my last blog post I mentioned the embedding of a javascript library inside Stoq. I got a couple of requests which asked me how this was accomplished, this blog post attempts to explain some of it.

Of course we need to use the great WebKitGtk library. Unfortunately we cannot use the introspection based bindings as this needs to work on Gtk+ 2.18 and PyGTK 2.17 which were shipped in the last Ubuntu LTS release.

WebView will do all the html/css/js parts. It’s almost as simple as a normal GtkTextView, add it to a scrolled window, load the content and off you go.

The first challange comes when you want to open http:// links in your normal browser, instead of handling them in your webkit. To do that you need to listen the navigation-policy-decision-requested signal ignore certain requests. You don’t actually need to use http protocols, you can invent any url which is parsable.

Next problem is AJAX, to write a proper asynchronous widget you don’t want to reload the whole page when something changes. Since we cannot implement our own protocols in the old libsoup bindings shipped for PyGTK we need to run our own http server. That is good for other reasons as well, we can do heavy IO such as database queries in there without actually blocking the user interaction.

When we need to execute scripting in gtk we just call web_view_execute_script() which will just execute a piece of javascript. For instance,

view.execute_script(“document.title = $(‘fc-header-title’).text()” is a actual line in Stoq, it sets the window title based on calendar header title from the dom.

Going the other direction is a bit uglier, the only way of communcation I found out was opening new urls, so I implemented an application specific domain which opens a dialog or some other action within the gtk application.

I know that some of these tricks are already outdated, in newer webkitgtk versions you should write your own libsoup handlers, use the gobject dom bindings for communication, but I didn’t have these options when writing this post

TL;DR

• Listen to the ::navigation-policy-decision-requested to implement your own uri handling if you can’t do it via libsoup.
• Run a separate daemon process which will serve as an internal webserver, so AJAX calls work and won’t block on IO.
• Use web_view_execute_script() for Gtk->Javascript communication
• Use window.location = “customprotocol://”  for Javascript ->Gtk communication
• Make the javascript parts work in a normal browser so the normal developer tools can be used
• If possible, use a newer version of WebKitGtk and avoid all of this.

Xan and the other webkit hackers will probably look at me in disgust for telling you how to do all of these dirty hacks