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.

Bug 56070 - Show partial lines and Copy input text to display in output window
Summary: Show partial lines and Copy input text to display in output window
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Output Window (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Milos Kleint
URL:
Keywords: UI
: 59809 69206 80649 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-03-07 15:57 UTC by Jesse Glick
Modified: 2008-12-23 14:33 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-03-07 15:57:18 UTC
See Alvin's comments to issue #47708. I am filing
them separately since they are really an
independent issue, and furthermore not under the
control of the Ant module (only the OW
implementation).

Suggested changes:

1. Display partial lines (those without any
newline having come in), perhaps if no further
output to the line has come within a second or so
of printing, since they are used often for input
prompts.

2. Whenever a line of input is sent from the OW
input textfield, print it in the text area so you
can review the complete session. Would be best to
display the input in a separate color to keep it
clearly distinct from the output (and error) streams.
Comment 1 Milos Kleint 2005-03-10 11:23:17 UTC
well, this seems to involve quite comple coding as the output2 module now seems
to either ignore all other calls than println() or convert them to println(). so
writing a simple character doens't work, it's burried deep down in the
implementation of Storage, Outwriter and Lines, so I would prefer not to do the
changes for 4.1.
Comment 2 athompson 2005-03-10 12:42:42 UTC
in that case, you can probably assume that any text sent to stdout without a
newline before an input is the input prompt. how about using that text as the
label for the GUI input field so people know which input is which? then, you can
easily copy the prompt + input + newline to the output buffer once you get the
input. looks reasonable and the (eventual) output looks as it should.
Comment 3 rcking75 2005-06-27 16:50:55 UTC
*** Issue 59809 has been marked as a duplicate of this issue. ***
Comment 4 rcking75 2005-06-27 17:03:09 UTC
Has there been any progress made reagarding this issue.  I see athompson 
posted a suggestion, but I don't see a reply.  Are you considering his 
suggestion or are you working on an alternative solution?  I think his 
suggestion would satisfy my issue #59809 which I have marked as a duplicate of 
this issue.
Comment 5 athompson 2005-06-27 17:35:26 UTC
IMHO this really should be addressed for 4.2 as it is a major weak point
compared to other IDE's.

<useless-commentary>
since a lot of work has been done on the Netbeans UI/useability front, and since
Sun has been bundling Netbeans with the JDK, and since Sun has been lobbying for
Netbeans adoption at universities, it seems the major thrust at Sun has been to
get new Java programmers started using Netbeans in the hope that will 'stick'. i
imagine most new programmers still start off writing console applications. since
Netbeans is currently incapable of supporting console apps, it seems they are
undercutting their own objectives.
</useless-commentary>

a 'terminal'-like solution would be best but the alternative i suggested
previously will do.
Comment 6 Milos Kleint 2005-06-28 08:05:28 UTC
this is actually being worked on.
what i've done so far, is to allow processing of print() calls (not sure if it
will get through ant though).
the problem is that I have no chance to figure out if a read will be requested
from input. but that's more or less just a performance issue.
the copying of input to output should be fairly easy.

