Lazesharp.net

The title for this post is a little misleading because what I’m proposing is both a frontend and a backend for configuring FUSE-based filesystems.

This started off with me spending 2 days hacking together a small PyGTK tool to mount SSHFS filesystems. It quickly became apparent that my limited PyGTK skills had left me with some pretty ugly code. So, with a little more experience under my belt I decided to start again.

However, this time I’m not just going to tackle the mounting and unmounting of SSHFS filesystems - instead I plan to build a tool for mounting and unmounting any FUSE-based filesystem (whether it’s local or remote) and have it automatically mount selected filesystems on start-up.

I now have a basic specification which calls for the following major components:

• A new file, ~/.fusetab, that will contain definitions for all your FUSE-based filesystems.
  • It will need to contain: FUSE driver (e.g. sshfs), filesystem path (local or remote), mount point and a flag to determine whether it should be automatically mounted on startup.
• A PyGTK frontend to manage the filesystems defined in ~/.fusetab.
• A fast, simple Python script to parse ~/.fusetab on startup and automatically mount the specified filesystems.
• A shared library, likely a simple Python class, that encapsulates a filesystem with methods to mount, unmount and get the mount status.

There will need to be hooks defined in the shared library that allows drivers to define additional creation and pre/post mount/unmount behaviour (i.e. when mounting over SSH for the first time it should attempt to append your local ~/.ssh/id_rsa.pub to your remote ~/.ssh/authorized_keys in order to remove the need for a password on-mount).

FUSE drivers will also have to instruct the shared library exactly how to mount filesystems. This I haven’t fully researched but I’m hoping that the Python FUSE bindings themselves will have something to do this elegantly, otherwise I’ll have to have the driver define the CLI program to execute for mounting filesystems.

If anyone reading this has any thoughts on this, especially regarding its design, please comment, I’d love to hear from you.

The Gnome desktop has for a long time, been a collection of related projects. The official distribution of Gnome generally includes only those projects that have been declared “a part of the Gnome desktop” - anything that fits well and complies (loosely) with the Gnome Human Interface Guidelines (HIG).

It’s a shame in many ways because it leaves the Gnome desktop feeling incomplete. Recently I’ve been thinking long and hard about the Gnome control panel applets (cutely abbreviated “capplets”) and how best to tackle them. Generally, I’ve found them to be a bit fragmented, with often related options in totally different capplets or with seemingly vital options missing entirely.

That’s not to say there’s a lack of good software and developers out there making such programs for Gnome, but unfortunately they appear either unwilling or unable to integrate this work in to the Gnome desktop itself.

Case in point: Today I found out about sysinfo, an application for displaying useful system information in a user friendly way and is miles better than the standard “Device Manager” capplet. It’s written for Gnome in GTK+, so in theory, there’s no reason why it shouldn’t be a part of the Gnome desktop. It would require fairly minor changes to integrate it in to the Gnome desktop as a control panel applet so why not?

Sysinfo isn’t alone, there is a multitude of applications and especially applets that provide much needed functionality and yet hasn’t been included in the Gnome desktop. All that would be required is someone from Gnome to contact these developers and say “Hey, you’ve got a pretty good thing going there, with a few small changes/additions this’d fit great in to the Gnome desktop.”

If I was approached by a seasoned Gnome-er and asked to incorporate my application in to Gnome, I’d leap at the chance. Especially if it’d fill a whole and make the Gnome desktop just that little more complete.

Gnome 2.18 has been released, but after looking at the release notes, I feel this release is much less significant than people are making it out to be.

Compare the release notes of the last 3 releases of Gnome with that of Gnome 2.18:

• Gnome 2.12 release notes
• Gnome 2.14 release notes
• Gnome 2.16 release notes

The 2.18 release notes are important because they are a single page, whereas the others are all split over multiple pages - each one of a length that rivals the entirety of the 2.18 release notes.

Are the release team getting lazy in their documentation? Or has Gnome development slowed significantly over the last 6 months resulting in a fairly dull release.

I’ve heard reports that there are “numerous performance improvements” in 2.18, but they’re not documented in the release notes - unlike in previous releases.

Does this mark a change in the detail to which releases are documented? I hope not.

I’m no artist and when it comes to design it usually takes me several attempts to get it right. This is where rapid prototyping comes in handy. Being able to quickly and easily produce a design, twist, turn and tweak it or simply throw it away and start again is a vital process to any application design.

Step up Glade

Glade is probably one of the most underrated development tools for Gnome. It makes prototyping an interface a sinch, with no need to worry about typing out laborious GTK+ code; move everything around, add and remove features from your design and mess around with settings quickly and easily until you have something you’re happy with.

Once you have your final UI design, you have two options. Either use libglade to set up your application UI or convert the glade UI in to real GTK+ code by hand.

The former is far simpler, but the latter adds more flexability, removes redundant widgets and a dependancy on libglade and increases performance.

Converting the Glade XML by hand isn’t as much of a chore as it sounds. Widgets in the Glade XML only define options that have non-default values so you simply need to arm yourself with the GTK+ documentation, run down the XML and implement each widget, adding children where necessary.

Guest starring: Anjuta

While Glade is great for prototyping a UI, testing your UI (Glade appears to render slightly differently to GTK+, so it’s a good idea to run the prototype properly), converting it to GTK+ code and of course, writing the actual program code is a necessity. While gedit, vim and emacs are all fine for the job, creating a source tree and build system for your application can be a bit of a nightmare.

There’s nothing worse than spending more time debugging your build scripts than your program code.

Anjuta makes it all easy - while it may not generate the most optimal build scripts - it does a good job of providing you with a source tree that will build without the need for any tweaking. Which is perfect for testing your UI prototype quickly and without fuss.

I’m just starting out with GTK+ programming and, in fact, C; but I’m already finding tools that make the learning curve so much less steep.