[forge-dev] [forge2.0 ui classes]

[Max Rydahl Andersen]

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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev