[GUI] Let's port or build a GUI system using these existing libraries

[craftworkgames]

There's been a lot of discussion lately about finally getting a GUI system into MonoGame.Extended. There's been a few attempts by myself and others but so far we've only got a half finished system.

Tonight I took the liberty of gathering a list of as many GUI systems as I could find that might be candidates for porting, or at the very least, a reference for inspiration.

https://docs.google.com/spreadsheets/d/1hvlqhWh2UJWL4PKDZMDCi_4BLQS4fE4Sxh6vCyhmeTg/edit?usp=sharing

This spreadsheet is shared like a wiki. If you have anything to add please do so.
(if you have trouble editing the document, let me know)

I'm going to close issue #20 and #255 by referencing them here.

Note that in #255 @Aurioch has already started work on porting Nuclex and depending on how that's going it might be the way we go. Even so I think it's a good idea to have this spreadsheet for future reference.

Also note that whatever we do we have to respect licenses. We can't steal code from other frameworks and it's respectful to get permission from the original author first.

[killerrin]

Porting over Nuclex seems like it might be the ideal way of doing this, especially if we have permission from the developer to do so.

[craftworkgames]

Yeah I agree. I think we should start by porting Nuclex (unless we run into some major blocker) and use that as a base to build upon. Getting something working end to end is the first step.

None of libraries in the spreadsheet are ideal, but they all have something interesting about them. Tomorrow I'm going to start looking at them in more detail and figuring out what features would be nice to have.

The other thing I'll like to do is take a look at how far @Aurioch has gotten with the port and help him with anything that's not working yet.

[ghost]

To be honest for me Nuclex looks like an UI built to create desktop application ui rather than game ui

libGDX scene2d is so flexible, and the table layout system is easy and powerfull to use, it makes it easier to make ui for games

I'm not really using MonoGame anymore, but i wish there was an scene2d port for it

The things that matter the most is the layout system, and how easy it is to extend existing controls, and create custom ones without pain

[craftworkgames]

libGDX scene2d is so flexible, and the table layout system is easy and powerfull to use, it makes it easier to make ui for games

Yes, I agree that the LibGDX one is a great candidate. I've used it on a previous project and I like how it works.

The way I see it, we'll probably end up starting with a straight port and then expand on it to make it our own, taking inspiration and features from others (as long as we're not breaking any licences).

I think the main reason we're looking into Nuclex is because it's already XNA based, so porting it shouldn't be too much work. It is quite old though, so it might not work out so easy.

LibGDX is Java based so there's quite a bit more code to port over. On the other hand, I believe the one in Nez is a port of LibGDX so that's probably a good place to start with that. A lot of the code in Nez actually came from MonoGame.Extended so I don't think it'll be a problem to take some back ;)

The other one that looks interesting at this stage is Squid since it's designed to be engine agnostic. I was talking with @zunath earlier today about it and he said he's used it before and it worked well.

[zunath]

I wrote some documentation on how to use Squid with FlatRedBall (XNA extension framework) last year. http://flatredball.com/documentation/tools/glue-reference/plugins/glue-gluevault-component-pages-squid-gui-integration/

I attempted to change the implementation to be XML based, but it doesn't necessarily require that. It was basically just a wrapper around the code. It shouldn't be too difficult to port over to straight MonoGame - if I have time today I can try to dig into it.

I looked at a lot of different UIs before settling on Squid. Most of them had issues with handling resizing of the window, straight up didn't work, or didn't fit the style I was going for.

I'm not opposed to Nuclex but it's one of those that I felt didn't fit the style very well. However, if someone's able to reskin it for use in MonoGame.Extended then I think that solves that problem.

I took a look at EmptyKeys last night and it had a resizing issue even in its demo project. Might be an easy fix, but it scares me when the demo itself doesn't work out of the box.

[craftworkgames]

Most of them had issues with handling resizing of the window, straight up didn't work, or didn't fit the style I was going for.

Could you explain the resizing issue a little more? I'm curious what to look for.

I'm trying out a few tonight. I haven't got to Squid yet but it's on my list and it does sound very promising.

[zunath]

So with the resizing issue, I've seen a couple major issues.

1.) After resizing the game window, the mouse positioning is not picked up correctly. It doesn't seem to be offset by the change in window size even though the rendering works as expected.
2.) With EmptyKeys in particular, resizing the window to make it smaller makes all of the controls extremely small and hard to read. It doesn't seem to have any sort of scaling mechanism in place.

[craftworkgames]

After resizing the game window, the mouse positioning is not picked up correctly. It doesn't seem to be offset by the change in window size even though the rendering works as expected.

This issue actually sounds kinda familiar. There's a similar known bug (or at least there used to be) in MonoGame when you're using the DirectX renderer. The OpenGL one doesn't have the same issue. We worked around it in MonoGame.Extended from what I recall. Maybe it's related, I dunno.

