gplugin 0.0.1^H2 released!

After *MANY* months of on again off again coding I'm very proud to announce version 0.0.2 of GPlugin.

Version 0.0.1 had a broken pkg-config file, which I fixed in 0.0.2... I knew I was forgetting to test something...

GPlugin is a library that will give your program GObject based plugins.  Right now it only supports native (compiled plugins), but there are plans for at least a python loader and whatever else anyone wants to write.

During this release I transitioned this project off of guifications.org to bitbucket.  All GPlugin related business (bug reporting, file downloads, etc) should be done at the bitbucket site.

Also, documentation is in the source and will eventually be built/posted once the gobject-introspection guys figure out whats going on with g-ir-doctool.  Right now you can build the docs and open them in yelp, but not devhelp. I'll put something on the bitbucket site soon for how to do that.

Source tarballs can be found here: zip gz bz2

nodm and matchbox window manager and auto starting applications

I'm working on a project for work that is based around a live distro.  For the live distro building, I went with live-build since Debian is by far my favorite distro.  The live build was pretty easy to implement, and I'm not going to bore you with the details when there's plenty of documentation out there, especially the live-manual.  This post is all about how to get Xorg started and how to launch an application when Xorg starts up without diverting files in other packages, or having a match install anything to a users home directory.

The clear start to this task is nodm.  It'll automatically login as a user and start your xsession.  If you don't have an xsession installed, it'll fall back to the normal Debian xsession script that'll just launch an xterm.  This is simple enough, but remember that without a window manager, you're not going to get any of the standard desktop magic that the freedesktop.org window manager specification gives you.  For example, being able to call gtk_window_maximize.

To fix that problem I went with matchbox window manager.  It's very light weight window manager meant mostly for mobile devices and runs apps in full screen, thus eliminating my need to maximize the application window.  Matchbox registers itself as an alternative for x-window-manager under Debian which, in this bare bones approach will start matchbox on boot, but no apps.

Luckily, the matchbox package depends on matchbox-common and matchbox-common contains /usr/bin/matchbox-session.  This script looks for a session script and will execute it, if it doesn't find one, it'll launch matchbox-desktop and matchbox-panel in the background, and then launch matchbox-window-manager in the foreground.  The real awesomeness here, is that matchbox-session checks if there is an executable script named session in /etc/matchbox/.  What this means, is that you can easily create a package that depends on matchbox and install that file.  This fulfills all of our requirements!!  But wait, matchbox-session won't be called from nodm...

Solving that problem is actually a lot easier than you're probably thinking.  Debian's Xsession scripts give a higher priority to x-session-manager which is in the alternatives system.  So all we need to do, is to register matchbox-session as an alternative for x-session-manager.  Once this is done, our custom /etc/matchbox/session will get executed and we're good to go :)

Due to NDA's and stuff, I can't post my exact package here, but here's the jist of it.

Make sure your control file depends on "matchbox" (that's the meta package for matchbox and will pull everything in); you can probably clean it up to just matchbox-common and matchbox-window-manager, but I leave that to you.

Next create a postinst script that contains the following:

#!/bin/sh
set -e
case "$1" in
        configure)
                update-alternatives --install /usr/bin/x-session-manager \
                        x-session-manager /usr/bin/matchbox-session 50
        ;;
esac
#DEBHELPER#

and a prerm which contains the following:

#!/bin/sh
set -e
case "$1" in
        remove)
                update-alternatives --remove x-session-manager /usr/bin/matchbox-session
        ;;
esac
#DEBHELPER#

Then create your custom session script.  Mine looks something like this:

#!/bin/sh
application &
exec matchbox-window-manager

Make sure all three of those are executable, add the session script to your install file, fire off debuild  and you should be good to go.

I hope this helps other, since googling for this earlier came up pretty empty :)

The corporate software world should be ashamed of themselves...

So a few days ago I started tinkering with my Macbook again.  It's been awhile, and I was using macports, so it was seriously out of date.  I upgraded the pieces I immediately needed to test some code.  Then I decided to update the rest of my installed ports over night.  When I got home from work the next day, the updates had failed for numerous reasons.  I spent the majority of the night trying to fix these issues.  After a few hours, I decided to look at homebrew which I just discovered the other day.

