coala-html as a proper GUI for coala

[impmihai]

Hello! I would like to debate with you the idea of evolving the coala-html project into a true GUI for coala. At the moment, we use coala-html only to see the result of running coala on a directory and that's all. We could do so much better than that.

My idea is to combine all other projects in a nice and simple interface, one could start using right away. My first experience with coala was quite the opposite of what I was expecting...not so intuitive and natural. It took me an hour to get comfortable with the environment. My honest opinion is that I can't be the only one to face those problems. Imagine that I had some trouble by understanding how it works, and I have a lot of technical backgrounds. How about the common user? We need to improve the user's experience so that it will feel as intuitive as it should.

I would like give coala a proper GUI, similar to what git has. It took me about two weeks before finding that we have a coala-quickstart project that generates a coafile for your projects. Why not put a button to do that, the first time you open a project that does not have one? We could facilitate installation of bears and coafile writing too. Hovering a bear could show up their description as well.

What I am thinking of is an interface that combines the existing projects, not rewriting what already exists. So when someone tries to use a feature he has not previously installed, an install prompt would ask him of he want it installed automatically. This project is aiming mostly at beginners, not advanced users of coala. We can still show the CLI commands we are executing, to let the user learn what he is actually doing.

Going technical now. Firstly, I would like to port the coala-html project to a framework like electron, keeping the current functionality. Other projects don't really need modifications to work with this, as I am calling their CLI commands and catch their output. Or another better approach would be to import their modules and call them, I am wait for a suggestion on this. A possible approach to combine python and electron I found here: https://www.fyears.org/2017/02/electron-as-gui-of-python-apps-updated.html Firstly, adding the coala-quickstart support and a coafile editor are a must. Good for a beginner would be to add a panel with all bears and a small description on what they do and need, and also their optional parameters. For globbing files, I would like to show what files will be used when coala is run and what files are not, or even let the user check what files should be used and try to generate a glob for him. Next up is a bear management panel that uses the cib project and allows you to install or remove bears and their dependencies very easy.

I would also add a terminal-like window that displays the commands runned, to give the user an idea of what is going on behind, so he can still learn something.

What do you say about this? Would you consider this useful? @Udayan12167 @sils @sims1253 I am posting here as i am not able to write on coala-html, because i am not respecting it's issue template. I would like to help coala evolve, it's not necessarely a project for GSoC, but to improve the user experience.

[Adrianzatreanu]

I feel like this sounds quite complicated and hard to achieve, considering some parts of coala are not that stable (we dont even treat bear requirements right). But supposing we'd have what youre aiming for: a nice GUI, which would integrate quickstart, coala and even installation of bears, would be a dream and probably make it a top tier choice. However, I find it hard to achieve and it would probably take a long while and be full of bugs.

But, as ive seen, youre already tackling a hard issue (shows youre capable) so if nobody is against, im giving you my support for doing this.

[sils]

@impmihai gorgeous, I think we're on the same page. The important bit here is that coala-html evolves and we don't make a new project because that would loose focus and there'd be a higher chance of either coala-html or the new project or both being unmaintained in the end.

From a technical POV: I think we should modularize this properly. I.e. there should be a module that just shows the results that would be used by the full thing. The point here is that this is reusable for displaying results in http://coala.io/#!/tryonline beautifully.

That also means that the core stuff should be also usable on websites, if that is true for electron it sounds perfect.

[sils]

See also https://discuss.atom.io/t/how-to-run-electron-desktop-app-in-web-browser-without-downloading/30495

[sims1253]

One concern is that we (or at least I) got a lot of feedback during conferences that people liked the html output we have right now. Just some kind of "status page" they can look at. We'd want an option to keep that. Besides that, I dislike building stuff on top of browsers buuuut they sadly are the only "simple" option for unified UIs

[impmihai]

@sils, a commend from the link you gave me:You misunderstand what Electron is. Electron is just Node14, packaged up with part of Chromium so that it can display HTML and compile JavaScript. If you want a web app that does exactly the same things, just write a web app with Node.

We could share the same core between the electron app and the website. The idea about the site is that we would have to run a node server somewhere, and let users use it without actually downloading coala. We could have a ready-to-go server hosting all bears and coala and let the user upload his project or give his git url and then give him full acces on his project in the browser. This would be the same thing as downloading the app, just that in the last part he is hosting the server on his machine through electron. I am thinking of a way to modularize everything in a plug-and-play way right now.

