Constructing full screens at runtime from small XAML files
Heya,
I've got a question regarding UI/screen creation at runtime:
In our game, we will not code full screens in XAML (at least not normally). Instead, we want to have single elements like buttons, a window, image-holder, text fields, etc. all in separate XAML files and convert those to noesis format and then deliver those with the game.
Then, in the game, Lua-scripts will be responsible for bringing it all together, something like this (in pseudocode):
This will allow us to have a very dynamic UI and also a UI that modders can use to create their own screens if needed without having to learn XAML. As that is something we really do not want to force upon players & modders. Also, I don't even know if we were allowed to deliver the NoesisGUI binary creation tools with the game.
Now to the question:
Is that even possible?
I mean, loading single elements like a button from XAML, then putting them together at runtime.
And if so, how?
I've got a question regarding UI/screen creation at runtime:
In our game, we will not code full screens in XAML (at least not normally). Instead, we want to have single elements like buttons, a window, image-holder, text fields, etc. all in separate XAML files and convert those to noesis format and then deliver those with the game.
Then, in the game, Lua-scripts will be responsible for bringing it all together, something like this (in pseudocode):
Code: Select all
// "ThisWindow" is a XAML that defines an empty window
window = CreateNewWindow("ThisWindow")
window:SetLayout("Vertical")
// "MyTextField" is a XAML that defines an empty text field, 80 means it covers 80% of the window
textField = window:addTextField("MyTextField", 80.0)
button = window:addButton("MyButton", 20.0, triggeredCallbackFunction)
ShowWindow(window)Now to the question:
Is that even possible?
I mean, loading single elements like a button from XAML, then putting them together at runtime.
And if so, how?
Re: Constructing full screens at runtime from small XAML fil
Yes, it can be done. XAML is nothing more than a serialization format. So, the following XAML:
is equivalent to the following code:
And that button can be later added to a panel for example.
Having said that, I don't know if what you are proposing is a good idea because you are going to lose the layout features of noesisGUI. At first, I would say that you are going to reinvent the wheel by designing a new meta language for that. Why not using XAML also for that?
Code: Select all
<Button Content="Click Me!"/>
Code: Select all
Ptr<Button> button = *new Button();
button->SetContent("Click Me!");
Having said that, I don't know if what you are proposing is a good idea because you are going to lose the layout features of noesisGUI. At first, I would say that you are going to reinvent the wheel by designing a new meta language for that. Why not using XAML also for that?
Re: Constructing full screens at runtime from small XAML fil
Of course, we could use XAML to design a screen. But that would not allow us to dynamically change screens at runtime via script.
And we need to do that, plus we already have a scripting language that is capable of everything (Lua) where we need to write a lot of functions anyway, why not use it for the purpose of initially creating the screen, too?
Also, as I already said, it allows us to define our own methods, etc. which will be MUCH easier to write than XAML for any scripter (as almost nobody knows this format). So we can integrate it much better in our workflow.
And I do not see where we would lose the layouting of NoesisGUI. If anything that can be done by parsing a XAML file can be done at runtime (and I guess that this is possible) we can do anything. It will probably be slower, but this will be done rarely so it does not really matter.
It would be different maybe if NoesisGUI could parse XAML at runtime (and not the binary format), but afaik that is not possible yet. As it is now we have the choice between implementing an additional parser for XAML AND implementing additional commands for UI in Lua or just do everything in Lua.
And Lua rocks, so...
And we need to do that, plus we already have a scripting language that is capable of everything (Lua) where we need to write a lot of functions anyway, why not use it for the purpose of initially creating the screen, too?
Also, as I already said, it allows us to define our own methods, etc. which will be MUCH easier to write than XAML for any scripter (as almost nobody knows this format). So we can integrate it much better in our workflow.
And I do not see where we would lose the layouting of NoesisGUI. If anything that can be done by parsing a XAML file can be done at runtime (and I guess that this is possible) we can do anything. It will probably be slower, but this will be done rarely so it does not really matter.
It would be different maybe if NoesisGUI could parse XAML at runtime (and not the binary format), but afaik that is not possible yet. As it is now we have the choice between implementing an additional parser for XAML AND implementing additional commands for UI in Lua or just do everything in Lua.
And Lua rocks, so...
Re: Constructing full screens at runtime from small XAML fil
I think that XAML is easy to understand, at least the basic things like simple layout, putting buttons, text, paths. You can google the internet for almost everything. What you are doing is creating a new abstraction on top of XAML that will be probably more limited that the XAML itself.Also, as I already said, it allows us to define our own methods, etc. which will be MUCH easier to write than XAML for any scripter (as almost nobody knows this format). So we can integrate it much better in our workflow.
I would allow my modders writing XAMLs directly, not for the fullscreen but for a constrained region in the screen where mods can be shown.
No no, you can use the parser at runtime. There are several options:It would be different maybe if NoesisGUI could parse XAML at runtime (and not the binary format), but afaik that is not possible yet. As it is now we have the choice between implementing an additional parser for XAML AND implementing additional commands for UI in Lua or just do everything in Lua.
And Lua rocks, so...
- As you have access to the source code, you can incorporate the XamlParser directly in your runtime. The interface has been improved in v1.2
- You can use the BuildTool and distribute it with your game SDK for modders. This is probably the option I would choose. In v1.2 the BuildTool is easier to use, we have simplified a lot of things.
Re: Constructing full screens at runtime from small XAML fil
You are right that our own Lua approach would be limited to whatever we need to implement. But implementing the parser to produce a direct screen instead of a binary file would be a lot of work (I guess) and we are kinda limited in what we can focus on right now.
Even though the Lua approach would be limited in functionality, it would be faster to implement for us. Unfortunately I fear we do not even have the time to take some weeks to just "try out how either way would go".
And no matter what we do, we need to modify screens at runtime in ways that may or may not be foreseeable, so we cannot hold all alternatives in full XAML screens. So our Lua interface will have to be able to do "insert element X at position Y, replacing Z, change layout", etc. in any case. That's why I think it would be easiest for us to just go all the way and add some more functions to construct a screen from the get-go.
I'd also like to have as few tools modders need to use as possible. Right now its a Blender exporter and ZeroBrane for Lua editing and with that everything can be done. Introducing XAML would be one more thing to learn (even if easy) and the BuildTool would be one more tool to handle (even if also easy).
That is not much work for us devs, but we have a BIG focus on moddability, so it has to be as easy as possible. And there is no such thing as a "limited section" on the screen where mods would go. Everything can be changed.
No perfect solution here, we'll have to talk that through with the team once we are about to implement it.
Even though the Lua approach would be limited in functionality, it would be faster to implement for us. Unfortunately I fear we do not even have the time to take some weeks to just "try out how either way would go".
And no matter what we do, we need to modify screens at runtime in ways that may or may not be foreseeable, so we cannot hold all alternatives in full XAML screens. So our Lua interface will have to be able to do "insert element X at position Y, replacing Z, change layout", etc. in any case. That's why I think it would be easiest for us to just go all the way and add some more functions to construct a screen from the get-go.
I'd also like to have as few tools modders need to use as possible. Right now its a Blender exporter and ZeroBrane for Lua editing and with that everything can be done. Introducing XAML would be one more thing to learn (even if easy) and the BuildTool would be one more tool to handle (even if also easy).
That is not much work for us devs, but we have a BIG focus on moddability, so it has to be as easy as possible. And there is no such thing as a "limited section" on the screen where mods would go. Everything can be changed.
No perfect solution here, we'll have to talk that through with the team once we are about to implement it.
Re: Constructing full screens at runtime from small XAML fil
Agree with you, there is no perfect solution. The are good points in your solution also. It is only that I doubt you will be able to create a new format that is so powerful and expressive as a block of XAML is. And for basic things, they don't need new tools. They can use a text editor and write XML directly.
Keep us informed about your solution.
Keep us informed about your solution.
Who is online
Users browsing this forum: Ahrefs [Bot] and 17 guests