Page 3 of 7
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 12:04 am
by MrFlibble
On it now.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 12:20 am
by Cholmondely
Just to mention - Hiran was using the debug console for his
Nexus/Oolite Communicator add-on. To allow players to communicate with each other, share goodies,
et cetera.
Will your changes enhance this?
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 12:22 am
by cag
MrFlibble wrote: ↑Sat Apr 20, 2024 9:27 pm
Alas quite a few folk don't care to have 'latest' python, especially not system-wide. In the Telescope thread it became apparent that Cholly is still on a system where 2.7 is standard.
Obviously, for developer tools like the DebugConsole, requiring a reasonably current python is not an issue. The intended audience will already know, or rapidly learn, how to set up a Python environment. It's almost funny that the 'normal' Debug Console needs python2, though it was written c. 18 years ago.
I disagree. Many of the oxp authors know only JS and only since they entered the dark side of Oolite. The learning curve is tough enough without adding Python to their list. Most systems will have some Python by default and I was hoping they could use DebugConsole without having to touch it. I also published a Windows executable at the time in cases where it was absent; I figured a Linux user could build their own (esp. as I have no Linux experience).
MrFlibble wrote: ↑Sat Apr 20, 2024 9:27 pm
hiran wrote: ↑Sat Apr 20, 2024 9:07 pm
But what exactly did you mean by setting up git? What is your goal? (I guess setting up a git repository on Github is just a buttonclick any of us can do)
I think cag was intending to put DebugConsole v3 on github so we could collaboratively fix/improve it. I'm of the opinion that the most stable/current debug console should be kept alongside the debug OXP in the github for Oolite itself, and maybe even bundled with the dev version to simplify entry to Oolite development.
Exactly so. Part of the problem is what MrFlibble and I are doing right now, juggling the source back and forth. Another part is I cannot and should not be the single point of failure. Collaborating will be much easier and having multiple users will help prevent losing access the next time my PC goes up in flames. I'm thinking a minimum of 6 users: me, hiran, MrFlibble, phkb, Milo, Commander_X, a_c, etc. Not that I expect anything more from them other than hanging on to a spare set of keys!
PS: As for licencing, I'll go with the most permissive one you can suggest. There's no money to be made and my ego has been punctured enough over the years it can no longer hold any hot air.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 12:34 am
by MrFlibble
OoliteDebugConsole2-02.zip
Hopefully I've (with the aid of ImageMagick) translated the newer ico into pngs correctly.
Re: Fonts. I'm not sure that's such a problem. I'll fire up a virgin setup when time permits, test it out, and come up with at least a predictable workaround.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 1:01 am
by MrFlibble
I made a self-contained version with pyinstaller on Linux. Doddle. Should be fairly easy to churn out static versions for most OSes between us so the non-pythoners won't have to get involved.
Currently the config/logs etc. all get spat out in the current directory, which can be annoying. Perhaps it would be nicer to have the config directory configurable with command line args, while defaulting to something more 'normal'. e.g. on Linux maybe default to: $HOME/.Oolite/DebugConsole2/ with a --configdir=[configdir] command-line arg, and or a DebugConsole2_CONF environment variable. I work around this with a wrapper script to set the pwd appropriately, but that's not very "user-fluffy", and doesn't lend itself to the exe versions.
If (as I suspect) there's a way to redirect Oolite's log directory at launch, that could be applied to the DebugConsole.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 1:07 am
by cag
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 1:32 am
by MrFlibble
cag wrote: ↑Sun Apr 21, 2024 1:07 am
Bizarre. It worked for me. Still does.
BTW I didn't convert the xbm from the pngs as the difference is minor. I should be able to make the colour icon work under Linux which seems to be currently falling back on the xbm. I've already found one way (at least for Python3+), I just need to test it on more distros.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 1:39 am
by cag
a line got duplicated: 298 & 299
there's an extra 'u' (my fault) in 2888: errmsg = 'Uunsupported var ...
were you not going to change default value of 'Use Oolite Plist for local font/colors'? line 214
wrt cfg/log files in current directory, I've been running it from the folder it was unzipped into; my desktop shortcut has it run from that folder. Thus, I had no need for command line arguments or re-directing output files. It could be done but is there no similar functionality on Linux?
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 2:37 am
by MrFlibble
cag wrote: ↑Sun Apr 21, 2024 1:39 am
a line got duplicated: 298 & 299
there's an extra 'u' (my fault) in 2888: errmsg = 'Uunsupported var ...
were you not going to change default value of 'Use Oolite Plist for local font/colors'? line 214
Dupe lines and extra u removed. Default changed. Hopefully I've tweaked the link to work for all.
OoliteDebugConsole2-03.zip
cag wrote: ↑Sun Apr 21, 2024 1:39 am
wrt cfg/log files in current directory, I've been running it from the folder it was unzipped into; my desktop shortcut has it run from that folder. Thus, I had no need for command line arguments or re-directing output files. It could be done but is there no similar functionality on Linux?
I run most things from a terminal, especially under development. If I mouse-launch this from its own folder, all is well... If I create a shortcut (symlink) on the desktop, then that's where the current directory is, and that's where the logs etc. go. On the desktop.
If the user creates a symbolic link to it like $HOME/bin/OoDS2, they can simply type OoDS2 in a terminal from anywhere, and whatever directory they're in at the time gets logs and configs dropped in it, and we likely start with no config.
Creating a desktop/panel launcher using xfce4 (my window manager of choice), the dialogue allows to set a working directory. As long as the user bothers to do that, all will be well.
Whatever the current directory is, is where this drops its logs and configs. No biggie for me once I'd spotted it.
I mostly wrapper things like this as scripts in $HOME/bin rather than as symlinks, so I can simply use something like this as a shell script:-
Code: Select all
#!/bin/sh
cd $HOME/Oolite-scripts/OoliteDebugConsole2 && python DebugConsole.py
If we replace the symlink from earlier (~/bin/OoDS2) with that as an executable (chmod 755 ~/bin/OoDS2), then OoDS2 can be run from a terminal or launched via a clicky interface from any directory, with the expected results.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 4:16 am
by cag
link works fine
I read your last post a few times. Not being a Linux user, that did not help.
I'm it is possible to limit the files to the launch folder if you know how. Let's put off any further changes unless we get multiple requests.
All we need now is a place on the wiki to store your zip file.
(but not today)
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 5:40 am
by MrFlibble
Thanks cag. All good.
Random hint.
Some users may find this helpful. Assumes they either already use ssh, or are happy to add it.
In this case, the game computer runs an ssh server for various reasons. File transfer, remote shell and this trick among them.
Today, I'm testing the current DebugConsole2 on an uninitiated laptop, and rather than set Oolite to connect to external hosts, I can use ssh from the debug laptop to listen to the debug port at the game machine.
The following is run on the debuglaptop, and is connecting to gamehost, and is run prior to launching anything else.
Change gamehost to the name or IP of the target game machine.
Code: Select all
ssh -R8563:127.0.0.1:8563 gamehost
Of course you also get a shell connection to gamehost, handy if you need to kill a runaway fullscreen game that may be struggling to render a generation ship flying into a planet.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 6:12 am
by hiran
I pushed this code into
https://github.com/OoliteProject/oolite ... ree/newGUI
Next we should check whether you guys have developer access and are able to continue developing there.
If that is confirmed, we can think of how users should be able to download and use the outcome.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 6:17 am
by hiran
MrFlibble wrote: ↑Sun Apr 21, 2024 1:01 am
I made a self-contained version with pyinstaller on Linux. Doddle. Should be fairly easy to churn out static versions for most OSes between us so the non-pythoners won't have to get involved.
Would like to know more details on the Doddle part.
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 6:52 am
by Cholmondely
cag wrote: ↑Sun Apr 21, 2024 12:22 am
MrFlibble wrote: ↑Sat Apr 20, 2024 9:27 pm
Alas quite a few folk don't care to have 'latest' python, especially not system-wide. In the Telescope thread it became apparent that Cholly is still on a system where 2.7 is standard.
Obviously, for developer tools like the DebugConsole, requiring a reasonably current python is not an issue. The intended audience will already know, or rapidly learn, how to set up a Python environment. It's almost funny that the 'normal' Debug Console needs python2, though it was written c. 18 years ago.
I disagree. Many of the oxp authors know only JS and only since they entered the dark side of Oolite. The learning curve is tough enough without adding Python to their list. Most systems will have some Python by default and I was hoping they could use DebugConsole without having to touch it. I also published a Windows executable at the time in cases where it was absent; I figured a Linux user could build their own (esp. as I have no Linux experience).
MrFlibble wrote: ↑Sat Apr 20, 2024 9:27 pm
hiran wrote: ↑Sat Apr 20, 2024 9:07 pm
But what exactly did you mean by setting up git? What is your goal? (I guess setting up a git repository on Github is just a buttonclick any of us can do)
I think cag was intending to put DebugConsole v3 on github so we could collaboratively fix/improve it. I'm of the opinion that the most stable/current debug console should be kept alongside the debug OXP in the github for Oolite itself, and maybe even bundled with the dev version to simplify entry to Oolite development.
Exactly so. Part of the problem is what MrFlibble and I are doing right now, juggling the source back and forth. Another part is I cannot and should not be the single point of failure. Collaborating will be much easier and having multiple users will help prevent losing access the next time my PC goes up in flames. I'm thinking a minimum of 6 users: me, hiran, MrFlibble, phkb, Milo, Commander_X, a_c, etc. Not that I expect anything more from them other than hanging on to a spare set of keys!
Red Herring! (should that be Red Python?)
1) How many of our OXPS actually use Python?
Is it just Telescope (+Telescope Options?) and the Debug Console - or are there
oodles of them?
2) Note: I've not had any problems whatsoever with my 2.7 that I've noticed (I
can happily live with my ephemeral Masslock borders - and they might well be due to something else).
And my attempts to investigate Debug Console proved a failure. I ended up with
a handful of magic formulae, none of which I've ever used. Not even before Hiran bamboozled me into tweaking the Console so we could experiment with Nexus/Oolite Communicator!
So for the handful of Dark-Side devotees who both can and will use the "cageily-flibbleificated" Console, adding in a newer Python version just for them seems an easy enough requirement.
3) Old Computers: one of the seeming "selling points" of Oolite used to be the ability to run it on old computers. If you read through this BB, this is a point which has come up time and time again. I'm not too sure where this stands today - the recent attempt to hide the ability to download the 32-bit versions implies that it is not the priority it used to be. This would be an argument to carry on with 2.7 for normal OXPs.
___________________________________________________________________________________________________________________
cag wrote: ↑Sun Apr 21, 2024 12:22 am
PS: As for licencing, I'll go with the most permissive one you can suggest. There's no money to be made and my ego has been punctured enough over the years it can no longer hold any hot air.
If you can make it to the Anniversarial shindig in July we can try some sticking plaster and see if it helps!
___________________________________________________________________________________________________________________
MrFlibble wrote: ↑Sat Apr 20, 2024 9:27 pm
... exactly ...what ... ?
Would a log-in for our wiki be of any use?
Re: [WIP] new GUI for debug console
Posted: Sun Apr 21, 2024 7:23 am
by hiran
Cholmondely wrote: ↑Sun Apr 21, 2024 6:52 am
3) Old Computers: one of the seeming "selling points" of Oolite used to be the ability to run it on old computers. If you read through this BB, this is a point which has come up time and time again. I'm not too sure where this stands today - the recent attempt to hide the ability to download the 32-bit versions implies that it is not the priority it used to be. This would be an argument to carry on with 2.7 for normal OXPs.
I do not believe the old versions are dropped because anyone considered them no longer important. Oolite largely relied on one person doing all that. No-one chimed in to support, and meanwhile the person no longer does it. No-one else took over when that happened. I barely managed to setup automation so we get the project built for two out of three target operating systems (and their most current version only).
You need to balance the value of running on old computers versus the amount of work it takes maintain the build environments and regularly create all these nice builds.