[WIP] new GUI for debug console

[Cholmondely]

Is this still true?

...you can only (currently) pass one parameter in the console

....If you want to know the list of current macros in the console, either use the :listM command in the console, or for the more manual approach look in debugConfig.plist in the config folder of basic-debug.oxp. The built-in macro definitions start around line 56.

[MrFlibble]

oolite.space still has links to the older v1.6 console in the downloads page. This should be updated. The packaging has also changed. Previously we had one package for both Windows and Linux, now it is one package per platform. This has to also be updated on the website.

Here's my take on that: Speaking as a picker of fluff and whacker of small issues. I anticipate corrections from Hiran and/or Cag.

• 1.6 is not likely to get any functional updates, or changes of behaviour. It is stable.

• 2.x, though very close to maturity (a few days, I hope), is still in functional flux, so, beta.

The 2.x release tar/zip files contain just an executable. There's no README.txt or license file.

I've made a script to generate an installation ready Linux tarball with .desktop file, icon etc. and a wrapper script, able to set config directory via an environment variable. When extracted to $HOME/.local, /usr/local, or /usr, the debugger will appear in application menus under Games and Development, and be in $PATH for easy shell execution.

That works well, for a range of distros/DEs I've tried, and should be up in the next couple of days. Once a few users have found the glaring errors, and we've whacked those, it can become the stable, at least for Linux.

Fluffing the windows version is not something I've personally explored (yet). I hope there will at least be some basic wrapper script to make it play nice when launched via the gui, and a launcher icon. Once I've got the Linux end nailed down, I'll boot the dreaded M$-OS and have a look.

IMHO, the executable alone in a tarball/zip should not be the 'stable' solution as presented to end user.

More news presently

[hiran]

oolite.space still has links to the older v1.6 console in the downloads page. This should be updated. The packaging has also changed. Previously we had one package for both Windows and Linux, now it is one package per platform. This has to also be updated on the website.

Thank you for pointing out. I'll take a look.

Done. The link and text is still valid but now version agnostic.

Here's my take on that: Speaking as a picker of fluff and whacker of small issues. I anticipate corrections from Hiran and/or Cag.

• 1.6 is not likely to get any functional updates, or changes of behaviour. It is stable.

• 2.x, though very close to maturity (a few days, I hope), is still in functional flux, so, beta.

The 2.x release tar/zip files contain just an executable. There's no README.txt or license file.
[...]

All good. Noone said it is perfect the way it is, or that it has to stay that way. You are still free to chip in all your improvements.

[MrFlibble]

All good. Noone said it is perfect the way it is, or that it has to stay that way. You are still free to chip in all your improvements.

Oh, alright then This is for Linux x86_64. (It occurs to me the archive file names ought to reflect architecture in future).

My scratchings in github arrived at this 'installable' tarball. I'll not push it into main just yet. Any grumbles/issues, let me know.

https://github.com/OoMrFlibble/oolite-d ... llable.tgz

That tarball is ready to unpack into to $HOME/.local, /usr/local, or /usr. I've only tested it in $HOME/.local.

Suggested installation method for testing: This assumes $HOME/.local exists and that $HOME/.local/bin is in your $PATH. That is likely the case for most modern Linux distributions.

Code: Select all

tar -C $HOME/.local -xzf Oolite-Debug-Console-2.0.7-linux-installable.tgz

Contents of tarball (so you can rip it out if it tries to eat your kittens):

Code: Select all

./bin/OoliteDebugConsole2-real
./bin/OoliteDebugConsole2
./share/icons/hicolor/256x256/apps/OoliteDebugConsole2-icon.png
./share/applications/OOliteDebugConsole2.desktop

The app should now appear in your application menus under Games and also Development for you clickable pleasure. It can alternatively be invoked in a terminal as OoliteDebugConsole2. The config file and logs will by default go to $HOME/.Oolite/DebugConsole2 but that can be changed by an environment variable "OoDC2_CFG_DIR".

So to launch this and save config and logs to /home/dev/myconfigs

Code: Select all

OoDC2_CFG_DIR=/home/dev/myconfigs OoliteDebugConsole2

I'll likely turn this into a mkinstall or similar once we know it does the right thing.

Note to self: I should make the wrapper check the directory it is in for OoliteDebugConsole2-real before resorting to $PATH. That would be more versatile for those who don't care to have it in their application menus.

