[WIP] new GUI for debug console

[MrFlibble]

I think I cracked the Linux icon on alt-tab etc.

It may even work with pyinstaller. I'll have a crack and report finding momentarily.

[MrFlibble]

This seems to work well for the Linux app switcher etc. in python 3

It doesn't have any effect with python 2.7, where the xbm fallback still shows.

I used to the 'overkill' 256x256 icon, for the sheer joy of it.

It also works with pyinstaller, as long as

Code: Select all

--add-binary "OoJSC256x256.png:."

is added to the pyinstaller command.

Here are the main points.

Code: Select all

 		iconFile = 'OoJSC256x256.png' if platformIsLinux else 'OoJSC.ico'
 #stuff happens here.. iconPath gets created in pyinstaller friendly way.
 #this goes in the 'try'
 		tempicon = PhotoImage(file = iconPath)
 		top.iconphoto(False, tempicon)

Full, pasteable version.

Code: Select all

	def __init__(self):
		self.readConfigFile()
		self.init_toplevel()
		self.makeFonts()
		# app has 2 frames stacked vertically, for menubar and the paned window
		self.top.columnconfigure(0, weight=1)
		self.top.rowconfigure(0, minsize=self.lineSpace)
		self.top.rowconfigure(1, weight=1)
		self.menubar = Frame(self.top, background='#eeeeee')
		self.menubar.grid(row=0, sticky=E+W)
		Frame.__init__(self, self.top)		# constructor for the parent class, Frame
		self.rowconfigure(0, weight=1)		# make row 0 stretchable and
		self.columnconfigure(0, weight=1)	# make column 0 stretchable so it fills its frame
		self.grid(row=1, sticky=N+S+E+W)	# make the Application fill its cell of the top-level window
		self.gameStarted = IntVar(name='gameStarted')
		self.addTraceTkVar(self.gameStarted, self.checkGameStatus)
		self.createWindows()
		self.createDebugMenus()
		self.createOptionsMenus()
		self.createAliasFrame()
		self.createFontMenus()				# Settings menu is created upon connection, as they vary
		self.loadCmdHistory()
		self.setconnectPort()
		self.processMessage()
		self.sendSilentCmd()				# initiate polling
		self.top.bind_all('<<closeAnyOpenFrames>>', self.closeAnyOpenFrames)

	def init_toplevel(self):
		top = self.top = Tk()
		top.minsize(MINIMUM_WIDTH, MINIMUM_HEIGHT)
		top.resizable(width=True, height=True)
		top.title(DEBUGGER_TITLE)
		top.protocol("WM_DELETE_WINDOW", self.exitCmd)

		# self.menubar = Menu(self.top)	# create a toplevel menu
		# self.top.config(menu=self.menubar)# display the menu
		# NB: menubar must precede .geometry call, else app shrinks by height of menubar (20) on each invocation
		#     - no longer relevant as not using toplevel menu, good to remember

		try:							# if geometry are not valid, revert to default
			top.geometry(self.localOptions['Geometry'])
		except:
			top.geometry(DEFAULT_GEOMETRY)# "500x380"
		iconFile = 'OoJSC256x256.png' if platformIsLinux else 'OoJSC.ico'
		iconPath = os.path.join(os.getcwd(), iconFile)

		if FROZEN:
			meipass = None
			if HAVE_MEIPASS:
				meipass = sys._MEIPASS
			elif '_MEIPASS2' in os.environ:# windows compiled runtime (pyInstall)
				meipass = os.environ['_MEIPASS2']
			if meipass:
				iconPath = os.path.join(meipass, iconFile)
				
		# Under Windows, the DEFAULT parameter can be used to set the icon
		# for the widget and any descendents that don't have an icon set
		# explicitly.  DEFAULT can be the relative path to a .ico file
		# (example: root.iconbitmap(default='myicon.ico') ).
		if platformIsWindows:
			try:
				top.iconbitmap(default=iconPath)
			except:
				try:
					top.iconbitmap(default=os.path.join(os.path.dirname(sys.argv[0]), iconFile))
				except:
					try:
						top.iconbitmap(default='@oojsc.xbm')
					except:
						pass
		else:
			try:
				tempicon = PhotoImage(file = iconPath)
				top.iconphoto(False, tempicon)
			except:
				try:
					top.iconbitmap(iconPath)
				except:
					try:
						top.iconbitmap(os.path.join(os.path.dirname(sys.argv[0]), iconFile))
					except:
						try:
							top.iconbitmap('@oojsc.xbm')
						except:
							pass

