Create browser extensions as a GSoC project about web-console

[sh19910711]

Hi all,

I have been accepted as a student in the Google Summer of Code 2016 again this year (under the ruby-org). In this summer, I will be working on three things with the @gsamokovarov's help:

• _Auto-completion_
• _Console fired from "anywhere"_
• _Built-in commands_

The last year, I have developed a prototype of a Chrome Extension and touched on a Firefox Add-on. And also, I will make the chrome extension is production ready, and touch on Firefox and Safari supports in this summer.

And, just for your information, anyone can see the project details of the above ideas in here: https://git.io/vaMkL

Thank you :-)

[sh19910711]

And also I'm not fluent in English, so I've prepared some figures to describe my proposal. The figures are pseudo-images (they are fake screens).

1. Main Feature

The browser extension allows to display the console aside from the web application's view (i.e., the console will be displayed in the web browser's developer tools):

2. Context Viewer

And one more thing - I'm thinking of implementing the context viewer which allows to view all variables in the current context. It will be something like the CSS viewer of Chrome DevTools, and its window will be docking with the console view:

[sh19910711]

Hello, again ✌️

Today, I have made an animated gif of context viewer as a mock-up (and fixed misunderstanding):

The change than before is that an array can be expanded in the viewer. Here is an example diff showing that change:

- @items: ["hello", "foo", "bar"]
+ @items: ▼
+     #<Item id: 1, ...> ▼
+         id: 1
+         name: "hello"
+     #<Item id: 2, ...> ▼
+         id: 2
+         name: "foo"
+     #<Item id: 3, ...> ▼
+         id: 3
+         name: "bar"

I think the context binding of the viewer will be the same as the console.

[gsamokovarov]

Yo @dhh, @jeremy, @chancancode and anyone interested in the development of this project: do you guys wanna chime in and share your ideas about our direction?

One of the ideas I want to explore is have the web-console be optionally always on. Meaning, you can introspect and evaluate code in every binding of the current execution stack. We may crash them Rubies, but its something I'm interested in trying out.

Whatever ideas and directions you guys have, we'll be thankful for all your feedback!

Cheers!

[dhh]

Love the idea of having the console be always on in development mode.

On Tue, Apr 21, 2015 at 11:03 AM, Genadi Samokovarov <
[email protected]> wrote:

Yo @dhh https://github.com/dhh, @jeremy https://github.com/jeremy,
@chancancode https://github.com/chancancode and anyone interested in
the development of this project: do you guys wanna chime in and share your
ideas about our direction?

One of the ideas I want to explore is have the web-console be optionally
always on. Meaning, you can introspect and evaluate code in every binding
of the current execution stack. We may crash them Rubies, but its something
I'm interested in trying out.

Whatever ideas and directions you guys have, we'll be thankful for all
your feedback!

Cheers!

—
Reply to this email directly or view it on GitHub
#121 (comment).

[sh19910711]

Hi, all. This is an intermediate progress report of GSoC 2015, in short. 🍵

1. Add JavaScript Test Environment

PR #138

2. Add Close Button to Web Console

PR #140

3. Web Console in Chrome DevTools

http://brx-web-console.blogspot.jp/2015/06/web-browsers-developer-tools.html

And Next?

From this week, I will start to implement the context viewer experimentally. And so, welcome any comments, and welcome any claims. Let me know your thoughts about this project if you feel something in your heart.

Thanks.

[gsamokovarov]

Now that we have prototypes of the browser extensions, let's discuss where they should actually live.

1. Let them live in rails/web-console. I like this approach as everything is in one place and we can easily reuse the JavaScripts across every project. However, it does have the drawback of blowing up the repo with extension specific commits. We may also end up with extension specific maintainers and they will have access to all the codebase.
2. Let each of them live in own repositories. This has the benefit of easier to track history and project specific maintainers. The drawback is tricker JavaScripts reuse and maybe desynchronization of the projects. Say, the Chrome maintainers are more active and it has more features/less bugs than the Firefox and Safari extensions. This can happen in option 1 too, of course.

I generally lean over option 1, but I would like to hear your thoughts.

[sh19910711]

I haven't sorted out my ideas of that yet, but I think the browser extensions should be located as a sub-project of Web Console, and I think it is better, in that point, to put the code of the browser extensions under the rails/web-console, so plus one to the option 1 so far.

However, it does have the drawback of blowing up the repo with extension specific commits.

Yeah, that is my concern.

The drawback is tricker JavaScripts reuse and maybe desynchronization of the projects.

That is also. I need to think of that.

Thanks.

[thromera]

Any news on that one? :)

[sh19910711]

Nothing for now :-| but I'll be back 👍

…

On Fri, Jun 23, 2017 at 6:15 PM, Thomas Romera ***@***.***> wrote: Any news on that one? :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#121 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA99trVwBhjEkldLhO64jnF1meOavnqSks5sG4I0gaJpZM4D3e7A> .

-- Hiroyuki Sano [email protected]

[thromera]

Thanks @sh19910711. I may take a look and start something (Unless you already did?)

[gsamokovarov]

We haven't worked on them in a while, but the code we have is at: https://github.com/rails/web-console/tree/master/extensions