GNOME People

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

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

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 level 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 enforcement. 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. First, 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. Second, 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. Third and finally, 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!

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

Another important thing coming along in the gedit channel is the resurrection of the GObject bindings for libgit2. The good thing about this bindings is that as we added support for GObject introspection they come for free with support for vala, python and javascript.

Jesse has been doing a great job here, updating the bindings and adding the missing API, probably he will point you out at some point his new pet project but for now it is kind of top secret

If you are interested on helping out with the bindings, testing them or writing the so boring unit tests you can find the repository in my github. Once they are ready or we have a serious user for them, we will probably move them to the gnome infrastructure and make a release.

I think after so long without posting anything it is time to put some of the cool stuff we were doing lately.

One of the side effects of staying in Italy last month for a couple of weeks was that I had the weekend without anything productive to do. So Paolo Borelli and I decided to make a mini gedit hackfest where to decide the next directions to take for your favorite Text Editor of the GNOME desktop. The cool thing about staying in Italy and not having anything to do was that we autoinvited ourselves to Lapo Calamadrei’s home to discuss about some gedit’s design problems, to fix some bugs and mainly to eat, drink and enjoy of the cool views from Tuscany :) Thanks Lapo for the great hospitaly that you gave us

If anybody is interested we have also updated the roadmap that you can find here. The main taskes to be done are:

• Port to GtkApplcation
• Make use of the new GMenu
• Use GResources (this will be great for the Windows port)
• Finish the new sidepane (currently a work in process in the branch: wip/newpnael)

If anybody is interested on helping here will be much appreciated.

Apart from this, I also invested some time resurrecting the Win32 port of gedit. Thanks to Dieter I managed to get it working again but there are still a few problems in Gtk+ 3 in order to get an stable release. At least I would like to see the theming working on Windows XP correctly. For those interested, Dieter passed a really great startup tutorial for those who also would like to try out Gtk+ 3 in win32. I hope he will finish it and publish it soon with some great scripts to make our life easier.

Mobillians by Brian King (CC-BY-NC)

This year’s FOSDEM was a special one for me. It was the first time I attended it as a Mozillian! I had already met quite a few European community members at MozCamp Europe last year but this FOSDEM was a great opportunity to meet even more Mozillians face-to-face. I stayed at the Mozilla DevRoom most of the conference but also spent some time catching up with my fellow GNOME hackers.

Chris and I gave a “State of Firefox Mobile” talk on Sunday. I usually don’t share my slides because they tend to be too short in content to be useful. However, we wrote some speaker notes that give enough information and context on what we talked about. So, here’s the deck alternating between slides and speaker notes—I wish Speaker Deck had proper support for speaker notes…

All in all, I had a great time at FOSDEM this year! PS: The weather during the conference was quite special too—in a painful way!

On Monday at the CSS Working Group, Microsoft, Mozilla and Opera announced that each are considering supporting some -webkit- prefixed CSS properties.

I include here Bruce Lawson's excellent summary:

Lots of developers, despite evidence to the contrary, have assumed that mobile Web = WebKit browsers, because that’s the rendering engine in Android and iThings. Suppose the site was made a while ago and used the experimental, pre-standardised code -webkit-border-radius and didn’t use the cross-browser future-proof method. The real CSS property border-radius has been long been standardised and supported without prefixes in all the major browsers. But the -webkit- prefixed version still lingers on in Safari and Chrome, so that legacy code looks fine in the webkit browsers, but broken in Opera, Firefox and Internet Explorer.

We've been through this fight before. A few years back, Internet Explorer proposed the X-UA-Compatible header, which would mean that IE8 would act like IE7 unless you specifically told it to act like IE8. The proposed solutions back then were similar to what we're seeing today in response to -webkit-* CSS in non-WebKit browsers: developers shouldn't be lazy; developers should do it right; sites should break if they use WebKit-only CSS in order to punish the developer; use this library to help you do it right (LESS for CSS pre-processing on the server side, prefixfree on the client-side); WebKit should stop supporting a prefixed CSS property once it supports the unprefixed version; vendor prefixes are a broken concept and should be abandoned.

