4:39 p.m.
There is no reason these addons would not work in Eclipse via the Shell
Integation, but in the IDE itself, it does not make much sense to run these
commands from a dropdown menu or wizard.
On Tue, Jan 15, 2013 at 11:11 AM, Max Rydahl Andersen <
max.andersen(a)redhat.com> wrote:
for me ls, grep, dir, find, less and more seems pretty useful to have
the
IDE participate in...i.e. to make them comprehend eclipse workspace
hiearchy ?
But maybe is some other kind of context dependent functionality you refer
to ?
Why is there a need for this special knowledge of wether it is running in
bash/command prompt or in the IDE (in the ide, at least in eclipse current
form it will basically be running both at the same time won't it ?)
/max
> Good questions:
>
> 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)
>
> To be clear, I envision things like: "ls, grep, dir, find, less, more"
to be shell specific and likely not avaiable in the IDE.
>
> 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:
>
> public abstract UIShellCommand implements UICommand {
>
> }
>
> So it may be best to make an entirely new interface in a new addon:
>
> public interface UIShellCommand {
>
> }
>
>
> 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.
>
> 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.
>
> ~Lincoln
>
>
>
>
>
> On Mon, Jan 14, 2013 at 9:48 AM, "Ståle W. Pedersen" <
spederse(a)redhat.com> wrote:
> hi, i might have misunderstood somewhat how the ui* classes are designed
> to work, but as i can see now it there isnt any clean way to decide in
> which context the commands are executed/run.
>
> eg the only execution point atm is UICommand.execute(UIContext c)...
> with no way of differentiate if the command is run in a shell or ide.
>
> what if we could provide two methods to UIContext that returned a
> ShellContext and a IDEContext?
> that way we could provide useful object to the commands eg:
> - console input/output: aesh support stderr/out (simulating it since it
> saves it in a buffer and the flush it to the proper stream, but it works
> similar). that way it will also support pipelines/redirections.
> - standalone commands: eg commands that "take over" the input stream.
> examples in common shellprograms are: man/less/etc...
> - ++
>
> - or is this already covered by some other way i havent figure out of
> yet? :)
>
> ståle
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."