INF3330 - Projectdescription - OpenBox Config Brendan Johan Lee (brendajl)

INF3330 - Projectdescription - OpenBox Config Brendan Johan Lee (brendajl)
INF3330 - Projectdescription - OpenBox Config
Brendan Johan Lee (brendajl)
September 24, 2008
Abstract
This is the first draft of my suggested project in INF3330 - Problem solving with
high level languages - fall 2008. The idea behind the project is a proper configuration utility for the wonderful OpenBox window manager. All configuration
of OpenBox is done in XML and sh files. As of now the graphical configuration
utility is extremely limited, and only supports the very basic possibilities.
Short description
As of today the only graphical configuration utility that exists for OpenBox is
ObConf. ObConf is very limited and the only configuration options that can be
edited are the theme, window appearance, general behaviour, number and names
of desktops and dock options. None of the really powerful settings like keyboard
shortcuts, key chains, auto start-up, window-management, menus, etc can be
configured graphically. If you don’t configure these options OpenBox doesn’t
really offer anything other that even the most primitive window manager offers.
The only way you can configure OpenBox properly is “hacking” XML-files.
OpenBox is definitely a window manager for people who long for “the good old
days, when men were men, and wrote their own drivers”. No matter how much
we fight it these days are coming to an end, and today’s new *nix users want
fancy graphical click and point configuration.
OpenBox is a very powerful window manager and at the same time extremely
sleek and lightweight. Not many people use it though. I think there are two
reasons for this. First of all new users (who have heard how great OpenBox is
from people like me) might take a look at the configuration utility first. Their
first thought is most likely something in the order of “What??? Is this really
all there is??? Screw this”. Or perhaps they think “This is a typical old school
kind of things for dinosaurs who hate everything that has anything to do with
graphics”.
A good graphical configuration utility might change the first impression of
OpenBox and help “trap” more new users. And more users means more people
contributing. And more people contributing means a (if possible) even better
window manager. Hence this project.
Project overview
• Part 0 - Foundation The first thing that must be done is create a
foundation for the program. This should include a good system for parsing
and writing the XML and sh files. We also need a system for testing if
the config file(s) exist, and generating default config files if not due to the
fact that OpenBox doesn’t actually generate any config files before you
actually want to change a setting.
• Part 1 - Graphics Now we need to make a main graphical interface for
the application. In the first version QT bindings will be used, later on I
hope to include the choice of using GTK+ bindings instead.
• Part 2 - Window management This will add the first real configuration
possibility. Here I will enable configuration of single windows and also
groups of windows. This part of the program should also allow the user
to easily grab window identification by clicking on a window.
• Part 3 - Keyboard shortcuts and key chains Here I will add support
for configuring keyboard shortcuts and key chains.
• Part 4 - Auto-load script This part will enable graphical configuration
of the auto-load script used by OpenBox.
1
• Part 5 - Configuring menus This is probably the most demanding part
of the project as OpenBox allows the use of multiple menus in addition
to menu pipes. Menu pipes are menus that are generated run-time by a
script written in the users language of choice.
• Part 6 - Other stuff Include support for themes, window appearance,
general behaviour, desktops and docks. This step has the lowest priority
seeing as ObConf already supports configuring these options.
• Part 7 - GTK+ bindings To make the program more portable we
should include the choice of using GTK+ bindings instead of QT bindings. Perhaps even TK support should be included for those who have an
extremely minimal system.
Time use and the reality of things
This is a quite large project. It’s impossible for one person to complete this
in only one week. In one week it should be possible to complete at least part
0 to part 3 or 4, possibly even a little bit more. Part 6 is probably almost as
large as all of the preceding parts. I decided to include the whole list in the
project description because I will complete the project at a later point, even if
the whole project isn’t finished in the one project week.
2
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising