Better Web IDE

I can see how Angular can really work for websites, and I have used similar things in production sites I've done and I've loved it. I just think in this case (with very few views, not many controls, but lots of code) it might do more harm than good.

At the moment, I just see that your current version reintroduces a lot of the pain I was trying to avoid with the refactor (having every UI element on the main page defined in one place). It's not a major issue at the moment, but when people try and contribute extra things (just look at the existing non-refactored Web IDE's main.html) it turns into a complete mess really quickly.

For HTML - I get the formatting issue - but does it matter? I use Chrome element inspector and that formats it all nicely for me anyway :) I just wonder what things like the settings page would look like with dynamically loaded HTML...

from:

html += '<input name="'+configName+'" type="checkbox" style="float: right;" '+(value?"checked":"")+'/>';

to:

$.get("/templates/settings_input_checkbox_"+(value?"checked":"unchecked")+".html", function(data) {
 $(data.replace("{{name}}",configName)).appendTo(".settings .current");
});

Doesn't seem much better to me. I'd be totally with you on using jQuery to build the elements though - and that would solve the escaping issue:

$( '<input/>' ).attr({
  name: configName,
  type: "checkbox"
  // ...
});

And then maybe anything that's more complex than a simple element gets loaded from a file? Although I hope there won't be too much of that.

Wrt plugins: I've had a bad time with them to be honest. Better support is great - except keeping each one of your plugins up to date is a nightmare... And what happens when you update jQuery and that breaks a bunch of them, and you find your plugin hasn't been updated since 2006?

So I'm really not convinced for the smaller stuff - but for the big things, awesome - and to be honest the Terminal is a big thing (I just didn't find a workable version when I started making the Web IDE so I had to roll my own)...

Anyway, thanks for looking into it!

Hey Gordon,

That's cool, we'll leave angularjs out of it. If the idea of the IDE is to stay simple, you're right that it might add a learning curve overhead for little gain (maybe take a look at it in future if the demands of the IDE get a bit more complex).

Regarding the HTML, I was meaning from a developers perspective it looks ugly in the source (I don't really care what it comes out like in the raw HTML). I just know someone will get caught out by a rouge quote somewhere, and those are the annoying issues that eat up hours trying to debug if you don't know what you are doing :)

I know the example you show does look a bit bigger, but if this is a standard approach, you could make the viewpath part of a modules config, and have the core code load it and call init when it's done? Just an idea.

I might just be being picky on the 3rd party plugins, I just think it's handy if we re-use (both saving writing own code, and having a wider audience from which to get fixes if there are bugs), but again, if it works, don't fix it right? :)

Matt

oh, just looked over your code example again, loading in html, and that's not how I would suggest it by the way. I'd suggest you have 1 html file for your module, with the markup needed for it, then use jquery to modify it if you want to turn on and off a checkbox (rather than loading in 2 seperate html files).

Just thought I'd mention that.

Hello,

Please consider running the IDE on the board itself will use memory/space that i would like to have for my own applications.

Sacha

If you could get the terminal to run over websockets, to be honest, it wouldn't matter where the IDE was hosted. Heck, it could be hosted online (easy upgrades to the IDE) and take up no space on the board.

(This is why I've been trying to find a board that supports js / websockets for a long time. The web connected possibilities are endless)

Matt

Hmm... That'd be nice. Do websockets not have to be to the same server that the page was hosted on?

I've now abstracted away all the nasty interface-dependent bits of the networking, so implementing websockets shouldn't be a big deal. I just did a quick google though and there seem to be a million different WebSocket libraries for node... I don't suppose anyone has standardised yet have they?

It'd be nice to implement some API that was code compatible with what most people are using...

Nope, WebSockets can be hosted anywhere. As the WebSocket client code would be run in the browser (ie, on the end users machine), that would mean that the WebSocket could even be just on your local network. As long as you can access it's IP, it should work.

Going off topic, I've been wanting this for a while so in theory, you could create controls in a webpage that talk to a local device. You can't do that straight from the webpage with standard sockets, but if you have websockets, you can.

The most popular socket library I know of is socket.io , so if you went with whatever WebSocket protocol they are using, I think that would be cool. Also, Chrome is one of the few browsers that truly supports WebSockets, so even better for the IDE :)

Matt

If you wanted to access your device from an external location, you could then look to implement a central hub like how spark do it.

Just food for thought :)

PS If you are just after a pure WebSocket node library, it looks like ws is the one everyone is using (seems many of the larger libraries are using that underneath).

Yes, ws looks like a good API to base it on...

In a way it seems like I should implement 'normal' sockets as well though. I guess if I do it right it shouldn't take up too much flash to support all 3.

For sure, I wouldn't say implement WebSockets to the detriment of regular sockets, but I think WebSockets should be high-ish priority IMO. Espruino's main selling point is that it is JS based, so supporting JS's main method of communicating cross applications has got to be a winner.

Matt

Hi Gordon,

Yes, please implement 'normal' sockets. Maybe a subset of this implementation:

http://nodejs.org/api/net.html#net_net

WebSockets can then be implemented on top as a module only loaded when needed. Just like any other protocols on top of sockets.

