Auto-open web browser

[dubiousdavid]

The default behavior should be to automatically open a web browser after running "lein gorilla". An override option could be passed to suppress this behavior.

[ghost]

Agreed.

cheers Jan

On 06.01.2015, at 17:52, David Sargeant notifications@github.com wrote:

The default behavior should be to automatically open a web browser after running "lein gorilla". An override option could be passed to suppress this behavior.

— Reply to this email directly or view it on GitHub.

[JonyEpsilon]

There was a PR a while back to add this feature #46 and at the time I held it pending having a way to configure the behaviour on or off.

I think now, though, my view has changed, and I don't think this belongs in the Gorilla server itself (i.e. in the lein gorilla task). Mainly because each thing should do what it does and no more! I think the lein gorilla task gets used in a wide range of settings, often on a headless server, and it seems like mixing something else in to have it open your browser.

There's definitely work that could be done on making Gorilla easier to work with. I've toyed with the idea of having a wrapped-webview shell (like atom-shell or node-webkit) to have Gorilla behave like a true desktop app. I think, though whatever way it goes it would be good to keep the server code just that - server code - and have helper code live elsewhere.

So in this particular case, one suggestion would be to just use existing scripting capabilities of the shell. I'm no bash expert, but I think it should be easy to write a shell command that runs gorilla and then opens a browser. The port that gorilla is running on is written out in a file .gorilla-port when it starts.

[JonyEpsilon]

For completeness, the other things that I've toyed with for making Gorilla more user friendly:

• helper app that monitors running Gorilla instances and has links to open worksheets
• intellij plugin that does much the same
• integrating into atom or lighttable (not easy, sadly)

I would like to see progress on this front, and am going to have another crack at the native app thing when I have a chance.

[ghost]

I won't argue for putting it into gorilla-repl itself, but I think lein gorilla is a good place.

So --head or --headless, either could be the default.

I like gorilla because it runs in a plain browser instead of some node, fake app that throws away portability for menu bar integration looks at light table.

Currently working with gorilla sadly involves a lot of restarting (no interrupt), we could at least make that process as painless as possible.

Cheers Jan

[JonyEpsilon]

I agree with you fully in spirit - it is a pain in the **\ to restart Gorilla, and it could definitely be made much better. I'm still a bit uneasy about the current proposal, though, so let me try and write what I think, and figure out why ...

I think the usability of Gorilla could be much better. Using it daily myself, and watching my students use it, I find that it's awkward - when working locally - to have many Gorilla processes running in tmux windows (one for each project). And it can be confusing to remember which port corresponds to which project.

While I do agree with you about whether wrapping a webapp for the sake of having native menus is worthwhile, I think there are arguments for having a native app. I think Gorilla could be a very good environment for complete Clojure beginners, especially with some tutorial material integrated. And my experience with students is that they can find the complexity of running a Leiningen process, opening a tab in a browser etc very confusing, although they do of course get used to it. So, I do think there’s value in thinking about a more application-like experience.

Another problem that I’d like to work on is startup time. At the moment it’s painfully slow to go from wanting to make a quick plot to actually seeing it appear. For one-off quick calculations or plots I still find myself opening Mathematica for just this reason. I don’t think the problem is intrinsic to Clojure itself as an uberjared Clojure app can open much quicker than Gorilla currently does.

All of that said, I think the fact that Gorilla runs as a true web-app, with an easy to run server is one of its greatest features. I love being able to run emacs and gorilla on a remote server, all over an ssh connection, and still have an excellent user experience. I would definitely not want to do anything that takes away this possibility.

So, I’d like to make progress on the usability/desktop/beginner-user front, and on the startup time front, but without sacrificing anything on the server/advanced-user side. I’m not yet sure how to do this, which is - I think - where my reluctance to go along with this suggestion is coming from. I guess my gut feeling is that whatever solution manages to satisfy all of these requirements will necessarily be modular, and it will probably be important to have all of the modules doing just what they should, and no more.

I’m not sure I yet know what I think the lein-gorilla part of the puzzle is really for. It’s key function is to resolve dependencies in the project.clj file and make sure the classpath is right. Whether it should do anything more than that is something I’m hazy on. I say this, because in terms of speeding up startup, minimising dependency on Leiningen would be a good thing. Whether it, or something else should be responsible for helping the user with browser opening/management is very fuzzy in my mind.

That’s quite a long reply for quite a simple topic, but it’s good for me to try and write down what I’m thinking! I’d propose that for the moment we continue to hold off on this feature until I’ve had a chance to think more about how the various bits might fit together, and how the next steps of Gorilla might go.

I’d be very grateful for any thoughts on this matter anyone has :-) I'm going to open a new (vaguely titled) issue for this sort of discussion. I'll close this one, for now, but am very much open to reopening/revisiting it as things move on.

[JonyEpsilon]

OK, have opened #184 to discuss the wider point.