[sils]

Yep love it! :)

[impmihai]

@sims1253 Evolving does not mean removing features :D At the moment, what i see in the coala-html project is that it runs coala and then opens a web-server that has the results. The way I see this is having a button to execute coala and after it is executed, the output appears, showing the same thing it is right now. I think that we could still keep the interactive type we have in the CLI would be possible too, but this would take some more work to be done, although not impossible. :)

[sims1253]

I totally like the idea of some form of gui for coala. Makes it much more approachable for a wide audience that doesn't use the terminal. Just wanted to add that the simple thing we have at the moment actually gives value by being as simple. Couldn't we even write html files and offer them instead of spawning a server?

[impmihai]

Well, this is the way electron works. It gives you the ability to serve html files and make them dynamic using javascript while also having access to the computer's functionality like the file system or executing processes through node.

[sims1253]

and that totally feels bloated for just displaying results. But I have no experience with web dev stuff so my opinion shouldn't hold much weight :D

[impmihai]

Well, have you ever used the atom text editor? It is built using electron :D You can see on their website some of the projects that use electron, on the bottom of the page: https://electron.atom.io/

[sims1253]

I did and it felt slow as hell compared to sublime, hogged my ram and so I left it :D

[impmihai]

https://github.com/electron/electron/issues/5672 you can find here more about it's performance. It feels slow because it is actually opened in a browser. This would be the best option for portability. This or PyQt, but it is not as flexible as electron.

[sils]

browser performance is totally ok for running coala, making a native app would be a total waste, we kind of agreed on that earlier so let's not open pandoras box again.

Sincerely,

Lasse Schuirmann

lasse@schuirmann.net http://coala.io/ - http://viperdev.io/ - http://gitmate.com/

On 14 March 2017 at 15:27, Mihai Ionut notifications@github.com wrote:

electron/electron#5672 https://github.com/electron/electron/issues/5672 you can find here more about it's performance. It feels slow because it is actually opened in a browser. This would be the best option for portability. This or PyQt, but it is not as flexible as electron.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/coala/projects/issues/258#issuecomment-286437869, or mute the thread https://github.com/notifications/unsubscribe-auth/AFc6KC8qwpluNGxzbSDKWS09oXixqne5ks5rlqPqgaJpZM4Mcft- .

[hemangsk]

browser performance is totally ok

Agree entirely, and if we want a native app feel, we can open a completely new 'browser window' everytime coala-html is fired up.

So if you think about it, Atom opening in an electron wrapper and Atom opening in a browser window is not entirely different apart from the fact that, we get a url bar and reasonably good performance when its opened in browser.

[impmihai]

http://projects.coala.io/#/projects?project=improve_coala_website_%26_supporting_tools I just read a little more carefully this and I see that there is some pretty high involvement around coala-html too. How would this project affect what is written here? Can I write a proposal for that project with the ideas I have written here?

[sils]

We'll sort that out with you during the application phase, just make sure to submit your application as soon as possible so we can give you feedback for potentially needed adjustments.

[impmihai]

Okay!😀

[impmihai]

If I already have coala-html running in an electron window, should I make a PR with this, to prove my capabilities of finishing this?

[impmihai]

Ok, so by looking deeper in the project, I found 3 possible solutions to this.

My first approach is to port everything to javascript from python. This would be the most elegant solution, as it cleans up the project and makes it easier to understand. Also the instalation will be easier for beginners. coala will be called with process spawning and the output will be saved as a json in the analyzed project. At the moment, what the project does is running coala with the json output format, make a separate directory in the project coala is being run and copy a website structure and the json output in that directory, spawning a web-server there. The conclusion is that we only use python in order to execute coala and obtain the output, which can be done by simply spawning a process.

The second, non-optimal approach is to make a communication bridge between the current python scripts and the javascript app. I say this is non-optimal since the current functionality of the coala-html project can be easily ported and the scripts number will be reduced. Also, we are not really required to work with python scripts here, since we don’t really need a true communication bridge.

And the last approach is to combine the first two. Spawning the current script as a separate process, let it do it’s job running coala but remove the website copying, letting just the json output in the directory we are running in.

What do you say, @sills ? Is the 1st one too drastic to go that way?