Project Managment 0.1

[emoon]

Things that should be part of this is.

Setup a project that stores things like:

• Which backend that is active.
• Settings for the backend (executable used)
• All views needs to be able to store/load state

[emoon]

It's also worth remember what the user wants to do. The way I see it is to start to debug an executable should be very easy. You shouldn't need a "project per se."

I would guess what a user would do is to:

1. Find a way to select debugging the executable that you want to do
2. In File -> Debug Executable is expected to be there. As ProDBG i general it doesn't actually "know" which backend to be used here. So I would guess the best thing here is to have that in a config and say "Default backend on Mac: LLDB, Windows: ..., etc"

It should now be easy to find the file to set breakpoints in which is usually what you want to do unless you just looking for a crash.

I think populating a "Workspace view" with files found with the debug symbols would be good here.

Also should we default to "stop at main" when starting an executable? Or should this be optional and in that case how would user select it? Different alternative when starting the executable perhaps? Then in that case it's possible one can do

1. File -> Debug Executable.. (stop at main)
2. Debugger stops at main, populates Workspace view with files
3. User select file, adds breakpoint
4. Starts running

Also ProDBG allows debugging other targets (Amiga, C64, etc) How should these be selected? Should we have a selection for each backend in File -> Debug -> "Amiga UAE", "VICE C64", etc ?

Should plugins be responisbel to show UI for settings? Or is it ok with a setting file here. Highly dependent on each backend.

[Patuti]

Would a custom file dialog be somewhat desirable? This way, there would be a single File -> Debug Executable and the stop at main, backend or any other (maybe plugin specific) settings would be exposed at the custom file dialog.

[emoon]

A custom file dialog would work yes but would also require platform specific implementation which is a bit annoying (On Mac, Windows and Linux) as it uses native file dialogs.

I'm thinking that perhaps another dialog could popup afterwards but the question is if each plugin backend should then implement a UI for this? Maybe or should it only be based on settings? I think it might be the case that each backend needs to present this info so user can select it.

Also maybe it would be possible to set (if you need to pick emulator path for example) that "these settings should be default" so next time they will be filled in correct.

[Patuti]

I believe I would be happy with the following behavior:

• First time I chose to debug an executable with path X - an UI pops up with a minimum/essential set of backend settings + general settings (if any?), those settings would not be asked again if I try to debug the same executable (uniqueness by path) even if ProDBG is closed/opened again.
• Second time I chose to debug the executable with path X - no UI shown as the settings would come from the settings_per_executable_with_path_X.
• Create new Project X - tweak backend and general settings, save under Project X settings.
• Debugging an executable within Project X - no UI shown as the settings would come from the project settings.

Hope that will make any sense =)

[emoon]

Makes sense. Thanks!

[emoon]

Some ideas here https://www.youtube.com/watch?v=GfGNPo9Z6mA

[Jake-Shadle]

In regards to that Handmade video, today I got really annoyed with one of the things he pointed out, which is that you can't switch between "configs" quickly in VS, which is really annoying. Simply being able to specify an exe path and cmd line args and then quickly being able to switch between them would be amazing. And it's so simple.