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

[Ivan Soleimanipour-4]

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.

[Wade Chandler]

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 <Ivan.Soleimanipour@...>
> To: nbui@...; Tomas Holy <Tomas.Holy@...>
> 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.

[Ivan Soleimanipour-4]

Wade Chandler wrote:
> 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.
>  

Thanks for trying to grok my complex question ...

Here's the crux of the question:
What would you expect to happen when you close the TC (or the tab within
the TC) hosting a shell?

a) you expect it to terminate the shell and go away w/o ability to
re-open the window.
b) you expect it to close the window which you can bring back up again
later.

If you expect (b) then we have a problem because the only way to bring
(accidentally
closed) io windows back up is via the progress bar. But that forces you to
see a progress bar for a shell which we seem to agree is undesirable.