One of the buzzwords of the moment, and what looks to be a movement with an increasing momentum within the open-source community (even stretching itself into the GNOME project), is that of the document-oriented desktop.

This is opposed to the traditional application-oriented desktop in which the program is the key. Application-oriented designs are the sort of thing developers would come up with; they’re constantly looking for ways to tweak things, so nothing should be hidden.

The focus of document-oriented desktops is to minimise the amount of conscious interaction between the user and the program in favour of leaving the user to simply get on with working with his documents. The theory is that it promotes greater usability and efficiency; the user doesn’t think of how to work with their program but instead how to work with their data. No longer does the user think of Evince or epdfview or Acrobat; they think of ‘a PDF viewer’.

Likewise there is increasingly an attempt to increase the dynamism of the desktop, with recognition that old static models just don’t cut it any more. Thus there is a move away from manual saving and undo/redo histories towards applying a revision control system to every document, with ‘milestones’ taking the place of the old save system. The aim is to minimise data loss and maximise workflow. Then there are many other potentially world-changing ideas; it really is a whole new paradigm.

I’m hoping that bene can take the best parts of these ideas. That’s the point, really.

The first component of bene I wrote was a shell script to open specific files using specific applications, part of a move towards a document-oriented environment. It really bothers me that I can’t choose to open just this file in Gnumeric, just this file in gedit.

I’m an A-Level student who makes notes for politics and physics using his laptop. I use ODT almost exclusively as my file format for these notes; however, I really don’t need the overhead of Openoffice.org Writer in politics lessons; I don’t need the power of OO.o just to make notes. So I use Abiword for politics notes.

But on the other hand, I do need the power of OO.o for physics lessons. I need embedded spreadsheets and diagrams and equations in my documents; Abiword can’t do all of this.

The problem is when we continue notes from previous lessons; I can’t just double-click a file in the file-browser when I’m in politics because Writer is set as the default application for opening .odt files. I find it quite frankly shocking that in the year 2009 we’re still unable to choose to open a specific file by default in a different application to other files of its type.

That’s the point then of this first bene module; to open a file using the specified application. It has very little error-handling at the moment, and the code’s not as clean or elegant as it could be. It’ll be improved though.

#!/bin/bash
## This script opens a file with the appropriate application, which might be different for some files than others, even of the same type. Thus one might want to open the vast majority of PNG images in an image viewer such as gthumb, but open photos from a wedding in the GIMP.

exit

#!/bin/bash
## Copy this file, modify it as needed and then make it executable to use it

## If your dependency has been found then the script should not reach this far
echo "$required dependency $depends_name not found"
## If an exit value of 2 is returned then the calling program should abort as a non-optional dependency is missing
if [[ "$required" == "optional" ]]; then
exit 1
else
exit 2
fi

With its tendency to monopolise a system in terms of setting wallpapers, screensavers and GTK themes it is bad enough, but what is worse is the way in which it does so.

There is little modularity of which I am aware; why can’t I make it call Nitrogen, my preferred wallpaper application, to set the wallpaper for example? Why can’t I set one GTK theme for some applications and another for other applications (an ability which comes in very useful when you want to use a dark theme, which most web browsers inherit very badly from)?

Why, especially, are so many GNOME applications programmed not to take some acceptable defaults, or rely on a backup config file, when they can’t find a running gnome-settings-daemon process, and instead will immediately and without asking launch it to destroy my wallpaper and carefully crafted balance of themes within my Openbox desktop?

Why isn’t changing my preferred panel easier, rather than relying on arcane gconf modification and .desktop entries? Isn’t part of the aim of GNOME to be simple?

I suppose my frustrations boil down to the question of why, in short, can’t GNOME be less of an arrogant pig when it comes to my environment and actually allow some flexibility in the applications used?

Don’t get me wrong; on the whole I like GNOME. It’s certainly more elegant than most of the credible alternatives; xfce to my mind is crippled and KDE looks like someone let a tasteless and flamboyant three year old loose with plasticine and glitter. If I were feeling generous I might call it avant-garde.

I want to avoid making the same mistakes in bene. There will be a settings manager, but it won’t run all the time; I don’t see any need for it to do so.  Instead any applications which need to read a setting can source it by running the settings manager when needed; there should be no need to run any component of bene longer than it’s needed.

In addition, bene should be flexible. It already shows some flexibility merely in in the existence of its file opening script, which is soon to be rewritten to have an even greater amount of flexibility in addition to functionality.

At the moment the settings manager’s main role is to handle dependencies and define some generic functions for other components. It’s very incomplete, largely because I didn’t plan it; I’m going to rewrite it and expand it in future however. The main reason for this post, to be honest, was so that the later post on the open-file script would be useful, as the open-file script sources the settings manager.

#!/bin/bash
echo "SM - Hello from the settings manager" ## Check for dependencies
echo "SM - Checking for dependencies"
for file in `ls core/dependencies/*.sh`
do
if [[ ! "$file" == "core/dependencies/example.sh" ]]; then
$file
if [ $? -eq 2 ]; then
## A required dependency was not found; exit
exit 1
fi
fi
done ## Check for config directory
if [ ! -e "$HOME/.bene/" ]; then
mkdir "$HOME/.bene"
fi ## Define function to create config files; only to be used by scripts sourcing this one
_create-config-file () {
if [ `touch "$create_file"` ]; then
echo "SM:$FUNCNAME - File not created, exiting script"
exit 1
else
echo "SM:$FUNCNAME - File created successfully"
fi
}

I first announced the bene project in the #ubuntu-uk channel on the Freenode IRC network as ‘hopefully fun, likely naive, certainly unnecessary and, more likely than not, already doomed before it begins.’

The first three are almost certainly still the same. The last… well, the project has begun, and the first component has reached a semi-usable state (more about that later). It was then wrong to say it was doomed before it began.

It still has time to become so, of course. Ah well.

What is bene, then?

This is quite a good question. When I announced it on IRC I described it as a desktop environment, and certainly that’s the objective – to create a lightweight, functional and above all modern desktop environment.

I’ve seen a thousand and one brilliant ideas for the future of the Linux desktop experience on these here Intertubes, and so far I’ve not really seen any implemented. I’ve also had a few ideas myself which I’ve not seen implemented, and which I don’t expect to see implemented because I can’t code the patches myself.

Ideally bene should be lighter than GNOME and at most only slightly heavier than Xfce, but with the functionality that people have come to expect of modern environments.

A great problem here, I feel, will be maintaining this slimness while forging ahead with the innovations I hope that bene will.

One phrase can summarise the idea that should lie at the heart of bene, and that is ‘paradigm shift’. bene should perpetually be pushing the frontiers of technology, attempting to keep one step ahead of everyone else. And this causes problems in that we cannot build on the efficiencies of the past; we can’t reuse code which hasn’t been written.

At some point I’ll make a list of components which should be the baseline for bene to be considered a ‘minimal’ environment; in the meantime feel free to make suggestions.