White terminal background

[stefanct]

Not everybody uses terminals with black backgrounds/dark themes. While gdb-dashboard can't support every possible color scheme out of the box it would be nice to have at least something for people using the quite commonly used black font on white background.

As far as I can tell (after looking at the code for about 60 seconds) I think the colors are set in the R class as ANSI color numbers. Since most of that class deals with styling properties I presume that creating another instance of that class and replacing the references to the R class in the remaining code with references to either an instance with the existing values or a user-provided (or supplied) white-background instance would be a viable way to implement customizations like this(?)

[cyrus-and]

IMHO it's way more common for people to use terminals with dark background, for this reason the defaults reflect that.

But of course you customize the colors (and pretty much everything else...). Please take a look at this wiki page.

[stefanct]

Sure, I was not proposing to change the default but making it easier for those who don't use a dark theme. I don't know of any scientific surveys but quickly found this poll with over 2500 participants where a significant number of people (>10%) stated that they are using a light background. It might be a minority in relative terms but enough people to warrant an easy option for them IMHO: suppose that the 10% of the poll are also true for the 6k people that starred this project on github then about 600 people would have to fiddle with the colors to get it to work properly in their setups.

If I understand you correctly you would rather not change the code. Would adding a gdbinit script to the repo that sets up custom colors be more to your liking?

[cyrus-and]

I could add a section to the wiki with something like "themes" so that people con contribute. Unfortunately though, I use the wiki to host assets too, so I will not allow public modifications; still people can interact via issues.

If you come up with a configuration script for white background terminal I'd be happy to add it to the wiki and crediting you as the author (if you want).

Alternatively you/others can host their theme in a Gist or a separate repo and I can simply add a link to it. In this way authors would be able to maintain their code autonomously, which is better.

What do you think?

[stefanct]

I think an entry in the wiki with the themes directly would be completely fine for now. If there are really lots of submissions you can re-evaluate later. :)

Here is what I was able to come up with so far (no need to credit me but you can if you like):

dashboard -style divider_fill_style_primary '94' # divider (bar): light blue
dashboard -style divider_fill_style_secondary '1;30'
dashboard -style divider_label_style_on_primary '94;1' # divider labels: light blue, bold
dashboard -style divider_label_style_on_secondary '1;37'
dashboard -style divider_label_style_off_primary '33' # unused divider labels: orange (unchanged)
dashboard -style divider_label_style_off_secondary '1;30'
#dashboard -style style_selected_1 ';7' # current/changed values: bold
dashboard -style style_selected_1 ';7' # current/changed values: reversed
dashboard -style style_selected_2 '90;7' # surrounding items: grey, reversed
dashboard -style style_low '0' # register names etc.: black
dashboard -style style_high '34' # variable identifiers: blue
dashboard -style style_error '31' # error messages
dashboard -style style_critical '97;41' # breakpoints, ellipses: white on red

dashboard -style syntax_highlighting "xcode"

The use of reversed colors for style_selected_1 is a bit brutal because it is used in so many places... that's why the bold alternative is in there.
I was not really able to figure out what all the *_secondary styles represent but I noticed something that seems a bit dubious: the ellipses in the variables pane are styled with style_critical (line 309). It is important to not overlook truncated values - sure - but that seems a bit excessive. Is this really intended or a bug?

Another thing that might warrant another bug report/feature request: it would be great if panes could have a constant/minimum height. The flickering due to #59 is already very annoying but there is at least a workaround by using multiple terminals (I'd very much would like to avoid that but it's another story). For example the source pane is shrunk to a single line when an error message is printed (which is rather common in most of my use cases but just an example anyway). I'd rather see lots of empty space than jumping panes.

[stefanct]

Ah, and one other thing: I often use remote debugging. This usually works by having some kind of proxy (gdb server) running near the target and transferring control and status information via a serial protocol (often tunneled through TCP).

