Live Wire

Back from FOSDEM 2007, after a little detour in Helsinki.

I’ve opened a bug for the places support in GtkFileChooser: #413076. Attached to it you’ll find a patch; it should be taken with a grain of salt: it’s still a work in progress, but implements the main features and shows how the new API should work. In short, if your application need to use some predefined, user visible folder and you want to provide a link inside the file chooser, you need to create your bookmark file, drop it somewhere and call:

gtk_file_chooser_add_shortcuts_from_file (file_chooser

We’d need an intltool able to recognise the title (and eventually description) markup elements of the bookmark files and merge them into the translation pool, so that you can have the places already localised (the machinery is already in place in the patch). I’ll keep working on it, and finish up the implementation of the automagic places that applications can install in a common place and have it appear in every file chooser, based on the group or application name used in the bookmark.

I’m also working again on the Application class (the wiki page is really out of date with the current iteration I have been workin on – I’ll update it as soon as possible); now that the session management code has landed in libegg I will add hooks into the application class to have it do The Right Thing®. Other than an application class, GTK+ really needs a desktop abstraction – a simple API to know whether we are connected to a network, or to control the screensaver, or to launch the default browser/mailer/editor/whatever. For that to work properly we should really have a working configuration system like GConf moved below GTK+. I did some prototype API for a configuration engine, mostly stealing^Wtaking inspiration from alexl work on GVFS (which already has a nice and clean API); will probably have something usable soon.

3 Replies to “Live Wire”

  1. Wrt the configuration engine, are you planning on keeping GConf’s current architecture? (i.e.: having a central configuration daemon which clients can connect to)

  2. @william:

    yes. there’s no point changing that, as it saves us locking and contention issues, while centralising configuration of sources and backends. theonly change would be in the backend definition and the IPC mechanism (D-Bus with peer to peer channels instead of CORBA),

  3. I feel like thate should also be an abstract toplevel (app)-window class. Platforms can then plug their default implementation (GtkAppWindow, GnomeAppWindow, MaemoAppWindow). This ofcourse has some integration issues. Do we want to ship a Win32AppWindow and a GnomeAppWindow (what about a KdeAppWindow)? If not where do we put the platform code? Maybe this is a usecase for the new AppointType API in GObject?

Comments are closed.