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

[Lincoln Baxter, III]

Max, I think perhaps we are mis-communicating slightly. I am not making a
distinction between CLI Shell and IDE Shell. I am making a distinction
between Shell and GUI.


On Fri, Jan 18, 2013 at 5:38 AM, Max Rydahl Andersen <
max.andersen at redhat.com> wrote:

> > 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 at 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 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
> >
> >
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130118/309818bb/attachment.html