This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Describe terminalemulator architecture by answering NetBeans Arch Questions as described at http://openide.netbeans.org/tutorial/api.html I suggest to place the answers to core/arch/arch-term.xml.
I will take this for now (unless you really want to Tim!).
Ivan - I tried to draw up a high-level architectural description of the termulator, based primarily on information given in your functional specification. (Which was nicely written and helpful BTW!) Will attach resulting HTML. If you have a moment, please double-check it for accuracy. If there is anything wrong, just let me know, or you can directly edit and commit core/arch/arch-core-term.xml in NB sources according to its DTD; it should be mostly self-explanatory.
Created attachment 8977 [details] Generated HTML, for convenience; to regenerate, type ant -f core/arch/build.xml term after editing core/arch/arch-core-term.xml
Simple answers - everything is No ;-) But please use <api> tag to describe the stability of the public api in term's package, so the bottom of the page more meaningful and not just "WARNING: No interfaces". Thanks and I guess the priority is lower now.
Done.
Reopening as a result of following questions and requirements: > > q: terminal emulator - what does it exactly do? > a: does the terminal emulation only, as a dumb terminal > NeedSpec > > q: > http://www.netbeans.org/unbranded-source/browse/~checkout~/core/libsrc/org/netbeans/lib/terminalemulator/func_spec.html must be copied to the case materials directory
Ivan says (paraphrasing): [What is its exact tty emulation compatibility - is Solaris dtterm the best match?] Two things ... it's configurable. We have "dumb" which I suppose we could claim is complete. We have "ansi" which is not %100 complete. We have "dtterm" which is some additional functionality on top of "ansi" and that is not complete either. It is only called dtterm because the various tools that were to run underneath it needed to see TERM set to dtterm. In retrospect that might end up being unneccessary. The termulator itself does not know anything about subprocesses and cannot possibly set a termcap.
committed * Up-To-Date 1.4 core/arch/arch-core-term.xml committed * Up-To-Date 1.34 core/libsrc/org/netbeans/lib/terminalemulator/Term.java committed * Up-To-Date 1.6 core/libsrc/org/netbeans/lib/terminalemulator/TermStream.java removed * Up-To-Date 1.1 core/libsrc/org/netbeans/lib/terminalemulator/func_spec.html removed * Up-To-Date 1.1 core/libsrc/org/netbeans/lib/terminalemulator/interpreter.html added * Up-To-Date 1.1 core/libsrc/org/netbeans/lib/terminalemulator/package.html removed * Up-To-Date 1.2 core/libsrc/org/netbeans/lib/terminalemulator/properties.html removed * Up-To-Date 1.1 core/libsrc/org/netbeans/lib/terminalemulator/proposal.3.html added * Up-To-Date 1.1 core/libsrc/org/netbeans/lib/terminalemulator/doc-files/func_spec.html added * Up-To-Date 1.1 core/libsrc/org/netbeans/lib/terminalemulator/doc-files/interpreter.html added * Up-To-Date 1.1 core/libsrc/org/netbeans/lib/terminalemulator/doc-files/properties.html committed * Up-To-Date 1.3 core/term/.cvsignore committed * Up-To-Date 1.5 core/term/build.xml committed * Up-To-Date 1.85 nbbuild/build.properties committed * Up-To-Date 1.7 nbbuild/javadoctools/template.xml committed * Up-To-Date 1.11 openide/arch/arch-openide-io.xml
moving terminal emulator issues to terminalemulator component. To see the correct version and target milestone of this issue look at Issue Activity table.