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

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&gt; 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

> 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. hmm - I thought the idea was more that when executing a command it will only trigger additional UI if it was missing some values to execute... I think deciding wether a command is relevant in UI or shell is not a yes/no question which is why i'm not really thinking this is something best represented with an inheritance hierarchy. /max > > > On Tue, Jan 15, 2013 at 11:11 AM, Max Rydahl Andersen < max.andersen(a)redhat.com&gt; 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&gt; 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." > _______________________________________________ > 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