actually netbeans had (still has) a terminal like implementation of output
window, but it was abandoned (I don't know the reasons, probably performance).
Comment 7 Milos Kleint 2005-06-28 08:31:16 UTC
issue #56341 is closely related. jesse claims that running through ant will
always behave the current way, no matter what is done in OW. will investigate
more. the copying of input can be done of course.
Comment 8 Milos Kleint 2005-06-28 12:04:04 UTC
number 2. is done, input is copied to output, no color differenciation for now.
could be an enhancement though.
number 1. doens't work for ant output ;(
Comment 9 Jesse Glick 2005-06-28 17:32:00 UTC
I know, Ant needs to be patched to transmit partial lines, so it's not going to
happen before Ant 1.7. Milos can you file it separately? For now just make sure
that the Output Window itself can deal sensibly with partial text line output,
using some non-Ant-based test module or unit test or whatever.
Comment 10 athompson 2005-06-28 17:41:26 UTC
IMHO my second comment (comment 2) is a reasonable interim solution. i think 99
times out of 100 any partial line is an input prompt and can be treated as such.
that way you wouldn't need any ant patch or test case until a terminal-like
solution is implemented. why make things harder than they need to be?
Comment 11 Milos Kleint 2005-06-29 06:47:14 UTC
sorry, athompson. When running you app in netbeans, it's done through ant. And
ant will wait till the line is finished before sending out. At least I didn't
get the partial lines in the output window code from ant.
Comment 12 athompson 2005-06-29 18:27:08 UTC
oh, i understand now. so there's no way of knowing what's on that partial line
until it's actually sent. you're right, of course.
Comment 13 nshrine 2005-10-18 11:39:18 UTC
I notice this doesn't seem to be fixed in 5.0 beta.

It's a real show stoppper for us for our first-year Java workshop here at the
Univeristy of Birmingham, see comments from teacher:

"However, the main issue remains that most code they will see in your
bog-standard Java example on the internet or in books uses std in/out in a
certain way which makes assumptions which are not true in netbeans 4.1.

Ideally we'd like an IDE that did behave in a more usual way, but
obviously changing IDE is a big thing and we certainly don't plan on
doing it half way through the semester. We currently plan to look at IDE
choice again at the end of this year and change if necessary/practical"

So basically, unless this is fixed I can see that we will be switching to
Eclipse next year as that does console I/O properly.
Comment 14 garganti 2005-10-19 13:57:15 UTC
I teach Java to first year undergraduate student. I would like a real console,
where they can see the std output and enter the std input. In netbeans I get a
panel for the ouput and a dialog for the input. This confuses the students. For
this reason I have to use eclipse in lab and suggest the use at home of eclipse
(even if I use (andlike very much) netbeans). (I have already voted this issue)
Comment 15 Milos Kleint 2005-11-22 09:25:59 UTC
Summary: the issue is actually fixed/implemented on the side of output window,
partial lines get printed and input gets copied to output.

the remaining problem is in ant, which we use to run user programs.

This issue should be probably closed.
Comment 16 nshrine 2005-11-22 10:36:44 UTC
I just tried beta 2 and lines printed with print() as opposed to println() don't
get printed in the output window until after a line has been read from standard
input. So when we write code to prompt for input such as:

System.out.print("Prompt: ");
String line = in.readLine();
System.out.println("Line was: " + line);

you get:

hello
Prompt: Line was: hello

instead of:

Prompt: hello
Line was: hello

The Netbeans people can keep washing their hands of this issue and saying it is
an Ant problem but all the time people will be switching to Eclipse, including us.
Comment 17 Milos Kleint 2005-11-22 12:02:57 UTC
it's not about washing hands.
the problem with System.out.print() calls in user programs had 2 levels.
1. print() was not implemented in the Output Window component, that's now fixed. 
2. running the program through ant didn't do print() either. that's now filed as
#56341

So only number one is the actual core/output issue, not much more can be done
here. Having 2 issues tracking the same problem is not very efficient.
Comment 18 Milos Kleint 2005-11-24 08:29:46 UTC
*** Issue 69206 has been marked as a duplicate of this issue. ***
Comment 19 toddlongfellow 2005-11-25 00:25:10 UTC
The thing I find interesting about this particular problem is that it has gone
on for some time now. I just tried the Netbeans 3.6 version that comes on a cd
in the back of my Deitel & Deitel 6th ed. Java text and the same problem exists,
and as someone here has already mentioned, it does not work in version 5 betas.

Yes, it may be an ant problem, but I am surprised that with pressure from the
Netbeans org that the people at ant have not fixed the problem.

I wish to add my voice to the others here that have said that they would like an
actual terminal window for running console applications. Please give that idea
some serious thought.

Thank you.
Todd Longfellow
Payson AZ
Comment 20 dguardalabene 2005-12-06 00:35:25 UTC
It seems to me that they are not trying to fix this issue, even though several 
universities (mine included) use NetBeans.  It is incredibly annoying 
especially when someone else is testing your program.  That other person could 
get easily confused if you have multiple inputs.
Comment 21 Marian Mirilovic 2006-01-03 10:53:58 UTC
Too late for NB5.0, please reevaluate.
Comment 22 Milos Kleint 2006-07-10 15:05:17 UTC
Update:
there was another issue in the output window implementation, that I just fixed.
Output window is ready for partial lines output. The ball is now on the ant
integration side. (issue #56341)
For the Netbeans Bluej edition I've created a special ant task that workarounds
the ant issue (for details, see #56341) however because it's based on 5.0
release it doesn't get this latest bugfix. However the basic scenario of
System.out.print("enter name:");
System.in.readLine();
does work there..

closing as fixed.
Comment 23 Milos Kleint 2006-07-20 11:11:11 UTC
*** Issue 80649 has been marked as a duplicate of this issue. ***
Comment 24 Quality Engineering 2008-12-23 14:33:58 UTC
This issue had *4 votes* before move to platform component