One of the greatest strengths of open source – freedom of choice and open code for anyone to work and develop on – is also one its weaknesses. The Portland project may be about to change all that.
Without getting too deep into the philosophical and developmental debates, one of the greatest strengths of open source — freedom of choice and open code for anyone to work and develop on — is also one its weaknesses. In a world where everyone can do their own thing, standardisation and consistency aren’t usually invited to the party. The LSB (Linux Standard Base) was one key step in helping to solve this, and now Portland is another.
Many years ago now, from two completely separate toolkits, the popular Gnome and KDE desktops were born. Built as they are for themselves, interoperability between applications of one on the desktop of the other wasn’t a priority for a rather long time — it’s only been in the last couple of years for example that you could install applications that will work in KDE’s system tray the same way it will with Gnome’s, for example. While the applications always ran, as long as you had GTK or QT installed, they weren’t generally aware of their host desktop if it wasn’t native.
And this was especially true when it came to updating menus. If the functionality was included at all, the author of a Gnome application for example would only bother about updating menus under Gnome, leaving KDE users to scratch their heads and manually create a new entry.
Generally, it’s been up to the package maintainers of distributions to fix this, to create install scripts that properly add a program to the menus of the installed desktops (KDE, Gnome, Fluxbox, XFCE and others). But the onus then is on the distribution package maintainers to do this for each and every application where applicable, and it doesn’t help at all if users install programs not part of the distribution’s package portfolio.
So back to Portland — a great idea that’s sorely needed, Portland provides a set of tools primarily for use at application installation that standardise the process completely, so no matter whether you use Gnome or KDE, an application can simply call the same Portland tools to update the user’s desktop, and Portland will do the rest.
While, generally, this isn’t going to remove the entire workload of package maintainers — as distributions generally have their own configuration formats to maintain — it’ll certainly help automate the process.
Best of all, however, is if everyday developers start using the Portland tools — this way users can install an application not provided by a distribution and find, miraculously, that their desktop is aware of it and they can get right on and use it, just like under Windows. It’s such a simple thing, but it’s been missing from Linux for too long. If there’s one thing we can learn from Microsoft, it’s that consistency matters.
Actually, it’s more just common sense: people want to use their desktops, so don’t make them work for it. Linux as a desktop has come a long way — Ubuntu is a testament to this — and projects like Portland that are one more step in the yellow brick road.
You can check out Portland’s releases and documentation at the official homepage.
Source : APCMag.com