Archive for the ‘GNOME’ Category

Vala 0.3.3

Wednesday, June 4th, 2008

It’s release time again. Yesterday we’ve released Vala 0.3.3. Tarballs are available from the GNOME FTP servers.

Thanks a lot to all the people helping out and have fun with the new version! For the following two releases we will focus on GObject introspection hacking to make it easy to write great bindings for many languages.

Vala 0.3.1

Tuesday, April 22nd, 2008

We’ve just released Vala 0.3.1. Tarballs are available from the GNOME FTP servers.

  • Non-null types are enabled by default
  • Experimental support for writing D-Bus services
  • New handwritten parser
  • Don’t require `new’ operator for structs
    var color = Color (0×00, 0×88, 0xee);
  • Many bug fixes and binding updates

Vala Roadmap and 0.2.0

Tuesday, April 8th, 2008

Last week I wrote an initial roadmap that we want to follow for the upcoming Vala releases on our way towards guaranteed language stability. Today we’ve released Vala 0.2.0 as planned. Tarballs are available from the GNOME FTP servers. It’s mainly a bug fix release, however, it also got some new features like nested namespaces, static constructors, and GType-registered enums. We also have three new contributed bindings for GNOME Keyring, SDL, and libftdi, and the usual updates for existing bindings.

Vala 0.1.7

Sunday, March 2nd, 2008

We’ve just released Vala 0.1.7. Tarballs are available from the GNOME FTP servers.

  • Enhanced property syntax
    public int foo { get; private set; default (3); }
  • New errordomain syntax
    public errordomain MyError { NOT_FOUND, TIMED_OUT }
  • Detect missing return and break statements and unreachable code
  • Improved pointer support (pointer member access, pointer element access, and pointer arithmetic)
  • New bindings: WebKit, JSON-GLib, goocanvas, hildon-fm-2, taglib, libusb, and bzip2
  • A lot of bug fixes

Vala Project Generator

Sunday, November 25th, 2007

Vala 0.1.5 has been released. Tarballs are available from the GNOME FTP servers. I’ve added a small tool to create new Vala projects:

Vala Project Generator

It generates the necessary autotools magic for a Vala console or GTK+ application including i18n support and it passes distcheck. Suggestions for improvements are more than welcome.

We’ve also replaced the bindings generator gidlgen by vala-gen-introspect which includes a real C parser instead of Perl scripts using regular expressions. The 20 included bindings have all been ported. Some smaller features and many bug fixes can also be found in the new release.

There are two articles about Vala and an interview in the German Linux-Magazin, all by Christian Meyer.

Vala 0.1.4

Tuesday, October 9th, 2007

Vala 0.1.4 has been released. Tarballs are available from the GNOME FTP servers. We’ve added some small enhancements besides bug fixes and the previously mentioned #line support for debugging.

  • Object initializers
    var btn = new Button () { label = “Button” };
  • Creation methods in structs
  • Experimental support for new fundamental classed types
    class MiniObject : TypeInstance { … }
  • [Notify] attribute for properties

Vala and Nemiver

Wednesday, September 5th, 2007

I’ve added preliminary support for #line directives to Vala. This means that the debug information of your application compiled with valac -g will now contain the filename and line number of your Vala sources, instead of the generated C sources. Vala applications can be more or less graphically debugged using Nemiver now :) Mathias was kind enough to create a little demo video as the screencast tools didn’t work well on my system. There are still some issues left but it’s a start.

Vala 0.1.3

Friday, August 31st, 2007

Vala 0.1.3 is out. Tarballs are available from the GNOME FTP servers. There are a lot of new bindings from many contributors: D-Bus, GConf, libgnome, libgnomeui, Glade, libnotify, GnomeVFS, GtkSourceView, Panel Applet, GNOME Desktop Library, libsoup, libwnck, GtkMozEmbed, Poppler, Enchant, Hildon, SQLite, and curses. Many bugs have been fixed all over the place.

A noteworthy change is that the type system has been made more consistent by converting the reference-type structs in the bindings to classes. The [ReferenceType] attribute is gone, you can now declare all reference types as classes in bindings, even if they don’t derive from GObject. A side-effect of this change is that you now always have to specify the base class in your class declarations, e.g. use

using GLib;
public class Bar : Object { … }

to declare a class Bar which derives from GObject. The advantage is that you can be sure now that all structs have value-type semantics and all classes have reference-type semantics, no mixup anymore.

Documents and Windows

Saturday, August 25th, 2007

GNOME applications currently follow two different metaphors regarding the relationship between documents and windows. Some applications use a Single Document Interface (SDI) as recommended by the HIG, i.e. one window per document, as for example evince, nautilus, eog, and inkscape. The first two also obey spatial behavior, i.e. they remember window position and size per document resp. folder. Other applications use a Multiple Document Interface (MDI), i.e. one window by default and one tab per document, examples: gedit, epiphany, firefox, devhelp. This week I had the idea of a third way that might work well for most applications.

SDI is very simple to use and quite convenient when combined with spatial behavior as you can arrange your document windows how you like it and you’ll see your documents exactly the same each time you open them. The main disadvantage of SDI is that you end up with many windows, one for each open web page, folder, conversation, text file, and more. The window list applet and the Alt+Tab window switcher don’t scale well, you spend a lot of time finding your window when you have several dozens of windows open.

That’s why some applications use MDI. You’re able to manage your documents or web pages on two levels, that means the window list applet and Alt+Tab are a lot more useful again. A disadvantage is that the configuration of your windows vanishes when you close the window. This may mean that you keep your windows open relatively long, also across logout/login, so that you don’t have to arrange your windows that often. You end up with quite a lot of open windows, again, using more memory and taking time when restoring your session.

My idea now tries to combine the main advantages of the two approaches by making windows first-class objects. So instead of treating windows and documents as the same or forgetting about a window as soon as it’s been closed, treat windows as separate objects. I want you to care about your windows, give each of your window a name, an icon, maybe even a special color for the window frame. Windows should be persistent: if you close a window, its name, icon, position, size, and content should be kept. You can open this window again by using the name and icon you’ve chosen. Creating and destroying - in contrast to opening and closing - a window should be a conscious action, not something that happens as a side-effect of something else; there will be exceptions, of course.

A more concrete proposal follows: Replace the window list applet by something like the dock in Mac OS X with the big difference that it’s about windows instead of applications. The main part is a persistent list of icons of open and closed windows; the windows are stored as desktop files. If you click on an icon and the window isn’t open yet, it will be opened, i.e. like a launcher but you get your documents back. If the window is already open, it just activates the window. To the right of this icon list is a list of currently open non-persistent windows, just like the current window list applet.

Metacity should also have knowledge of the persistent windows and set the visible window title and icon according to the user’s configuration. Applications should use tabbed MDI as basis and add support for restoring windows by name - similar to the session restore feature already implemented in many applications.

Does this make sense or am I missing something substantial? I’ve implemented a proof of concept applet in Vala and patched epiphany to work as described, will import it into some repository later, if there is interest.


Bad Behavior has blocked 5 access attempts in the last 7 days.