DragonSpark
Topic Author
Posts: 10
Joined: 19 Sep 2015, 23:54

Re: Investigating Noesis

03 Mar 2017, 13:02

Hey Team Noesis, congratulations on the v2.0 launch! I have been taking advantage of the new free-to-indie licensing and checking out your wares. :)

There was also a wicked awesome suggestion by your Twitter handle to possibly create a kickstarter to address the very popular request of a ubiquitous .NET client application model.

I decided to reply here as it is much more than 140 characters. :)

So to start with, Noesis offers pretty much everything that is required for this idea. There are four major platforms that would need (or expected) to be reached:
- Windows (duh)
- iOS (Mono)
- Droid (Mono)
- Web (on the way)

So next is the actual capabilities you find in WPF. Taking the morning to review your NoesisManaged assembly, it appears that all the pieces are in place here, with the exception of markup extensions which appear to be on the way (accomplishing something UWP hasn't been able to do in five years, but we'll step over that). Also, it appears that a lot of the expected controls are in the Noesis namespace, so that looks good. You also have NameScopes, so we're able to access controls in code behinds if necessary. Attached properties are also there, which is important as this adds a lot of the power/flexibility/extensibility that we enjoy with WPF.

The only thing that isn't offered is 3D, but that is easily addressed by pairing your product with Unity or any of the integrations that you (unofficially :) ) support. So to me this isn't a problem. There is also the System.Windows.Interactivity namespace, with behaviors and triggers. This would need to be built, but I do not think that would take much effort.

Plus the extra cherry on top is that you already feature Ammy integrations. You are also very engaging on your forums and (again, not drawing names, ha ha) seem to care a lot about Xaml. So there is a lot here that already exists and that you have going for you.

All the fundamentals are there. It would seem the only things missing are control contracts with the big name vendors (such as ComponentOne), and also styling. Because, as you mention in your tweet, your focus is on gaming, and not (I assume LOB) "applications." Well I hate to break it to you, but if you support theming and skins, you already support everything. It's just a matter of implementation at this point. :)

So I wanted to this out there and get your take on this and what you meant by a Kickstarter and what that would involve/look like. I would definitely be interested in perhaps assisting if necessary, but I am thinking most of the highly sought-after value is already there and wanted to get your take.

In any case, this is really promising, team. When I posted that idea to UserVoice in October 2015, I was expecting maybe 1,000 votes at the very most after a year or so of time. We're sitting here 19 months later at 6,200+ and it seems like promising answers are finally emerging. The comments of that idea are pretty active right now, with Noesis mentioned in nearly every one. Pretty excited about the future here. :)

Thanks again,
Michael (or Mike-EEE on Twitter and elsewhere)
 
PhilippeMonteil
Posts: 6
Joined: 25 Feb 2017, 10:53

Re: Investigating Noesis

03 Mar 2017, 14:00

<<The only thing that isn't offered is 3D
Being able to inject surfaces rendered separately by the GPU in the visual tree would suffice, IMO.

The idea of a Kickstarter to cofinance a WASM compliant version of Noesis, for example, is excellent:
I would be glad to participate.
 
User avatar
ai_enabled
Posts: 231
Joined: 18 Jul 2013, 05:28
Contact:

Re: Investigating Noesis

04 Mar 2017, 14:32

I have doubts regarding the possible Kickstarter campaign success. It's expected to give something valuable to the backers, with various reward tiers. What tiers are reasonable here? Also starting a Kickstarter campaign without having the already big engaging community is not a great idea - many projects failed to accomplish their goal simply because they could not gain momentum. And that's not possible without people ready to throw money right right after the campaign launch...

But even without Kickstarter, I see a very positive future of NoesisGUI. During the last three and half years I've spent hundreds of hours collaborating with NoesisGUI team to make their UI solution a perfect crossplatform alternative to WPF. Every issue was resolved quickly and professionally, often with the much better approach than expected. Jesus and Sergio are among the best developers I've ever worked with!

Now I see nothing preventing them from success. The technology is mature, the missing features are just a few and will be addressed promptly. The rendering quality and performance are already superior to WPF/UWP, and support for dozen of platforms is already here! More than that, by following gaming-first approach they've made a really powerful API when developer has a full control over UI rendering. It's much more reliable and effective than WPF (anybody who tried to use WPF for the game UI will immediately understand what I mean - there is no even a control over when and where to render). This approach satisfies AAA gaming middleware requirements for performance, parallelization, memory usage, stability... I need to say these requirements are much higher than what LOB applications are expected to have!

The community seems to be gaining momentum now as never before. With the new licensing policy (FREE for indies (<100k EUR gross annual revenue), FREE for open-source projects (it should be properly announced soon!)) and upcoming support for WASM NoesisGUI might become the leading UI solution for every platform and every use case.

The only thing frustrating me now in NoesisGUI is, surprisingly, XAML. I was a big advocate of it for many years (and WPF, Silverlight)... but now, when we have Ammy, XAML feels so outdated! Ideally, I would like to have the first class Ammy integration into NoesisGUI (BTW, I just updated NoesisGUI Ammy integration to support NoesisGUI 2.0). Yes, that's my dream - getting NoesisGUI license will allow license-free usage of Ammy for NoesisGUI-powered projects, and it will be the default language for NoesisGUI instead of outdated XAML, so it could directly parse Ammy... But that's not that easy as Ammy heavily relies on some .NET libraries (Nitra, Nemerle) which could not be easily ported to other platforms (and require .NET, after all). Well, NoesisGUI team could at least develop their own modern alternative to XAML! It's not rocket science. They will need to write plugins for IDE's, but now that's not that hard with good SDK's available for most popular IDE's.
Then we might finally get an UI solution which is only a pleasure to work with!