None of these approaches will work.

Expecting developers to just Do It Right To Begin With™ is a noble goal, but it doesn't work like that. Everyone has deadline pressures; most people are not on the bleeding edge of the web standards community; the tension between "make it work today" and "make it right for the future" is never going to go away, no matter that we wish it would. The way to success is to align the right way to do it with the easiest way to do it; the way to success is to make correctness the path of least resistance. This is what informs the HTML5 "pave the cowpaths" approach, and it's that way for a reason; if correctness requires extra work, then at least some people will be incorrect through lack of time or lack of knowledge.

Breaking websites, by having WebKit deliberately stop supporting a -webkit property once it supports the unprefixed property, is not going to happen. The WebKit team have explicitly stated that they won't do that, for "backwards compatibility reasons". Also, frankly, expecting them to is naive; they should make websites break just in order to teach developers the Right Way To Do Things, when those websites currently work? Remember, it's not developers who are punished by this; it's the users of the sites, because those users get a new phone or a phone OS upgrade and suddenly half the sites they use don't work. This hurts them, and they're who we're doing this for. The WebKit team are looking out for WebKit, but they can't be blamed for that; stuff works for them, after all.

There's an argument that users who find their sites broken will blame the sites, and then the site developers will fix the problem. I disagree. If I decide to try Opera Mobile or Firefox on my phone and half the sites I use don't work, I'll say: oh well, can't move to that, then, and I'll go back to the built-in browser. This is the Microsoft argument: one broken program will prevent an upgrade, and they're right. What we get is de-facto lock-in, just the same as all those businesses which couldn't migrate away from IE6 because of their intranet.

Using a server-side preprocessor or a client-side JS patch to turn some-property into -webkit-some-property, -moz-some-property, -o-some-property, -ms-some-property is a useful tool for developers who know what they're doing but can't be bothered to type it all in. Think about it: if I just use the unprefixed standardised property right now, then eventually (when the browsers all implement it) my site will work! I don't have to do anything to make that happen; I'm out in front and waiting for technology to catch up with me. It does not help the developers who are actually affected here, the ones building sites with only -webkit CSS properties in them, the sites that Bruce calls "legacy code" above. And it's those legacy sites which are compelling Mozilla and Microsoft and Opera to debate supporting that WebKit-only CSS.

So, then, smart-arse, what's the solution, if it's none of those?

Well, obviously, the evangelism efforts should continue. Progress is made. People do learn. It's slow, but we get there in the end. What we're talking about is an interim solution in addition to that.

I think @leaverou's prefixfree JS library has the right idea, it's just backwards. Prefixfree takes proper CSS (an unprefixed property) and turns it into all the vendor-specific prefixed properties, so that you write CSS-of-the-future and the library turns it into CSS-of-today. It's a polyfill. What's wanted here, I think, is something like prefixfree but which takes CSS-of-the-past (-webkit-some-property and turns it into CSS-of-today (-webkit-some-property, -moz-some-property, -o-some-property, -ms-some-property, some-property). This wouldn't be a hard polyfill to build (it's just prefixfree, tweaked), but then of course you have the problem that no-one knows about it. So here's the second part of the proposal: common JS libraries should do this sort of thing by default. Imagine if jQuery fixed this stuff for you. I think, without wishing to sound snobbish, that most reasonably-complex websites include some JS (progressively enhanced, ideally), and most of those use a library. The developers we're talking about (and this is the snobbish part), the people writing legacy WebKit-only code, will have that WebKit-only code automatically patched to work with all other browsers without having to know that it's even happening. The ones who are short of time get that time back; the ones short of knowledge can learn on their own time and are helped to not screw their users in the meantime.

