Feature request - console-only Linux build (built executable currently requires GTK libraries)

[philpem]

Disc Image Manager has command-line/console interface, but also requires the GTK libraries and an X server (e.g. Xvfb) in order to run, then runs in a console anyway.
This is a bit sub-optimal as these amount to around 500MB across 100 packages, all of which seems to be unused.

As a future enhancement, could a version of Disc Image Manager be made available which doesn't need the GTK/LCL dependencies?
It seems possible based on this -- https://wiki.freepascal.org/Console_Mode_Pascal#Console_mode_programming_with_Lazarus

root@35407ff2419c:/# DiscImageManager
DiscImageManager: error while loading shared libraries: libgdk-x11-2.0.so.0: cannot open shared object file: No such file or directory

root@35407ff2419c:/# apt update ; apt install -y libgtk2.0-0

# (about a hundred packages install)

root@35407ff2419c:/# DiscImageManager

(DiscImageManager:1221): Gtk-WARNING **: 17:39:49.983: cannot open display:
root@35407ff2419c:/# DiscImageManager --help

(DiscImageManager:1222): Gtk-WARNING **: 17:39:53.217: cannot open display:
root@35407ff2419c:/# DiscImageManager -?

(DiscImageManager:1223): Gtk-WARNING **: 17:39:55.287: cannot open display:

root@35407ff2419c:/# xvfb-run DiscImageManager
********************************************************************************
Disc Image Manager Console V1.49 by Gerald J Holdsworth

Linux Intel 64 bit

Ready
>exit
********************************************************************************

[geraldholdsworth]

