Skip to content

libgphoto2 based FUSE filesystem

Merry Christmas, Happy New Year, etc, etc.

I’m currently in Singapore visiting my family for the holidays and I finally caved in and bought myself a digital camera, which happens to be a Canon Ixus 55. It’s all nice and shiny but it doesn’t support the USB Mass Storage class, which means I need to use libgphoto2 based tools to interact with it. So, I thought to myself that there ought to be a FUSE filesystem based on libgphoto2 that handles this. And, in fact, Christopher Lester wrote one. But it doesn’t use libgphoto2 directly, and instead interacts with the gphoto2 command line tool which makes it a bit clunky. As Christopher has no plans to change this, I decided to write a filesystem that did use the library, and I now have a happy 0.0 release here.

As you might imagine, it’s very basic at the moment, but allows you to retrieve and delete files which is the majority of most people’s interactions with a camera. Deletion is very slow for reasons I don’t currently understand, but it does work.

The implementation is rather interesting because the libgphoto2 (cameras in general?) model doesn’t map to filesystem operations terribly well, particularly in the separation of file and directory iteration and the all-or-nothing approach to file access, which should make implementing writing files to a camera rather interesting. As a result, anyone looking at this code will probably be entertained.

And yes, if you read hub’s announcement of the latest libgphoto2 release, you may have noticed that it now exposes mounted Mass Storage class devices. While you could then turn around and mount those using gphoto-fuse, I probably wouldn’t recommend it. 🙂

VMware and the 770

As Christian points out, the final 1.0 release of the VMware Player went out last week. His blog gives a good description of it, so I won’t repeat all that here.

I will, however, point out this, where Zack suggests that anyone wanting to do 770 developement on windows grab the Player and the Browser Appliance VM and just install the Maemo SDK inside it; I’d like to second that suggestion, for obvious reasons.

In fact, the next logical step is to have a VM with the SDK already installed and configured. Anything that lowers the barrier to entry for developers is a good thing. Tommi, any chance of you guys putting one of these together? I’m pretty sure you’ve got a Workstation licence. 🙂

On the subject of the 770, I’ve been continuing work on my port of gweather which is now at version 0.4 (with working icons!). Also, I’m very happy to report that my libgweather refactoring has now been merged to HEAD after Davyd and James reviewed it. I’m really looking forward to James’ GObjectification and HTTPResource rewrite of the libgweather internals – hopefully auto-connect will start working on the 770 after that 🙂

Update: Fixed a mangled tag.
Update: Turns out I had at least 2 1/2 mangled tags…

GWeather-maemo 0.1

Another day, another update. And today there’s a new release as well. I made my planned second pass at refactoring that breaks out the prefs and gconf management into another library. By doing this, the homepage applet can now access the user’s prefs and selected location – making it actually useful. The applet now features a refresh button and clicking on the text will actually have the desired effect of launching and/or raising the full application. Turns out that you do indeed handle the “top_application” message by just presenting the HildonApp object.

I have turned off translations for the locations and gconf schema which shrinks the package down dramatically (over 90%) so you shouldn’t feel scared to install it now. 🙂

I expect my next big step to be to stop trying to reuse the original gweather UI. It’s simply too big for the device. Now that I’ve refactored the useful backend stuff out, I can do this without worrying about having to rewrite that code. I also really want to sort this whole icon theme out and get the weather icons displaying.

More GWeather on 770 progress

Today, I contined my porting of GWeather to Maemo. I don’t have a happy bundled package to throw up right now, but I’m happy with today’s progress.

The first thing I did was put together a libgweather from the backend code. It was originally rather tangled up with the backend requiring knowledge of the applet object and gconf. After refactoring that, I now have a functional library. Using this I was able to define simple homepage applet that currently queries the infamous Pittsburgh default location. I plan to refactor the gconf code out into another library and then use it from the home applet to query the right location.

In other areas, I attempted to set up a script to run the application with support for internet auto-connection. Unfortunately, nothing gets triggered. I believe this is because the auto-connection library isn’t interposing itself in the path that gnome-vfs uses. This seems rather surprising but it’s all I can think of right now. On the size front, I changed the Locations.xml rule to skip the translations which brings the file size down to a more manageable 1.3mb – it now only takes 20 seconds to bring up preferences. Small favours eh? 🙂