BTW. I think you already implemented i kind of sockets. The existing HTTP Class must be based on it.

Ok, I added an issue for this: https://github.com/espruino/Espruino/issues/258

But back on track, if anyone else wants to try this:

• Download https://github.com/espruino/EspruinoWebIDE/archive/major_refactor.zip to a directory on your PC
  
• Click the menu icon in Chrome's top right
  
• Click 'Settings'
  
• Click 'Extensions' on the left
  
• Click 'Load Unpackaged Extension'
  
• Navigate to the EspruinoWebIDE Directory and click Ok
  
• Job Done. It'll now appear as an app with the 'Unpacked' banner so you can tell it apart from the normal Web IDE.
  
  

IMO it's working pretty well now (it even lets you specify font size, which others have asked for) but I'd be extremely interested to get other people's points of view on this.

Personally I might knock 10px off the size of the title/separator bar, but I wonder whether it would spoil the look.

I'm planning on going through and tidying all the spacing up. Honestly, I think it's this level of detail that makes all the difference.

Regarding spacing, I'd say keep it as is. An air-ey interface makes it look simpler and cleaner IMO, and once everything has been evened out and lined up, I think it'll look pretty tight.

Matt

@gordon quick question, I take it you will be happy for me to move buttons to where I think they should be? (basically where they were in my original design). I spent a lot of time looking at the design and planning where things should go to be most contextually relevant, and would hate to loose this.

What did you have in mind? Re-adding the other bar?

As i'd said before, can we keep the two panes in that order? I don't care what they are if you add the up/down mode, but at the moment all the tutorials explicitly mention which pane to use by where it is.

Note that at the moment each button has a sort order that determines the position, so that if/when someone contributes a plugin they don't have to change a bunch of other files.

Hi Gordon,

I'm happy to leave the terminal on the left, but I would like to introduce the sidebar for the terminal with the clearscreen button, and put the webcam icon in there too (rather than on the toolbar). Likewise I don't think the code/blocky switcher works in the main toolbar.

For the configurable icons, I'd probably look to change how this works a little so you can provide an area ("toolbar", "terminal" or "code") and a position ("top", "middle", "bottom", "left" and "right") where relevant, so we can still have the buttons configurable. There would just be more options.

I would like to reintroduce the vertical / horizontal splitter button aswell. Maybe this could be a 4 way toggle button? Standard is console left / code right, click once switches to console top / code right, click again give you code left / console right, and again for code top / console right. This way it covers all layout options for peoples preference.

To re-introduce this would probably mean using the splitter I wrote though (I couldn't find any which supported changing mode at run time) but it shouldn't be a big deal to port over (I wrote it as a jQuery plugin).

Something else I'd probably look to introduce could be a status bar along the bottom where we can put the "not connected" text as I think it just looks out on a limb in the toolbar (I would prefer to not have it at all and let the button colour identify the status, but if you want it, I think a status bar would look better).

Matt

Yes, that all seems great... Flipping the view is fine - it might be helpful if the button could be switchable in settings though (I'm aiming for a bare minimum of buttons when you start at first, so it's extremely obvious what to do).

Not using your splitter was just a side-effect of the way I merged your code and my refactor - nothing personal :) I'd be happy to have it back.

As for status - I agree, it's rubbish where it is. I was considering:

• A popup for state changes (I think you had this before?)
  
• Actually write other status into the Terminal window - I'm thinking things like more information about what's happening when Flashing Espruino, and more information for warnings (such as module not found) and error messages.
  
  

I'm not sure about the percentage bar either. It's useful but ideally it wouldn't get in the way at all (even when showing). I guess it could even be a 60px wide control in one of the vertical dividers...

Ok, cool.

Just a though on keeping the split button in toolbar (but mabe make it only a 2 mode button, with an option in settings for code / terminal positions), the idea for it in my design was to give people more horizontal space when coding whilst still keeping the terminal for quick commands. Not sure how much of an edge case this is, or whether it would be handy for people (I'd also really like buttons / keycodes to quickly maximize the terminal, or the code editor to give people focus, but these are nice to haves at the moment).

Anyway, really glad to hear you are open to these suggestions, so like I say, I'll try and get some of this done over the weekend.

Matt

Hey Gordon,

Made some good progress this evening. Added a custom titlebar, setup all the icon areas (and they work). Added a notifications module (like in my demo). And started to get things looking all-together cleaner.

I've also tweaked the CSS for the modals so that they are positioned via CSS, and therefore don't need re-positioning via JS, and likewise for the splitter.

I'm gonna do some more bits tomorrow, but thought I'd give you a bit of an update.

Matt

Bit of a screenshot update. Still need to tidy up the options dialog, and need an alternative for the Status progress indicator, but otherwise looking good.

I've pushed everything I've done so far to my fork here if you want to take a look.

Matt

1 Attachment

More screenshots. Now added a status bar with progress bar (so you can now write to status bar, or use alerts). Have also styled the options panel a little.

I think, this should be pretty much there. @gordon you fancy giving it a test?

Matt

2 Attachments

Actually, I guess we need to update the intro with the new button icons too.

Progress is looking really good!

Pull request submitted :)

Matt