Re: I/O Window vs Progress (of long running processes)

I don't really see the correlation. I don't see I/O and Progress as being linked. They can be, but they are not meant to always be used in a tandem fashion.

I would think there may be some actions one runs from  the shell which show up as progress actions, but I would not expect a shell window itself to show up as a progress icon, and I'm failing to see how that is necessary as those APIs are completely separate things.

From the other view point. It is an IOProvider. So, it provides input and output. It seems to make a lot of sense for that area to be used for a shell.  

That said, just that general area, the bottom right where tasks, search results, and IO reside, is a good place for another TC to hold a shell of some kind. This can completely detach from the I/O and becomes its own TC in that general area which seems like a good place for a shell/command window as it resides under the editor and other things as is common in other environments and editors. 



Wade

 ==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor


http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org



----- Original Message ----
> From: Ivan Soleimanipour <[email protected]>
> To: [email protected]; Tomas Holy <[email protected]>
> Sent: Tuesday, April 14, 2009 5:26:25 PM
> Subject: [nbui] I/O Window vs Progress (of long running processes)
> 
> The current NB convention separates the closing of I/O windows from the 
> termination
> of the processes running under those I/O Windows.
> 
> For example, if you use the Progress UI and Cancel something, or use the Stop
> button in the I/O Window's action bar the process is terminated but the I/O
> window stays around and the user can see the last of the io and things
> like "exit satus is 0".
> Conversely one can Close an I/O window w/o impacting the underlying process.
> The I/O window can be re-opened, not throught the Window menu, but via the
> Progress UI.
> 
> However, as I've been working on my terminal project,
> http://wiki.netbeans.org/TerminalEmulator, I'm a bit hesitant to
> follow the above mode. For example, my project will allow the
> creation of a TC running a shell. This window may be in it's
> own "Terminal" window or in a generic Output Window (I haven't decided yet
> what would be best).
> 
> Now the purpose of the Progress UI is to track "jobs" like builds
> or vcs actions etc. These are long-lasting actions which the use
> presumably wants to track, hence the progress UI animation.
> But a shell doesn't quite fall into this category. A shell
> lasts longer than a build or a vcs action. In fact a "utility"
> shell is likely to hang around for the duration of an IDE session.
> 
> For such a thing having Progress UI animation seems an unneccessary
> distraction, as any animation is.
> 
> So, if one agrees that for a long lasting shell job a Progress item
> is undesirable the distinction between closing and termination becomes
> an issue. Looking at how shells within terminals are used on
> the regular desktop we see that a Close of the terminal will
> terminate the shell and vice-versa.
> This contradicts the current procatice of how the IO window is used.
> 
> OTOH, my project will allow the creation of "Command" windows
> where one can execute an arbitrary command like 'ls' or 'date'.
> For these it _does_ make sense to separate window closing from
> process termination based on the current NB convention.
> 
> Now, the latest I/O APs from Tomas Holy allow for the creation
> of alternative IOProviders and windows. It would make sense, for
> example, to have a TC _other_ than Output for shells. However,
> the I/O API doesn't allow for the conflation of closing and termination,
> which is the sensible thing to do for shells.
> 
> The question is then ... should we enhance the I/O API to allow for
> the conflationof close and terminate or should shells go into their
> own, specialized, not I/O API based TC's?
> 
> One way to answer this is to see if there are existing really-long-lasting
> actions in NB which are similar to shell as mentioned above for which
> the animation of the Progress UI is a distraction.