DBFrontend is a new windows frontend for DOSBox.
It manages DOSBox projects, screenshots, documentation data links and weblinks for the projects.
It is puplic domain, free and open source.
Stockholm, Sweden, Europe, Earth Interests: Old games & young women
Gruß Knito,
Ich habt nicht dein frontent geprüft, nur der Pascal kode examiniert.
No, I think I better switch to English - it would take me 2½ hour to construct a readable answer in my very rusty German 😀
With the Knito DBFrontend we have 3 (soon 4) DOSBox frontend to choose from:
DoBoxFro by SLRHUI
A new, upcoming frontend (to be called?? DB Game DB?) by MabusRaeen
Boxer by P-J
DBFrontend by Knito
The original frontend, DoBoxFro v. 0.45, is in my view dead and obsolete 😵 The interface is a litle archaic, it can not handle paths with spaces, and it has not been updated to support any new settings since DOSBox 0.58(?). I used it for a few days, and while it did allow me to play around with DOSBox settings, I soon abandoned it, and have since hand-edited my configurations.
Rest in peace, DoBoxFro...
Boxer 0.61.4 looks the part! 😎 The interface looks very much like the normal Windows PIF Manager and the VDMSound LaunchPad.
DBFrontend v. 0.5.6A different interface - that someday will need a redesign. As the set of DOSBox options grow, the single-line, tabbed interface, will outgrow most desktops. I also noticed an old friend: DBFrontEnd do not like spaces in the paths... 🙁
As I said, I have gotten used to hand-editing my DOSBox configurations, so I have not tried Boxer and DBFrontend. I looked at the DBFrontEnd source because I was interested in seeing how it supported such a fast-moving target as DOSBox. And the sad answer is: It does not. Section names, settings names, and settings values, are all hard-coded into DBFrontEnd.
I can understand this method, as it makes the frontend simpler. But it also requires constant updates, tinkering, rebuilds and end-user installs, if it is to support any new DOSBox features.
The best method to solve this would be if DOSBox could export its supported configurations in a slightly more machine-readable format. The INI-file format currently used is machine-readable, but a lot of valueable information, e.g. alternate settings are hidden behind the universal '#' comment character:
1[dosbox] 2# language -- Select another language file. 3# memsize -- Amount of memory dosbox has in megabytes. 4# machine -- The type of machine tries to emulate:auto,hercules,cga,tandy,vga. 5# Try a specific type if your game has problems with auto. 6 7language= 8machine=auto 9memsize=16
With a little redesign of the generated configuration file, a frontend could dynamically pick up not only the section names and the current defaults, but also all the available alternatives.
1[ dosbox ] 2# language -- Select another language file. 3# memsize -- Amount of memory dosbox has in megabytes. 4# machine -- The type of machine tries to emulate:auto,hercules,cga,tandy,vga. 5# Try a specific type if your game has problems with auto. 6 7language_options=word:english,spanish,german 8machine_options=word:auto,hercules,cga,tandy,vga 9memsize_options=int_range:16,256 10 11language= 12machine=auto 13memsize=16
But let us face it: This method is a hack. A nice hack, since it requires very few changes to the DOSBox code, it is backwards compatible, and promises a future where better things exists.
I noticed that DBFrontEnd uses its own special configuration sector, [ general ], to keep track of items such as projectdir, manualfile, and wwwsite.
Again, it works, but it is a hack. A different frontend will have to adapt to the format of the 'general' section and any new configuration item could break other frontends.
So, where does all this lead, you ask? For one, I urgently ask that the programming leads from DOSBox and the frontends, start to communicate and synchronise the use of the current DOSBox configuration file. The DOSBox team needs to inform the frontend authors about new sections and settings, and the fronters need to inform the DOSBox team on their (mis)use of the configuration file for storing frontend-private information.
But this is just a stop-gab meassure. The real way forward lies, in my humble opinion, to define a common XML-DTD to be used by DOSBox and the frontends for its configuration file. An XML file (validated against the DTD) is always readable by a program, and also (in a pinch) readable by a human. If necessary, an XSL-translator can easily convert the XML-file to an INI-file, or into a nice-looking HTML-file. Similar, a generic XML-editor can, with access to the DTD, provide a - not a top notch, but usable - editing environment.
--
MiniMax - "Shutting the XML up now!"
It also always uses my dosbox.conf, instead of configurations made with it.
Yes, again.
DBFrontend always loads the dosbox.conf as a default to start with.
All settings are loaded from dosbox.conf because I assume the basic configuration is mostly a good guess for a new setting.
Ich habt nicht dein frontent geprüft, nur der Pascal kode examiniert.
...
Hi MiniMax,
thanks for the review. Yes I do not like spaces and so does DBFrontend. DBFrontend still is in alpha stage but already working satisfactorily.
It can change in many ways (and already did a little since the last release).
I like your idea of an ini file that contains the type and predefines for the configuration values. A good frontend could parse it and build up all visual configuration elements dynamically and would be up to date with every release of DOSBox.
Yes, I misuse the project ini file to store some hidden information (hidden from DOSBox with #-chars). I was surprised when I first tried the new section and the items where not hidden: DOSBox does not like this!
The parser seems to read whatever it finds, even if the value is not needed. Or is the name "General" a not so good name for my section?
Thinking of that "dbknitofrontend" would more likely have been a guess that nobody else but me would have chosen.
The next step willl make DBFrontend multi-language capable. Maybe someone translates my English to English. 😊
DBFrontend always loads the dosbox.conf as a default to start with.
I am not talking about starting. Let's take your screenshot at the top of this thread as an example.
If I double click on XCOM it starts the game, though it always uses cycles=2500, machine=auto. It doesn't use XCOM-TFTD.ini file created with your frontend
robertmo wrote:Knito:
you must use this command in your frontend:
dosbox -conf "d:\program files\dbfrontend\xcom.ini" […] Show full quote
Knito:
you must use this command in your frontend:
dosbox -conf "d:\program files\dbfrontend\xcom.ini"
not this:
dosbox -conf d:\program files\dbfrontend\xcom.ini
Thank you very much for examining so deeply the source of the error.
I will change it at this second. You know, I install everything to C:\Programme and there are no spaces within the path.
DBFrontend will become the smallest frontend for DOSBox on the desktop: The new version (not uploaded yet) will be able to cut off the configuration area.
I have uploaded a new release of dbfrontend. This version is 0.0.5.8.
Here are the changes:
changes to dbfrontend 0.0.5.8
* No more buttons, they went to a new menu.
* Remember the last project used and reload it on startup.
* The snapshot image becomes less important and smaller and goes into the bottom left corner. This was done in order to waste less space and to fit on a 800x600 screen.
* New menu sections for all project tabs. Of course, all menus are new now, but "Sections" did not exist before and the buttons in "File" and "View" did.
* Hide the DOSBox settings away by moving the splitter bar or using the "View" menu "Show / Hide DOSBox settings" to gain more space for the configuration area.
* DBFrontend becomes the smallest frontend available with the new feature "Show / Hide configuration area". Now there is also some space left on 800x600 screens: 640x480 here I come!
* Menu translated to 3 languages: English, German and French.
* And, of course: Double quoted the dangerous path strings in the dosbox starting command. Thx robertmo.
Stockholm, Sweden, Europe, Earth Interests: Old games & young women
Knito, while you still "in the zone" hacking away at DBFrontEnd, consider changing your version numbering scheme to the same scheme adapted by Boxer. That is, the version number of the frontend includes the version of DOXBox that it supports. E.g. your current DBFrontEnd is 0.0.5.8 (not sure what all the zero's are for ...). You could change it to 0.61.5.8, indicating that it supports all the settings of DOSBOX 0.61.
--
MiniMax
Thank you, Knito, DBFrontend is very good and I really like it. Minor things I miss are:
a) When I create a new project and then click on open snapshots directory icon, I´m in the C directory, not in C:\Program Files\DBFrontend\snaps\gameX directory where I would like to be. Maybe would be also nice, if the first taken snapshot (by ctrl+F5) was loaded automatically as the project picture.
b) I would rather run the project by pressing Enter instead of Ctrl+R.
c) Possibility to create project´s shortcut icon on the desktop.
...You could change it to 0.61.5.8, indicating that it supports all the settings of DOSBOX 0.61. ...
Hi MiniMax,
DBFrontend is still in alpha stage and as you already remarked, it is a hack.
I am thinking about extern configuration scripts, allowing to follow the changes of DOSBox versions by not re-writing the program, but generating a new configuration script with a text editor like notepad. This script then should have the correct DOSBox version number and will be plugged in at the DOSBox configuration section of the program.
It will be possible for anybody to quickly adopt DBFrontend to a new environment using his notepad.
Jiri wrote:Thank you, Knito, DBFrontend is very good and I really like it. Minor things I miss are:
a) When I create a new project and then […] Show full quote
Thank you, Knito, DBFrontend is very good and I really like it. Minor things I miss are:
a) When I create a new project and then click on open snapshots directory icon, I´m in the C directory, not in C:\Program Files\DBFrontend\snaps\gameX directory where I would like to be. Maybe would be also nice, if the first taken snapshot (by ctrl+F5) was loaded automatically as the project picture.
b) I would rather run the project by pressing Enter instead of Ctrl+R.
c) Possibility to create project´s shortcut icon on the desktop.
Hi Jiri
do you really use the new version as of 0.5.8 ???
Here is a screenshot:
a) with version 0.5.8? I already was thinking about automatically loading the first snapshot, it would be easy to do. But I think there are reasons not to do it.
b) hmm ... I will remember this
c) a projects shortcut? Kewl idea!
Gruß,
Knito
Last edited by Knito on 2004-02-23, 06:43. Edited 2 times in total.
Hi Jiri
do you really use the new version as of 0.5.8 ???
Yes. The problem with .ini was fixed, but I think that the snapshot problem has still something to do with spaces in the path. If I create and save "test" project: C:\Program Files\DBFrontend\snaps\test and click on snapshots directory icon, I am in the C directory. Now if I put the path in the question marks: "C:\Program Files\DBFrontend\snaps\test" and click on the icon, I am in the C:\Program Files\DBFrontend\snaps directory. Not in the C:\Program Files\DBFrontend\snaps\test, where I would like to be, but it is at least better. 😀
Now I also noticed than when I delete the test project, the test snapshots folder remains in the snaps directory, even if no snapshots were taken. So soon could be the C:\Program Files\DBFrontend\snaps directory filled with needless empty folders. Maybe a confirmation dialog if a project is deleted "do you also want to delete the snapshots folder?" or automatic deletion of empty folders and confirmation dialog only for full folders would solve this.
Last edited by Jiri on 2004-03-04, 23:43. Edited 1 time in total.
After killing my new experimental external config.ini yesterday I was a bit of melancolic and had to play TFTD for hours.
This happened:
First I wrote an external config script and then implemented a testmodule to read it. This worked fine and I wanted later to work on on this point. After correcting the french xml section and implementing the dektop-shortcut creator I added the return key to start and then tried to improve the deleting algorythm. Not thinking of anything I had a configuration skript config61.ini and sillily made a project config61. Deleting the empty project resulted in a loss of my configuration script which previously was overwritten by my empty project when I saved it. I could not undelete it and was *very* sad. And there was no backup of the config file which took me an hour to write. I was depressed and stopped immediatly working. Today I'm better again and rewrote the configuration script in less than 10 minutes. I thought it would be a good idea to have a ending sequence unlike ".ini" for non-project ini files and named it now config_0_61.cfg.
I uploaded a new release 0.0.5.9 to sf.net.
I think that Jiri will be pleased about the shortcut generator.