[hiran]

All good. Noone said it is perfect the way it is, or that it has to stay that way. You are still free to chip in all your improvements.

Oh, alright then This is for Linux x86_64. (It occurs to me the archive file names ought to reflect architecture in future).

My scratchings in github arrived at this 'installable' tarball. I'll not push it into main just yet. Any grumbles/issues, let me know.

https://github.com/OoMrFlibble/oolite-d ... llable.tgz

That tarball is ready to unpack into to $HOME/.local, /usr/local, or /usr. I've only tested it in $HOME/.local.

Suggested installation method for testing: This assumes $HOME/.local exists and that $HOME/.local/bin is in your $PATH. That is likely the case for most modern Linux distributions.

Code: Select all

tar -C $HOME/.local -xzf Oolite-Debug-Console-2.0.7-linux-installable.tgz

Contents of tarball (so you can rip it out if it tries to eat your kittens):

Code: Select all

./bin/OoliteDebugConsole2-real
./bin/OoliteDebugConsole2
./share/icons/hicolor/256x256/apps/OoliteDebugConsole2-icon.png
./share/applications/OOliteDebugConsole2.desktop

The app should now appear in your application menus under Games and also Development for you clickable pleasure. It can alternatively be invoked in a terminal as OoliteDebugConsole2. The config file and logs will by default go to $HOME/.Oolite/DebugConsole2 but that can be changed by an environment variable "OoDC2_CFG_DIR".

So to launch this and save config and logs to /home/dev/myconfigs

Code: Select all

OoDC2_CFG_DIR=/home/dev/myconfigs OoliteDebugConsole2

I'll likely turn this into a mkinstall or similar once we know it does the right thing.

Note to self: I should make the wrapper check the directory it is in for OoliteDebugConsole2-real before resorting to $PATH. That would be more versatile for those who don't care to have it in their application menus.

I just looked at your forked repository and see you tweaked the Github workflow to provide another build artifact. Congratulations, I like seeing that progress!

Yet I am wondering why you put so much effort into the 'distribution' part. Why a wrapper script if the debug console is under your control and one or two lines in the source code could make the application load the configuration from another place? I do understand that having an icon, a readme and some other goodies should be there. But then that's where Oolite uses this 'autopackage'. Reusing that would not make your life easier - it would also make the installation of both Oolite and OoDebugConsole look homogenous on Linux.

For Windows we would then go for NSIS, and again the installations would look homogenous.

[MrFlibble]

Yet I am wondering why you put so much effort into the 'distribution' part. Why a wrapper script if the debug console is under your control and one or two lines in the source code could make the application load the configuration from another place? I do understand that having an icon, a readme and some other goodies should be there. But then that's where Oolite uses this 'autopackage'. Reusing that would not make your life easier - it would also make the installation of both Oolite and OoDebugConsole look homogenous on Linux.

For Windows we would then go for NSIS, and again the installations would look homogenous.

I used a wrapper script as a quick workaround which avoided a potential rabbit-hole, and extra platform specifics in the python code

I'll look into finding a sane way to do it natively with python as time permits. I'd prefer the path to be 'choosable' there anyway, with a default that makes sense. That would make it possible to set $PWD to the source (so we get the icons and stuff), run it with python interpreter, and still have sane configs. Switching that scenario, running with $PWD of config dir, the icons don't get found unless we're using the compiled version.

I just glanced at autopackage. I remember it now. Yes! I'll go that way.

[hiran]

Yet I am wondering why you put so much effort into the 'distribution' part. Why a wrapper script if the debug console is under your control and one or two lines in the source code could make the application load the configuration from another place? I do understand that having an icon, a readme and some other goodies should be there. But then that's where Oolite uses this 'autopackage'. Reusing that would not make your life easier - it would also make the installation of both Oolite and OoDebugConsole look homogenous on Linux.

For Windows we would then go for NSIS, and again the installations would look homogenous.

I used a wrapper script as a quick workaround which avoided a potential rabbit-hole, and extra platform specifics in the python code

I'll look into finding a sane way to do it natively with python as time permits. I'd prefer the path to be 'choosable' there anyway, with a default that makes sense. That would make it possible to set $PWD to the source (so we get the icons and stuff), run it with python interpreter, and still have sane configs. Switching that scenario, running with $PWD of config dir, the icons don't get found unless we're using the compiled version.

