VOGONS

Search

Common searches

Debugger size and colors in Linux

Topic actions

First post, by doshea

Posted on 
User metadata
Rank Member
Rank
Member

I've had some trouble with the debugger's appearance (size and colors) on Fedora 10 after building from the latest sources in CVS. I thought I'd share these in case the workarounds help anyone else:

Under xterm, dosbox doesn't resize the terminal so I have to use 'xterm -geom 80x50', and most of the text is dark grey on black which I can barely read.

Under gnome-terminal, dosbox doesn't resize the terminal so I have to use 'gnome-terminal --geometry=80x50'. The text is black on dark grey which is readable but not ideal.

Under konsole, dosbox doesn't resize the console so I have to do that manually before starting dosbox. The text is light grey on black which is perfectly readable, but it seems to be wrapped at 50 columns. Swapping the order of the parameters in the call to resizeterm() in debug_gui.cpp doesn't help, but commenting out the printf("\e[8;50;80t"); in debug.cpp fixes it, as does reversing the 80 and 50, but http://h30097.www3.hp.com/docs/base_doc/DOCUM … N5/0196____.HTM suggests that the existing code is correct so I guess this is a bug in konsole. I'm using konsole from the RPM kdebase-4.1.4-2.fc10.i386 and there is an update available so perhaps that will fix this problem, but I can't update right now due to lack of disk space.

I'm happy for now since I use konsole most of the time anyway and I guess if the KDE update doesn't resolve the issue I'll have to file a bug with KDE and consider myself lucky that my terminal emulator of choice is the one with the decent colors 😀

Reply 1 of 5, by MiniMax

Posted on 
User metadata
Rank Moderator
Rank
Moderator

printf("\e[8;50;80t") ?? That looks like a terrible, lazy hack to me. Outputting hard-wired terminal dependent escape codes? There must be a newwin() call somewhere where the window size is defined.

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 2 of 5, by Qbix

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

well I couldn't come up with some better. For some reason it is very hard getting xterminals to resize from within the application.
and most of the time ncurses fails to notice the fact the terminial is resized.

Water flows down the stream
How to ask questions the smart way!

Reply 3 of 5, by MiniMax

Posted on 
User metadata
Rank Moderator
Rank
Moderator

You could try sending the debug-process a SIGWINCH.

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 4 of 5, by doshea

Posted on 
User metadata
Rank Member
Rank
Member
MiniMax wrote:

You could try sending the debug-process a SIGWINCH.

I might be wrong, but I thought that that signal was used by the terminal to instruct the process inside it that the terminal's dimensions changed and the application should adapt. I gather that what is wanted is the opposite, i.e. for the process to tell the terminal to change its dimensions.

Also, I forgot to say in my first post: thanks all for making a great product!

Reply 5 of 5, by doshea

Posted on 
User metadata
Rank Member
Rank
Member
MiniMax wrote:

printf("\e[8;50;80t") ?? That looks like a terrible, lazy hack to me. Outputting hard-wired terminal dependent escape codes? There must be a newwin() call somewhere where the window size is defined.

In src/debug/debug_gui.cpp, DBGUI_StartUp() calls resizeterm(50,80) but from reading the man page it sounds like this is meant for use in your SIGWINCH handler, i.e. so you can respond to a change in size rather than cause a change in size.

I did a bit of Google searching and didn't manage to find any information about the terminfo database containing information on how to perform a resize (except some suggestion that terminfo might not support storage of this) so there's probably no choice but to hard-code it!

One option might be to provide a shell script which starts an xterm of the correct geometry and then runs dosbox in it, e.g.:

#!/bin/sh
xterm -geom 80x50 dosbox $*

I note that xterm isn't installed by default in Fedora, but it's easier to go and get it than to mess around trying different terminals 😀 That color issue still remains, though - it seems to me like dosbox is requesting black on black or something very close to that, so perhaps this is actually a bug in dosbox. If I have time I'll investigate further.

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window