Closed g-arjones closed 6 years ago
Since the work is done, I don't have a problem with merging it, even if I do plan to remove it in fine.
Do go all the way, it will clean things up tremendously.
it will clean things up tremendously.
Do you want to keep "package selection" and/or the statusbar?
Do you want to keep "package selection" and/or the statusbar?
The underlying question I guess is, what would they be still useful for ?
Since the work is done, I don't have a problem with merging it, even if I do plan to remove it in fine.
Actually, not entirely true. I might want to reuse this.... I like the attach/launch dichotomy in the launch configurations.
The idea would be:
The underlying question I guess is, what would they be still useful for ?
Package selection just to avoid keep asking which package will be affected by a command. And the statusbar just to show which package is selected. Personally, I don't think it is worth it and my idea was to remove everything...
The idea would be:
I like that
Personally, I don't it is worth it and my idea was to remove everything...
Then follow your idea. I currently don't "see" what would be the effect, so let's follow your guts.
That is it.. Unit tests for the debugging configuration providers are missing (currently only the base class is unit tested).
I am currently using this for my orogen-related activities. Personally, I think it works much better than the current scheme that relies on rock-run and it also allows me to debug more than one component simultaneously. If you think this is acceptable, I can go all the way and remove all the alternative mechanisms (build, launch, package selection, statusbar) and you can rebase #38 and do your work on a (much) cleaner codebase.
This closes #10 and closes #14