Questions that I still have:

  • Why doesn’t the home page wrap a HildonHomeApplet container around user supplied home applets? The lack of this causes them to look inconsistent as the screenshot below illustrates.
  • If a home-applet depends on a library (my libgweather in this case) that is installed in /var/lib/install, can it be found? My experience in scratchbox is that it cannot, and you have to symlink the library into /usr/lib, which seems wrong.
  • What’s the right way to install icons into the icon-theme? Just put them in /var/lib/install/usr/share/icons/? The hello-world example does this and fails miserably.
  • What should a HildonApp based application do in response to a “top_application” event? If the window is currently hidden and you get one of these events, it seems that nothing happens automatically.

Anyway, it’s been a great learning experience doing this. I hope to have another drop tomorrow.

The Home Applet

GWeather for the 770!

So, I decided that I would take the opportunity presented by the thanksgiving weekend to start work on my port of GWeather to Maemo and the Nokia 770. And I’m pleased to announce that I’ve got something that you can actually run, even if it’s not particuarly usable right now.

It runs as a regular application (not as a home page applet yet) and provides the weather information about a single location. There are a lot of caveats that I’ve listed in the readme file, but it basically works, which is pretty neat.

The biggest problem is that the locations.xml file is 18mb in size which is a lot of space to take up and it also causes the preferences dialog to take about 30 seconds to appear because the file is being parsed. I’m not sure what would be a better format to use, but one is needed.

I’ve been writing the code with an eye to keeping it mergable back to gnome-applets, because most of it is unaffected. I think the refactoring should be healthy in general because it will make life easier when gnome-panel goes away. If there are any gnome-applets maintainers reading this, I’d like to hear their thoughts.

I’ve thrown up the source and deb and slackware packages here along with the readme.

Here’s a couple of screenshots: (I was too lazy to make thumbnails. Sorry)

Main window
Details

Nokia 770 casting?

So, I was listening to the BBC Go Digital show on the drive home from work just now and they were going on about Podcasting as they are wont to do, and I thought to myself: The 770 is an interesting little device – it’s both capable of being a podcast device and a podcast downloader. You’ve got fast wifi access and if you stick a 1gb MMC card in there, enough space for a respectable collection. And, of course, it’s got decent audio output capabilities. Now, this is not a unique combination – most modern PDAs will qualify too – but I think we’ll all agree it’s cooler than a WinCE PDA 🙂

So, the first step is someone needs to port, or write, a suitable podcast manager for the little fellow. A little thought is required here, because I imagine that many people would still download stuff on their desktops and transfer them over – so you want to keep your subscriptions and such in sync. A simple way would be to store that information on the MMC card so that a desktop manager could sync it when you plug the 770 in.

Anyway, food for thought. I still intend to tackle gweather first, so if you’re looking for a My-First-Maemo-Applicaition(tm)… 🙂

Jumping on the 770 bandwagon

Well, I think it’s time for me to join in the fun. My 770 showed up on monday, despite the complete lack of email from the fullfillment company; but I’ll take underpromise/overdeliver over the alternative any day 🙂

I’ve been playing around with it over the last few days and it really is a joy; the screen is spectacular and I’m particularly impressed by the newsreader application. The only knock I can give it is that I’m seeing the same 802.11 instability that a few other people have reported; bluetooth pairing is solid, however. RealNitro has done some experiments with forwarding X applications to the 770 but to me it seems that it would be more rewarding to forward an entire X session running Maemo. That would take care of worries about things like virtual keyboard input and window management. Has anyone tried forwarding a session like this? I assume it’s probably a little tricky because you’d have to get all the networking set up without the X session running.

As for My First Project(tm), I’m currently planning to try porting gweather as a home page applet. This should be an interesting experience as home page applets are not covered in the tutorial, although Tommi says they are supposed to be in there. I haven’t looked through the examples yet, but hopefully there’s a relevant one. From what I understand of the existing applets, the actual applet itself is supposed to be very minimal, as it’s running inside the home page process, and that it should turn around and launch a regular application when activated. The clock seems to be a good example of this behaviour. I assume that some sort of libosss/dbus magic is going on in that process but I haven’t investigated yet.

