[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-tm-dev] RE: [dsdp-dd-dev] Console requirements?
|
Hi Aaron,
I came to the consoles from the Target Manager side of our commercial
product where we launch a few external applications with different
requirements to the console. As Doug Gaff wrote, we currently have a few
different implemenations for the different console types like Terminal
or Debugger Command Prompt which we want to unify. From that background
I investigate the console framework (originally the one of Eclipse
3.0.x) and wrote a framework on top of the Eclipse console framework to
handle basic process output. Input had been missing because the 3.0.x
console framework could not handle it. With Eclipse 3.1 out, I
reinvestigate what I would have to do to make it work again with Eclipse
3.1 and came to the point to say that the existing ProcessConsole of the
debug.ui plugin is doing probably around 90% of what we had for Eclipse
3.0.x but the ProcessConsole has two heavy drawbacks:
- The implementation is internal
(org.eclipse.debug.internal.ui.views.console.ProcessConsole) and
- The implementation is tight to much to the debug model by using
IProcess and ILaunchConfiguration.
Because as the Eclipse platform, we had no bandwidth at this time too to
address the issue directly, we could only file an bugzilla entry to
track the desire for opening within this area.
My original ideas/"design" visioned an multi step approach:
- Factor out a org.eclipse.ui.console.ProcessConsole based on the
IOConsole
* make it simple to construct the console for a given
java.lang.Process or to simply associate such object
* stream connectivity to the process should be handled from the
ProcessConsole directly
- Based on the org.eclipse.ui.console.ProcessConsole, there should be
still exist the
org.eclipse.debug.internal.ui.views.console.ProcessConsole to avoid
breaking anything within the platform
- Once the org.eclipse.ui.console.ProcessConsole refactoring is done,
investigate refactoring and extending of the
org.eclipse.debug.ui.console.IConsoleColorProvider for achieving are
second very basic requirement of easy and simply custom output colouring
and custom fonts.
Given the requirement that we should not limit us to a process only, the
IStreamProxy concept of the existing ProcessConsole seems worth
investigation and extension. The IStreamProxy can decouple the console
from the source of the three streams and should allow to connect a
console basically to any backend.
Kevin may correct me if I have misinterpreted or tried to misuse any of
the original implementation and interface classes and/or additional
comments from his experiences with the console framework.
The desire to have pluggable actions/commands, as expressed from the
discussion here, had not been part of our investigations so far.
Hope it does answer a few of your points from the email below :).
Best regards, Uwe
--
Uwe Stieber
Senior Software Engineer
Engineering - Wind River Gmbh - Austria
office: +43 662 457915 0
> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> Sent: Montag, 10. April 2006 19:00
> To: Device Debugging developer discussions; Target Management
> developer discussions
> Subject: RE: [dsdp-dd-dev] Console requirements?
>
> Ewe,
>
> We just finished talking about it a little bit on the TM
> phone call. To
> summarize:
>
> >From the comments on these feature requests/bug reports, it
> appears that
> Darin and others would be open to having us submit whatever changes we
> need to the platform (as stated, they don't have the bandwidth to do
> more at the moment) As such, it sounds like we ought to
> figure out our
> requirements, and then after a bit of design and review,
> copy-and-paste
> what we need to live somewhere in the DSDP sources for now, and then
> submit whatever makes sense back (at least any framework changes). It
> sounds like the pluggable terminal emulations should be used by the
> existing RSE "shell" component as well as the process console.
>
> I must disclose that I have not yet studied the current console
> architecture. It sounds as though you have. I am presuming that you
> are the one that wrote Wind's current telnet implementation which both
> Doug and Martin have talked about being a possible contribution. How
> do you think we should go about discussing the refactoring
> that needs to
> happen in the framework as well as the design we want to have for this
> stuff moving forward? You mentioned a few items below. I
> have no idea
> what the process should be as far as the platform changes
> goes. Perhaps
> if the changes to simply enable what we want are not too radical they
> can be done before 3.2 is complete if we do the implementation and
> submit it? (no idea if that is a ridiculous expectation or not)
>
> regards,
> Aaron
>
> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Stieber, Uwe
> Sent: Saturday, April 08, 2006 3:11 AM
> To: Device Debugging developer discussions; Target Management
> developer
> discussions
> Subject: RE: [dsdp-dd-dev] Console requirements?
>
> Hi Aaron,
> you may want to refer to the bugzilla entries
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36669 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=111186. They both deal
> with Consoles and need to take into account if modifying the platform
> console service.
>
> Basically an improved console should allow easy "connectivity" to
> whatever. First hand, we look mainly for getting the
> currently existing
> implementation of the ProcessConsole splitted into an public
> ProcessConsole (not tight together with launch configurations) and
> possible still internal DebugProcessConsole (tight together
> with launch
> configurations as the current implementation is, no change to current
> users/clients). This is basically similar to what you pointed out in
> your second point besides the console infrastructure should not be
> limited to debuggee processes only.
>
> Additional, the consoles should have an contributable font and colour
> provider which allows to change fonts/colours for matching
> parts of the
> document. The current implementation of the platform console
> infrastructure requires to replace the whole
> IDocument/IDocumentPartitioner implementation of the console
> which is an
> overkill for the basic requirement to get all three streams
> of a process
> very easely connected to an console and to have influence on the
> presentation by in example simple regex matcher.
>
> Best regards,
>
> --
> Uwe Stieber
> Senior Software Engineer
> Engineering - Wind River Gmbh - Austria
>
>
> > -----Original Message-----
> > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> > Sent: Friday, April 07, 2006 5:54 PM
> > To: Device Debugging developer discussions; Target Management
> > developer discussions
> > Subject: [dsdp-dd-dev] Console requirements?
> >
> > Hello All,
> >
> > I wanted to kick off a thread to solicit some requirements/thoughts
> > for consoles in the brave new DSDP world. I will throw a
> few out that
>
> > I can
> > see:
> >
> > -Pluggable/Selectable terminal emulations (plain text, vt-100,
> > vt-220,...). We ought to have stock ones like those mentioned, but
> > there should be an extension point so others can contribute
> something
> > completely specific if they want.
> >
> > -Pluggable connectivity to the other side. The simple use
> case is a
> > replacement/augmentation of the existing Eclipse console, one that
> > does stdio with the debugged process. I think that we will want to
> > reuse the same component elsewhere though, e.g. a terminal
> opened on a
>
> > socket from the RSE or something.
> >
> > I don't know what exactly we will do with this little
> sub-project. It
>
> > seems to me that it should probably be pushed into the platform (at
> > least the framework changes for
> > consoles) and then perhaps we have specific terminal
> emulations that
> > exist in DSDP?
> >
> > cheers,
> > Aaron
> >
> > --
> > Aaron Spear
> > Debug Tools Architect/Staff Engineer
> > Mentor Graphics
> >
> >
> >
> > _______________________________________________
> > dsdp-dd-dev mailing list
> > dsdp-dd-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> >
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>
