Markup format (think QML) to create GUIs
sinni800 opened this issue · comments
I would love if some sort of markup format (XML maybe) would be usable to create GUIs.
This way we could actually serialize GUIs into a format like this and deserialize them back. GUIs could be sent over the network and displayed somewhere else without having to painstakingly build it up on the other side.
XML would be a better format here since we could do
<panel id="pnl"> <button id="btn" /> </panel>
Instead of having to do
{ type: "panel", id: "pnl", children: [ { type: "button", id: "btn" } ] }
This sort of thing always seemed to me like the inner platform effect showing it's ugly head. Besides, there is a go-qml implementation already available.
@binaryblade Well, I like this because it allows me to cleanly seperate GUI and logic. Besides, HTML is basically the same. Presentation, Logic...
@sinni800 I don't see why the introduction of a separate language is needed for this.
I agree with @binaryblade.
"Templates separate technologies, not concerns."
@binaryblade How would you do this then? Go produces huge executables.
I know what the answer is, "just don't do it at all", keep being boring and just send people more executables.
Also how does the qml implementation help any if I want a gui that isn't dependant on something like qt being casually there? IMHO while I know that go produces huge executables, that doesn't mean I have to pile on top to get a 50mb distribution.
@ngrilly Is this suggesting that we lock out every NoScript user ever? I know that's not the topic, but man. It still makes sense, I would actually favor something different now (Yeah, yeah,, inner platform effect): An interface to mutate forms from an interpreted language, maybe http://github.com/robertkrimen/otto or rather https://github.com/robertkrimen/natto.
Hi,
I'm reluctant to add a serialized UI format to the core GXUI package. The reasons being:
- Binding between the code and the UI is always kludgy and error prone. You either go down the path of looking up controls by name (usually by string), which is a runtime error waiting to happen - or have compile-time identifiers generated by some build tool. The latter requires the code and data to be kept in sync, and an identifier .go file to be generated (where you might as well have generated the entire UI setup logic in Go).
- These languages usually start simple, with just control nesting and property assignment, but nearly always start feature-creeping with data-binding and inline event handling. Before you know it, you have a language that requires an entire book to describe the language and features.
- One of the big wins for separating logic from data is that you can update your data without lengthy rebuilds of your code - this is simply not an issue with go.
With all that said, I'm not opposed to someone implementing such a thing - it just does not belong as a core component of GXUI.
@sinni800 - part of your argument was:
GUIs could be sent over the network and displayed somewhere else without having to painstakingly build it up on the other side.
Do you have any real-world examples of where you'd want to do this? Have you seen @shurcooL's WebGL renderer?
I understand that GXUI requires a designer, and I had started experimenting on such a thing. My thoughts were that the designer could generate (and parse) .go files that contain:
- a
structrepresenting the root of the designed widget - a constructor function that would construct the child Controls, assign properties, hook up events to methods and return the root.
Regular logic handling could then be placed in another .go file in the same package that implements the necessary methods on the generated struct.
Alas, work and personal circumstances mean I haven't had much time to focus on GXUI lately, but I'm eager to get back on this when time permits.
Binding between the code and the UI is always kludgy and error prone.
I can see that... Even Microsoft didn't do it at first (WinForms), but rather generated code all the time (.designer.cs) with a warning not to edit it.
but nearly always start feature-creeping with data-binding and inline event handling.
Well, you'd have to limit yourself to controls and their properties... I can see how XAML really went wrong here.
update your data without lengthy rebuilds of your code - this is simply not an issue with go.
Right, but this always means a recompile. With some, especially permanently running applications or web services...
Do you have any real-world examples of where you'd want to do this?
Well I know some real world examples where it is executed really well. Maybe not with a language like XAML (I even tried doing this with XAML, it was very cumbersome... Not recommended, there's too much automatic coupling to redo it yourself), but rather just code. One would be SAP, one of the most successful ERP solutions ever. Their core is built around sending GUIs over the network and handling their events in a mix of server side logic and client side logic.
I understand that GXUI requires a designer, and I had started experimenting on such a thing.
This would be cool too, and I think that would rectify most of the problem. I thought a declarative language like JSON would be better in creating GUI controls just because it's declarative and optimized around declaring data.
Regular logic handling could then be placed in another .go file in the same package that implements the necessary methods on the generated struct.
This is basically how .NET WinForms does it, this is the file you write in and leave the generated one alone mostly because it's very hard to change it without the designer breaking :(
generate (and parse) .go files
This would rectify the part where you have to leave it alone, it would actually read your additions.
Have you seen @shurcooL's WebGL renderer?
That would be pretty cool, actually... Would still need an exit and a recompile to deliver a new functionality (okay, I am way too hurt about restarting an app :) ). But at least I don't have to deliver 13 MB of executable every time (because my target audience wouldn't go and recompile software).
Another idea I had (and actually executed, and kinda made to work!) is using otto (https://github.com/robertkrimen/otto) to do the UI and much of the client side event handling. It would really basically be an inner platform but Javascript can be sent and executed. I wish go had such a functionality (to dynamically add code in a running exeuctable, one way or another, dynamic binding or whatever), but that doesn't seem like it's in the pipeline anywhere close.
@ben-clayton Were you thinking something along the lines of this? Doing the layouts is a bit clunky without a struct annotation as opposed to a struct field annotation. I think with perhaps a smarter use of annotations the Go type hierarchy can be the complete declarative description and used in much the same way as QML or others.
I think instead of using markup format we can just use structs like this library https://github.com/lxn/walk does .. seems easier to integrate and also has type checking ...
That actually looks pretty sexy.
I'm thinking of setting some time aside to work on an XML view format for GXUI; I know a good developer will properly separate concerns regardless of technological choices but I love writing GUIs as declaratively as possible.
I'll keep you posted!
I agree that it shouldn't be part of the core project though.