Just wondering - what are other people's most important features for the update after 2.2?

For me:
1. Startup speed

Then:
2. Support for languages (Arabic, Bengali, Sinhala)
3. Anti-aliased lines and no paint artifacts (I have to add 1.5 pixel gradient to all solid color shapes, e.g. circles now for "artificial AA")

Perhaps we could make a survey once we get more responses here :)

Thanks for opening this thread Nokola. By the way, in a few days we are going to definitely deprecate our Trello board in favor of the tracker. The roadmap and rest of pages are going to be the way to discover what new things are coming in the future.

Things we already have planned for next big update:

• Hot reloading
• Effects
• Support for 3D UI (integration with meshes) and VR
• A remote inspector to debug in realtime the visual tree and edit properties (this is almost finished, it is a pity it didn't make it into 2.2...)

That sounds like awesome priority. Whats the estimated time for this next big update aprox?

That sounds like awesome priority. Whats the estimated time for this next big update aprox?

Well, we didn't finish the current big update (hopefully final version is happening next week) so we didn't have time to think about the next one. But, this update has been really painful, one year working on it. In the future we would like to avoid this and have releases with more frequency, like 2.3 in a few months and so on.

3. Anti-aliased lines and no paint artifacts (I have to add 1.5 pixel gradient to all solid color shapes, e.g. circles now for "artificial AA")

Could you elaborate on this? Are you using GPU MSAA or our emulation (PPAA) ?

This is likely influenced by my own project needs, but I feel like there is a feature gap around how Noesis game controller input affects built-in Noesis user controls. Game developers represent a large share of the Noesis client base and I think this makes support for gamepad interaction important. My app is converting from UWP to Noesis and while UWP is similar to WPF, I feel that UWP introduced some very important features and capabilities with gamepad support in mind. I understand and appreciate that the stated goal of Noesis is to support the WPF spec, but I think it is worth noting that capabilities of Microsoft's UI has evolved through UWP, and some very beneficial features were added.

Here is where I feel Noesis is deficient, with respect to game (gamepad) support:

Focus Engagement (https://docs.microsoft.com/en-us/window ... cus-visual)
Focus engagement is intended to make it easier to use a gamepad or remote to interact with an app. When the property IsFocusEngagementEnabled on a FrameworkElement object is set to True, it marks the control as requiring focus engagement. This means that the user must press the A/Select button to "engage" the control and interact with it. When they are finished, they can press the B/Back button to disengage the control and navigate out of it.

Edit: Noesis has this: Version 2.1.0b16 - Enhancement Focus engagement implemented. yay!

Separation of Focus and Selection Events
I don't believe the Noesis ListBox (and ListView) distinguish between navigation through a control's selectable children and actual selection. Gamepad support in UWP means that a user may navigate through elements in a user control's collection without kicking off SelectionChanged events. When a confirm button (A on Xbox) is pressed the selection event fires. Assuming I understand this properly, this is a limitation that affects creation of things like game inventory or selections from a list. (This is also the current Noesis conversion obstacle I am currently working through). The UWP ListView allows navigation of selectable children using a gamepad without firing events until a keyboard or gamepad confirm button is pressed. If a mouse is used the user control behaves similar to a WPF control. (viewtopic.php?f=3&t=1611).

Edit: I have this working. I needed to ignore selection events and then look for KeyDown mapped to Gamepad input when a controller is used.

Focus Visual
The focus visual is a border around the UI element that currently has focus. This helps orient the user so that they can easily navigate your UI without getting lost. I believe Noesis has this worked out pretty well -- but I do have a few selectable controls where it is not happening that I carried over from UWP. I think I need modify the style with incorporation of this capability in Noesis.

UI Element Sizing (https://docs.microsoft.com/en-us/window ... ent-sizing)
Assuming it is not there in Noesis, there is likely value in exposing a similar capability. UWP provides this for what they call the 'ten foot experience', using XAML on television screens (LayoutScaling). I am using the Noesis ViewBox but this does have some limitations (viewtopic.php?f=3&t=1608).


*edited for typos
* also edited because I have worked through most, if not all challenges I initially encountered.

This is likely influenced by my own project needs, but I feel like there is a feature gap around how Noesis game controller input affects built-in Noesis user controls. Game developers represent a large share of the Noesis client base and I think this makes support for gamepad interaction important. My app is converting from UWP to Noesis and while UWP is similar to WPF, I feel that UWP introduced some very important features and capabilities with gamepad support in mind. I understand and appreciate that the stated goal of Noesis is to support the WPF spec, but I think it is worth noting that capabilities of Microsoft's UI has evolved through UWP, and some very beneficial features were added.

Thanks for your detailed post. Before answering to each point let me say that when we say we are WPF compliant it doesn't mean we only implement WPF features. We are perfectly aware of all the XAML implementations and it is not the first time we bring features from other XAML flavors like Silverlight or UWP in form of NoesisGUI extensions. We are trying to get this more organized and documented. In 2.2 we offer a NuGet package (code on Github) to bring those compatibilities to Blend projects.

Focus Engagement (https://docs.microsoft.com/en-us/window ... cus-visual)
Focus engagement is intended to make it easier to use a gamepad or remote to interact with an app. When the property IsFocusEngagementEnabled on a FrameworkElement object is set to True, it marks the control as requiring focus engagement. This means that the user must press the A/Select button to "engage" the control and interact with it. When they are finished, they can press the B/Back button to disengage the control and navigate out of it.

As you later discovered, this is fully implemented in Noesis. Our demos are compatible with only-gamepad experiences. So things like pressing 'A' to edit a slider a 'B' to stop editing should work fine. We don't have this properly documented, but soon or later there will be a tutorial about input in Noesis.

Focus Visual
The focus visual is a border around the UI element that currently has focus. This helps orient the user so that they can easily navigate your UI without getting lost. I believe Noesis has this worked out pretty well -- but I do have a few selectable controls where it is not happening that I carried over from UWP. I think I need modify the style with incorporation of this capability in Noesis.

If you find anything strange, please, don't forget to report in the tracker.

UI Element Sizing (https://docs.microsoft.com/en-us/window ... ent-sizing)
Assuming it is not there in Noesis, there is likely value in exposing a similar capability. UWP provides this for what they call the 'ten foot experience', using XAML on television screens (LayoutScaling). I am using the Noesis ViewBox but this does have some limitations (viewtopic.php?f=3&t=1608).

Not sure if this is exactly the same, but it's been requested many times to implement DPI in Noesis. A global variable that affects the scale of all UI elements. I assume this is something similar right?

Thanks again for your time.

I would say that I definitely did not initially comprehend the extent to which Noesis has adopted the best features from both WPF, UWP, and Silverlight. It is impressive, and in some respects, perhaps a little underrepresented.

Not sure if this is exactly the same, but it's been requested many times to implement DPI in Noesis. A global variable that affects the scale of all UI elements. I assume this is something similar right?

Yes, DPI scaling is a great way to describe the capability. UWP allows scaling of entire layouts with visual elements appropriately positioned and scaled. A resolution operating at 150% effective scale keeps elements left aligned on the screen or centered as dictated by the XAML. I like this capability -- but where it perhaps isn't' successful in my mind (with UWP) is that the developer has limited control over the scale percentage used because it is an OS setting. On XBOX it automatically scales UI to ... 150% or 200% for the ten-foot experience. I had to disable layout scaling because this wasn't universally the behavior I wanted throughout the app. I am wondering if the same can be accomplished with layout transforms and/or viewboxes at a top-level root element. It's always elegant when an API call does the heavy lifting for the developer.