I just glanced at autopackage. I remember it now. Yes! I'll go that way.

You don't like platform specifics? How about this?
https://github.com/OoliteProject/oolite ... e.py#L4319

Browsing the source I think the config filename receives a default value here:
https://github.com/OoliteProject/oolite ... le.py#L103
but here you see it explicitly refers to the current working directory:
https://github.com/OoliteProject/oolite ... e.py#L1984

Actually I'd prefer resources like config files to be loaded according to the Linux Filesystem standard, which means they should come from within the User Home (although in .local or .config or somewhere). See also https://phoenixnap.com/kb/linux-config- ... -heading-3

And resources could be loaded relative to the application's filesystem location. That gives you freedom to install it per user or globally - via different install systems. To get the path to the application see
https://stackoverflow.com/questions/129 ... nning-file
or
https://stackoverflow.com/questions/404 ... yinstaller

[MrFlibble]

I just glanced at autopackage. I remember it now. Yes! I'll go that way.

Wow, Autopackage is a dead project that has not seen any love for 15 years AFAICT!!

I'll have a crack at it anyway. Seems to load and run.

[hiran]

I just glanced at autopackage. I remember it now. Yes! I'll go that way.

Wow, Autopackage is a dead project that has not seen any love for 15 years AFAICT!!

I'll have a crack at it anyway. Seems to load and run.

True. Do you have something better? That is portable to Linux other than .deb or .rpm? Autopackage seems not too bad a choice but I wonder why it was discontinued.

Ah, reading again: one of the mentioned alternatives is appimage. But I have not yet managed to create one.

[MrFlibble]

I just glanced at autopackage. I remember it now. Yes! I'll go that way.

Wow, Autopackage is a dead project that has not seen any love for 15 years AFAICT!!

I'll have a crack at it anyway. Seems to load and run.

True. Do you have something better? That is portable to Linux other than .deb or .rpm? Autopackage seems not too bad a choice but I wonder why it was discontinued.

I'll look for something better. I've just checked out the syntax for the config file in oolite... Wow.. that'd be a lot of work to install three files. Granted maybe we could add a man page or something, but as this is a GUI app, after a basic readme, the help could be shown by the app itself.

apt install makeself <- seems as good a place as any to start.

[cag]

Is this still true?

...you can only (currently) pass one parameter in the console

....If you want to know the list of current macros in the console, either use the :listM command in the console, or for the more manual approach look in debugConfig.plist in the config folder of basic-debug.oxp. The built-in macro definitions start around line 56.

Yes. The macro system has remained intact.

The reply to that post

...
Since PARAM contains everything after the macro name, you can parse it in a macro. For example:

Code: Select all

:setM spawnN (function(){ let params = PARAM.split(" "); this.Ts = system.addShips(params[0], params[1], PS.position, 10000);})()
// Usage: :spawnN pirate 5

shows a way to work around that limitation. The form (function () {...})() is an iife (Immediately-Invoked Function Expression), in case you wish to google it. When you hit Enter, the function executes.

Note that your macros will be stored in the command history, not the config file. If you craft one you'd like to reuse, you should keep a copy in a text file.

For more complex operations, consider using aliases (debug console 2.x, 3.x), which are stored in the .cfg file. Anything you can do in your JS script you can do in the debug console with an alias.

Aliases are not a replacement of the macro system; they're just another way to interact w/ Oolite. I still use macros, depending on the situation, as they are simpler to use.

[MrFlibble]

I just glanced at autopackage. I remember it now. Yes! I'll go that way.

Wow, Autopackage is a dead project that has not seen any love for 15 years AFAICT!!

I'll have a crack at it anyway. Seems to load and run.

True. Do you have something better? That is portable to Linux other than .deb or .rpm? Autopackage seems not too bad a choice but I wonder why it was discontinued.

Ah, reading again: one of the mentioned alternatives is appimage. But I have not yet managed to create one.

Appimage has it's uses, but doesn't install. It makes a lump with all that's required to execute without unpacking as such, but no desktop icons or app menu entries. No better than fixing the conf dir thing and making a binary as we do AFAICT.

An appimage could perhaps be crafted to add it's own .desktop files, but I guess if you move/delete the appimage, those are likely to become become orphans in the menus.