[cag]

Good work. It's nice to finally get some work done on the Linux side.

We should try not to overwork hiran. Are you on github? Do I need to make an account before I can get access to out project? Anyone got suggestions on learning how to git?

[hiran]

Good work. It's nice to finally get some work done on the Linux side.

We should try not to overwork hiran. Are you on github? Do I need to make an account before I can get access to out project? Anyone got suggestions on learning how to git?

You need an account on Github. Not for reading our open source projects but to contribute.
To learn git there are myriads of tutorials out there. If both of you are beginners I'd keep it simple: just learn about these verbs:

- git clone -> copy a git repository to your local machine (initial checkout)
- git status -> show what git thinks about your filesystem
- git checkout -> go to a specific time in history
- git commit -> write the change set into version control. Change set?
- git add -> add a changed file to a change set (yes, you can add multiple files and then commit)
- git push -> write the local changes back to Github
- git pull -> read subsequent changes from Github

Of course there are a lot more tweaks that can be done. But the above commands and a good reference can get you very far. If you are interested in an excellent graphical animated tutorial have a look at https://learngitbranching.js.org/

[MrFlibble]

With the desktop file for linux (XDG desktop file), there's no obvious way I can see to set a current/working directory, which may be a problem for DebugConsole and its log/config files. It does have a way to pass variables to whatever's being launched.

It seems the working directory (at least for xfce4) is $HOME, which is undesirable for the conf an log files.

This is how I've done a 'user local' install manually.

For my test, I've copied and renamed OoJSC256x256.png to $HOME/.local/share/icons/hicolor/256x256/apps/OoliteDebugConsole2-icon.png

I'm using a "shim" script to handle setting the working directory and launching the debug console. This will check if the variable OoliteDebugConsole2_conf exists, and use that as the config/log directory, else it will use a hard wired default of $HOME/.OoliteDebugConsole2 which is of course hidden from plain user view by the leading dot.

Both that script and the debug console executable are in $HOME/.local/bin (I used symlinks to my dev versions)

Code: Select all

ls ~/.local/bin/Oo*
OoliteDebugConsole2  OoliteDebugConsole2.sh

The shim script (OoliteDebugConsole2.sh) is set chmod 755 and looks like this:

Code: Select all

#!/bin/sh

#Wrapper script for OoliteDebugConsole

xit(){ echo "Error: $*" >&2 ; exit 1 ; }

# Set up and cd to the working directory, where the configs and logs should live.
# If we want to have multiple/different ports/configs, this script can be copied
#  and tweaked to point elsewhere.
#default
confdir="$HOME/.Oolite/DebugConsole2"

#or get from env (crude)
x="$OoliteDebugConsole2_conf"
[ "x$x" != "x" ] && confdir="$x"

[ -d "$confdir" ] || mkdir "$confdir" ||\
 xit "Failed to make config directory $confdir"

cd "$confdir" || xit "Could not change directory to $confdir"

#Now pwd is the config directory, we launch the app.
"$HOME/.local/bin/OoliteDebugConsole2"

As always, it looks better in a context highlighting editor.

The $HOME/.local/share/applications/OoliteDebugConsole2.desktop file:

Code: Select all

[Desktop Entry]
Type=Application
Name=DebugConsole2 for Oolite
GenericName=DebugConsole2 for Oolite
Comment=Debugger for Oolite version 2
Exec=.local/bin/OoliteDebugConsole2.sh
Icon=OoliteDebugConsole2-icon.png
Terminal=false
Categories=Application

I suppose exec should be the full path, but as the desktop pwd seems to be $HOME, I figure realtive is ok here. In production, this ought to do as the Oolite installer does and set a full path.

The good news here is that if we call the wrapper script on it's own, we get the config and logs from $HOME/.Oolite/DebugConsole2 but we can either copy and change the scripts default to have different configs, or call it like this:

Code: Select all

OoliteDebugConsole2_conf=/tmp/test OoliteDebugConsole2.sh

And voila! The config directory is /tmp/test.

To do that in the .desktop file we can tweak the Exec line thus:

Code: Select all

