Myra - UI Library for the MonoGame

Myra 0.8.8 is out.
No new features, just bug fixes.

1 Like

Myra(UI Library for MonoGame, FNA and Xenko) 0.9 is out.
That is another stabilization release without new features, but with many bug fixes.
Also MyraPad had become primary UI design tool: https://youtu.be/NZUCq2RMgZU

Important. Button had been renamed to ImageTextButton.

1 Like

Myra 0.9.1 is out.
The only new feature is the ellipsis in the TextBlock widget.
Also Myra has two major API changes:

  1. Now texture atlases and stylesheets use xml instead of json. Binary release contains two new utilities to convert old format to new.
  2. Rectangle Desktop.Bounds property had been replaced with Func<Rectangle> Desktop.BoundsFetcher, which is initially set to Func returning the entire screen(Destkop.DefaultBoundsFetcher).
    So code like:
  _desktop.Bounds = new Rectangle(0, 0, GraphicsDevice.PresentationParameters.BackBufferWidth,	
    GraphicsDevice.PresentationParameters.BackBufferHeight);

should be removed from the apps using Myra.

Myra 0.9.2 is out!
Mobile support had been added finally:

There’s yet another API change: MouseUp/MouseDown/MouseDoubleClick events had been replaced with TouchUp/TouchDown/TouchDoubleClick. Latter handle mouse clicks as well as screen touches.

1 Like

Myra 0.9.3 is out: https://github.com/rds1983/Myra/releases/tag/0.9.3.177

1 Like

Myra 0.9.4 is out: https://github.com/rds1983/Myra/releases/tag/0.9.4.180

1 Like

Myra discord server had been made: https://discord.gg/ZeHxhCY

1 Like

Myra 0.9.5 is out: https://github.com/rds1983/Myra/releases/tag/0.9.5.183

1 Like

Hey RDS. I like Myra, it’s a nice framework. I’ve been studying your source code and borrowing ideas here and there for some of my own project work. While playing around with things I came across a need to implement some focus switching/handling logic in my own game and looked to Myra source code for any inspiration.

If it wouldn’t be a problem, maybe you could enlighten me on a few details? This question also relates to using Myra itself, so this question isn’t 100% self serving and might be useful for others to know as well. : )

The way which a Window(or any Widget) handles focus generally seems to be that the Desktop environment checks its internal ‘_widgets’ observable collection and iterates through it (GetActiveWidget()) and grabs the first widget which is set IsEnabled and IsVisible.

What manner do you go about changing the active focus if there are multiple windows in the desktop environment? I did try to find an answer to this but couldn’t find anything here or in the documentation. As near as I can tell, GetActiveWidget() only ever grabs the first widget even if other windows are enabled and visible.

		for (var i = ChildrenCopy.Count - 1; i >= 0; --i)
		{
			var w = ChildrenCopy[i];
			if (w.Visible && w.Enabled)
			{
				return w;
			}
		}

^ This block here. If there are 3 active windows on the desktop, only the first one in the collection is grabbed and given input priority. The only means I see of controlling which window has current input focus(input focus meaning accepting mouse button clicks to change active window) would be to re-order the widgets in the desktop’s environment. Or, programatically setting IsEnabled to false outside the Myra API to change which windows get skipped by GetActiveWidget (is that the intended method?) Only problem with the latter method is that in order to set that window back to Enabled, it needs to know when it’s being clicked on, and I don’t see a way to natively do this as now that it’s disabled it can no longer receive any mouse events of any kind. I could circumvent the Myra API and do this with my own code, but that feels a bit like a hack and that I must be missing something.

It’s late and I’ve been awake a long time so I feel like I’m being dumb or something, lol. But if you have a minute, I’d be interested to hear from you. Thanks.

Hello Rei,
Thanks for the kind words about Myra.
I’ve refactoried that code a bit recently, so that method is now caled GetTopWidget(which describes what it does more accurately). Here how it looks:

		private Widget GetTopWidget(bool containsTouch)
		{
			for (var i = ChildrenCopy.Count - 1; i >= 0; --i)
			{
				var w = ChildrenCopy[i];
				if (w.Visible && w.Enabled &&
					(!containsTouch ||
					(containsTouch && w.Bounds.Contains(TouchPosition))))
				{
					return w;
				}
			}

			return null;
		}

So if containsTouch set to true, it’ll return any widget that contains mouse cursor(or touch position for devices). Hopefully that answers your question. :slight_smile:

p.s. Still right now, it’s not possible to have multiple windows and switch input focus beetween them. As any Window can be shown only in modal mode(see Window.ShowModal method). However method Window.Show will be added eventually.
Actually, thanks for the reminder, as I’ve created corresponding case: https://github.com/rds1983/Myra/issues/137

Ah! Okay, so it wasn’t a natively implemented feature after all. Your new method there seems like it’d do exactly what I was expecting. That would allow the sort of focus switching I was thinking about. Thanks for taking the time to answer my question.

Since it’s on my mind, I’ll take a moment to backseat program since I’ve been thinking about this. You probably already solved all these issues and are aware of them, but figured I’d throw it out there anyway.

It might be good to store a record of the most previously ‘touched/active’ widget and check that one first. My thought there is that it looks like there could be a scenario where two windows are overlapping which might cause a conflict.

Say window A and window B. Window B is visually overlayed half way over window A and is the current focus of the user. Then the mouse cursor enters into the intersection point of window A and B.

In that scenario, two widgets are viable return values in GetTopWidget(), but again only the first one iterated will returned(which may even be window A in this case, even though visually B overlays it).

An alternative would be that it checks what the current ‘touch focused’ widget is. If its bounds contain the touch, return that one. If they don’t, a new window is being touched. Set that new window as a the current active ‘touch focus’ and then return it instead.

The tricky thing is that you could still want a scenario in which window A becomes the new touch focus, but window B still has keyboard/input focus because the user hasen’t actually ‘clicked/touchedDown’ window A yet.

Also, rendering order is a thing. Rather than rendering in order of the observable collection, it might make sense to have a history of the order of previously focused widgets and render in that order instead. So if window A was the last window the user interacted with, it’s at the bottom of the list, followed by C, and finally B the currently active window.

Actually thinking out loud like this helps me a lot with my own ideas. Thanks again.

Anyway, i’ll stop rambling and presuming to code Myra in my head.

Probably if user clicks/touches a window, I’ll simply move it into the end of _widgets collection, so it’ll be returned first by GetTopWidget call.

Myra 0.9.6 is out: https://github.com/rds1983/Myra/releases/tag/0.9.6.184

1 Like

Myra 0.9.7 is out: https://github.com/rds1983/Myra/releases/tag/0.9.7.185

1 Like

Myra 0.9.8 is out: https://github.com/rds1983/Myra/releases/tag/0.9.8.188

Happy New Year!

4 Likes

Myra 0.9.9 is out: https://github.com/rds1983/Myra/releases/tag/0.9.9.198

2 Likes

New project announcement: Myra.Extended provides additional functionality for Myra. If you would like to contribute a Myra widget, feel free to PR it there: https://github.com/rds1983/Myra.Extended

Hi rds 1983

It seems that I can’t get running myra on linux. Everything works fine on Windows.

Kinds Regards
Andru

After almost 4 years of development, Myra 1.0 had been released: https://github.com/rds1983/Myra/releases/tag/1.0.0.204

Thanks everyone!

5 Likes

Congrats and well done for the milestone! :champagne: :sake:

1 Like