Are you ready to take the autostart challenge?

Now, here’s one for the masochistic types out there: As far as I can tell, there is no way to for an application to be installed such that it will startup as part of every user’s session the next time they log in to GNOME. Mark can probably tell me if this is absolutely true or not, but if there’s a way, I can’t find it.

On windows you can add an entry to HKLM/Run and in KDE you can stick a .desktop file into /opt/kde/share/autostart. I know Mark’s vision for the future of gnome-session includes this revolutionary capability, but for right now, it seems I’m not going to get anywhere fast. So, what can we do? There’s a half measure that can be taken, which is to edit the default.session but this will only affect users who log in for the first time after installation, which won’t be the common case. On top of that it doesn’t seem possible to add non-session-aware programs this way. gnome-session does know how to read the session-manual file but that’s per user and there’s no system wide equivalent.

We’re currently experimenting with having our system daemon detect that a user logged in and then launching the per-user process on their behalf. But this is limited because you can only reliably detect ?DM managed logins (as opposed to startx or similar) and the launched process will lack the full environment of the session.

So, the question I’m posing: Is there a proper way to install an auto-start app for GNOME? If not, are there saner alternatives to the current plan?

Update: Just to clarify: I know that the session supports restarting running applications – I’m saying I can’t find a way to say that an application should start, for the first time, the next time a user logs in.

So much for that idea

Well, I guess this conversation will have to continue in public. Caleb, if you want to take advantage of the fact that my blog supports followup comments, please feel free.

Thank you for clarifying what you meant with respect to “id” vs “in”. I though that the “id” attribute in question was on the ‘filter’ tag rather than the feGaussianBlur tag. The former seems to be a non-negotiable attribute while the second can, as you say, be done without. If I was aware of this at the time, I’d certainly have immediately made that change, or discarded the attribute completely, but as I thought the offending id was the ‘filter’ id, the only way to avoid the problem was to remove the gaussian blur, and that was the precedent that I didn’t want to set. I certainly have no objection to tweaking the file without affecting the artwork, and I should go do that right now! It would have saved us much grief if we’d been aware of it at the time.

I wondered to myself whether the first blog entry was belabouring the point, and clearly it was. I did not, and do not, want to create the impression that you and the rest of the librsvg team are not responsive; My apologies.

Caleb will love me for this…

Caleb, I’m sure you’re less than enthused about seeing that bug now mentioned a third time by me, but what can you expect? 🙂

First off, I have no nothing but praise for how quickly it was handled; the bug was fixed and a release made within 24 hours. And for distributions like Ubuntu which track upstream releases, we know that users will almost instantly see the fix. But when the bug manages to sneak its way into a distro that has a policy of not pushing out upstream updates, then users of that distro will suffer indefinitely unless and until an updated package is specially made by the distro publisher – and that’s what happened with SuSE 10 – the only distro unlucky enough to cut a release with the bug. So, until the updated package was released yesterday, the bug continued to be very real for SuSE 10 users and as you’d expect, they were very quick to blame us when the crash happened. Would you rather I not have told Joe what the problem was and how to fix it? As I said at the beginning of that post, I’d rather just have written a comment to his blog entry but that option wasn’t available. Heck, I’d rather that this be a comment to your blog entry, but that’s also not an option.

I also don’t understand what you mean by saying that an “in” was mispelled as “id”. The bug in question was that the library was attempting to parse the “id” attribute of filter elements but was accidentally reading out of the xml into one variable and then attempting to manipulate a second, otherwise unused, variable that had been initialised to NULL as if it was the id, which was causing it to fail an ASSERT that the id was not NULL. I fail to see how changing the svg file so that the “id” attribute was an “in” attribute would have helped. Ignoring the apparent requirement that all elements have ids, we’d obviously just hit the same ASSERT or worse if the attribute was missing. The only work around I could conceive of would be to alter the svg to not use filter elements at all, and I considered that excessive.

I don’t like the idea of harping on about this bug because I know you guys responded to it immediately and that you’ve been doing a lot of cool things since then, but it only became old news for SuSE 10 users yesterday. Like you, I’m very much hoping to never have need to talk about it again.