This has the disadvantage that there is quite some delay between entering a command and getting all the required data back from the device (especially if lots of stuff is read from the device as with gdb-dashboard). This causes perceived screen update times in excess of one second (if lots of code is executed in single-step mode it could be much longer). It would be great if the screen is only updated after all data is received and the old screen is preserved (maybe with an activity/busy marker). Is anything like that remotely possible? :)

[cyrus-and]

Thank you, let me think the best way to integrate this in the wiki. If (as I suspect) this will be the one and the only submission then the whole theme thing could not be ideal.

The use of reversed colors for style_selected_1 is a bit brutal

It is! :)

I was not really able to figure out what all the *_secondary styles represent

It is probably something that used to have sense but it is unused now. I need to clean up that part.

Another thing that might warrant another bug report/feature request: it would be great if panes could have a constant/minimum height.

I see your point, but there is no ultimate solution. Making some modules always fixed in height could be an option. But while it would work fine for Source and Assembly modules it wouldn't for, say, Stack and Threads. So instead of implementing something half good I'd rather wait to have a better idea...

It would be great if the screen is only updated after all data is received and the old screen is preserved (maybe with an activity/busy marker). Is anything like that remotely possible? :)

It would be great indeed! But AFAIK it's simply impossible. The reason is that when the program is stopped and one step (s) is issued I need to clear the screen immediately because GDB would print some status information (e.g., the current PC location) and possibly the program output.

Displaying the dashboard in a separate terminal does not have this problem though; why it's not an option for you?

[cyrus-and]

It is important to not overlook truncated values - sure - but that seems a bit excessive. Is this really intended or a bug?

Yeah, I tried to reuse the most appropriate style without introducing something new. It's a (maybe) temporary decision, I wanted to wait for the things to settle (new modules, new features...).

[stefanct]

The use of reversed colors for style_selected_1 is a bit brutal

It is! :)

In general the reversing is very effective to highlight important values. watch for example has a -d option that uses this to "highlight the differences between successive updates".
If the dashboard would provide a distinct style to indicate a few such elements it would be great also in other "themes".
For example, updates to the current line number happen way too often to be important enough for that - register or variable values on the other hand...

I was not really able to figure out what all the *_secondary styles represent

It is probably something that used to have sense but it is unused now. I need to clean up that part.

Oh, OK. Documenting this like I had to do in my comments to make sense of it, would probably be a good idea (e.g., on the style customization page). That sometimes leads to new insights on how to refine the actual code too.

Another thing that might warrant another bug report/feature request: it would be great if panes could have a constant/minimum height.

I see your point, but there is no ultimate solution. Making some modules always fixed in height could be an option. But while it would work fine for Source and Assembly modules it wouldn't for, say, Stack and Threads. So instead of implementing something half good I'd rather wait to have a better idea...

For the stack it would be possible to only show the last n levels of the trace (and this would actually be favorable to seeing the whole trace IMHO). I don't see threads as a big deal here either... the number of threads in debugging shouldnt vary that much that one could not specify the maximum number for the height beforehand. And that's only an issue if the threads pane is used at all. So IMHO there is clearly a direct benefit in implementing it right away even if it does not solve all the problems of jumpiness.

It would be great if the screen is only updated after all data is received and the old screen is preserved (maybe with an activity/busy marker). Is anything like that remotely possible? :)

It would be great indeed! But AFAIK it's simply impossible. The reason is that when the program is stopped and one step (s) is issued I need to clear the screen immediately because GDB would print some status information (e.g., the current PC location) and possibly the program output.

I have played only a bit with the logging commands of gdb to get rid of its output. That didn't work out but maybe there is already a way to redirect the output of the status information to e.g. a pipe and parse it later (I presume this is needed, else just discarding it with redirecting it to /dev/null would suffice). If that's not the case maybe we should propose such a possibility to GDB upstream? This might also be an option for other problems you encountered. Have you made contact to them?