Exec=env OoliteDebugConsole2_conf=/tmp/test .local/bin/OoliteDebugConsole2.sh

So now, to have different configs, we can do it from different desktop files.
The env trick works with desktop launchers creates by right clicking desktop and using 'create launcher', at least in xfce4.

(edit: changed the names in .desktop file to stop it jumping in front of oolite in search selections.. I launch Oolite by invoking the start search via the windoze key, hitting oo, then return. I just fancied a play and got the debugger instead.)
(edit: fixed bad check for env var in shim script)
(edit: changed icon to 256x256 and changed name and location)
(edit: changed default confdir to $HOME/.Oolite/DebugConsole2")

Another issue which is probably in the game itself. If the debugger goes away, the game does not try to reconnect. Should that be an issue on oolite's github?

[cag]

For my test, I've copied OoJSC128x128.png to $HOME/.local/share/icons

Was there a problem w/ the 256x256 icon?

In production, this ought to do as the Oolite installer does and set a full path.

Are you planning to include this in Linux package/installer?
All I've been doing is parking the executable in the Oolite folder and get different configs as I have multiple copies installed.

Another issue which is probably in the game itself. If the debugger goes away, the game does not try to reconnect. Should that be an issue on oolite's github?

Pressing 'c' while the game is paused toggles the connection. If the debugger crashes, just relaunch it and reconnect (hit 'c' twice while paused).
The debugger is only available in a dev build so it's good the way it is. Why have extra code in Oolite for something that almost never present?

[MrFlibble]

Was there a problem w/ the 256x256 icon?

Nope.. I should have gone with that. Have edited above accordingly. Also tweaked the icon filename and location to something more sane/normal.

In production, this ought to do as the Oolite installer does and set a full path.

Are you planning to include this in Linux package/installer?
All I've been doing is parking the executable in the Oolite folder and get different configs as I have multiple copies installed.

I feel it ought to be included. Unless anyone has a better workaround.

If making as a .deb or similar package, we ought to put the programs in /usr/bin, the icons and desktop in the appropriate places in /usr/share, and the default config location should really be $HOME/.Oolite/DebugConsole2. I've changed the default config in my example above too.

Thinking about it, perhaps $HOME/.Oolite ought to reside in $HOME/.config/Oolite as is now the fashion. But for now, it is where it is.

Perhaps there also should be an executable installer like the one for Oolite, which allows either system or user-local installs.

Another issue which is probably in the game itself. If the debugger goes away, the game does not try to reconnect. Should that be an issue on oolite's github?

Pressing 'c' while the game is paused toggles the connection. If the debugger crashes, just relaunch it and reconnect (hit 'c' twice while paused).
The debugger is only available in a dev build so it's good the way it is. Why have extra code in Oolite for something that almost never present?

Good to know. Thanks. Perhaps that could be a hint in the debug console at startup.

[cag]

Perhaps that could be a hint in the debug console at startup.

You control the source at the moment, add what you'd like at line 4309

[MrFlibble]

Perhaps that could be a hint in the debug console at startup.

You control the source at the moment, add what you'd like at line 4309

On it. Will upload a 2.04 in a couple of minutes.
Will also upload a tarball of my binary builder which works nicely on a normal installation, and a tarball installable with a binary built on debian 11 which should work fine for most.

[cag]

I tested my luck by simply applying this. Got an error message in the logs.

I needed a github account to view the logs. cag was taken (!) so I'm Oocag

[MrFlibble]

https://www.uploadlite.com/en/d/DebugCo ... 4devbundle

I zipped it all up 'cos the upload service doesn't like tarballs.

The linked zip (DC204-devbundle.zip) contains three archives:

OoliteDebugConsole2-04.zip : My latest version.
Changes: at least-

Code: Select all

	Added console hint how to (dis/re)-connect a running Oolite.
	Hopefully fixed alt-tab and icon on Linux.

OoliteDebugConsole2.04-linux-installable.tar.gz : As the name implies. Build on debian 11 for a slightly smaller size. I made it with OoDC-0.02 (below).
Can either be unpacked in $HOME/.local for a user-local install, probably /usr/local fpor a system-local install, or /usr for a system install.
For a user-local install this might look like:-

Code: Select all

tar -xpzf OoliteDebugConsole2.04-linux-installable.tar.gz -C $HOME/.local

OoDC-0.02.tar.gz : This is my 'builder' also contains OoliteDebugConsole2-04.zip. Aimed at a normal workstation.

Contains the desktop, wrapper-script, icon, and means to tie them together.

Extracts as a directory (OoDC), which contains:

Code: Select all

install-tree  make.sh  OoDebugConsole.cfg  OoliteDebugConsole2-04.zip  OoliteDebugConsole-latest.zip

install-tree gets tarballed after build, with symbolic links de-referenced. It contains:-

bin/OoliteDebugConsole2 : symlink to ../../OoliteDebugConsole (the binary post-build).
bin/OoliteDebugConsole2.sh : my wrapper script
share/applications/OOliteDebugConsole2.desktop
share/icons/hicolor/256x256/apps/OoliteDebugConsole2-icon.png


make.sh is the script to check deps, build our binary, and make a tarball.
To inhibit the annoying login prompt when it checks for packages:-
./make.sh nocheck

OoDebugConsole.cfg is my current favourite config.
OoliteDebugConsole-latest.zip is a symlink to the latest dist zip which could be elsewhere
OoliteDebugConsole2-04.zip is included for ease.

It should work anywhere. I'll assume you want to try in /tmp and have copied OoDC-0.02.tar.gz there:

Code: Select all

tar -xzf OoDC-0.02.tar.gz
cd OoDC
./make # on subsequent runs I'd suggest ./make nocheck

To rebuild, just remove the build directory.

If a new version wants building first change the symbolic link OoliteDebugConsole-latest.zip thus:

Code: Select all

# Assumes the current directory to be OoDC
# and new ver is a zip called OoliteDebugConsole2-05.zip
ln -sf OoliteDebugConsole2-05.zip OoliteDebugConsole-latest.zip

The edit make.sh and change the variable ver (which is near the top) to whatever the new version is. That way the output tarball will have a sane name. I'll ponder a nicer way to do that.

I feel I've bundled it all backwards. The parts for OoDC 'should' be contained in the dist zip. I'll play with doing that another day. I expect the bits to do the same on other platforms could ultimately be bundled that way.

[MrFlibble]

Here's 2.05. OoliteDebugConsole2-05.zip

• No changes to the python script bar the version number.

• Made the Linux binary builder into a tarball under "builder" and added a readme.

• Added a version file so we don't need to faff with the builder.

• Added a rudimentary changelog.

Probably need a license file for the next version, and add the basics of it into any scripts or files of relevance.

[hiran]

I tested my luck by simply applying this. Got an error message in the logs.

I needed a github account to view the logs. cag was taken (!) so I'm Oocag

The next step is to hook you up into the OoliteProject organization into the Developers group.
You can request being added, and it takes an owner to approve.

https://github.com/orgs/OoliteProject/p ... le%3Aowner

[hiran]

Are you planning to include this in Linux package/installer?
All I've been doing is parking the executable in the Oolite folder and get different configs as I have multiple copies installed.

I feel it ought to be included. Unless anyone has a better workaround.

If making as a .deb or similar package, we ought to put the programs in /usr/bin, the icons and desktop in the appropriate places in /usr/share, and the default config location should really be $HOME/.Oolite/DebugConsole2. I've changed the default config in my example above too.

Suggestion: Skip thinking about an installer for now.
We can include DebugConsole into the Oolite dev and test builds (those that have the debug oxp). At least I will consider that once we have executables for both platforms.

[MrFlibble]

Suggestion: Skip thinking about an installer for now.

I for one, am not thinking MUCH about an installer.

In hacking around, trying to make the bits all work, and while making tools to test it rapidly, locally, on various boxes and different scenarios. I figured it wouldn't hurt to include those tools and notes in the source.

In the next version, the Linux builder icon file is a symlink to the one dist-root, getting the linux kit payload down to 4k including the readme, and removing a duplicate.

Hmm! I've got to try rolling a debug executable on an x86_32 distro. I can repurpose an otherwise not very useful old netbook as an external debugger Better yet if I can make it work on alpine x86!!

I'll attempt to get into github a bit more over time of course.

We can include DebugConsole into the Oolite dev and test builds (those that have the debug oxp). At least I will consider that once we have executables for both platforms.

Sounds good. We've got most of it working well enough on Linux x86_64 now. The desktop bits should work on most disros and are in the Linux.tar, even if you don't use the make.sh.