|Re: [dsdp-dd-dev] DSF design question|
Vladimir Prus wrote:
This is implemented by GDBCLIProcess extending AbstractCLIProcess, which in turn extend java.lang.Process. There is also a separate module CLIEventProcessor (all in the org.eclipse.dd.mi.service.command package), which parses CLI commands and events and generates corresponding model events as needed.On Wednesday 18 June 2008 20:27:32 Pawel Piech wrote:Hmm.... The eclipse console is a view which uses the stdio channels of the process object provided by the debug model. The GDB CLI functionality: converting user-entered text into CLI commandsFor my education -- which methods are responsible for those conversion of user-entered text into CLI commands?
Of course where there's a will, there's a way :-) The current design of the CLI interface is based on the CDI-GDB debugger integration in the CDT project. It re-uses the standard Eclipse console view, which also used by Eclipse to show the standard IO of many things including builds etc. If it's important to someone to have a dedicated view for GDB CLI interaction, they could very well contribute such a view and not need to go through this somewhat awkward Process interface.and interpreting the output is done within the debug model. So this logic is not and cannot be aware of the currently selected UI context. If multiple console views are open (in multiple windows or not) they will be sharing the same IO channel and the same CLI session. So, if we want to have the active context in the CLI console synchronized with the active context in the window, we will need to write some agent at the UI level which monitors the window selection and emits the necessary thread and stack commands, into the console. To avoid consoles in multiple windows from clashing with each other, we would need to make sure that this agent is active only if the window is active. I agree all of this is pretty messy, but the multiple windows (and multiple-context debugging in general) really does complicate things.This sounds complicated. Is there no way, in the code that handles user-entered text in console to: 1. Figure which console view has generated that text 2. Figure, from that, which main window is that 3. When GDB response, change debugging context only in the window found in (2)
To answer your question though, to point 1, there is no way for the model object to know which window the command came from. There is a clean separation in DSF as in most Eclipse plugins between UI and non-UI components, and the AbstractCLIProcess doesn't even have access to the Window class in which the command was entered. So to deal with issues in the UI, a component needs to be created at the UI level, hence my proposed agent which would be tied to the console view.
Thank you, it was much appreciated.I think at this point, I agree that having GDB emit some kind of =thread-selected notifications in response to CLI commands is the best approach.OK. I've posted a description of how threads should work in MI to the gdb mailing list, eariler today.
Back to the top