Re: [orion-dev] Need help with creating an extension point

[Andy Clement <andrew.clement@xxxxxxxxx>]

> 1) A console "Section" embedded in other Orion pages, such as the editor
> or navigator.
> 2) A single Orion console page (say http://orionhub.org/console/). This
> single page would allow you to interact with all the various console
> extensions you have available.. Git, Cloud deployment, Rails console, etc.

When Kris and I started playing, we went with (1) in the editor - which was my initial view of how I'd like to use it. Using keybindings I can slide it out to do some whatever-it-is and then close it again - I never leave the editor tab.  We had this kind of working but it became apparent that (currently) to make it a nice plugin we had to promote the CLI to its own page rather than having a slideout.  I had hoped when it got into orion core that we'll have the slideout support again (in the editor certainly, perhaps elsewhere).

Having said that I can imagine a slideout is best for a simple targeted activity against a few files, possibly only the file you are looking at (if you slideout in the editor view).  So I can also see value in a full page console where I have more screen area to work.  I'd hope the same commands would work in both, it is just a question of how much space I would want to get the job done.  I feel like if I saw a prompt anywhere it ought to always offer the same commands.

Perhaps building on that there can be task based consoles which offer mostly the CLI but maybe a bit of additional UI for the task you are trying to achieve, but that could follow on from getting the basics going.

To offer a thought on Johns note:

> Hmm, when I use command line tools it is typically via a series of putty windows. If I had my
> source code on one server, a second server for running builds, and a third server where my 
> deployed application lived, I would have a separate putty window for each. I wouldn't expect 
> commands for interacting with my deployed server to work from the console on my source 
> control server, and vice versa. Apart from security problems with that, I'm not even sure 
> how that would work. I.e., what does "ls" mean when my tooling workflow spans several 
> servers like this? Which file system does it list? In an older world where I could edit/build/run
> on a single box I can see how this works, but in software development for the web
> I'm having trouble visualizing how a single monolithic console works.

My initial view had been that I want a console purely to interact with the contents of my workspace and perform activities for which there is no UI (either because it hasn't been built yet or because it will never be built due to my funky use case).  I hadn't considered using the console view as the bridge to 'other places' - it is an interesting point.  On my regular desktop I can of course just open another terminal and putty, but on my ipad I don't have that luxury.

cheers
Andy

On 5 March 2012 08:58, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:

Hmm, when I use command line tools it is typically via a series of putty windows. If I had my source code on one server, a second server for running builds, and a third server where my deployed application lived, I would have a separate putty window for each. I wouldn't expect commands for interacting with my deployed server to work from the console on my source control server, and vice versa. Apart from security problems with that, I'm not even sure how that would work. I.e., what does "ls" mean when my tooling workflow spans several servers like this? Which file system does it list? In an older world where I could edit/build/run on a single box I can see how this works, but in software development for the web I'm having trouble visualizing how a single monolithic console works.

John

Andrew Eisenberg <andrew@xxxxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

03/05/2012 11:37 AM

Please respond to
andrew@xxxxxxxxxxxx; Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To	Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Subject	Re: [orion-dev] Need help with creating an extension point

My personal opinion and expectation is that we would have one single page that understands all console commands.  When I work on the command line locally, I expect that I don't need to need different consoles for each set of commands (eg- git vs vmc commands).  From an implementation side, it might be easier to keep the consoles separate, but for a user this is an unnecessary complication.

Besides, even if we went with a separate console per extension, they would still all need to recognize the basic commands (eg- cd, ls, pwd, ...).

So, from a user's point of view, I would prefer to see #1 or #2 below.



On Mon, Mar 5, 2012 at 8:11 AM, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:
Stepping back a bit, I'm wondering what the overall UI experience of the command line will be, and how it will fit with other pages. Ignoring any security or architectural limitations for a minute, would it look like:

1) A console "Section" embedded in other Orion pages, such as the editor or navigator.
2) A single Orion console page (say http://orionhub.org/console/). This single page would allow you to interact with all the various console extensions you have available.. Git, Cloud deployment, Rails console, etc.
3) Individual console pages for various tasks. For example, http://mygithost.org/console to interact with a Git repository, http://cloudfoundry.org/console to interact with a deployed cloud application, etc.

4) Something else? _______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev


_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev