VOGONS

Common searches


DOSBox Game Launcher (DOSBox Frontend)

Topic actions

Reply 1641 of 1962, by arobbo

User metadata
Rank Newbie
Rank
Newbie

Hi Ronald,
I'm running into a strange and unwanted directory creation problem in DBGL093beta8, and probably versions 090 onwards in Puppy Linux. I am using a 'frugal' install of DevuanPup64, on a Panasonic cf 52 mk3 laptop (2core duo, 2.3Ghz, 4 GB ram).
So when I attempt to start a session of DBGL - either by extracting a fresh download of v092 from your homepage with/without updating the dbgl.jar and lib folder files to v093 - and what happens is that despite the folder from which I open DBGL, new directories for captures, db, dosroot, template, export, profiles, xsl (but not lib) are generated in the ROOT directory and are subsequently populated for profile entry and updates etc - the file structure within the respective DBGL folder (extracted) remain ignored.
I don't know if anyone else using the latest Linux versions of DBGL have seen this issue, but I have attached screenies to illustrate:

Attachments

  • DBGL(0).png
    Filename
    DBGL(0).png
    File size
    325.93 KiB
    Views
    3123 views
    File comment
    "HOME" structure of sda on left, Puppy "home" (~) on right
    File license
    Public domain
  • DBGL(1).png
    Filename
    DBGL(1).png
    File size
    151.24 KiB
    Views
    3123 views
    File comment
    Inside one of the DBGL folders (left), about to click dbgl.jar
    File license
    Public domain
  • DBGL(2).png
    Filename
    DBGL(2).png
    File size
    218.21 KiB
    Views
    3123 views
    File comment
    DBGL.jar populates puppy home (right) with new directories (highlighted)
    File license
    Public domain

Reply 1642 of 1962, by arobbo

User metadata
Rank Newbie
Rank
Newbie

In other words, the previous portability of DBGL seems to have been lost somehow in the Linux version. I realise that the file structure of "frugal" Puppy Linux can cause issues - there are two "Home" folders, one representing the partition/drive area immediately outside of the savefile (in DBGL(0) above, the "devuanpup9.6.0frugal" folder), and a second home/root directory folder ("~") - which is where dbgl.jar processes are populating new DBGL folders.

One of the main benefits of the Puppy 'frugal' system is that you can install multiple Puppy versions and have folders common to each *outside* the respective Puppy installs. Experienced Puppians typically store browser caches in this manner, so that expanding cache sizes don't inadvertently impinge on resources (e.g., ram, processing speed) of their session that may not require those features. Here, I have tried to keep a working database of 200+ DOS games (some of them ISO's, etc) outside of normal running environment of Puppy.
It is also notable that if I move all these freshly-generated directories *into* a fresh DBGL folder *inside* the home (or root) directory, these are also ignored in favour of newly populated folders.
Perhaps mention has been made already of these phantom directory creations, but I can't work out how to stop it from happening. Any advice welcome, Cheers

Reply 1643 of 1962, by Lawnie

User metadata
Rank Member
Rank
Member

Quick query for anyone with the knowledge here.

I'm running a Linux distro (Mint) and installed dbgl quite happily via the terminal, decided I wanted to add DOSBox Staging and X as well, but upon installing Staging's repo it not only replaced my original DOSBox but removed dbgl as well!

Undeterred, I went with the flatpack version from the GUI software manager on Mint and everything went fine. Except I can't find a way to add the Flatpack version of Staging or X to dbgl.

Anyone with Linux experience have any ideas? Am I missing something really obvious here?

GET OFF MY LAWN - Yet another retro PC game review channel.

Reply 1644 of 1962, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

For dosbox-staging you'll need to discuss that on the dosbox-staging site. I haven't been keeping track for awhile but last I heard their intent was for when staging was installed to replace dosbox.
Unknown why dbgl would be affected, was it installed via a package manager or downloaded and installed?

For flatpak see:
Re: DOSBox Game Launcher (DOSBox Frontend)

/Edit
Bleh you made me visit that site again, here you go:
https://github.com/dosbox-staging/dosbox-stag … mment-718856147

How To Ask Questions The Smart Way
Make your games work offline

Reply 1645 of 1962, by _Rob

User metadata
Rank Member
Rank
Member

Starting flatpak versions of dosbox from the commandline does not work the normal way. You need to use the "flatpak run" command. I have not tried this with DBGL, but you may just want to create a shell script with the necessary syntax and then call the shell script from DBGL.

flatpak run com.dosbox_x.DOSBox-X

Or create a script and save it as ~/bin/dosbox-x:

#!/bin/sh
flatpak run com.dosbox_x.DOSBox-X $@

Reply 1646 of 1962, by Lawnie