Makeself 2.5.0 from https://github.com/megastep/makeself, documented at https://makeself.io/ is looking good. It's basically a self-extracting tarball maker.

Makeself script-wrapped-tarballs unpack via a temp directory, optionally run a shell script from the archive, then delete the temp dir.

I rolled a package very quickly, with an embedded script to install itself into a test location.

An adequate install script should be quite easy to conjure. Written in plain .sh (not bash) it could work on very many distros including compact oddballs like Alpine.

If I do it in the builder scripts, it may be useful to those wanting to repurpose 32 bit laptops as debuggers, or port to other architectures.

[hiran]

Appimage has it's uses, but doesn't install. It makes a lump with all that's required to execute without unpacking as such, but no desktop icons or app menu entries. No better than fixing the conf dir thing and making a binary as we do AFAICT.

True again. It has the same flaw as pyinstaller. It just doesn't do the installer part.

Meanwhile I like running .appimage both for games or other stuff but I use to launch them via terminal.
But looking at this video it just could be so much easier: https://www.youtube.com/watch?v=nzZ6Ikc7juw

And here is how to add this to the menu? https://www.youtube.com/watch?v=KUiCnwhUo1M

[MrFlibble]

Appimage has it's uses, but doesn't install. It makes a lump with all that's required to execute without unpacking as such, but no desktop icons or app menu entries. No better than fixing the conf dir thing and making a binary as we do AFAICT.

True again. It has the same flaw as pyinstaller. It just doesn't do the installer part.

Meanwhile I like running .appimage both for games or other stuff but I use to launch them via terminal.
But looking at this video it just could be so much easier: https://www.youtube.com/watch?v=nzZ6Ikc7juw

And here is how to add this to the menu? https://www.youtube.com/watch?v=KUiCnwhUo1M

I too usually launch Appimages from a terminal, having usually symlinked them with nice names in ~/bin. I don't think it makes sense to wrap a pyinstaller in an appimage.

One thing I just noticed though... Appimage files can have icons embedded, which show up for me in Thunar (I never browsed to ~/bin the fluffy way before! Those icons work through symlinks on Xfce4, but there's still no sane way to make them appear nicely in the app menus. It would be VERY shiny indeed to have the icon appear in file browsers for the pyinstaller binary. On the plus side, I understand using --icon pathto/iconfile.ico should work on windoze and mac.

Adding even pyinstaller binaries to the apps menu is a doddle with most desktops, but there's no "one instruction to solve them all", and neither is there a way to get a nice menu icon short of providing one, and getting the user to select it when they create their launcher. Else they just get the default 'cogs' icon or whatever.

So, a quick scout around:-

Flet looks good at a glance, but might need a GUI rewrite and looks fairly heavy with license, and has some ugly dependencies. Using a battleship factory to build a canoe!

A quick play with Nuitka https://nuitka.net, which I pip installed in the builder venv. https://nuitka.net. The executable turned out 21 megs, so 50% larger. Seems to launch/render a tad faster. License may not be compatible.

Code: Select all

python -m nuitka --linux-icon=OoJSC256x256.png --follow-imports DebugConsole.py

However slick, it did not have a desktop icon in Thunar.

A desktop file and icon could be emitted by our program I suppose, making it 'self-install', with the possibility of menu oprphans as mentioned before... Unless the same 'click to install me' moves our blob to ~/.local/bin, leaving it hard for Captain Numpty to fumble, and easy for Doctor Knowsthesystem to pluck it out.

https://python-appimage.readthedocs.io/en/latest/apps/ hints at something I'd thought about... to cover as many distros old and new as possible, due to libc headaches, building with an older system can be a good idea. A way to get that done using actions, without changing direction, might be to use kvm-qemu with a small headless linux image from e.g. lilnuxcontainers. IIRC that would not be much different to what I did recently to make an Alpine32 version of the debugger.

I still feel a simple scripted installer on linux is the most distro agnostic thing, and the path of least resistance. As long as it checks arch, asks whether to use user local, system local, or system, checks the $PATH, warns if not there, and can invoke sudo or doas intelligently, it will cover the bloomin' lot.

I've got my stackoverflow reading list lined up for: read system variables, sanity check path strings, create paths with parents etc. in python. All those thing I did in a few moments with shell script. Plus sidem I think I can do it cross-platform in python.