As Andy mentioned, initially we experimented adding a 'slideout' console at the bottom of the editor.
But currently what I've got working is (2): a single console page.
I'm with Andrew that a 'many different consoles' approach doesn't appeal to me. I would rather have all the commands in one place. The nice thing about this is it isn't a challenge to figure out what Window/View I have to open before I can execute my command. What I find annoying about orion's current UI is that I end up choosing between one of two problems:
1) an overwhelming amount of disconnected open windows and tabs (when I opt to open in new window tab to avoid problem 2)
2) I end up loosing my context every time I click a link (plus the fresh page load is rather slow)
I would like the option of having the console accessible 'in page'. Like a slideout at the bottom of the page. If so, I would like the same console to be accesible from (almost) every page in the same way. I would expect that all those different consoles provide access to the same commands rather than be a limited set. It would also make sense for the console to have some kind of 'state sharing' with the other content on the page (e.g. the current directory, at least initially would be tied to the editor's current file, or the navigator's current contents.
The main reason for going with Model (2) for now is that it is simpler and easier to think about. (When its on the bottom of a page, we have to start thinking about how to share state with the page and keep the rest of the page 'synched' with console changes/state. (e.g. When I cd in a console at the bottom of the navigator... does it then also point the navigator to the new directory? What if I 'cd' on an editor page?? Or is that not allowed?)
Kris
PS: I am nearly at a point where I can contribute back an initial console implementation. The console has 'baked in' support for cd, ls, pwd and allows extra commands that produce 'pure text' output to be added by orion plugins. It is still 'rough work' but I'll do so ASAP so people can start criticising something concrete rather than continue to reason about an imaginary UI).
PS2: Unfortunately I won't be able to share my commandline UI as an orion plugin... it will require running a 'customized' localhost orion setup to try out.
> 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
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
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
