Long Overdue Update
I haven't posted anything in a while, but I'm not complaining. The last month I've been mostly busy pretending to be busy. Ok, to be honest, that's not entirely true. Over at Xfce, we have achieved a lot in August:
- We've moved all Xfce repositories (including the goodies) over to Git. Kudos to Brian for doing most of the work.
- All Xfce translation updates are now submitted via Transifex. Thanks to the Transifex developers for all the support and for being such a friendly bunch. It amazes me that Dimitris, the founder of Indifex, is also active on our translations mailing list to support people!
- The migration of the Thunar core to GIO is complete and has been merged into the main development branch. The overall delta was 2.9MB, although admittedly, a big part of that is due to the removal of ThunarVFS, so I can only take credit for about 16,000 of the 24,335 insertions and 6,000 of the 41,356 deletions.
- We've kicked off the Xfce 4.8 development cycle on August 16th. The schedule and all other details are available on the wiki. Xfce 4.8 is scheduled for April 12th, 2010. Expect development releases of the various core components soon!
Other things I've been planning to blog about but didn't have the time to:
- Samuel is still busy setting up Buildbot. With less time than he had hoped for at hands this might still take a while.
- I was provided with a free Linutop 2 in June. I'd like to thank the Linutop company again for this gift! So far, I've only found the time to give it a few test boots but I'm planning to set it up as a Xfce test machine soon. Its limited hardware makes it much better platform than my rather powerful laptop and/or virtual machines for testing the speed and memory demand of Xfce.
- My thesis is progressing slowly. I think I have at least 3/4 finished now. I'll keep you posted about the result. I'm hoping to kick off the six month learning phase for my final exams before October because a friend of mine is already waiting for me. ;)
Build a project with Vala
This post is about using Vala in a project but in the end provide the C code for the releases. I think that this is very essential and that releasing source code to be build from Vala is wrong. Vala will always rewrite the code to GObjects in C, but has already proven that compiling the same code from two different versions of Vala will fail. So when you are doing releases with Vala you will break your releases sooner or later. Another good point is when the Vala code is compiled on top of patched vapi files, doing only C compilation with the releases will drop the requirement to apply them.I'll take as example the Autotools, if you are using a different tool-chain you can surely adapt it. The idea is simple, the Vala sources are only compiled in maintainer mode. When you compile the application from the development branch you will usually have a script called
autogen.sh to build the configure script that will automatically be executed with the parameter --enable-maintainer-mode. When providing the distribution tarball that is created with make distcheck, the configure script will not be run with that parameter (except if specified by hand) and the source files to build from will be filled in with the C filenames.The example below is very generic and can be copy/pasted but should be adapted.
Autoconf script
1. The initialization of Automake and the maintainer mode in the autoconf script. The Automake version is checked for 1.11 which is the first version that comes with Vala support. The extra dist-bzip2 argument is there to provide an extra bzipped distribution tarball as you guessed it.AM_INIT_AUTOMAKE([1.11 dist-bzip2])2. The check for Vala only on maintainer mode. The AM_PROG_VALAC defines the variable VALAC that can be reused inside the Makefile.am files and accepts an optional version check.
AM_MAINTAINER_MODE()
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then3. It is possible to sum up the build configuration at the end of the autoconf script.
AM_PROG_VALAC([0.7.4])
if test "x$VALAC" = "x" ; then
AC_MSG_ERROR([Cannot find the "valac" compiler in your PATH])
fi
fi
echo
echo "Build Configuration:"
echo
echo "* Maintainer Mode: $USE_MAINTAINER_MODE"
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
echo
echo " * Vala: $VALAC"
echo
fi
Automake script
1. The declaration of the Vala sources and their respective compiled C sources.product_VALASOURCES = \2. Use the special BUILT_SOURCES variable to build given targets before running a dist with e.g. make distcheck. This usually done in maintainer mode, as in this case to be sure the releases won't have anything to do with Vala.
obj1.vala \
obj2.vala \
main.vala
product_VALABUILTSOURCES = $(product_VALASOURCES:.vala=.c) product.h
if MAINTAINER_MODE3. The final sources for the product are filled in with the generated Vala sources. The Vala sources are not passed to any SOURCES which is why they are passed to the special EXTRA_DIST variable.
PACKAGES = --pkg=gtk+-2.0
BUILT_SOURCES = vala.stamp
vala.stamp: $(product_VALASOURCES)
$(VALAC) --vapidir=$(srcdir) $(PACKAGES) $^ -C -H product.h
touch $@
endif
product_SOURCES = \
random-source.c \
random-header.h \
$(product_VALABUILTSOURCES)
EXTRA_DIST = $(product_VALASOURCES)
if MAINTAINER_MODE
CLEANFILES = \
$(BUILT_SOURCES) \
$(product_VALABUILTSOURCES)
endif
That's it
There are many existent Vala projects nowadays from where you can pick up new ideas, and this post is just an example amongst many others. The full example is available in the xfce4-vala bindings.Update: I corrected some mistakes seen in green in the script portions. If VALAC is unset the configure script must quit otherwise the resulting Makefiles will have empty commands instead of /usr/bin/valac. Also the generated header file must be passed to product_VALABUILTSOURCES otherwise it would have been left out from distributions as it wans't passed to any product_SOURCES nor EXTRA_DIST variables.
Code Comments
I’m a bit of a minimalist when it comes to commenting my code. This is probably in some ways a bad thing; code that is completely obvious to me in its function may be difficult to understand for others, and I’m often not so great at realizing this on the first pass. So that leads [...]The new Xfce release manager for users and packagers
I deleted the last post about the release manager because due to the high number of changes I made it was soon out of date. So let's get back to the topic again. I'll split it up into two posts: this one which is for users and packagers mostly, and another one directed to developers or, more precisely, maintainers.
Let's start with a simple question (with a long answer): what am I talking about and what is this release manager anyway?
First, a bit of background. At Xfce, we are currently working on improving our infrastructure. We are about to switch to git and along with that, our repository layout will change. Xfce and goodie repositories will no longer be found in separate locations. We thought it would be nice to implement the same layout in other places as well, like Bugzilla and our download archive.
Nick went ahead and enabled so-called bugzilla classifications and used those to resemble the repository layout on bugzilla.xfce.org.
That still left us with separate download archives for core Xfce, goodies and other stuff. For goodies, we had a very simple release manager web application written in PHP that uploaded tarballs to http://goodies.xfce.org/releases/ and was able to send release announcements to mailing lists. The design however was very limited. For Xfce releases we had nothing like that. Uploading and copying tarballs around manually for each release was what we had to do.
And this is where the new all-in-one release manager comes into play. It's called Moka, it is written in Ruby using Sinatra, ERB and JSON and the source code can be found here.
For you as a user or packager, it does two things:
- it uploads all (core and goodies) tarballs to http://archive.xfce.org which uses the same layout as our future git repositories and bugzilla
- it pushes release announcements out to mailinglists, Atom feeds, identi.ca and Twitter.
Download archive
The layout is described in the archive reorganization section of this mail. It contains releases of all projects, be they goodies, core components or something else. Again, we use classifications like apps, libs, bindings or core to add semantics the archive layout.
All tarballs are accompanied by an MD5 and SHA1 checksum file. In the future, we're hoping to also support PGP signing of tarballs. So, for the 0.4.0 release of terminal, you'll get these three files:
- Terminal-0.4.0.tar.bz2
- Terminal-0.4.0.tar.bz2.md5
- Terminal-0.4.0.tar.bz2.sha1
If you download one of the checksum files along with the tarball you can verify the download went fine with md5sum -c Terminal-0.4.0.tar.bz2.md5 or sha1sum -c Terminal-0.4.0.tar.bz2.sha1.
Announcements
Release announcements are sent to different mailinglists (almost always to xfce@xfce.org, so you're on the safe side subscribing to that one), identi.ca/xfce and twitter.com/xfceofficial.
The status updates on identi.ca/xfce and twitter.com/xfceofficial use the following format:
terminal 0.4.0 released! http://releases.xfce.org/feeds/project/terminal !Xfce
Atom feeds for all projects are available on http://releases.xfce.org/feeds/project/. There also is a dedicated feed for bundle releases of Xfce core components available on http://releases.xfce.org/feeds/collection/xfce. These feeds provide more information about the releases than the posts on identi.ca or Twitter do. There's no central feed for all releases yet, but you can as well subscribe to the feeds offered to you by identi.ca or Twitter.
Mailinglist announcements and feed posts use the same format. Here's a good example for a project release announcement:
xfce4-power-manager 0.8.3 is now available for download from http://archive.xfce.org/src/apps/xfce4-power-manager/0.8/xfce4-power-manager-0.8.3.tar.bz2 http://archive.xfce.org/src/apps/xfce4-power-manager/0.8/xfce4-power-manager-0.8.3.tar.bz2.md5 http://archive.xfce.org/src/apps/xfce4-power-manager/0.8/xfce4-power-manager-0.8.3.tar.bz2.sha1 SHA1 checksum: 2d531b9fc2afec3cff034e1acfc331051d8bf47a MD5 checksum: 0db6b6f5b13c8b0829c6a07b7dfdc980 What is xfce4-power-manager? ============================ This software is a power manager for the Xfce desktop, Xfce power manager manages the power sources on the computer and the devices that can be controlled to reduce their power consumption (such as LCD brightness level, monitor sleep, CPU frequency scaling). In addition, xfce4-power-manager provides a set of freedesktop-compliant DBus interfaces to inform other applications about current power level so that they can adjust their power consumption, and it provides the inhibit interface which allows applications to prevent automatic sleep actions via the power manager; as an example, the operating system’s package manager should make use of this interface while it is performing update operations. Website: http://goodies.xfce.org/projects/applications/xfce4-power-manager Release notes for 0.8.3 ======================= - Provides more standard org.fd.PowerManagement DBus methods and signal (bug #5569). - Make it possible to compile without network manager support. - Add never show icon to the system tray configuration (bug #5613). - Fix a typo that prevents from getting the correct critical configuration (bug #5619). - Use Gtk as a popup indicator to show the brightness level as the cairo seems to be problematic on some hardware. (bug #5544 #5632). - Better alignement in the interface file, worked by Josef Havran.
This is what the new release manager does for you. I think or rather hope that it provides an efficient way to to keep you posted about what's going on. And hopefully, all of you enjoy our efforts to unify our infrastructure and by that make things more transparent. As always, if you have any ideas for improvements, let us know!
Notes, notebook, tabs
The notes plugin features a notebook since the port to Xfce 4.4 and in the last release I hide the tabs and gave a try to a new navigation bar. Seems you like the tabs so no worries it will be back in the next release.Update: Revision 7717 has an option to show the tabs.
Appfinder Ideas
I've switched to using xfce4-appfinder as a replacement for xfrun4 recently. It's a pretty nice experience overall, even though I'm missing the ability to launch arbitrary commands like I could with xfrun4. So today I had an idea on how we could improve this: all we need is a custom tree model and a plugin infrastructure to allow plugins to be written as appfinder item providers. They could provide any kind of actions depending on the text typed in by the user. Here are two example mockups:
Implementing this should be relatively easy with a bit of experience in GTK+ and GLib. It's not as powerful as GNOME Do but it's also much more simple ... and useful, at least as far as I'm concerned.
Anyone up for the task? Maybe this could be one of the projects for next year's GSoC, should we decide to apply.
iTunes Protected vs. Unprotected
Dear lazyweb,
A friend of mine has released an album on the iTunes store, and I want to buy it to support her. Of course, I don’t want to buy it there if it’s a DRM-protected AAC file. Anybody know how you can tell before you buy? I checked both using iTunes on a Mac, and on the iTunes Store app on my iPod Touch, but I can’t seem to figure it out.
It seems her album is also sold on Amazon (cheaper, even), and they sell 256kbps MP3s, so I’ll probably end up doing that regardless. But it would be nice to know if you can figure this out for Apple’s store too.
Update: It appears everything on the iTunes store is now DRM-free. Interesting.
Preview: Browsing SFTP with Thunar
It feels like I'm finally getting somewhere. My GIO migration branch of Thunar now generates thumbnails using the D-Bus service provided by Tumbler (which is still in development but almost ready for a release). It has no references to ThunarVFS anymore, except for one function required by Thunarx, the Thunar extension library. The next step will be to prepare thunarx-2 with a ThunarVFS-free API. All plugins shipped with Thunar itself need to be updated. ThunarVFS will be moved out of the Thunar tarball and into its own, so that applications depending on it will still work. And then we only need to fork the HAL based volume monitor from GVfs and of course thunar-volman needs to be rewritten on top of GIO ...
Anyway, just a few moments ago, I did something I thought is worth sharing: I browsed one of our servers remotely over SFTP! Mounting still needs to be done from the terminal but after that, you can simply type in the SSH or SFTP URI and it will display its contents. Thumbnails are generated over D-Bus. Here's a screenshot:
Update
Thunar can now mount remote URIs on demand:
FTP browsing also works:
On In-Kernel Drivers
It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for [...]Xfce4 Screenshooter 1.6.0
I'm pleased to announce the 1.6.0 release of Xfce4 Screenshooter. This cycle was quite long because I had some exams and the number of implemented features is bigger than usual.
First, there is a brand new interface based on a review by Fabrice Viale : it is simpler and more polished. This new interface also allows you to choose whether the mouse cursor should be captured and whether the application should be closed after taking the screenshot. Here is a screenshot of the application:
It is now possible to save screenshots on any remote share supported by GVFS: ftp, sftp, samba... You just need to connect to a share or a distant computer using Gigolo or gvfs-connect and it will be displayed in the sidebar of the save dialog.
This release also features the possibility to host screenshots online, on ZimageZ. You just need to set up an account on their website and you will then be able to upload your screenshots to ZimageZ directly from Xfce4 Screenshooter. This feature is still a bit experimental and will be improved in the next release: for example accents in the user name or password cause a fail during the upload...
There are also some other small changes which can be found in the changelog. I would like to thank Jannis Pohlmann (for his help concerning jobs and threads), Fabrice Viale (for his interface review), Mike Massonnet and Enrico Tröger (for their various patches) ,Yves-Alexis Perez and Ali Abdallah (for the testing and the suggestions). And last but not least, the translation team who did a great job by adding and updating a lot of translations of the application and of the documentation.