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.
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 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.
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.
I finally started blogging as some people seem to be interested in what’s going on in Vala land. Now to the topic: Vala and D-Bus. It’s really easy to use D-Bus services from Python, compared to C. There is no reason why it should be more difficult to use D-Bus services from Vala, so I’ve just committed experimental D-Bus bindings to Vala SVN. You don’t need any formal specification of the D-Bus service to get started, just get the object and call methods or connect to signals with the correct parameters. It also supports async method calls with a simple callback system. Future versions will support and recommend static checking against a supplied D-Bus introspection file, currently the compiler just assumes that you know what you’re doing. I’ve added a simple example using the Pidgin D-Bus interface to the wiki.