This sort of view is problematic. I'm proposing giving a man a fish, not teaching a man to fish, and that's wrong. I agree. In this instance, given the choice between not educating a developer or not screwing some of his users, I'm choosing the users. I don't know a way to choose both. It's also problematic because I'm suggesting that library developers do all the work, and everyone using that library takes a performance hit even if they don't need to. So, I'm sure there will be other suggestions, and I'd love to hear them. I'd just like to stop hearing all the ones above that don't help the problem get fixed.

If you try to test GStreamer 0.11 there’s this nice gst-uninstalled script; somehow that didn’t work for me as soon as I tried to use more non-gst interdependent libraries so I opted to use jhbuild. Luckily that’s quite easy with the stock gnome jhbuild moduleset.

To do that, I created a new .jhbuildrc-gst-0.11 with the following modifications. skip and modules can of course be adjusted to own needs.

moduleset = 'gnome-world-3.4' modules = [ 'vala', 'libgee', 'gstreamer', 'gst-plugins-good', 'gst-plugins-bad', 'gst-plugins-ugly', 'gst-ffmpeg', 'gssdp', 'gupnp', 'gupnp-av' ] skip = ['gtk+', 'atk', 'gcr', 'gtk+-2', 'rarian', 'NetworkManager', 'gnutls', 'polkit', 'p11-kit', 'gnutls', 'cantarell-fonts', 'gtk-engines', 'librsvg', 'gnome-themes-standard', 'libgnome-keyring', 'pango', 'expat', 'libgpg-error', 'libgcrypt', 'glib-networking'] os.environ['JHBUILDPS1'] = '[gst-0.11] ' branches = { 'gstreamer' : '0.11', 'gst-plugins-base' : '0.11', 'gst-plugins-good' : '0.11', 'gst-plugins-bad' : '0.11', 'gst-plugins-ugly' : '0.11', 'gst-ffmpeg' : '0.11' }

Matt Fischer wrote a great post about writing a greeter for LightDM.  Runs through an example of a Python greeter and how it works.

• Si la lluvia llega hasta aquí Voy a limitarme a vivir. Mojaré mis alas como el árbol o el ángel o quizás muera de pena. Luis Alberto Spinetta — Canción para los días de la vida

  Thank you for everything, Flaco.

We released Stoq 1.2 last week, this release features quite a bit of features:

Calendar application

It’s now possible to list payments, purchase orders and client calls in a graphical view:

 

It might look familiar, it uses the fantastic javascript library fullcalendar. We really wanted to use a normal GtkWidget for the calendar but it would have been a lot more work to rip out half of evolution. If there are any other options that can match fullcalendars functionallity there we’d be open to switching as embedding WebKit, jQuery and fullcalendar in a Gtk+ application is not ideal.

Configurable keyboard shortcuts

This is something that has been requested many times over the years. It makes it easier to remap the keyboard bindings use often to other keys, such as the function keys. There’s still an open task to redo all the existing keybindings that aren’t uniform enough.

Configurable form fields

Some companies does not use all the form fields (fax anyone?) that we show per default and Stoq know has a configuration interface where you can make fields non-mandatory and even hide them if you don’t wish to see them. Perfect for the first steps of localization.

New manual

One of our interns rewrote old docbook manual to mallard, and it looks beatiful and is now well integrated in the application. You can find the online version here. It involved removing a lot of screenshots and text. It’ll be easier to update the manual in the future if there aren’t any screenshots. He also fixed the interface, there are now various help buttons in the application that goes to a help section describing that part.

Localization support

It’s now possible to configure some of the fields that are specific to each region/country. The only thing that made it into this release was company identification number (Brazil: CNPJ, Sweden: Organisationnr, US: Employer Identification Number). But person identification number and list of states has landed in the code repository since the release. We still need someone to step up and start doing the actual localization for this, be the hero of the day and download Stoq and start localizing it!

Boleto Bancário (Bank invoice)

