Opened 6 years ago

Closed 6 years ago

#9758 closed enhancement (fixed)

Debugger: Add optional command line output capture

Reported by: stippi Owned by: anevilyak
Priority: low Milestone: Unscheduled
Component: Applications/Debugger Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This is really low on the list of needed features, I mainly wanted to record the idea.

Debugger could detect whether or not the user sees the command line output of the debugged team (assuming that's possible somehow). If the user would not otherwise see it, there could be another view for the debugged team's stdout and stderr streams. I would place that in another tab with the variables/registers group. Just because Eclipse puts it there by default. Along the bottom would be another option.

Attachments (2)

console.png (85.9 KB) - added by anevilyak 6 years ago.
console_v2.png (82.4 KB) - added by anevilyak 6 years ago.
Updated layout as suggested by stippi

Download all attachments as: .zip

Change History (17)

comment:1 Changed 6 years ago by anevilyak

Status: newin-progress
Version: R1/alpha4.1R1/Development

comment:2 Changed 6 years ago by anevilyak

I'm leaning towards along the bottom myself (as a split, so collapsible), so it can be viewed concurrently with everything else. The question that remains is if it'd be preferred to have the output of the streams separated or unified, as they'd typically be the latter on the actual Terminal itself. Thoughts?

comment:3 Changed 6 years ago by bonefish

Since you ask: The streams should be unified with the option to toggle either (well, could be tri-state). Using different colors (e.g. black for stdout, red for stderr) would be nice, too.

comment:4 Changed 6 years ago by anevilyak

Attached a screenshot of the UI as initially implemented for feedback. Let me know what you think.

Changed 6 years ago by anevilyak

Attachment: console.png added

comment:5 Changed 6 years ago by bonefish

Looks nice. There's some extra spacing around the view though.

comment:6 Changed 6 years ago by korli

I'd use blue for stdout :) Do you define somewhere the tabulation size? Also a scroll lock could be useful.

comment:7 Changed 6 years ago by stippi

Looks nice. I would place the check-marks and the button to the right of the output. Scroll-lock should work automatically, I think: If the output is already scrolled to the bottom, then it should automatically follow, if it's scrolled up, it should lock on to that view portion. But I would vote to keep stdout black. :-)

comment:8 Changed 6 years ago by stippi

You can probably also remove the "Show " portion of the check-mark labels, so it's even less waste of width if you move the controls to the right.

comment:9 in reply to:  5 ; Changed 6 years ago by anevilyak

Replying to bonefish:

Looks nice. There's some extra spacing around the view though.

That should just be a matter of insets, will deal with that.

Replying to korli:

I'd use blue for stdout :) Do you define somewhere the tabulation size? Also a scroll lock could be useful.

The color seems to be a topic of some contention :-) As far as tabulation/scroll lock goes, that view is currently just a BTextView, so it follows the behavior of the latter in that sense.

Replying to stippi:

Looks nice. I would place the check-marks and the button to the right of the output. [...] You can probably also remove the "Show " portion of the check-mark labels, so it's even less waste of width if you move the controls to the right.

Will try that and see how it looks, I'd actually put them across the top in order to try to make more real estate available for the textview itself.

comment:10 in reply to:  9 ; Changed 6 years ago by stippi

Replying to anevilyak:

Replying to stippi:

Looks nice. I would place the check-marks and the button to the right of the output.

I'd actually put them across the top in order to try to make more real estate available for the textview itself.

But isn't it more annoying to be able to read fewer lines? As it is, the lines in your screen shot already appear to be wide enough.

Last edited 6 years ago by stippi (previous) (diff)

comment:11 in reply to:  10 Changed 6 years ago by anevilyak

Replying to stippi:

But isn't it more annoying to be able to read fewer lines? As it is, the lines in your screen shot already appear to be wide enough.

Indeed, my initial thought was just that the amount of vertical real estate it takes to pack them into a single row is less than the number of horizontal pixels they'd absorb by putting them on the side, but I guess in this case the vertical is more valuable. As I said, I'll give it a try along with the inset adjustments and see how it looks, shortening the checkbox names helps already.

comment:12 Changed 6 years ago by bonefish

If horizontal space is a concern, icon buttons could be used. E.g. ones depicting ">" and "2>" for stdout respectively stderr and something recognizable for the "Clear" button (IIRC in eclipse a broom is used).

Changed 6 years ago by anevilyak

Attachment: console_v2.png added

Updated layout as suggested by stippi

comment:13 Changed 6 years ago by anevilyak

Attached an updated version taking into account feedback/suggestions.

comment:14 Changed 6 years ago by anevilyak

Implemented in hrev45797. Leaving ticket open pending feedback on the adjusted UI. Personally, I like the new layout better.

comment:15 Changed 6 years ago by anevilyak

Resolution: fixed
Status: in-progressclosed
Note: See TracTickets for help on using tickets.