I hope everyones vacations are going well. I am working on a new project and because of it I starter working on a library to make Babylon GUI in XML.
The most annoying and bothersome process in game development in BABYLON, for me at least, is designing the GUI in javascript. This is particularly true in bigger projects.
My basic idea is to be able to write all the GUI elements in XML and then handle the interactions in javascript . We should be able to add elements, attributes, events in XML and then easily handle the dynamic interactions in JS.
I have just started and am in the midst of writing the XML to BABYLON.Gui parser. Is there anything I should have in mind? Do you guys have any suggestions in how the UX in using the library should be? I am open for suggestions.
Easier in implementation yes, but I think JSON gets real ugly real quick if you start designing a big GUI file. Don’t you think so? Complex layouts in my opinion are cleaner in XML.
It should not be very hard to add a JSON parser as well on top of it. This way everyone can use whatever they please. I think this should be fairly easy and quick to implement in general so adding a second parser should be easy.
But it’s a more than valid point so thanks for asking. We also discussed this with Deltakosh in a different thread. The best solution in my opinion would be to support both but XML for UI is much better/ cleaner than JSON.
Agreed. A GUI designer is always better, however, I would personally prefer a GUI designer which outputs a modifiable / usable file. if what is output is JSON or XML which is then parsed into JS for use in specific projects would make it very cool!
Anyway, this is what I have so far. I am not sure whether I have forgot anything. I have attributes, child controls and events down. The Grid was a little bit more complex but I was already expecting it. Will have to check for any special cases which are still not handled. If all good will make a github repo soon .
Hi gang. I’m an XML junkie too, but… look at the numbers. Total bytes of XML file will be about quadruple size of JS for same project… cuz of the tag names. Now add in time and size of parser/pre-process, and labor, and tips, and donation to xmas party… and we’re lookin’ at a pretty big bill.
One cool thing. If everything works right, a stylesheet could be applied to the XML file… to display it in HTML, too. Why anyone would want to do that, I dunno. With a GRUESOME stylesheet, it could be displayed in SVG, too… and all from the same XML file.
Next, someone is going to say “Hey, what about an entire BJS scene… from an XML file?” Then we’re ALL in trouble. Babylon Scenegraph Markup Language v0.1 (BSML.dtd) Yuh, yuh, yuh, ahem.
You could also build your own GUI script language/interpretter… in JS. GUIscript 1.0. High level. Just feed sentence-like text to it, and it builds GUI.
Thank you for your input. I have been thinking about the bill you mention as well, more specifically in the parser/pre-process, labor and all the donations. However I feel this will not differ much from JSON ( Not sure if you are comparing ) . I agree for huge layouts you will save a couple of bytes, but, is it worth it? In the end it comes down to simplicity of usage over performance. If someone wants full performance they should skip the loader, it makes sense to do so, but would anyone do that? Also, this would be just a one-time fee. You would only need to parse a layout only once.
I don’t know about GUIscript, I would have to check it up. But, as I see it, it’s not possible to avoid the parsing. It’s the bill we have to pay for having a human usable layout to build GUI’s on. I believe this stands true no matter the format. However, I have a first version already done and ready to be published. Hopefully this will help us understand if it’s really worth it and how it can be improved.
guiScript is just something I made-up… and yes, same parsing… in fact even more… due to string munging “the goods” out-of the “sentences”. Essentially, it would turn paragraph… to gui… munge-regexp fest. It would be painful… Eliza meets GUI.
The other stuff you said… I agree. But many would say… if you MUST stare at text, they’d rather stare at 10 tons of JS than at 40 tons of XML. Not sure.
Are you going to make XML tagnames match JS property names, wherever possible? Probably so. Interesting project, thanks for telling us about it. I enjoyed looking-at your earlier “gxml” paste… looks good. Case-insensitive like a good xml should? Make a .dtd too, so we can run the XML thru a validator? (ahem)
Haha I honestly believed guiScript was real , didn’t put much thought into it, good one .
Maybe it was the way I have built GUI in Babylon, but everytime I had to make a new layout I wanted to kill myself. No kidding. It was horrific, organizing the code and making it reusable, dynamic, scalable. As I am on the verge of starting a new project, I didn’t want to go back and suffer. Working on this was a must for me, otherwise, no new project .
Almost everything matches. Except for the Grid Row and Columns, I have put some conventions there, the rest follows BABYLON.GUI namings. It should be fairly easy, besides the Grid which has a couple of rules, the rest can be done very easily just by following the BABYLON.GUI documentation. The less conventions and rules the better, only where needed. This also means less needs for maintenance. Besides the events ( obviously ) and some properties like Control.horizontalAlignment which needs to be parsed in order to get the value, the rest is just strings parser side.
Any set/getAttribute? Any <param> elements? Are you planning on “laying it into” the real dom tree… as maybe a <foreignObject>… and that way user can do DOM addChild/removeChild/etc dom commands on it, and then maybe have it re-parse after changes?
Sorry, so many questions.
I just looked at your paste again. Lots of attributes. No child param tags like an HTML object element might use. Good… I think. I never really wrapped my head around html param tags. Key-value setters, I guess.
For now I have only a getNodeById ( Thats why there is an ID there ) and a getNodes functions. The first returns a node, by ID ( obviously ) and the second retrieves the array with all nodes. All the nodes are parsed Controls. I am not sure what else could be useful for now. Maybe being able to retrieve elements by more than the ID.
Laying into the real dom tree, would it help ? I don’t see much benefit to be honest. Adding and Removing Nodes is already there, its the addControl and removeControl functions. These are already provided by BABYLON.GUI. All the DOM-like interactions are already there. These should remain separate in my opinion, the Loader should simply be able to parse complex layouts from XML to JS. After that, the old way of interacting should apply. I am open to change my mind nevertheless
Quick update, got a first working version at GitHub - Null0924/GUILoader: XML GUILoader for BabylonJS . I have tested this with TextBlocks, Rectangles, Grids, Images but I think it should work with every element. Probably it needs to be tested in a real project setting. I will diligently do so later on. What I already know, is that there are some exceptions to be handled more gracefully but I will deal with them later. For now, I am open to suggestions.
.
Make a .dtd too, so we can run the XML thru a validator? (ahem)
, didn’t put much thought into it, good one 
.