Second beta, German translations, FOSDEM
Just in case some of you are wondering already – yes, we’re late with releasing the second beta of Xfce 4.6 by a few days. It’ll probably be released this weekend, so we won’t fall behind the schedule too much.
On Wednesday we had a very productive IRC meeting with the most active German translators being present. Plans we made on that evening include to clean up the team’s wiki page so that it only contains rules and hints that are directly useful for everyone. We also decided that we need a better communication channel than private mails or the Xfce i18n mailinglist, so we’re probably going to have a mailinglist focused on German translations. Other teams might have the same need, so we’d like to do it public and encourage other teams to do the same, maybe officially hosted on foo-projects.org.
Another idea was to take a look at some of the distributions shipping Xfce. Do they have a translation system on their own? Are there potential translators among the users/developers of these distributions? How can we motivate more people to take part in the translation process so that everyone is happy with the result?
We’ve decided to have another German team meeting next Wednesday at 21:00 CET (20:00 UTC). Feel free to join if you’re interested and your German is good.
Today, we had a little discussion about the upcoming FOSDEM in February 2009. Several of us have expressed an interest to go there. With 4.6 out of the door and 4.8 ahead February is a pretty interesting date for Xfce as a project. I’m sure we could come up with several nice presentations and discussions about the future if we were to apply for a developer room. Xfce has been part of FOSDEM in 2005 already but since then a lot of things have changed and many new developers have joined the project, so it would be a great opportunity to finally meet everybody and have a few pints together.
We haven’t decided on whether Xfce is going to apply yet as we’re planning to get the second beta released before. Deadline for developer room applications is 11/22, so we still have some time. Even better, the deadline for the schedule itself is three weeks before the actual event. Enough time to prepare some decent speeches.
I’m pretty excited about all this. There’s a quite a lot of movement in the Xfce community at the moment (and also, related to this movement, a lot of exciting things are happening for me, with UDS and all that). I feel that things are improving constantly in terms of development as well as organization and communication. Now all we need is a proper goal – and FOSDEM might be exactly what we need to discuss things like that.
2AM, time for bed. Have a nice day (or night).
Xfce Commit Messages on IRC
This is a little dumb, but kinda fun. A week or 2 ago I set up a CIA bot in #xfce-commits on Freenode. If you have nothing better to do with your life than watch Xfce commit messages scroll by, feel free to join and idle with the rest of us losers.
Xfce Commit Messages on IRC
This is a little dumb, but kinda fun. A week or 2 ago I set up a CIA bot in #xfce-commits on Freenode. If you have nothing better to do with your life than watch Xfce commit messages scroll by, feel free to join and idle with the rest of us losers.
Xfce Commit Messages on IRC
This is a little dumb, but kinda fun. A week or 2 ago I set up a CIA bot in #xfce-commits on Freenode. If you have nothing better to do with your life than watch Xfce commit messages scroll by, feel free to join and idle with the rest of us losers.Xfce 4.6beta1 Released
Hey all… we just released the 1st beta leading up to 4.6. Go check it out. Full list of changes here.
Xfce 4.6beta1 Released
Hey all… we just released the 1st beta leading up to 4.6. Go check it out. Full list of changes here.
Event sounds in Xfce 4.4 / 4.6
The release-process took a little longer then expected, but its getting better. I’ve just send the announcement that Xfce 4.6 Beta1 is ready for download.
Some people have been reporting that they suddenly had event-sounds in their xfce. This is the result of using a distro that upgraded their gtk to 2.14 and installed libcanberra. With this release of xfce (xfce 4.6 beta1), the event-sounds XSETTINGS are managed, and as a result it is now possible to enable / disable these sounds.
It is important to mention that this feature is NOT present in 4.4. As a result you will experience in the default behaviour for gtk when the XSETTINGS are missing. You get event-sounds when you use Xfce 4.4.x with gtk 2.14 + libcanberra. To remove event-sounds you can do 1 of the following 3 things:
- Remove libcanberra
- Downgrade gtk to 2.12
- Upgrade xfce to 4.6
The first option is obviously the least intrusive one ;-)
Beta release and personal news
For those of you who are eager to test the first Xfce 4.6 beta: We’re running a bit late again. At least the delay won’t be that big this time. Most packages are prepared already and the release will be rolled out tomorrow or the day after that I suppose. To be able to do this we had to add several feature freeze exceptions. If you keep in mind however that we stil have the option to sacrifice the second release candidate to keep up with the schedule, the final release date is not in danger yet.
There are also some news related to my person. Last week I received the official sponsorship invitation to the Ubuntu Developers Summit for Jaunty. So if things go well, I’ll be able to be in Mountain View in December to represent Xfce when the Xubuntu team prepares their next release after Intrepid! This is very exciting and quite a big thing for me. So far I never made it across the pond and I’m not really happy about having to fly 11 hours or more to get there. But then again you just have to take the chances you get otherwise you’ll not receive them anymore at some point. I’ve already turned down the attempts of Google to get me into their internship program last year which was quite frankly stupid. Anyway, I decided to forget about my fear of flying for once and take this great opportunity I’m offered by Canonical. I still need to sort out a few things, get a new passport and prepare for the event itself but I’m quite happy I made this decision.
Xfconf — A New Configuration Storage System
I suppose others have written in broad terms about Xfconf, Xfce 4.6’s new configuration storage/retrieval system, but I guess an in-depth explanation is overdue and is probably up to me.
First, some background.
Xfce has used a configuration system called MCS (Multi-Channel Settings) for some time now, since 4.0 was released near the end of 2003. It’s inflexible and very monolithic. Only a single application (xfce-mcs-manager) is allowed to actually modify settings; all other applications can only query values. That means that the GUI settings dialogs have to run in the xfce-mcs-manager process. The GUI dialogs are implemented in shared libraries that are linked into the xfce-mcs-manager process at runtime. To add more confusion as to its purpose, xfce-mcs-manager also acts as an XSETTINGS manager, automatically proxying the settings stored in a “special” channel.
I had a few loosely-defined goals when designing Xfconf.
- Keep the familiar “channels” concept from MCS, but make the namespaces for settings storage inside channels hierarchical.
- The configuration storage daemon should be able to run without a GUI environment, and the client library shouldn’t have GUI dependencies.
- Get the XSETTINGS manager out of the configuration daemon.
- Integrate “kiosk mode” functionality directly into the configuration storage mechanism.
- Native support for arrays/structs in the configuration store.
- Provide a client library that’s easy to use and exposes commonly-used functionality.
- No client application is special: any app can read or write any setting.
There were probably others, but those seem to be the ones that stick out in my mind after the fact.
MCS used a protocol involving a special X window, X selections, and X window properties to pass settings around at runtime. Obviously this kind of thing isn’t suitable for a configuration system that can run without a GUI, or even on a non-X11 system. So, that was right out. Given momentum over the past couple years, D-Bus seemed to make the most sense as an IPC method. So, the D-Bus API for Xfconf was born. (Please note that I don’t consider this frozen until we release 4.6.0 final. I’ll do my best not to remove or change existing interfaces, though.)
The rest of the story might sound rather gconf-like, and I guess it probably is. There’s a settings daemon (xfconfd) and a client library (libxfconf). Apps use the client library to fetch settings from and store settings to xfconfd. The daemon stores the settings on disk in a format of its choosing and manages the D-Bus interface. D-Bus gives us a few nice things for free; for example, xfconfd starts via D-Bus activation, so there’s no need to include it in any startup scripts or have client applications specifically start it. D-Bus also ensures that two instances of xfconfd aren’t running, fighting over the config store (well, unless you start a separate session bus daemon).
As for settings themselves, you have a channel that holds an arbitrary number of hierarchical properties. Channel names are simple ASCII text strings, like “xfwm4″ or “xfce4-desktop”. Property names look a bit like path names and are, as I said, hierarchical. You can use this to logically organise properties inside your application. Xfdesktop is a good example of this, prefixing menu-related preferences with “/desktop-menu/” and backdrop-related prefs with “/backdrop/”. Xfwm4 is a terrible example of this, with all preferences prefixed with “/general/” for no apparent reason.
Anyhow, we support a variety of different data types: basically all of those supported and marshalable by dbus-glib, plus special 16-bit signed and unsigned types (though those two are pretty hacky at the moment and I’d like to be able to do those in a better way). The client library, libxfconf, lets you set commonly-used data types directly, and also has a generic interface for setting the others.
One thing I really like about libxfconf is its incredibly flexible support for array properties. Any property can be set to an array of values rather than a single value. The values in the array need not even be of the same type. Libxfconf has native support for setting array types, and also can directly map C structs to and from array types, automatically.
A final bit of usefulness is in libxfconf’s bindings mechanism. Libxfconf can “bind” an Xfconf property to a GObject property in your application. If the GObject property changes, then libxfconf will automatically update the value in the Xfconf store. If the value in the Xfconf store changes, libxfconf will automatically update the GObject property. This can greatly simplify the Xfconf code in your application. In your settings dialog, you simply have a single line of code to — for example — connect a GtkCheckButton’s “toggled” property to a boolean Xfconf property. If the user toggles the checkbox, Xfconf gets updated automatically. If the setting gets changed outside the application somehow while the settings dialog is open, the dialog gets updated automatically too. You can also use this functionality on the other “end” of the equation, too: if you use GObjects in your application, and your settings map to GObject properties on those objects, you can bind the properties there, too, and not have to manually take action when the user sets a setting in the settings dialog. Unfortunately, libxfconf only supports setting scalar properties now (not arrays), except for the special case of the GdkColor struct. Hopefully this will change in a future release.
We also include an “xfconf-query” application in the xfconf package, written mostly by Stephan Arts, which is a simple command-line Xfconf client. As you might guess, you can use it to query the values of Xfconf properties from the command-line, or from scripts. However, despite the “query” part of its name, it can modify Xfconf properties as well.
In Xfce 4.4 and below, we had the “XfceKiosk” system, which would allow you to lock down a desktop install so certain settings can and can’t be changed by particular users. It worked decently well, but was sometimes confusing to configure, and the application had to do special things to support it. Xfconf integrates a “locking” system whereby the system administrator can install a normally-formatted Xfconf configuration file with directives that instruct xfconfd to consider some properties unmodifiable by the user (and allows the sysadmin to set defaults too). This takes the burden away from applications to support a particular locking framework, as it’s natively built into the configuration system. (Unfortunately, as of this writing, the locking system isn’t working properly. It’ll definitely be finished by 4.6.0 final.)
So, I guess that’s it. If you’d like to get started with Xfconf, a good place to look would be the API documentation (please note that the API will not be frozen until 4.6.0 final). Otherwise, feel free to ask questions on the xfce4-dev mailing list.
Xfconf – A New Configuration Storage System
I suppose others have written in broad terms about Xfconf, Xfce 4.6’s new configuration storage/retrieval system, but I guess an in-depth explanation is overdue and is probably up to me.
First, some background.
Xfce has used a configuration system called MCS (Multi-Channel Settings) for some time now, since 4.0 was released near the end of 2003. It’s inflexible and very monolithic. Only a single application (xfce-mcs-manager) is allowed to actually modify settings; all other applications can only query values. That means that the GUI settings dialogs have to run in the xfce-mcs-manager process. The GUI dialogs are implemented in shared libraries that are linked into the xfce-mcs-manager process at runtime. To add more confusion as to its purpose, xfce-mcs-manager also acts as an XSETTINGS manager, automatically proxying the settings stored in a “special” channel.
I had a few loosely-defined goals when designing Xfconf.
-
Keep the familiar “channels” concept from MCS, but make the namespaces for settings storage inside channels hierarchical.
-
The configuration storage daemon should be able to run without a GUI environment, and the client library shouldn’t have GUI dependencies.
-
Get the XSETTINGS manager out of the configuration daemon.
-
Integrate “kiosk mode” functionality directly into the configuration storage mechanism.
-
Native support for arrays/structs in the configuration store.
-
Provide a client library that’s easy to use and exposes commonly-used functionality.
-
No client application is special: any app can read or write any setting.
There were probably others, but those seem to be the ones that stick out in my mind after the fact.
MCS used a protocol involving a special X window, X selections, and X window properties to pass settings around at runtime. Obviously this kind of thing isn’t suitable for a configuration system that can run without a GUI, or even on a non-X11 system. So, that was right out. Given momentum over the past couple years, D-Bus seemed to make the most sense as an IPC method. So, the D-Bus API for Xfconf was born. (Please note that I don’t consider this frozen until we release 4.6.0 final. I’ll do my best not to remove or change existing interfaces, though.)
The rest of the story might sound rather gconf-like, and I guess it probably is. There’s a settings daemon (xfconfd) and a client library (libxfconf). Apps use the client library to fetch settings from and store settings to xfconfd. The daemon stores the settings on disk in a format of its choosing and manages the D-Bus interface. D-Bus gives us a few nice things for free; for example, xfconfd starts via D-Bus activation, so there’s no need to include it in any startup scripts or have client applications specifically start it. D-Bus also ensures that two instances of xfconfd aren’t running, fighting over the config store (well, unless you start a separate session bus daemon).
As for settings themselves, you have a channel that holds an arbitrary number of hierarchical properties. Channel names are simple ASCII text strings, like “xfwm4” or “xfce4-desktop”. Property names look a bit like path names and are, as I said, hierarchical. You can use this to logically organise properties inside your application. Xfdesktop is a good example of this, prefixing menu-related preferences with “/desktop-menu/” and backdrop-related prefs with “/backdrop/”. Xfwm4 is a terrible example of this, with all preferences prefixed with “/general/” for no apparent reason.
Anyhow, we support a variety of different data types: basically all of those supported and marshalable by dbus-glib, plus special 16-bit signed and unsigned types (though those two are pretty hacky at the moment and I’d like to be able to do those in a better way). The client library, libxfconf, lets you set commonly-used data types directly, and also has a generic interface for setting the others.
One thing I really like about libxfconf is its incredibly flexible support for array properties. Any property can be set to an array of values rather than a single value. The values in the array need not even be of the same type. Libxfconf has native support for setting array types, and also can directly map C structs to and from array types, automatically.
A final bit of usefulness is in libxfconf’s bindings mechanism. Libxfconf can “bind” an Xfconf property to a GObject property in your application. If the GObject property changes, then libxfconf will automatically update the value in the Xfconf store. If the value in the Xfconf store changes, libxfconf will automatically update the GObject property. This can greatly simplify the Xfconf code in your application. In your settings dialog, you simply have a single line of code to – for example – connect a GtkCheckButton’s “toggled” property to a boolean Xfconf property. If the user toggles the checkbox, Xfconf gets updated automatically. If the setting gets changed outside the application somehow while the settings dialog is open, the dialog gets updated automatically too. You can also use this functionality on the other “end” of the equation, too: if you use GObjects in your application, and your settings map to GObject properties on those objects, you can bind the properties there, too, and not have to manually take action when the user sets a setting in the settings dialog. Unfortunately, libxfconf only supports setting scalar properties now (not arrays), except for the special case of the GdkColor struct. Hopefully this will change in a future release.
We also include an “xfconf-query” application in the xfconf package, written mostly by Stephan Arts, which is a simple command-line Xfconf client. As you might guess, you can use it to query the values of Xfconf properties from the command-line, or from scripts. However, despite the “query” part of its name, it can modify Xfconf properties as well.
In Xfce 4.4 and below, we had the “XfceKiosk” system, which would allow you to lock down a desktop install so certain settings can and can’t be changed by particular users. It worked decently well, but was sometimes confusing to configure, and the application had to do special things to support it. Xfconf integrates a “locking” system whereby the system administrator can install a normally-formatted Xfconf configuration file with directives that instruct xfconfd to consider some properties unmodifiable by the user (and allows the sysadmin to set defaults too). This takes the burden away from applications to support a particular locking framework, as it’s natively built into the configuration system. (Unfortunately, as of this writing, the locking system isn’t working properly. It’ll definitely be finished by 4.6.0 final.)
So, I guess that’s it. If you’d like to get started with Xfconf, a good place to look would be the API documentation (please note that the API will not be frozen until 4.6.0 final). Otherwise, feel free to ask questions on the xfce4-dev mailing list.