UI Frameworks

Following the advice of @GeonBit, I’ll promote my library here too.
Myra is open-source(MIT licensed) MonoGame(FNA support is on its way) GUI Library.
It has following pros:

  • Ease of deployment. Myra is the PCL assembly. And theoretically could be added to any MonoGame project. Therefore it is available in the NuGet and in the MSI binary distrbution form. Later I’ll add also ZIP binary distribution for the Linux development environment.
  • Rich choice of widgets. Myra is aimed to provide widgets not only for the actual game, but for the level editor as well. Right now, it has following widgets: TextBlock(aka Label), TextField(editable text), Image, SplitPane, Button, ScrollPane, Grid, Menu, Tree, Slider, ListBox, ComboBox, Window. SpinButton will be added too.
  • Standalone UI editor. Myra’s binary distribution contains the standalone UI Editor application, which could be used to draw the UI. It’s screenshot is attached to this post.
  • Styling support. Myra widgets has full support for custom styling. Customization can be done either in code or by providing custom JSON.

Unfortunately cons list is also considerable:

  • The library is quite young and has many bugs.
  • The documentation is very poor: https://github.com/rds1983/Myra/wiki. Though I hope to fix it eventually.
  • The library API might be complicated. Especially it is true for the layout.
  • It avoids using the Content Pipeline. Which might be confusing for MG developers that are used to it.

This is the offical Myra thread: Myra - UI Library for the MonoGame

I’ll make sure the top post there contains link to the latest release. Also I’ll try to answer all questions there.

Thanks.

2 Likes

I really like Myra so far and have already been using it for my game. I think the approach taken is correct; Simplicity, lean, natural. No excessive flashy show-off IOC MVVM stuff here - you can just focus on getting simple UI’s up and running pretty quickly. Thats all thats needed for most games. Its also installs correctly and is easy to update with Nuget.

Yup, looks good for the first version (beta or whatever). Both Myra and GeonBit are promising, tho still missing some advanced features, which are really needed for game dev. I hope that authors will keep working on it, that is the hardest thing. So keep working on it guys!

This one may also be interesting for game’s menus, config, etc.

1 Like

Bumping with some exciting updates since I first posted GeonBit.UI, which was pretty long ago (lots of updates in between but I didn’t want to bump too often)…

GeonBit.UI is now at version 2.0.1.0 which includes render targets, lots of bug fixes, optimizations, some new entities (like panels tab), scrollable panels and clipping mode, better API, and most importantly: a NuGet package :wink:

You can grab it here:

And here’s a comic to summaries this whole thread (myself included):

6 Likes

Empty Keys UI v3.0 has been released, DPI love, fixed bugs and some new features. The library was updated to MonoGame 3.6.

Release Notes: http://emptykeys.com/Community/aft/11/afc/2198
NuGets: http://www.nuget.org/profiles/EmptyKeys

BTW It has been three years since I started working on it. The MonoGame version of the lib has over 5k downloads!

6 Likes

With so many options for making (G)UIs for our MonoGame applications, perhaps it might be interesting to make a comparison post/guide to make it easier for developers to choose a UI framework.

Does anyone know if anyone is already working on something like that? If not, I might be willing to take up the task, though I don’t have a lot of spare time at the moment.

I did find this list of UI frameworks: What are you guys using for UI? Looking for a simple UI for MonoGame., but it’s hardly a good comparison. For example it doesn’t say anything about ease-of-use or features, which are things I would expect in a comparison.

2 Likes

I agree this would be nice. Not just for users, but also for the developers to know how to improve their lib.

I put that original GUI spreadsheet together a while back. It was never really intended to be a proper comparison. It’s mostly just a list to get some idea of what’s out there.

I put it together when we were considering how to include a GUI package into MonoGame.Extended. The result of which we ended up porting Nuclex and I also started working on one from scratch which I’m still working on, but making decent progress.

There’s been one or two pop up since I originally created the spreadsheet but as far as I’m aware it’s a pretty complete list. It’s certainly a good starting point if you’re going to do a write up about MonoGame UI frameworks. Feel free to take it and use it however you like.