I just took a look at Nez. The UI system seems like a decent port of the LibGDX one, so that's an option. There's no UI demo that I could find, although the samples do use a basic UI menu system.

At this stage though I'm very interested in Squid. I read your blog post and I really like the way it looks.

[zunath]

Looks like that page doesn't have the sample project I built and I can't seem to find it in my stuff either.

My code here should give you a starting place though: https://github.com/zunath/Ceriyo/tree/master/Ceriyo.Library/SquidGUI

[charles-esterbrook]

I'm curious why all these things go into one monolithic library instead of being specific libraries/repositories like:

• MonoGame.Extended.UI
• MonoGame.Extended.Tiles
• etc.

Maybe I should be asking that in a separate issue, but this issue helped trigger the question.

[craftworkgames]

I'm curious why all these things go into one monolithic library instead of being specific libraries/repositories

@charles-esterbrook please ask this in a separate issue and when you do also mention why you would prefer it that way.

The short answer is, it made sense to do it that way when we first started the project. A lot has changed since then and if there's a good reason to split it up, obviously we'll do it.

[Aurioch]

Hello

Sorry for not answering anything, was busy lately.
I'm the one who started porting Nuclex to Monogame.Extended, and I've put it on halt this week due to exams and some personal issues. Will continue with my work in a day or two, if nothing's been planned else.

[craftworkgames]

@Aurioch How did you go with the Nuclex port? If the code is in a semi-working (i.e compiling) state, even if it's not finished I'd be interested to take a look.

[Aurioch]

Right now? Due to job interviews and other life-related... things, I didn't progress far. XmlHelper class I've ported, which is used for skin loading, has a lot of errors related to the fact that it's in PCL; other than that, I have managed to deal with other errors, so if you disregard XmlHelper it can be compiled. Whether it can be used though, I'm not sure as I didn't manage to test anything yet.

Tbh, whole deal with skins, as you suggested, has to be moved to the Pipeline project. I'll try to do it as soon as I'm free.

[craftworkgames]

Right now? Due to job interviews and other life-related... things, I didn't progress far.

Yeah, no worries. I know how life can take over. It happens to me all the time.

XmlHelper class I've ported, which is used for skin loading, has a lot of errors related to the fact that it's in PCL; other than that, I have managed to deal with other errors, so if you disregard XmlHelper it can be compiled.

So we've got a couple of ways we can go with this:

1. We could move the XML skin loading code the the Pipeline project. This should work and it might very well be the easiest way to get something up and running.
2. Another option is to remove the XML based skins completely and replace them with JSON based skins. Obviously this will be quite a bit more work but at least JSON.NET supports PCL's. I personally prefer JSON as a file format these days.

To be honest, I think Nuclex has some nice qualities but it also has some downsides. I think we'll probably end up pulling it apart and combining it with features from other GUI libraries to create something new.

Alternately, if you'd rather keep Nuclex true to it's original design, maybe it would be better to split it out of the core library and keep it in separate repo, kinda like I did with MonoGame.Squid.

We could call it MonoGame.Nuclex or perhaps MonoGame.Extended.Nuclex (depending on how it works). If we take this approach it technically doesn't have to be a PCL at all (of course we'd loose the benefits of PCL's but the XML skins would work).

I've actually been experimenting with another project this week that is essentially a MonoGame GUI designer tool. It's working as a concept but I don't think it'll work with Nuclex directly. That's one of the reasons I'm in favor of evolving the GUI code into our own.

[Aurioch]

I think we'll probably end up pulling it apart and combining it with features from other GUI libraries to create something new.

This is actually something I think would be best. After all, Nuclex was originally written as support for XNA, so it hard to adapt it so that it works on Monogame.Extended as it would work originally.

In any case, I'll try to move the XML stuff over to Pipeline project so that I can get Nuclex up in its original design - it will be hard to work with there's no starting point. After that, if it works, we can pull it apart and evolve into something that will be easier to expand and interact with from other parts of the codebase and projects. For example, replace XML with JSON.

[craftworkgames]

Great 😄 I'm glad we are on the same page.

[craftworkgames]

No need for this issue anymore. We've got an implementation of Nuclex and there's still some work in progress on the other GUI code as well.

[Scellow]

I ported Nez UI (wich is a port of libGDX Scene2D) to MonoGame (no Nez dependency), are you interested about it?

[craftworkgames]

I'm always interested to have a look. Do you have it in a repo somewhere?

[Scellow]

It is for the moment integrated in my Engine, i'll setup a repo once i have some free time so you'll be able to take a look :)

[craftworkgames]

Great. Is it much different from how Nez does it? I've already looked through the Nez and LibGDX code a fair bit.

[Scellow]

It is not an exact 1:1 port from original libGDX code, but in term of functionality it is pretty much the same

[craftworkgames]

Oh well, it's up to you man. If you don't have time to put it in a repo don't worry about it. Nice work though. Maybe post a screenshot in gitter if you create something cool.