Dosbox-pykde

Contents

This is the homepage of dosbox-pykde. Not much here yet, just started writing the page.

What is it?

Dosbox-pykde is a frontend for dosbox for the KDE desktop. It is similar to other frontends for dosbox. The major difference with this one, is that it is centered around file management. This frontend is designed to separate the freshly installed files from the changed file, configuration files, and saved games. Every game entry in the frontend is split between two different archives. The first archive is a zipfile created upon entry to the frontend. This is meant to save a fresh install. The secondary, or extras archive, is a tarball whose contents are generated from an rdiff-backup of the leftover or changed files relative to the install archive.

Although it is currently usable, it is still being considered in the planning stage until I work out some of the features. I may make it optional to tarball the secondary archive, and let the user be able to just hold an rdiff-backup directory. I may make rdiff-backup optional, and make a cheap internal replacement for it. I don't really have a frontend to handle configurations yet. Currently, only one default configuration is supported, with per game overrides. Autoexec lines in the configuration are not yet supported.

Goals

One of the goals of this project is to provide a good example application of PyKDE. I have spent some extra time in writing comments throughout the code detailing some of PyKDE. As of now, there are very few applications that use PyKDE primarily. There are quite a few, not very many, but a few that use PyQt. The PyKDE environment is much richer than the PyQt environment, and provides easier widgets to work with. The sad fact is that there the current state of documentation and examples are pretty poor, leaving developers to read through the C++ documentation. This is not always easy for a person who is primarily a python user to do. This program makes an attempt to ease entry into programming with PyKDE. I will make an attempt, where possible or applicable, to use PyKDE the way it "should" be used. I heartily welcome suggestions that help this.

I do believe in using pure python where it is more appropriate, and using the PyKDE/PyQt widgets where they are best represented. One of the strengths of Qt and even KDE in the C++ environment is that they offer access to many things that are already handled by python. For example, in Qt, there is a QString type that provides many methods for dealing with strings. In python, the string type already has methods for dealing with string objects, and a python programmer would probably be more familiar with those. So while knowing how to use QString objects may really help the C++ programmer, they are more likely to just be in the python programmer's way. Other examples are the QMap and QList types, which are handled by the dictionary and list objects in python. Network functions and XML processing are preferred to be handled by python in lieu of using the Qt equivalents.

Features

A short history and rationale about file management

Probably the most feature of this frontend is its ability to manage archives. Most emulator frontends have little need for this type of functionality, because they are mainly console, or arcade frontends. These frontend usually work off of rom images or a zip file of rom images, and the configuration and savegame data is already separate from those images. This is not the case with dosbox, or even other computer emulators. With dosbox, the game files are generally stored in a single directory with the settings and saved games somewhere in that tree.

When I first started using dosbox, I decided not to use a frontend at all. What I did is make a "c: drive" out of a directory on my filesystem called "dosbox". I used an automenu program in the autoexec as my "frontend". This did a pretty good job, and it was comparable to how people used to run DOS on their computers. For file management, I used to do an rdiff-backup over the whole dosbox tree regularly. This method became somewhat cumbersome later on as I decided to add new games or remove old ones, or even rearrange the dosbox tree.

These problems led me to create this frontend that manages the files on a "per game" basis. I decided to keep using rdiff-backup, because it is an good program, and an excellent way to keep track of previous saved games and changes in settings. Currently, dosbox-pykde does most of what I want it to do with my files "under the hood" to my liking.

Lately, I have been wondering what other users would like in a frontend, and whether they would like file management features at all. I experimented with making file management optional, but ran across a few problems with it. The main problem, if file management is made optional, is that it is somewhat difficult to change your mind later and start trying to manage files after games have been added to the frontend. Another problem is the amount of code to change to adapt to users who don't want dosbox-pykde to manage their files. Due to this, I have decided to make file management a required feature.

However, I have been trying to decide whether rdiff-backup, rsync, tar, and bzip2 should be required dependencies. The main reason that they are required now, is that I don't want to reinvent the wheel to replace their functionality. Most dosbox-pykde users should already have tar and bzip2 installed on their systems. Most distributions have rsync, so it should be easy to install. Rdiff-backup is also pretty well-known, and should be available on most distributions.

I may soon make archiving the rdiff-backup repository optional, allowing the user to keep the rdiff-backup trees for the games in a directory. This would remove the dependencies on tar and bzip2. Rsync could be replaces with shutils.copytree from python, but I don't much like the copytree implementation. The copytree implementation may not be a problem when dealing with "dos" files and directories, but I haven't tried testing it yet. If these things are done, it would still leave rdiff-backup as a dependency. There is no easy way to replace rdiff-backup. There could be an option for a "flat" backup of files that are not in the installed archive, but I haven't thought it through yet.

Dependencies

Project

project page

Related projects

DboxFE - This is a frontend using C++ Qt. It has an advantage of being able to also run
in windows.

Intended Audience/Users

KDE users on i386/amd64 architectures.

Download

There is an initial release available.
dosbox-pykde-0.1.0

You can also obtain dosbox-pykde through subversion:

svn checkout svn://svn.berlios.de/dosbox-pykde/trunk dosbox-pykde

svn access (This will work in konqueror.)

Install

The python distutils are used to install this application.

In the toplevel directory, type:

./setup.py install

or type:

python setup.py install

and everything should install.

To run from the source tree, type:

PYTHONPATH=`pwd`/lib ./dosbox-pykde

Documentation

Working on this. It is currently located in data/doc/index.docbook . It can be built from the source tree with:

pushd data/doc && meinproc index.docbook && popd

This will build a collection of html files in the data/doc directory.

The docbook documentation is planned to be built, installed in the future.

Planned changes

This section is to describe changes that will affect the current usage of dosbox-pykde. This includes changes in the configuration, or changes to the locations of certain files and directories that will possibly adversely affect users.

Todo

Here is a list of things that need to be done. These things should not affect the usage of the application from version to version.

This project is hosted by berlios.