Displaying the dashboard in a separate terminal does not have this problem though; why it's not an option for you?

The beauty of dashboard is that it integrates so elegantly into all installed GDB instances (I regularly use various GDBs for at least 3 different CPU architectures/cross-GCCs). Often they are started as part of makefile goals. Fiddling with shell aliases or launch scripts to easily start the right gdb with the correct options with this multi-terminal setup ruins this experience. Also, having a single window is by itself a big usability advantage (we all have way too many terminals open already, don't we? :D)

But for now it might suffice... I will look into it further.

PS: On Friday when I was playing around with the logging and dashboard's -output option I also came up with a code fragment to derive the PTS for the current instance. Maybe this is useful to anybody so I just leave it here:

python import subprocess
python gdb.execute("set $tty=\"/dev/" + subprocess.check_output("ps -p $$ -o tty=", shell=True).decode("utf-8").strip() + "\"")

[cyrus-and]

For the time being I simply added a wiki page about a better theme for white background terminals. I've changed a couple of things about your proposed theme to be more similar to the original in spirit and I tried to use only basic ANSI colors. I expect to add a few more themes myself so to justify a proper "theme page" in the future, in that case, I'd love you to host your polished original theme somewhere so I can link back to it and so you can keep it updated as you please.

Thanks for all the suggestions.

It is probably something that used to have sense but it is unused now. I need to clean up that part.

I was wrong, it's used in the Memory module for example to separate the watched memory areas.

So IMHO there is clearly a direct benefit in implementing it right away even if it does not solve all the problems of jumpiness.

I need to thoroughly think about this, thanks for the hints.

I have played only a bit with the logging commands of gdb to get rid of its output.

I remember I've tried too and without luck. The logging feature sends all the output, including the dashboard to the log file (I guess it simply redirects stdout and stderr there). Maybe I can implement some hackish solution to force this to not happen, but I would rather not as it would probably be OS-specific. I'll try to fiddle around with this for mere curiosity though...

Have you made contact to them?

Quite frankly, I've lost my faith n the GDB dev team, see the implementation of fetch_breakpoints for example, it's a mess due to this.

[stefanct]

For the time being I simply added a wiki page about a better theme for white background terminals. I've changed a couple of things about your proposed theme to be more similar to the original in spirit and I tried to use only basic ANSI colors. I expect to add a few more themes myself so to justify a proper "theme page" in the future, in that case, I'd love you to host your polished original theme somewhere so I can link back to it and so you can keep it updated as you please.

Thanks you!
I'd rather see the actual theme added to the repo as file and contribute to it via pull requests than having a completely distinct process that relies on multiple repositories or gists.
BTW the wiki pages start becoming confusing due to the mere number of FAQ-like page names.

So IMHO there is clearly a direct benefit in implementing it right away even if it does not solve all the problems of jumpiness.

I need to thoroughly think about this, thanks for the hints.

I have played only a bit with the logging commands of gdb to get rid of its output.

I remember I've tried too and without luck. The logging feature sends all the output, including the dashboard to the log file (I guess it simply redirects stdout and stderr there). Maybe I can implement some hackish solution to force this to not happen, but I would rather not as it would probably be OS-specific. I'll try to fiddle around with this for mere curiosity though...

In the meantime I was implementing a workaround to use gdb-dashboard in my actual work flow. It creates and places a slave terminal window automatically when launching gdb and attaches the dashboard's -output to the new pty. I'll explain that in more detail in this new issue: #178

Have you made contact to them?

Quite frankly, I've lost my faith n the GDB dev team, see the implementation of fetch_breakpoints for example, it's a mess due to this.

Hm, funny. Github destroyed the link to the gdb bug you sent originally: https://sourceware.org/bugzilla/show_bug.cgi?id=18385
To me this superficially looks rather like there are simply not enough gdb-python contributors and thus one could get involved there and change quite a few things to the better. ;)