It’s always good to have more people creating blog posts or resources about MonoGame libraries. Aside from the time it’ll take to create something like that there’s really no downside to throwing stuff like that on the internet. Just be sure to post a link back here when you’re done.

Microsoft now OWNS xamarin so if you don’t want to be left behind fix mono game real quick before Microsoft does, bugs in opentk (android full screen) will soon be fixed inside xamarin/visualstudio18 if you want to open source develop I suggest you hurry, xamarins NEW pages telling us about D.I.P. help along way to getting screen resolutions on an android device? I thought monogame was going to be helpful, Microsoft give there community away for free and it’s good stuff, i’ll stick with monogame if they can answer one question AND ITS BEEN TESTED.
ANDROID ONLY
graphics.IsFullscreen=true;
ON ANDROID GIVES ME A FULL SCREEN?

@Paul_Crawley, you appear to be under the impression that MonoGame is now under the control of Microsoft. This is not the case. Xamarin did not own MonoGame at any time, and therefore Microsoft has no ownership of MonoGame. Some members of Microsoft have contributed code which goes through the same pull request/review process as everyone else. There is no “the sky is falling” happening here.

To answer your question, it does give you a full screen, i.e. no title bar and no soft buttons, at least the last time I checked it. Platforms do change however, so if an Android update has changed things, and this has happened before, it can be fixed, either by yourself or someone else in the community and submit a pull request with the changes.

not under any impression that Microsoft owns monogame, I know they don’t, they do own Xamarin now, latest Xamarin runs inside visual studio 2017 and Xamarin studio no longer works if you have VS 2017 installed.
I was pointing out that monogame claims to be cross platform, so setting a screen resolution of 800x600 on windows and setting a background picture (texture) should it not work on all platforms using the same commands, in the case of android it doesn’t.
to be truly cross platform shouldn’t the same code work the same way and be handled in the background? Try the code yourself, make a windows full screen mode of 800x600 on windows, use the same code for android, you’ll have an 800x600 box that DOES NOT cover the full screen (THE ENTIRE SCREEN!!!) as I been saying all along !!!

Spent the last two hours looking at UI Empty Keys,Mira and GeonBit UI.
And feel kind of lost right now. A solid and established UI library is really one of the things lacking.

1 Like

If you have any specific issues or need help with GeonBit feel free to PM me or open a ticket on github. building UI ain’t easy and feedback is always useful :slight_smile:

1 Like

There’s an entire Monogame.Extended.GUI framework and not an ounce of documentation (that I can find) around how to use it. So frustrating.

The GUI system in MonoGame.Extended is still very much a work in progress (and not currently top priority). Some parts of it work okay, other parts are still only half implemented.

I realize it’s frustrating when things are not complete and fully documented. If I knew of a way to snap my fingers and make it all happen I would.

Consider on the other hand what is done. A completely free, open source library that anyone can download, modify, dissect and use however they see fit. Anyone can spend the time to complete the unfinished bits, document the finished bits or just use it as a starting point for their own GUI system.

Literally hundreds of hours have already been put into it by myself and other contributors. We don’t get paid (the little bit that comes from Patreon helps cover some costs thanks to the supporters) but most of the work is purely driven by a passion for game development.

I love making libraries and tools to help other’s make games. That’s my passion, and I hope I can continue to get better at it. I’m always looking for ways to find more time to spend on it and new ways I can use that time more effectively.

Writing better documentation is something I’d really like to do. I haven’t found an effective way to do that yet.

I really hope I don’t come across as a jerk writing this. Honestly, I almost didn’t post it. Instead I hope it provides some insight into the frustrations I’ve been dealing with for the past couple of years.

Not at all, and I appreciate the dialogue.

I think one difference is, and perhaps I’m misinterpreting your feedback but based on it, it seems to me you see yourself as the only one who can work on this or get it done. The glory of OSS is that you can leverage the power of the mass to collectively work on, squash bugs and progress a piece of software.

