Josh @ Dreamland
|
|
Posted on: January 20, 2014, 12:26:29 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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
|
|
|
TGMG
|
|
Reply #1 Posted on: January 20, 2014, 02:33:45 pm |
|
|
Joined: Jun 2008
Posts: 107
|
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.htmlchromiumEmbeded: 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
|
meGMbed 2.0 :: Embed you gm games in websites.
|
|
|
Josh @ Dreamland
|
|
Reply #2 Posted on: January 20, 2014, 03:01:31 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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
|
|
|
|
Josh @ Dreamland
|
|
Reply #4 Posted on: January 21, 2014, 09:53:26 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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
|
|
|
|
Josh @ Dreamland
|
|
Reply #6 Posted on: January 22, 2014, 10:17:03 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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
|
|
|
|