Pages: 1
  Print  
Author Topic: HTML5 based IDE  (Read 2941 times)
Offline (Male) Josh @ Dreamland
Posted on: January 20, 2014, 12:26:29 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
I've never interfaced node.js with anything, personally (though I have linked V8 with things). It would be ideal to interface ENIGMA with it as a shared library, as it makes syntax checking faster and allows the compiler to keep relevant information in memory. A JavaScript IDE does exhibit a lot of promise—as I mentioned, there are already great code editing and image editing tools available in HTML5. I suppose the ENIGMA/node interface could be put off until the IDE actually worked, but I wouldn't run with this idea without involving some C++ code.

That said, your new biggest concern is speed. That code editor can get laggy on single big files. People will want to have multiple code files open at any given time... it can get messy. It's too bad there's no <html:use> similar to <svg:use>; another big emerging topic is the ability to have the same file open in multiple windows/tabs, and edit it concurrently. That tag is perfect for such occasions.

At this juncture, it might be best to split this topic. The requirements and ideals of this IDE project are larger than the entire rest of the contest; it should probably get its own thread.
« Last Edit: January 20, 2014, 12:28:01 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TGMG
Reply #1 Posted on: January 20, 2014, 02:33:45 PM

Developer
Joined: Jun 2008
Posts: 107

View Profile WWW Email
The nodejs-webkit project is just one of the possibilities, if the interface is decoupled from the backend it could allow different technologies to be used:
QT: http://qt.digia.com/Product/User-Interface-Creation-with-Qt/HTML5/
WebkitGTK: http://webkitgtk.org/
wxWidgets: http://docs.wxwidgets.org/trunk/classwx_web_view.html
chromiumEmbeded: https://code.google.com/p/chromiumembedded/

I have no doubt that some c++ code will be needed for integration in the backend but hopefully that won't be too much of a problem.
Speed is a definite concern but i'm hoping there will be opportunities to optimize for cases such as large scripts and multiple windows/tabs. A way to manage unused tabs to load in and out of memory would be good with some UI trickery to appear instant would be cool! But we'll have to see what the performance concerns are and try to come up with clever solutions.

As for server side certain features such as basic syntax checking could be done on the client Javascript side, caching of the c++ code generated from each script would be useful to only compile the changes made.
Then there is actually delivering the game to the user which would probably best be handled by a custom plugin (something like the unity player).

Ideally I would like to use TogetherJS (https://togetherjs.com/) for a google docs like collaborative game editor.

But the contest is for the basic components that can be used to develop this project further, it could completely fall on its face but I'd personally like to find out how it will go.
I split the topic at your post hope you don't mind!
Logged
me
GMbed 2.0 :: Embed you gm games in websites.
Offline (Male) Josh @ Dreamland
Reply #2 Posted on: January 20, 2014, 03:01:31 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
TogetherJS seems like a lofty goal; the rest sounds reasonable. I'm aware that other widget libraries have methods of embedding HTML, but I expect them to be awful compared to Webkit (meaning those which likewise utilize Webkit and V8 are the only real contenders). And using them wouldn't help with the continuity of C++ vs JavaScript, at all. You still don't have any low-level access; the only difference is now it's in a system widget library instead of a browser or node.js.

Doing even basic syntax checking client-side means more code to maintain. Yeah, you can color-code strings and do brace matching; you completely have to. All IDEs do that. But you can't do a tenth of the required syntax checking client side in a language as complicated as EDL, so users will still be sticking to the syntax button like glue.

As far as the contest goes, we already have the code editor, we already have the image editor; the other editors are GUI-heavy, but shouldn't take someone more than a few hours to set up, but forever to make work. For example, playing sounds in the sound editor. You're limited by your HTML environment's capabilities. And without a format to save to and load from, which is a critical part of the IDE's communication, it's hard to just jump into such specific dialogs.

What I'm saying is, all the general work is already done. The specifics are all that's left, and that's not the sort of substance for a competition. But yeah, I'm interested to see what happens, as well.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TGMG
Reply #3 Posted on: January 21, 2014, 03:27:06 AM

Developer
Joined: Jun 2008
Posts: 107

View Profile WWW Email
Low level Access will utilise the same basic enigma sever but the sever will be running locally rather than remotely. This allows one code base to be reused for both online and desktop components.

TogetherJS is definitely a lofty goal but it's good to think about the future potential of the IDE.

Most frameworks use WebKit or chromium afaik but yes if they don't they are not suitable.
I agree about syntax checking, I was mainly thinking of using a basic JavaScript checker first before calling the server to reduce impact on the server. If the user has done something really stupid it won't need to call the server.

Yes you make a very good point, I'll have to create a prototype and modify the competition so that it is more suitable. Which sounds quite fun, it's just finding the time..
Btw I know of a few good code editors but I'm interested to find out which image editors are available and which you would recommend.
Logged
me
GMbed 2.0 :: Embed you gm games in websites.
Offline (Male) Josh @ Dreamland
Reply #4 Posted on: January 21, 2014, 09:53:26 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
Reusing the code base would definitely be easier, but might introduce unnecessary overhead since the components are no longer on separate machines (resource manager, compiler, IDE).

I don't think that a JavaScript checker is suitable for doing any checking on EDL. EDL has types, for starters.

Reviewing the image editors I have seen in the past, none of them offer flood fill, and many of them are based on HTML entities rather than pixels. So they're not, in fact, great candidates for this IDE. So apparently, there is work left to be done on them. As far as the code editor is concerned, Ace seems to be your best bet. It already supports code completion and everything, though another concern is getting all the code completion definitions in.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TGMG
Reply #5 Posted on: January 22, 2014, 03:27:34 AM

Developer
Joined: Jun 2008
Posts: 107

View Profile WWW Email
I was hoping to just generate a static page for all the built in completions that only change when updating enigma (so the page can be cached) and send various project specific completions in a way that it can be stored on the client and updated when needed.

Sorry I didn't mean using a JavaScript parser to check EDL I meant implementing a basic parser (in antlr) which exports to JavaScript. When that success it can call the server for further analysis. It would check for specific basic problems such has missing an operator to give the user feedback as they type. It is to save calls to the server.

Thanks for that, that's not exactly what I wanted to hear about image editors :p but I agree with ace but also looking at code mirror.

Here are the main components I was thinking:
File sever: all this does is send yaml data for the resource when requested by the client via a URL (any web server, Dropbox API or local file system)
Enigma server: takes requests to parse files (via urls) and compile the game, executing the game will depend on the file server (local can just run).
Interface: calls to the file server to get list of all resources then when a user wants to edit a specific resource it requests the data from file server, also calls the enigma server for syntax checking, compiling etc
Logged
me
GMbed 2.0 :: Embed you gm games in websites.
Offline (Male) Josh @ Dreamland
Reply #6 Posted on: January 22, 2014, 10:17:03 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2956

View Profile Email
A static page is doable; JDI can generate that, no sweat.

As for Bison... you might be better off just emscripten'ing the piece of the compiler that actually builds the AST. If that succeeds, the code at least checks out from a context-free perspective.

I think a good approach to those server models is to code the libraries as though they are to be used natively (ie, application→library), then instead, code a new library that calls a remote application to work with them (application→networking library → server application→library), so that the actual code for the file and ENIGMA server isn't actually aware it's ever remote.

Also, keep plans for multiple ENIGMA servers at heart—if a server is doing the compiling, there's no reason not to have a farm of (virtual) servers running each OS. That way you can build for all, on-demand.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Pages: 1
  Print