User metadata
Rank Member
Rank
Member

Thanks for the tips! I'll give them a shot, and I've also got in touch with Dreamer to see if he has any ideas about why the Staging repo (which is where I got it) would be overwriting DBGL as well as Dosbox. It might well be something screwy my end, I'll report back when I've learnt more.

GET OFF MY LAWN - Yet another retro PC game review channel.

Reply 1647 of 1962, by DOStopic

User metadata
Rank Newbie
Rank
Newbie

Hi to everyone!
I often get an error "Argument cannot be null" and DBGL crashes when I try to edit a game profile to add screenshots from the Metropolis Launcher MobyGames database. I'm using the DBGL 0.93beta8 version and my platform Java is up to date (on Windows 10 Pro). This problem doesn't always occur but it almost seems to be random. Anyone with the same bug?

Reply 1649 of 1962, by DOStopic

User metadata
Rank Newbie
Rank
Newbie
pablokks wrote on 2021-03-21, 14:19:

DBGL doesn't seem to be downloading screenshots from MobyGames anymore, only the Cover-arts. Is it just me or are you guys also having this problem?

Try choosing "Metropolis Launcher MobyGames database" ...

Reply 1650 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie
arobbo wrote on 2021-03-15, 06:23:

Hi Ronald,
I'm running into a strange and unwanted directory creation problem in DBGL093beta8, and probably versions 090 onwards in Puppy Linux. I am using a 'frugal' install of DevuanPup64, on a Panasonic cf 52 mk3 laptop (2core duo, 2.3Ghz, 4 GB ram).
So when I attempt to start a session of DBGL - either by extracting a fresh download of v092 from your homepage with/without updating the dbgl.jar and lib folder files to v093 - and what happens is that despite the folder from which I open DBGL, new directories for captures, db, dosroot, template, export, profiles, xsl (but not lib) are generated in the ROOT directory and are subsequently populated for profile entry and updates etc...

Hi arobbo,

Not having any experience using Puppy, I admit I'm not really understanding the file structure used in this Linux distribution. Generally speaking, DBGL will try to use the DBGL folder itself to store its data (for portability, as you say), unless running on MacOS or Linux, or when the directory is not writable (for example c:\Program Files\DBGL). In the latter case:

  1. On MacOS and Linux, the users' home folder (in Java terms: System.getProperty("user.home")) is used and a .dbgl/ folder created for all DBGL data
  2. On Windows, System.getenv("LOCALAPPDATA") is used and a DBGL/ folder created for all DBGL data

If you do not want to use your home folder for DBGL's data when using MacOS or Linux, edit the startup script ./dbgl, and simply remove -Ddbgl.data.userhome=true on the last line.

Reply 1651 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie
DOStopic wrote on 2021-03-21, 09:29:

Hi to everyone! I often get an error "Argument cannot be null" and DBGL crashes when I try to edit a game profile to add screenshots from the Metropolis Launcher MobyGames database. I'm using the DBGL 0.93beta8 version and my platform Java is up to date (on Windows 10 Pro). This problem doesn't always occur but it almost seems to be random. Anyone with the same bug?

I've not heard of this problem before. Are you able to reliably reproduce this issue, maybe for a particular game, DOStopic?

pablokks wrote on 2021-03-21, 14:19:

DBGL doesn't seem to be downloading screenshots from MobyGames anymore, only the Cover-arts. Is it just me or are you guys also having this problem?

What DBGL version are you using, pabblokks? Please try using the latest beta one, as multiple changes to the MobyGames website have caused these kinds of problems in the past.

Changes in beta9:

  • Slowakian translation by Tomas K.
  • updated launch4j to 3.13 for improved JVM installation detection (Johnnydement and others)
  • Fixed a few 'Browse..' buttons, paths were incorrectly trimmed (Tomatko)

All the latest files. To upgrade, just update dbgl.jar.

Ronald

Reply 1652 of 1962, by arobbo

User metadata
Rank Newbie
Rank
Newbie

Hi again Ronald - thanks very much for your earlier reply. I just spotted this from your DBGL site (c0pied below) where I had earlier missed this 'fine print' on structural changes for Linux:
<snip>
0.90 will store user-generated content in the ~/.dbgl folder by default on Linux environments. If you want, you can still have the old behaviour (storing all data inside the dbgl folder itself) by editing the dbgl shell script, please see DOSBox Game Launcher (DOSBox Frontend).
<snip>
I logged on here to update my "problem" to find you have already clarified the matter (!) Thanks very much for taking the time to spell it out for me and anyone with similar observations.
Cheers 😀

Reply 1653 of 1962, by _Rob

User metadata
Rank Member
Rank
Member