My frustration is whoever wrote the GUI framework could create a simple piece of documentation in 5-10 minutes (I’m not expecting 50 pages or anything) with a simple explanation of use or just showing what objects are dependent on other objects that could save someone like me looking to check it out, hours of time. So with 0 documentation, nobody uses it and then the entire reason to open source it is lost. If nobody uses it, it might as well be on your hard drive kept away from everyone.

I would love to use it, contribute to it and make it better but if I can’t even get started I can’t help you. Neither can anyone else. That’s the point of OSS. Collectively creating software that’s better than one person could do is the point of this entire thing. Just my $.02

Spent some time on GeonBit UI, and is currently the best choice for sure.
It’s the most complete solution and very well documented.

I just wish more involvement from the Monogame Community helping to improve it

1 Like

In my experience it’s easier said than done. I started MonoGame.Extended nearly 2 years ago and in that time 48 people have contributed to the project. I appreciate the help of every one of those people. Thank you all.

What people often don’t realize is that creating a successful open source project is a lot of hard work. Simply throwing some code up on github is not good enough. Countless hours have gone into promoting the project. Talking about it on forums, answering questions, blog posts, tweets, merging pull requests, discussing designs and so on…

So yes, you can “leverage the power of the mass” but it’s certainly not easy

I wrote the GUI framework. Funnily enough I actually agree with you. Documentation is important and super helpful. We’ve all been on the receiving end of open source software that has very little documentation. It sucks.

The truth is, I worked on the GUI framework for a couple of months and I got burnt out. I had every intention of finishing it including documentation but I didn’t. Honestly, I’m not proud of it. I’d love to say I finish everything I start but the sad truth is I’m only human. Sometimes I make mistakes, sometimes I fail and not everything I do goes according to plan.

The previous paragraph is a little negative. Luckily, I’m generally a glass half full kind of guy. The good news is that making mistakes and failing is the only way to learn. I think I’ve learned a few things from my previous attempt and I have some ideas on how I’d approach it next time. Hopefully next time I’ll do a better job at not get burnt out and maybe I’ll even write a little documentation :wink:

Okay, let’s see. Well, I’ve already spent more than 10 minutes writing out this post. Maybe I’m just a bit slow gathering my thoughts tonight. What can I do in a few more minutes.

The place to get started would be the GuiDemo code in the repository.

Add some code like this to LoadContent:

        var titleScreen = GuiScreen.FromFile(Content, @"Content/title-screen.json");
        var guiRenderer = new GuiSpriteBatchRenderer(GraphicsDevice, _camera.GetViewMatrix);
        _guiSystem = new GuiSystem(_viewportAdapter, guiRenderer) { Screens = { titleScreen } };

        var quitButton = titleScreen.FindControl<GuiButton>("QuitButton");
        quitButton.Clicked += (sender, args) => _game.Back();

And call _guiSystem.Update(gameTime); and _guiSystem.Draw(gameTime); in the Update and Draw methods respectively.

Of course there’s also the json documents to explain but hopefully the demo will provide enough of a starting point.

I really do appreciate the help. I’m sure there’s more I could be doing to make it easier for contributors to contribute. I always take feedback seriously and I’ll definitely take it into consideration as we move forward.

Lastly, even though there’s a handful of other GUI frameworks, each with their own pros and cons, I still believe in the reasons why I started MonoGame.Extended.Gui in the first place. I’d love to bring it to completion some day. Its in the to-do list.

2 Likes

My real thing with this is everytime i try to start making my own.

It is the simple difficulty of what to use as the basis for all the buttons to make it extendable and flexible i find that these two in the case of a button class always seem to be counter to each other…

Do you guys go with a interface a base class or what pattern do you go with ? and why ?

I find if i go with a base class it keeps getting bigger as the number of different types of buttons i want to add grow as the requirements to keep it in a partitionable list that is still flexible make it so the base class has extra stuff previous buttons don’t require. So i just feel like im making slop. To boot there is the requirement for me that it doesn’t create garbage and be in a collision grid.