708213 - Dock the Scratchpad

Status: RESOLVED WONTFIX

(DevTools Graveyard :: Scratchpad, defect, P2)

Comment 1

[Cedric Vivier [:cedricv]]

The scratchpad is currently only usable as a detached window.
By default, it should be docked in the browser, as in shorlander's mockups attached.

Comment 2

[Cedric Vivier [:cedricv]]

Attachment: shorlander's dockup Scratchpad mockup (horizontal)

Comment 3

[Cedric Vivier [:cedricv]]

Attachment: shorlander's docked Scratchpad mockup (vertical)

Comment 4

[Mihai Sucan [:msucan]]

I believe we should make it a requirement to allow Scratchpad to be undockable - to have it as a window.

I wouldn't like to see the Scratchpad becoming only usable in a docked state.

Comment 5

[Cedric Vivier [:cedricv]]

(In reply to Mihai Sucan [:msucan] from comment #4)
> I believe we should make it a requirement to allow Scratchpad to be
> undockable - to have it as a window.

Definitely. Sorry if I've been confusing. This is suggested in the dockup with the "pop out" button.

I meant that the docked position would/should probably be the default position when you open Scratchpad for the first time.

Comment 6

[Mihai Sucan [:msucan]]

That's great then!

Scratchpad is one of those tools that makes sense in a separate window.

Comment 7

[Cedric Vivier [:cedricv]]

Just so that the idea doesn't get lost.
The new design should take advantage of the split view list to expose useful information.. like the Style Editor exposes the rule count for every style sheet for instance.

IMHO the last time a scratchpad has been executed would be really handy (currently I never know if I actually pressed Ctrl-R or when I did it - even less if I have multiple scratchpad open)

Eg. in the list:

__
scratchpad #1
Executed 10 seconds ago.
__
myscratchpadfile.js
Executed 5 minutes ago.
__
testing.js
Never executed.

Comment 8

[Paul Rouget [:paul]]

(In reply to Cedric Vivier [cedricv] from comment #7)
> Just so that the idea doesn't get lost.
> The new design should take advantage of the split view list to expose useful
> information.. like the Style Editor exposes the rule count for every style
> sheet for instance.
> 
> IMHO the last time a scratchpad has been executed would be really handy
> (currently I never know if I actually pressed Ctrl-R or when I did it - even
> less if I have multiple scratchpad open)
> 
> Eg. in the list:
> 
> __
> scratchpad #1
> Executed 10 seconds ago.
> __
> myscratchpadfile.js
> Executed 5 minutes ago.
> __
> testing.js
> Never executed.

Do we really want a splitview for scratchpad? Since it's not really used to edit the JS files of the page, I don't see why the user would want to handle several files.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Paul Rouget [:paul] from comment #8)
> (In reply to Cedric Vivier [cedricv] from comment #7)
> > Just so that the idea doesn't get lost.
> > The new design should take advantage of the split view list to expose useful
> > information.. like the Style Editor exposes the rule count for every style
> > sheet for instance.
> > 
> > IMHO the last time a scratchpad has been executed would be really handy
> > (currently I never know if I actually pressed Ctrl-R or when I did it - even
> > less if I have multiple scratchpad open)
> > 
> > Eg. in the list:
> > 
> > __
> > scratchpad #1
> > Executed 10 seconds ago.
> > __
> > myscratchpadfile.js
> > Executed 5 minutes ago.
> > __
> > testing.js
> > Never executed.
> 
> Do we really want a splitview for scratchpad? Since it's not really used to
> edit the JS files of the page, I don't see why the user would want to handle
> several files.

Scratchpad looks like a regular programming editor, so using it to try out several files (persisted scratchpads) would seem natural IMO. Furthermore, I can totally see this as an IDE of sorts that would allow one to edit code and refresh the page to see the results. Maybe this use case would be better handled by the debugger, but it seems like a waste to artificially limit Scratchpad's use cases.

Comment 10

[Rob Campbell [:rc] (:robcee)]

I think there's something here, but I'm not sure this is something we really want for the scratchpad. Having a single, simple, tear-off editor for working with JS feels right. Having a docked, multiple-file view for ... script files (which ones?) feels too heavy.

The original goal of the scratchpad is to replicate the experience of a Smalltalk Workspace and I think the current implementation does that quite well. Adding more complexity to this simple feature feels unnecessary.

Maybe as a component of the debugger, it will make more sense to have code editors with complete lists of script files contained in the document wrapped in a split view, but that's a separate thing that will happen to make use of the scratchpad and not the scratchpad itself.

Comment 11

[Rob Campbell [:rc] (:robcee)]

(In reply to Panos Astithas [:past] from comment #9)

> Scratchpad looks like a regular programming editor, so using it to try out
> several files (persisted scratchpads) would seem natural IMO. Furthermore, I
> can totally see this as an IDE of sorts that would allow one to edit code
> and refresh the page to see the results. Maybe this use case would be better
> handled by the debugger, but it seems like a waste to artificially limit
> Scratchpad's use cases.

sorry to harp, but I have some additional information:

My scratchpad directory currently looks like:

 black.js
 browser.js
 canvas.js
 chrome.js
 createTreeBox.js
 crytpoHash.js
 dockedHtmlPanel.js
 document-background.js
 dolla-0.js
 fib.js
 find-the-bad-tab.js
 fullzoom.js
 getBzLogin.js
 getCookiesForHost.js
 highlighter-frame.js
 highlighter.js
 inspectNode.js
 inspector.js
 js modules.js
 jsms.js
 mobile-window-resizer.js
 nodehidden-test.js
 photo-assignments.js
 potch-bookmarklet.js
 remove-dead-box.js
 stack.js
 style-inspector-path.js
 tab-opener.js
 tabgroup-tabs.js
 tbpl-links.js
 tbpl.js
 test_scrolling.js
 visibleTabs.js
 windows.js
 workspace-hud.js

Some of these are content scripts, some of them are browser scripts. Are you suggesting that we show the contents of a specific directory in the left side? Do we need a directory navigation widget to go along with this?

I also feel compelled to point out that the mockup in this bug was an example shorlander came up with to show off what the styling would look like, not necessarily as a suggestion for the design of the scratchpad.

You mention an IDE and that term carries a lot of baggage around with it. I think we can have some IDE-like features, but I'm not sure it's a thing we want to strive for.

Comment 12

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Rob Campbell [:rc] (robcee) from comment #11)
> (In reply to Panos Astithas [:past] from comment #9)
> 
> > Scratchpad looks like a regular programming editor, so using it to try out
> > several files (persisted scratchpads) would seem natural IMO. Furthermore, I
> > can totally see this as an IDE of sorts that would allow one to edit code
> > and refresh the page to see the results. Maybe this use case would be better
> > handled by the debugger, but it seems like a waste to artificially limit
> > Scratchpad's use cases.
> 
> sorry to harp, but I have some additional information:
> 
> My scratchpad directory currently looks like:
> 
>  black.js
>  browser.js
>  canvas.js
>  chrome.js
>  createTreeBox.js
>  crytpoHash.js
>  dockedHtmlPanel.js
>  document-background.js
>  dolla-0.js
>  fib.js
>  find-the-bad-tab.js
>  fullzoom.js
>  getBzLogin.js
>  getCookiesForHost.js
>  highlighter-frame.js
>  highlighter.js
>  inspectNode.js
>  inspector.js
>  js modules.js
>  jsms.js
>  mobile-window-resizer.js
>  nodehidden-test.js
>  photo-assignments.js
>  potch-bookmarklet.js
>  remove-dead-box.js
>  stack.js
>  style-inspector-path.js
>  tab-opener.js
>  tabgroup-tabs.js
>  tbpl-links.js
>  tbpl.js
>  test_scrolling.js
>  visibleTabs.js
>  windows.js
>  workspace-hud.js
> 
> Some of these are content scripts, some of them are browser scripts. Are you
> suggesting that we show the contents of a specific directory in the left
> side? Do we need a directory navigation widget to go along with this?
> 
> I also feel compelled to point out that the mockup in this bug was an
> example shorlander came up with to show off what the styling would look
> like, not necessarily as a suggestion for the design of the scratchpad.
> 
> You mention an IDE and that term carries a lot of baggage around with it. I
> think we can have some IDE-like features, but I'm not sure it's a thing we
> want to strive for.

Yeah, IDEs mean many different things to different people, I apologize for adding to the confusion. What I'm aiming at is having an environment where I could do most of my work in a single app, and I think the browser with Scratchpad, the console (especially GCLI) and the forthcoming debugger is an excellent fit for that role. The reason Scratchpad seems like a good fit to me, is that I have often seen such environments spring out from editors, but I can hardly recall one where the editor came last. A traditional work flow that can be mapped nicely into what we (almost) have is: edit using Scratchpad, maybe build using the console, view and inspect using the browser (and the inspector), debug using the debugger and maybe commit using the console again.

As for the file list, I'm actually not thinking about the traditional directory or project view. When I'm working on a particular task there's usually a collection of a few files that I'm switching between until I'm done. Quite like the tabs I have open in the browser (in a particular tab group). This is a straightforward extension of the Scratchpad's current behavior with respect to the session store. All I need in the file list is the number of files in my session, and if we respect the recent pref to open background tabs on demand, there wouldn't be a penalty in the Scratchpad startup time when restoring a previously open session.

This is something that I first experienced in the Eclipse Mylyn plugin/project, which would associate the current bug you were working on with the list of files you had touched since you started working on it. You could hide everything else in your huge project and only view the files that you had designated as significant for that task. Now, this is way more advanced than what I'm proposing here, but the existing session store implementation brings us very close to the same goal: work on multiple files concurrently, but not be overwhelmed by information.

Comment 13

[Panos Astithas (he/him) [:past] (please ni?)]

And in case that wasn't clear, all I want from Scratchpad is what a text editor like Sublime offers. What our various integrated tools provide is way more than that in some ways, but we don't have to advertise it as an IDE. On the contrary, I think underpromising and overdelivering can be a great strategy for us. In the same way that plain editors like vim or emacs have pleasantly surprised users by their capabilities, after being introduced to them. Even the name, Scratchpad, fits perfectly in such a plan!

Comment 14

[Rob Campbell [:rc] (:robcee)]

Filter on BLACKEAGLE?!

would like to have the blocking bug for this (devtools window).

Comment 15

[Tim Nguyen :ntim]

I've created an add-on that looks like the mockup : http://ntim.altervista.org/addons/devtools-snippets

In addition to running scripts, it lets you preview html and css. This is just a prototype, but it can probably do more things in the future, such as grouping html, css and js; and letting them run together.

Comment 16

[Panos Astithas (he/him) [:past] (please ni?)]

Note that the Scratchpad can be now docked (when debugging remote targets) and we already got WebIDE, which accomplishes most of what I've wanted in this bug (and it will likely host any further improvements in that area). I think this bug as it stands is a wontfix by now.

Comment 17

[Sebastian Zartner [:sebo]]

Also, there is now a Scratchpad panel additionally to the independent Scratchpad window. Due to this fact and because of comment 16, I close this now.

Sebastian