> On Apr 11, 2018, at 11:08 AM, Davide Italiano <dccitali...@gmail.com> wrote:
> Good day.
> While trying to implement a command in lldb I noticed lldb has this
> awesome `gui` command that opens an ncurses GUI.
> I find it really useful and I wanted to play with it a bit, but I
> wasn't really able to get it working.
> In particular, I tried to press enter on `target create` or `attach`
> but nothing happens.
> Greg, as you wrote the original implementation, can you please explain
> how this is supposed to work? Are you actively interested in
> maintaining this mode?

I really like this mode and would love to see some extra hands on this. I made 
this quite a while ago and it is definitely a work in progress with many things 
missing. I really want to work on it, but never had the time as there was 
always something else. 

So I would be really happy to see work done on this and I would like to 
contribute more to this. I am happy to change anything here as the code that is 
in there now was my first attempt at doing what I thought was right and I had 
no input from anyone else, so this is really a blank canvas we can do anything 

Basics things I tried to do were:
- One window at a time has the focus, and each window gets to make up its own 
key bindings. Not sure how good of an idea this is, but it is what I came up 
with. If you type "h" in any window, a dialog pops up and shows you the list of 
key bindings and what they do
- Arrow keys are used for navigation within the currently selected view. In the 
source view you can change the highlighted line and hit enter to run to that 
line, b to set a breakpoint etc. In the variables view, you can expand a 
variable with right arrow, unexpand it with left arrow and move up and down 
with the up and down arrows. In the process view you can expand the threads and 
stack frames.
- Menu items that require no options should just work now (step in/out/over, 
continue) and ones that do need arguments are incomplete and need work (like 
target create, attach, launch)

So things I would like to see changed:
- The "Threads" view should remove the top level process and just show all 
  - the current thread with stop reason should automatically be selected and 
expanded and have frame zero selected
  - might be nice to be able to expand a frame and see its variables in this 
view as this would allow us to see multiple variables for multiple frames and 
allow the user to hide the Variables view?
- Target->Create should pop up a dialog box and allow user to fill in 
everything for a target (file, triple (optional), platform (pop up list?), etc)
- Process->Launch should pop up a dialog box and allow user to fill in args, 
env vars, all launch options
- Process->Attqach should pop up a dialog box and allow user to fill in all 
attach options (pid, by name, wait for, stop on entry)
- Add a new console view that accepts LLDB commands. Editline doesn't have the 
callbacks that readline has that allows GDB to shared the terminal with the 
curses, so it is harder to have a command line in our GUI implementation. It 
would be great to have a console that can accept commands and drive the debug 
- Add a way to resize any window with some sort of CTRL+ARROW. CTRL+RIGHT would 
expand the width of the currently selected window by 1 column, CTRL+LEFT would 
shrink it. Same with CTRL+UP and CTRL+DOWN for the height of stacked views.

We might also want add a dedicated <Stack> view which will show the currently 
selected thread's frames here and have people select the thread from the 
"Thread" menu. Not sure if it is better to have all threads in a view that can 
each be expanded, or dedicated views there the threads list in a view on its 
own and as you select the thread, then the <Stack> view updates. Or both? All 
questions and open ended design decisions

So a resounded "yes!!!!" I want to see work done on this and think it is great. 
It definitely needs discussion so we can agree upon a great interface, but I 
think it is very close and has great potential!

Let me know your thoughts,

Greg Clayton

lldb-dev mailing list

Reply via email to