Brazilian banks supports a kind of invoice with a barcodes/numbers, called boleto bancário. It’s semi-standardadized, most of the data is similar, but you need to special case each bank that should be supported. There are two kinds, with and without cobrança (for eventually sending to a collection agency). There are a couple of 100 active banks and about 15 major ones. Stoq currently supports 7: Banco do Brasil, Banco Real, Banco Santander, Banco Bradesco, Caixa Econômica, Banrisul, Banco Itaú. All without cobrança though, support for that will come in a future release.

Call for volunteers

Stoq has initially been targeting the Brazilian market, since that what’s close to the current development team. But there is now longer an excuse for not trying to use it. We can barely handle the legal part of Brazil and we’d need volunteer help to make it possible to use in other countries. We’re very proud of the application so we wouldn’t want to stop you just because you live outside of Brazil!

So, why don’t you grab the code and get started, it’s all python (and a tiny bit of javascript) and shouldn’t be hard to get started.

Don’t be discouraged by the web site and manual is only in Portuguese, we use gettext and rosetta and the code is modular and easy to understand.

We’ll need a lot of work to support localization in different countries such as: company/person formats, states, taxes and other things we don’t know about yet, let us know and we’ll try to find a solution.

Just send me a mail or come in on our new shiny web chat: http://chat.stoq.com.br/ (aka #stoq on freenode)

As promised, I’m blogging periodically to update you all on the progress of our soon-to-be-named openSUSE conference in Florida.

Name it!

With our naming poll closing this Saturday (11-February), the naming poll is getting pretty exciting.   A last minute entry is gaining popularity and it looks like possibly it will be a toss-up between two proposed names before the poll ends.  If you haven’t voted yet, why not?  Vote here.

I wanna join!

On IRC, mails, and directly on our planning wiki page, people are volunteering to be a part of the planning.  On the wiki page, you’ll see we’ve solidifed the types of committees we need and added some good notes to relevant committees.  People have volunteered whether or not they think they can actually make it to the conference.  A good show that just because you may not actually be there, that doesn’t lessen your value within the community.

I’m especially excited to see some good diversity on the program committee.  Itxshell, from Honduras, is joining Alan Clark, Drew Adams and myself and will give us good mileage toward our goal of making this a great bi-lingual conference.  We want to make this a welcoming experience for both English and Spanish speakers, both languages have high presence in the area.

Sponsorship Committee

Many of the committees that have immediate tasks to perform are moving along at a good pace after our kickoff meeting last week.  However, one immediate need is the sponsorship committee.  This is a vital function that needs to be organized in the very near future.  As we have said already, we cannot expect guaranteed funds to cover all our conference expenses and we want to reach out to potential sponsor donors to help fund the conference as well as any possible travel sponsorships.  If you can join the sponsorship committee, everyone would be ever so grateful. 

What else is going on?

As said, our naming poll ends this Saturday.  At that point, we’ll be able to move quickly with setting up our conference web page, promotional posters and flyers to distribute to events, and other things that depend on having a formal name attached to the event.  Andi Silva is already hard at work coming up with designs for our posters and flyers.

Alan Clark has done a nice job of compiling a list of LUGS in the Florida area that can help our organizing efforts.  I think we should expand that to include neighboring states since they’re so close by.

Alexia, the conference manager for SUSECon, will be making a trip sometime in the near future to do ground scouting of the area near the hotel.  We’ll get some good information back about what resources exist in the neighborhood and a better idea for the lay of the land.  This is going to be useful for when we add location information to our website for attendees.

It is my hope that we make a formal public announcement launching the conference by early March.  We’ll tap into the expertise of folks like Mike McCallister and Jos Poortvliet to formalize the press releases, and in conjunction with a site launch and promotional materials printing, we should have a pretty good bang going on in March.

That’s not to say there’s already some excitement going on out there in the world about our conference.  LPI has already jumped in and offered to provide testing services for the LPIC exam.

I’m having the feeling we’re stepping into something good!