Disc Image Manager contains the code for both the GUI and Console environments. As such, it then needs all the libraries for the LCL even though it might not be used. The alternative would be to have two separate programs – one for GUI and one for Console. I’m sure that there is another way round this. It seems that, at least under Windows and macOS, the binary contains everything required to run without requiring any dependencies. I have little experience with Linux, so not sure what is happening here. Cheers, Gerald. From: Phil ***@***.***> Reply to: geraldholdsworth/DiscImageManager ***@***.***> Date: Sunday, 21 December 2025 at 17:50 To: geraldholdsworth/DiscImageManager ***@***.***> Cc: Subscribed ***@***.***> Subject: [geraldholdsworth/DiscImageManager] Feature request - console-only Linux build (built executable currently requires GTK libraries) (Issue #39) philpem created an issue (geraldholdsworth/DiscImageManager#39) Disc Image Manager has command-line/console interface, but also requires the GTK libraries and an X server (e.g. Xvfb) in order to run, then runs in a console anyway. This is a bit sub-optimal as these amount to around 500MB across 100 packages, all of which seems to be unused. As a future enhancement, could a version of Disc Image Manager be made available which doesn't need the GTK/LCL dependencies? It seems possible based on this -- https://wiki.freepascal.org/Console_Mode_Pascal#Console_mode_programming_with_Lazarus ***@***.***:/# DiscImageManager DiscImageManager: error while loading shared libraries: libgdk-x11-2.0.so.0: cannot open shared object file: No such file or directory ***@***.***:/# apt update ; apt install -y libgtk2.0-0 # (about a hundred packages install) ***@***.***:/# DiscImageManager (DiscImageManager:1221): Gtk-WARNING **: 17:39:49.983: cannot open display: ***@***.***:/# DiscImageManager --help (DiscImageManager:1222): Gtk-WARNING **: 17:39:53.217: cannot open display: ***@***.***:/# DiscImageManager -? (DiscImageManager:1223): Gtk-WARNING **: 17:39:55.287: cannot open display: ***@***.***:/# xvfb-run DiscImageManager ******************************************************************************** Disc Image Manager Console V1.49 by Gerald J Holdsworth Linux Intel 64 bit Ready

exit

******************************************************************************** — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[philpem]

That would certainly explain it. I didn't think there was a GUI in the Linux build goes, as the default seems to be to run in console mode unless it's run as DiscImageManager -g. I gather on Windows it defaults to the GUI.

I've had a quick go at making a "no GUI dependencies" build at:
https://github.com/philpem/DiscImageManager/tree/experimental-nogui-build
Sadly this has failed because the GUI and console both store data in MainForm, which means it has to be up and running for the app to work. Obviously that requires LCL to be working and MainForm to be created, which pulls in the GTK dependency.

In terms of fixing this, it looks like the console and GUI code is mixed in together. I guess the GUI was created first then the Console added on later -- nothing I haven't seen before, and it's something I've certainly done in the past in my Delphi dev days.
To fix it, the disc image processing code would need to be extracted into its own Unit or Class, then the MainForm and Console (and probably all the other forms) refactored to use that.

Given the scale of the work involved, I don't want to rush ahead and do all this only to end up stepping on your feet (it is after all your project!).

I see there's a "version 2" in the UI mockup phase. Thinking out loud, this kind of refactor could be useful for bootstrapping that, as afterwards things would be split into "the disc image UI" and "the disc image processing library code".

[geraldholdsworth]

All (most of) the disc processing code is held in the DiscImageManager series of files, which is it’s own class (TDiscImage). There’s still some code left that I need to put into this class. I don’t use Windows, so not sure what happens. I did add in code, in the last release, to detect how the application is being opened and adjust accordingly. Sounds like this addition needs looked at in more detail, or removed and we revert to using the -c or --console parameter. And, yes, you are correct. The console was added later as a feature request, and it does use a lot of code in MainForm. From: Phil ***@***.***> Reply to: geraldholdsworth/DiscImageManager ***@***.***> Date: Monday, 22 December 2025 at 02:33 To: geraldholdsworth/DiscImageManager ***@***.***> Cc: Gerald Holdsworth ***@***.***>, Comment ***@***.***> Subject: Re: [geraldholdsworth/DiscImageManager] Feature request - console-only Linux build (built executable currently requires GTK libraries) (Issue #39) philpem left a comment (geraldholdsworth/DiscImageManager#39) That would certainly explain it. I didn't think there was a GUI in the Linux build goes, as the default seems to be to run in console mode unless it's run as DiscImageManager -g. I gather on Windows it defaults to the GUI. I've had a quick go at making a "no GUI dependencies" build at: https://github.com/philpem/DiscImageManager/tree/experimental-nogui-build Sadly this has failed because the GUI and console both store data in MainForm, which means it has to be up and running for the app to work. Obviously that requires LCL to be working and MainForm to be created, which pulls in the GTK dependency. In terms of fixing this, it looks like the console and GUI code is mixed in together. I guess the GUI was created first then the Console added on later -- nothing I haven't seen before, and it's something I've certainly done in the past in my Delphi dev days. To fix it, the disc image processing code would need to be extracted into its own Unit or Class, then the MainForm and Console (and probably all the other forms) refactored to use that. Given the scale of the work involved, I don't want to rush ahead and do all this only to end up stepping on your feet (it is after all your project!). I see there's a "version 2" in the UI mockup phase. Thinking out loud, this kind of refactor could be useful for bootstrapping that, as afterwards things would be split into "the disc image UI" and "the disc image processing library code". — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[geraldholdsworth]

Hi Phil, I am more than happy for you to contribute towards this project. After all, what started out as a little side project for Repton Map Display has grown arms and legs and become more a Stardot (and beyond) project. What I will say is though, it might be a better idea to spend our collective energies on version 2 rather than trying to untie version 1. So, if you are willing, and I can work out how to do it, I can create a new repository for version 2 and make you a contributor. I can drop you a PM on Stardot, unless you want to drop me an email (which I’ve put in various places within DIM), and we can discuss this further. Cheers, Gerald. From: Phil ***@***.***> Reply to: geraldholdsworth/DiscImageManager ***@***.***> Date: Monday, 22 December 2025 at 02:33 To: geraldholdsworth/DiscImageManager ***@***.***> Cc: Gerald Holdsworth ***@***.***>, Comment ***@***.***> Subject: Re: [geraldholdsworth/DiscImageManager] Feature request - console-only Linux build (built executable currently requires GTK libraries) (Issue #39) philpem left a comment (geraldholdsworth/DiscImageManager#39) That would certainly explain it. I didn't think there was a GUI in the Linux build goes, as the default seems to be to run in console mode unless it's run as DiscImageManager -g. I gather on Windows it defaults to the GUI. I've had a quick go at making a "no GUI dependencies" build at: https://github.com/philpem/DiscImageManager/tree/experimental-nogui-build Sadly this has failed because the GUI and console both store data in MainForm, which means it has to be up and running for the app to work. Obviously that requires LCL to be working and MainForm to be created, which pulls in the GTK dependency. In terms of fixing this, it looks like the console and GUI code is mixed in together. I guess the GUI was created first then the Console added on later -- nothing I haven't seen before, and it's something I've certainly done in the past in my Delphi dev days. To fix it, the disc image processing code would need to be extracted into its own Unit or Class, then the MainForm and Console (and probably all the other forms) refactored to use that. Given the scale of the work involved, I don't want to rush ahead and do all this only to end up stepping on your feet (it is after all your project!). I see there's a "version 2" in the UI mockup phase. Thinking out loud, this kind of refactor could be useful for bootstrapping that, as afterwards things would be split into "the disc image UI" and "the disc image processing library code". — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>