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 
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.
Has anyone here tried the Myra.UI interface package? It seems fairly straight forward to use…
This sentence says it all, this is something we don’t talk that much openly.
The price we pay as software developpers.
Writing softwares is so hard
10 years developper here. got burnt countless times.
1 Like
I appreciate you willing to have a mature conversation about this. Thank you.
I know OSS is a thankless job most of the time. You’re right, the potential for people to contribute is always there but unfortunately not always as much as the creator would like. The more popular the software is the more likely people will contribute. I think for me I’m just trying to help give advice on how to make it more popular. Would it make 100’s of people come out of the woods and contribute, probably not. Would it encourage a few more people like myself to do so, maybe.
Either way we all appreciate the work you guys do, even if we don’t say it all the time.
2 Likes
@craftworkgames @1stAnd10 I actually have started hacking into the MonoGame.Extended.UI a while ago. I’d say sure making GUI library is hard, which I believe you agree with me 
.
I think I’m going to write a quick guide and a summary of my findings in the Extended category. Once we have a common ground then we can convince more people to contribute, or at least have an agreement on the direction the library would take.
1 Like
Looking forward to seeing what you come up with.
Only want to throw in my unfinished approach of recreating the legacy Unity3D GUI for MonoGame
1 Like
I know this is an old post but I wanted to shout out Empty Keys. Give yourself some time to learn WPF and you won’t regret it. Hands down my favorite UI.
I have started my own UI Framework, the code can be found on GitHub: https://github.com/Apostolique/AposGui
Information about my design choices are in the wiki: https://github.com/Apostolique/AposGui/wiki/GUI-design-choices
Right now, I support mouse, keyboard, gamepad.
Empty Keys UI 3.1 is out - https://www.nuget.org/packages/EmptyKeysUI_MonoGame/
- Library ported to .NET Standard 2.0
- Compatible with MonoGame 3.7
- Added support for Dispatcher
- Fixed auto layout issue for Grid
- Added auto scroll to selected item feature for ListBox
2 Likes
Nice I will try it
What happened to the first Empty Keys video on your YouTube channel? It’s currently set to private and I assume that’s the “Hello World” intro tutorial. I’m trying to figure out how to use Empty Keys and I can’t any other basic instructions.
It was bit obsolete, but you can find simple example on GitHub https://github.com/EmptyKeys/UI_Examples/tree/master/Empty_Example
Yeah, that’s how I’m trying to work out how to use it. If I get stuck I’ll come back here.
Id rather see a ui library as a addable project in pure c# / monogame.
But i like most of them about as much as i liked my old one.
I actually keep rewriting one i have been working on and off , of for a long time.
But i keep throwing it out and starting over.
It is the curse of a games programmer.
You think you need a new GUI, so you spend a couple of days looking around at what is available, decide none of them are quite right, and start writing your own … again…
I have been writing games for 40 years, and I have probably wrote at least 50 GUI’s
1 Like
My UI library is designed as a core to build your own UI on top. Perhaps you won’t need to build so many UIs anymore.
I can answer questions if you are suspicious.
In my game, I created this fancy Integer input box built on Apos.Gui: https://gfycat.com/ultimatecomfortablefurseal
I can use backspace and delete to remove characters in front or behind the cursor. I can write integers with any keyboard input layouts. I can use the scrollwheel on my mouse along with up and down arrows on my keyboard to increase or decrease the numbers. I can also use my mouse to move the cursor: https://gfycat.com/smoggycomplexblackrussianterrier
That’s just an example of a custom component.
I know this feeling well 
The GUI system in MonoGame.Extended is probably in it’s 3rd iteration and to be honest we’re still not happy with it. I’ve already got plenty of ideas for the next version.
I probably made a least a dozen GUI’s before I even started working on the one in MonoGame.Extended. Writing a really good GUI system is just… hard.