So I installed homebrew and started installing stuff, except I was getting a failure with "linking" packages.  I tried sudo brew link package and that seemed to work fine.  But I Google'd it anyways, trying to figure out what was going on since you're not supposed to need sudo for homebrew.  I ended up reinstalling homebrew after making sure /usr/local was set to mode 775 with root:admin for the user and group.  Now, more packages than not are linking correctly.

Now aside from all of this, homebrew was telling me to update XCode to 3.2.6.  Okay, simple task right?  Yeah, not at all.  Now, when I got my Macbook it came with Leopard installed.  At some point I installed XCode from the install disc.  I'm not sure what version, but I'm assuming it was 2.x since I never actually checked it.

Anyways, being computer savvy I went, "hmm, XCode should just update through software updates right?". So I fire up software update and, you guessed it, everything was up to date.  "Um, that's not right" I said.

Okay, so the AppStore, they'll have XCode available, right?  I fired up the AppStore for the first time ever, do a search for XCode, and see XCode 4.  Cool, bonus updates :)  I hit install, and I'm greeted with the following:

Alright, the AppStore is out of the question, because to the best of my knowledge, Lion doesn't support my Macbook and I'm not going to risk $30 to see if I'm right.  So I do a bit of Googling and discover that you can get a free XCode 3.2.6 at developer.apple.com.  So I head over there, and all I see is XCode 4 again.  I also see a link to get some developer access or support for XCode for $100 a year, for a tool they give away for free, there are other frills they throw at you as well, but yeah I'm good.  At any rate I still can't find a link to XCode 3.2.6.

I do some more Googling and find a direct link to the XCode 3.2.6 page.  Once on the page, I hit download and wouldn't you know it, I need an AppleID to download it.  So I say to myself, "It can't be that bad, just username, password, and email right?".  I click the register link, and boy was I wrong.  They want your full name, street address, email address, home phone number, possibly even your first born.  So I threw that option out.

At this point I figure I'm going to have to pirate it.  It's a free download, but let's be honest here, I've already gone through more work than most people will to try and get this setup.  I ask around and no one has it.  I don't want to hit some random site for it, because who knows if it's been tinkered with.  Then it dawns on me...

I never installed XCode from the Snow Leopard install disc.  So I dig through quite a few boxes of computer stuff and eventually find the disc.  I throw it in, go to optional installs, start the XCode installer, and hooray! it'll update my existing install.  The install didn't take horribly long, but when it finishes, I fire up XCode to check the version... 3.2.

Okay, so I'm making progress, I'm on 3.2 now, maybe I'll have updates in software updates now.  So I then fire up software updates, and sure enough, there's an update for XCode to 3.2.6.  After a nearly 700mb download, XCode 3.2.6 is finally installing.  After about another 30 mins, I FINALLY have it installed and up to date.

So what's the point of this post?  Simplicity.  XCode is a free download and as I've mentioned, it comes free on your install disc.  Why in the hell did I have to spend 2 days to get it updated?  Only Apple can answer the question of why they have made their development software such a pain in the ass to install/update.

What I really want to know is, if I'm updating my system which has XCode installed on it, from a disc that's installing the new version of the OS, which just so happens to also have an updated version of XCode on it, why the hell didn't the OS installer run the installer for XCode as well?

What I'm really saying here, is that the OSX installer fragmented my machine instead of automatically running the XCode update or simply asking me during install.  See, they simplified the installer, so what if a few developers have to suffer.  But even then, this is a horrible solution as well since you'll still get the software update to bring XCode back up to 3.2.6 and waste even more time.  Which leads me to the end of my argument.

It is my belief that if you're going to have an update tool (which is kind of like a package manager), it should be able to update software from any version to the current version.  This is, for lack of a better word, simplicity at it's finest.  In the diagram below I have mapped out the course I had to take to update OSX and XCode, this is the black and red edges (arrows for the non-diagram aficionados).  In an ideal and simplified world, I would have only had to have followed the blue edges.

So when people say Windows or OSX are easier, I can now add to my repertoire that I have never had to upgrade a piece of software to an intermediate version to be able to upgrade it to the latest and greatest version under any Linux, ever!

This, once again, has shown me that the corporate software world is completely and utterly disconnected from their user base, so much so that they'll try to trick them out of money to get a tool they give away for free, if you're willing and able to jump through the hoops that they've thrown in your path.  To me, this is nothing more than extortion and they should be ashamed for making it so difficult.