The correct way to handle this would have been to use the XDG specification
https://specifications.freedesktop.org/basedi … pec-latest.html

In particular for any app specific settings $XDG_CONFIG_HOME/dbgl which is typically ~/.config/dbgl

And for any "data" files, which I think is what the game config files should be classified as $XDG_DATA_HOME/dbgl which in turn is typically ~/.local/share/dbgl.

This also makes it easier to package the application, for instance for flatpak.

Reply 1654 of 1962, by _Rob

User metadata
Rank Member
Rank
Member

DBGL is no longer starting, I' m getting the following on startup:

Launching DBGL using 64-Bit VM 11.0.10 on Linux v5.11.11-300.fc34.x86_64amd64, HSQL Database Engine 2.5.1, SWT v4940gtk
Startup
Warning: Index 1 out of bounds for length 1
java.lang.IndexOutOfBoundsException: Index 1 out of bounds for length 1
at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:372)
at java.base/java.util.ArrayList.get(ArrayList.java:459)
at org.dbgl.gui.dialog.MainWindow.prepare(MainWindow.java:198)
at org.dbgl.gui.abstractdialog.BaseDialog.open(BaseDialog.java:97)
at org.dbgl.gui.Launcher.main(Launcher.java:52)

This is with 093beta9. Any idea what may be causing this? I have java-11-openjdk-headless and java-11-openjdk packages installed, and it was working until a few days ago.
So I'm guessing either some system update broke things, or a dbgl database file got corrupted?

Reply 1655 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie
_Rob wrote on 2021-04-07, 19:26:

DBGL is no longer starting... This is with 093beta9. Any idea what may be causing this? I have java-11-openjdk-headless and java-11-openjdk packages installed, and it was working until a few days ago.
So I'm guessing either some system update broke things, or a dbgl database file got corrupted?

DBGL is trying to set the last selected filter tab, but based on the contents of the loaded database, that tab index is out of range. Are you loading the correct database? In any case, you can try to reset [gui]filtertab to 0 in settings.conf

Reply 1656 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

More updates in beta10:

  • Updated (the 3 db/mobygames.*) MetropolisLauncher database files for HSQLDB 2.6.0;
  • Use ~/.local/share/dbgl for data files on Linux systems, and ~/Library/dbgl on MacOS (_Rob). Linux users might have to manually move any existing files to the new location like so:
    mkdir ~/.local/share/dbgl; mv ~/.dbgl/* ~/.local/share/dbgl
  • Updates to most jar libraries, most notably hsqldb.jar from 2.5.1 to 2.6.0. Please note that this new library does no longer support the old 1.8.x database format. If you're currently using a DBGL version older than 0.92, first update to 0.92, and only then update to beta10.

All the latest files. To upgrade, update dbgl.jar, replace all jars in the lib folder and replace the mobygames.* files in the db folder.

Ronald

Reply 1657 of 1962, by _Rob

User metadata
Rank Member
Rank
Member

Thanks for your previous hint on filtertab, that fixed the issue.

But I just now upgraded to beta10 and dbgl no longer starts due to another issue:

$ ./dbgl 
Launching DBGL using 64-Bit VM 11.0.10 on Linux v5.11.11-300.fc34.x86_64amd64, HSQL Database Engine 2.6.0, SWT v4934win32
Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
no swt-win32-4934r6 in java.library.path: [lib]
no swt-win32 in java.library.path: [lib]
Can't load library: /home/rderooy/.swt/lib/linux/x86_64/libswt-win32-4934r6.so
Can't load library: /home/rderooy/.swt/lib/linux/x86_64/libswt-win32.so

at org.eclipse.swt.internal.Library.loadLibrary(Library.java:342)
at org.eclipse.swt.internal.Library.loadLibrary(Library.java:256)
at org.eclipse.swt.internal.C.<clinit>(C.java:19)
at org.eclipse.swt.widgets.Widget.<clinit>(Widget.java:115)
at org.dbgl.gui.dialog.MainWindow.<init>(MainWindow.java:165)
at org.dbgl.gui.Launcher.main(Launcher.java:52)

Reply 1658 of 1962, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Hi _Rob, did you replace all jar files in the DBGL lib/ subdirectory? Strange though, looks like its trying to load the SWT v4934win32 variant.. Do you have multiple swt*.jar files in your lib/ folder, maybe? What Linux distribution are you using?

Reply 1659 of 1962, by _Rob

User metadata
Rank Member
Rank
Member

Hi rcblanke, yes the lib directory had a whole bunch of older libs in it from previous versions, including a swtlin32.jar and swtwin64.jar. The later dated Jun 24 2020, so it must have been included with an older build.

I cleared out the old libs, and made sure to only include those from you beta10 tar.gz file and dbgl starts up again.

Thanks for you work!