<div dir="ltr"><div><div><div><div><div><div><div>Good questions:<br><br>The whole idea behind the UI api is that the plugin developer should not know if they are in a GUI or Shell, so if we are going to support explicitly shell-specific features, then it is probably necessary to ensure that those commands are distinguishable (made explicitly incompatible with the IDE / generic UI API)<br>
<br></div><div>To be clear, I envision things like: "ls, grep, dir, find, less, more" to be shell specific and likely not avaiable in the IDE.<br></div><div><br></div>e.g, this would allow you to specialize the command for the Shell, but would still create a problem because the UICommand would be picked up by the IDE: <br>
<br></div><div style="margin-left:40px"><span style="font-family:courier new,monospace">public abstract UIShellCommand implements UICommand {<br><br>}<br></span></div><br></div>So it may be best to make an entirely new interface in a new addon:<br>
</div><div><br></div><div style="margin-left:40px"><span style="font-family:courier new,monospace">public interface UIShellCommand {<br><br>}</span></div><br><br></div>Which mirrors much of UICommand, but does not actually implement it. This UIShellCommand could support the things you need like, piping, and other such stream-based redirection.<br>
</div><div><br></div>This latter strategy would require, however, that the shell support both types of commands, so a common interface would indeed be useful here. Not the worst problem in the world, but none-the-less, we may want to think about how to best approach this problem.<br>
<br></div>~Lincoln<br><div><div><div><div><div><br><br><br><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Jan 14, 2013 at 9:48 AM, "Ståle W. Pedersen" <span dir="ltr"><<a href="mailto:spederse@redhat.com" target="_blank">spederse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
hi, i might have misunderstood somewhat how the ui* classes are designed<br>
to work, but as i can see now it there isnt any clean way to decide in<br>
which context the commands are executed/run.<br>
<br>
eg the only execution point atm is UICommand.execute(UIContext c)...<br>
with no way of differentiate if the command is run in a shell or ide.<br>
<br>
what if we could provide two methods to UIContext that returned a<br>
ShellContext and a IDEContext?<br>
that way we could provide useful object to the commands eg:<br>
- console input/output: aesh support stderr/out (simulating it since it<br>
saves it in a buffer and the flush it to the proper stream, but it works<br>
similar). that way it will also support pipelines/redirections.<br>
- standalone commands: eg commands that "take over" the input stream.<br>
examples in common shellprograms are: man/less/etc...<br>
- ++<br>
<br>
- or is this already covered by some other way i havent figure out of<br>
yet? :)<br>
<br>
ståle<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>"Simpler is better."
</div></div></div></div></div></div></div></div></div>