How do these interfaces bind commands?

[ClEngine]

How do I export the interface binding command to these outputs?

[aienabled]

Sorry, I don't understand the question. Could you elaborate please?

[ClEngine]

var config = new NoesisConfig(Window, graphics, providerManager,
                rootXamlFilePath: "Samples/MainWindow.xaml", 
                themeXamlFilePath: "Themes/WindowsStyle.xaml",
                currentTotalGameTime: lastUpdateTotalGameTime);

Can I load interfaces in such a way? If I want to add an event to a button, what should I do?

[aienabled]

Ok, I will prepare a demo project which will make this straightforward for newcomers.
I will try to finish it in this weekend.

[ClEngine]

Are the tutorials ready?

[andrew-sidereal]

Hi @aienabled , I would really benefit from that tutorial as well, so just pinging this thread to see if there are any updates. Thank you!

[aienabled]

Alas, I was and I'm extremely busy and the demo project turned out to be much more complicated than what I expected. I've discusses the rough edges with NoesisGUI team and we have agreed on some implementation details but it will take much more time than what I've initially planned. I hope to find free time to finish this after CryoFall release.

[ClEngine]

I have been waiting for 3 months.

[andrew-sidereal]

No worries, I know how it is. In the meantime, would you be willing to point me in the direction of some learning materials so I can do independent research? It sounds like you've had a lot of success integrating Noesis GUI with MonoGame and even basics like how to structure the views in one project, copy to another, how to have your viewmodels visible and access your game code, etc., would be extremely useful. Any Git repos accomplishing this would be great, youtube videos, blog posts, whatever. I'm hunting around now but a bit lost on the best way to go about this. Thank you!

[aienabled]

@ClEngine, I'm sorry. It was very irresponsible of me to say that it will be done soon but then disappear deep in the code!

@alundgren04, with the first game (VoidExpanse, made with Unity engine) I've used an approach with the separate WPF application and copying only the XAML files with an xcopy script invoked by a Unity menu tool (no actual file sharing or symlinks). C# files needed to be recreated specifically for the game (to access the game API and because NoesisGUI uses different namespaces). Turns out it's a pretty good approach without any #if GAME/#if WPF/#if NOESIS conditional compilation stuff but you have to write the UI-related C# code twice - for the WPF UI application and for the game project itself. As a side effect, I have a complete usable WPF application demonstrating the whole UI (with some fake data) - it was also super helpful at the time when there were many bugs in NoesisGUI and I needed to ensure that it matched WPF behavior completely (gladly, the most issues were resolved years ago!).

With the second game (CryoFall, client part is using MonoGame) I took another approach - making a custom game engine with the tight integration with NoesisGUI and with the shared "scripting" game code project (an open source part of the game). The cornerstone idea is to place that shared code into a VS2017 project with XAML/WPF support linking the shim game API assembly (DRY principle - so there is no need to write the code twice as in case of VoidExpanse game). We can open that project in Visual Studio and edit all the game code and XAML files and the game will take all the code (including XAML), compile and use it with NoesisGUI and actual game "scripting" API. So all the C# code is also dynamically compiled thanks to Roslyn. It took a lot of time to implement and the game engine itself is not open source. But the game (CryoFall, currently a free alpha) is shipping with the full XAML code (and all the gameplay code and data also there in open source) so you can have a look, use it as an educational material and maybe tinker with it a bit (BTW, the game has a live reloading feature for basically everything including XAML - that's was another major idea to speed up the game development; I was very enthusiastic after watching the amazing Bret Victor's talk here https://www.youtube.com/watch?v=PUv66718DII ).
As you might guess, it's a pretty difficult approach, requiring a custom Roslyn compiler shipped with the game to preprocess C# files to make them usable with NoesisGUI; a VS plugin to properly work with a custom C# XAML project (which is actually not WPF and based on the new Project System as you can see in my another GitHub repo) which will be too overwhelming for the most game developers looking for a simple example game project for MonoGame+NoesisGUI... I've discussed the matter with NoesisGUI team and they suggested that I could implement another popular approach with the complete XAML and C# code sharing between the real game C# project and WPF UI-only project. And I've started it, but have multiple problems. For example, you will need to use a lot of #if #else conditional compilation due to namespace difference (Noesis in case of NoesisGUI vs System.Windows.Controls* in WPF; BTW NoesisGUI team confirmed they will keep it this way). So the code is not compatible "as is" (which is not an issue for my own game engine which uses Roslyn compiler to rewrite the code before compilation - including all the namespaces shenanigans). Also the UI code in WPF project can't directly access the game classes and some kind of a shared API is also required here (or, otherwise, it will require a lot of another #if GAME #else) conditional compilation. Another issue is that NoesisGUI requires manual loading of XAML - by calling LoadComponent(pathToXamlFile) - which is not required for WPF as VS automatically generates the necessary *.xaml.g.cs files during the WPF project compilation.
With my game engine I was able to solve all these problems by using the base classes and Roslyn compiler - and I'm looking for a way to make that usable for the example MonoGame project too. After discussing with the NoesisGUI team I've got an idea to simply copy *.xaml.g.cs from WPF project as they contain all the required information to at least automate the locating and loading of the XAML in the game project using NoesisGUI. And a small MSBuild tool to rewrite C# files to replace WPF namespaces with Noesis. However, it's very time consuming (especially considering that it's not useful for my own game engine and games I make) - and, as turned out later, there are still some issues with WPF API compatibility as even last NoesisGUI C# SDK has multiple API differences to WPF (which are non-present in my custom fork of NoesisGUI C# SDK... all reported to the NoesisGUI bugtracker). So the development of this approach for the example game project is stuck.

I was so relieved from most of the integration pain by using my custom game engine so I wish the best experience for other developers too - trying to communicate with NoesisGUI team and find a better approach to every integration issue... but it seems there are no quick and easy solutions and now I'm thinking that it might be the best to apply my first approach (used in VoidExpanse) with the two separate projects (game + WPF UI demo app) and only the XAML files sharing/copying. It requires writing the UI C# code twice (and keep all the changes made to each project C# code in sync, which is quite annoying), but at least that code is clean (no conditional compilation symbols) and also the WPF UI demo app project could be run separately (which also allows to live-edit the XAML code thanks to the new XAML live-editing features in VS2017).

Unfortunately, as I've mentioned above, currently I'm super limited on the free time as multiple deadlines are already missed and we have to release the game in Steam this month.

Good luck with your MonoGame+NoesisGUI research! Also please check NoesisGUI forums for more nuggets of useful information and advice.

Regards!