Regards!
AtomicTorch Studio Pte. Ltd. http://atomictorch.com
 
DragonSpark
Topic Author
Posts: 10
Joined: 19 Sep 2015, 23:54

Re: Investigating Noesis

04 Mar 2017, 15:53

What an amazing post and testimony, @ai_enabled! Thank you for sharing.

I am in agreement with your sentiment. Noesis has really come out of nowhere (well, for those who haven't had their hands in it for 3.5 years. :D ) and it sort of seems like it is taking the .NET world by storm ATM. I am thinking it is very close to a LOB solution in addition to the gaming offering that it already has in place. I mean, if you can do games, you have pretty much done it all. It doesn't get much more involved and challenging than gaming. LOB applications are the easy part. Which is why I stick to them. ;)

As for Ammy vs. Xaml. I would caution you to not fall into the same trap that MSFT made w/ project.json. Sure, Xaml does feel dated. That's because it is nearly ten years old without much upkeep from MSFT. I posted the System.Xaml port request earlier in the thread (oh ok why not I'll post it again). This continues to be given the cold shoulder by MSFT at large (although they are in communication). Additionally, it is hard to say that you are using true Xaml without Markup Extensions and the System.Windows.Interactivity namespace (at the very least). As you know, UWP doesn't even have markup extensions, and in fact took them NEARLY SEVEN YEARS to even get to the point of specing it out, which is outrageous). So let's make sure that when we say "Xaml" that really we are meaning the WPF Xaml model, which no other model has gotten close to replicating (but Noesis is getting close).

That said, none of this should be seen as a slam on Ammy. In fact, as you hopefully can see from my GitHub chatter/interactions that I am a huge fan! It's the most innovative advancement in this space since System.Xaml. The caution here is to err for either-or (like MSFT did with project.json). My suggestion would be to aim for a paradigm that enables BOTH models (and maybe even more) to ensure maximum adoption (and retention). That way you can offer the ability to interface (pardon the pun?) with Noesis via traditional Xaml or the new-fangled beauty of Ammy. Don't forget that Xaml is based on XML, which has its own storied history in enterprises for nearly 20 years. A lot of people have experience with that and it's easier to leverage what you have learned than it is to pick up something new (for the most part).

Anyways, I will get off my soapbox now. After the whole project.json fiasco, I am hoping that we as a community can see the value in (well-designed) options and not forcing users to go one way or another. I mean, that's what made and makes .NET so great, after all. You have flexibility to choose your language and express yourself in a way that makes the most sense to you, aesthetically or otherwise. :)

Otherwise, really enjoy hearing your thoughts and experience on this for sure!
 
andekande
Posts: 5
Joined: 23 Jul 2017, 23:33

Re: Investigating Noesis

24 Jul 2017, 01:30

After just 2 days of digesting some posts and demo code I also see the huge potential where NGUI can contribute a huge part to the cross-platform puzzle. Because its responsibility is clearly defined it would still take much additional effort to integrate with the target runtime. Be it Unity, Unreal, MonoGame, Wasm - all of them change over time, adapt to new devices or concepts, so that bugs lurk on every new version. To handle that challenge continously and consistently provide compatible bindings will still be an effort one must consider.
Part of that investigation lets me wonder how this will work out, with new runtimes being supported. What is the business strategy there. Can you rely solely on open source contributions or are there (technological) partnerships with the runtime vendors?

One good thing about WPF is, that it did not had much evolution the last 5 years and seems to continue that path. So thats why I also see the ideas for recommendations such as having a 1:1 API mapping quite approachable. Yet It won't give us the full API surface which leads me to the original question I wanted to ask: Where would WPF classes like FocusManager and CommandManager fit. Focus is an super important aspect on Desktop where there is a difference in elements having a logical Focus state in the VisualTree and the actual keyboard focused element one navigated to with TAB. With that, the concept of Tab orders (KeyboardNavigationMode) and FocusScopes get immediately relevant. How would one add those functionalities in a NGUI solution targeted on desktop business applications and yet retain compatible XAML?
 
User avatar
jsantos
Site Admin
Posts: 3905
Joined: 20 Jan 2012, 17:18
Contact:

Re: Investigating Noesis

25 Jul 2017, 13:08

Hi and welcome to this community!
Part of that investigation lets me wonder how this will work out, with new runtimes being supported. What is the business strategy there. Can you rely solely on open source contributions or are there (technological) partnerships with the runtime vendors?
Well, apart from the SDK - C++ and C# - we also maintain official integrations like Unity and Unreal. So the business strategy is trying to give proper support to the most demanded runtimes and let the community support less demanded ones.
Focus is an super important aspect on Desktop where there is a difference in elements having a logical Focus state in the VisualTree and the actual keyboard focused element one navigated to with TAB. With that, the concept of Tab orders (KeyboardNavigationMode) and FocusScopes get immediately relevant. How would one add those functionalities in a NGUI solution targeted on desktop business applications and yet retain compatible XAML?
Almost all those concepts are properly implemented in Noesis. We provide support for keyboard focus, tab order, keyboard navigation modes, etc. We don't support the whole WPF API yet but if you find any critical feature for your development please report it.
 
User avatar
sfernandez
Site Admin
Posts: 2983
Joined: 22 Dec 2011, 19:20

Re: Investigating Noesis

26 Jul 2017, 09:34

FocusManager is not implemented yet but some customers just build their own manager on top of Noesis to control the logical focus between different sections of their UI.

Some sort of CommandManager is already implemented internally, so we just need to properly expose it to the public API.

If you find these features are required for your development with Noesis, please report them in our bugtracker and we will implement them as soon as possible.

Who is online

Users browsing this forum: Google [Bot] and 67 guests