[Lldb-commits] [PATCH] D104395: [LLDB][GUI] Add initial forms support

Fri Jun 18 14:20:32 PDT 2021

clayborg added a comment.

In D104395#2828065 <https://reviews.llvm.org/D104395#2828065>, @OmarEmaraDev wrote:

> @clayborg I tried implementing scrolling mechanisms as suggested. My first trial essentially defined a "visible area" rectangle which gets updated with every time the selection changes, then when it comes to drawing, each field checks if it is completely contained in the visible area and draws itself with an offset that we get from from the visible area origin. This worked, but fields that spans multiple columns can completely disappear leaving mostly no fields on the window, so it worked in most cases, but not all. My second trial was about drawing to an ncurses pad that is large enough to fit all contents, then the window is refreshed from that pad. This used manual ncurses calls because we don't support pads at the moment, so I scratched that for now. I think support for pads would be good for those kind of applications in the future. I plan to work on a proposal that would include support for pads and lightweight subwindows, I will detail that later.

Yeah, that is why I was suggesting that we use the list view for fields as it makes scrolling much easier as I really like your graphical approach that you have, it just means scrolling logic is much more complicated.

> I eventually opted to create "pages" for the forms. Basically, during form construction, if the number of fields is large and can't fit in the window, the user can call `NewPage()` to create a new page, all fields after that call gets added to the new page. As the user selects fields, the form can scroll to different pages. This is similar to the ncurses form scrolling functionality. Visual indicator for the current pages and the active page is added to the form if there is more than one page. I hope this solution is satisfactory.

That will work as long as you are wanting to implement all of the required features. I personally like to keep things simple, but I'm not against seeing a nicer solution.

It it were me I would probably make a ListDelegate that can manage a list of delegates where each field would be a delegate and each field would display on one or more line kind of like I detailed in ASCII art. This would make scrolling really easy to implement in an abtract ListDelegate kind of like how we did for the TreeDelegate. For example the "Path" for the executable would take up one line in the list window part of the form. A "Arguments" field for a Process launch dialog could take up one or more lines depending on how many entries the user typed. Same things for the environment variables field we will need. So think about all of the fields types we will need and think about how easy they all will be to implement as we add new things. The fields I can think of include:

- file path (for either a file or directory where constructor of the field specifies which one and also constructor would say if the path needs to exist (which would be true for an executable for a target, but not for a path substitution path)
  - target executable as a file that must exist
  - current working directory as a directory that must exist
  - script path to a file that must exist
- list field (for things like arguments or environment variables where the user specifies one or more items. Each item in the list could use a FieldDelegate so the list can be a list of anything)
  - arguments
  - environment variables
- string field (with optional validation on the string when it loses focus (This could be used to implement the "file path" above where the user types something and then hits tab to select another field, but we don't let the focus change because the path isn't valid or it is expecting a file and a path to a directory is in the field at the moement)
- pulldown to select something. If this was done on a single line, then we can pop up a menu from the menu bar to allow selection
- boolean value
- integer
  - for pid selection for attach dialog where we need to validate the process ID that the user enters is valid
  - for <port> value for a setting that uses sockets

So just think about all the ways we will want to use each of these items and make sure you are willing to support all that is needed to make these happen. If you prefer the more GUI like approach, it will be good for you to understand how much work or support this will involve as new things are added.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104395/new/

https://reviews.llvm.org/D104395