Hi, I am working through the evaluation. Very impressed so far with the quality of the docs, and the simplicity of getting started.

1) Do you have any demos in the iOS or Android app stores? I would like to see how it actually feels and performs on mobile.

2) I haven't seen anything in the docs or API having to do with setting the touch click radius. This is the threshold in pixels below which a touch event is considered a "tap" (click) versus being considered a swipe. This is a really important feature for mobile dev because the touch screen dpi varies greatly between devices. If the touch click radius is too small, users will experience frustration because not all their taps will be processed. How does NoesisGUI handle this? I am hoping that because it's a vector graphics system, all event handling is done in normalized vector space and we don't have to care about such things as pixel radius for touches. But it still would be good to expose such a parameter to the developer.

1) Do you have any demos in the iOS or Android app stores? I would like to see how it actually feels and performs on mobile.

We sent you an email regarding this.

2) I haven't seen anything in the docs or API having to do with setting the touch click radius. This is the threshold in pixels below which a touch event is considered a "tap" (click) versus being considered a swipe. This is a really important feature for mobile dev because the touch screen dpi varies greatly between devices. If the touch click radius is too small, users will experience frustration because not all their taps will be processed. How does NoesisGUI handle this? I am hoping that because it's a vector graphics system, all event handling is done in normalized vector space and we don't have to care about such things as pixel radius for touches. But it still would be good to expose such a parameter to the developer.

For now we are following the WPF API where there are no high-level touch events (swipe, tap...). Instead you have Manipulation Events that can be easily translated into high level commands. In this translation is where you should consider the threshold you are commenting.

In the future we will probably add routed events for tapped, swipe, pinch...

For now we are following the WPF API where there are no high-level touch events (swipe, tap...). Instead you have Manipulation Events that can be easily translated into high level commands. In this translation is where you should consider the threshold you are commenting.

In the future we will probably add routed events for tapped, swipe, pinch...

1) OK, just double checking because I'm not sure if you understood my question. I dont want to add any touch gestures. I want to make sure existing events (like Button click) get fired always, and don't get ignored just because someone has a 445dpi phone and your framework decided because they moved by 5 pixels so you deciced that it was a TouchMove. This is why other gui toolkits have a setting for "click radius" or similar.

Or are you saying that button Click events don't work at all with Touch screen and the touch events have to be implemented separately?

2) Is it explained anywhere what is the difference between routed, tunneling, and bubbling events? ( I am reading this http://www.noesisengine.com/docs/Gui.Co ... orial.html and it's not explained) Those terms surely make sense to GUI toolkit gurus. but not to me. I think I know what event bubbling is, but not the other two.

Thanks

1) Yes, our buttons react to touch events. In fact, the button fires the click event when it receives a TouchUp inside its region. So even if you moved the finger the button would work. The problem is when the button is so small that you end up leaving the finger outside the button area. In that case, a radius could be useful, but I am not sure if having a GUI with such small buttons is really usable at all. Not sure if this is what you are talking about.

2) As noesisGUI is based in WPF all our architecture is very similar to it: dependency object, dependency property, attached property, routed events... You can find all this information in internet. For example, this is a good introduction to routed events and their routing strategies.

Thanks for your replies- that all makes sense.

I was unable to get the evaluation running on mobile. (the version you sent me) It compiled but I got an exception at startup on iOS. I noticed in your docs that it's required to hack the C++ .mm file for the Unity wrapper. Maybe that's related- I don't know. I think your middleware should take care of patching the mobile build project as needed. For example see how Prime31 handles it with their native plugins- they are one of the largest middleware vendors for Unity.

Just another suggestion - maybe you should publish a tech demo in the Google Play and iOS app stores, for free download. Then if someone wants to see how the product works on mobile, it will be easy to find out.

I think you have an impressive product but without knowing it's rock solid and fast on mobile I cant go forward with it.

Is the iOS platform enabled under Window -> NoesisGUI -> Settings ? As said in the documentation, patching is not needed in Unity version 4.2 or above.

What is exactly Prime31 doing with their native plugins that could be applied to noesisGUI? I would love to know about things that can improve our product.

Thanks for the suggestion about publishing in the store a technical demo. Definitely something to be done in the future.

Thanks!

Is the iOS platform enabled under Window -> NoesisGUI -> Settings ? As said in the documentation, patching is not needed in Unity version 4.2 or above.

Ah yes- that's what it was. In the docs I read about patching the .mm but did not notice particular versions being mentioned. It would be great if this step with an extra "Build" button was not necessary. It's so easy to forget. You should be able to use unity editor API to find the current build target, and hook into the build post-processor.

What is exactly Prime31 doing with their native plugins that could be applied to noesisGUI? I would love to know about things that can improve our product.

They were just automatically patching the C++ source, only when necessary though.

Thanks for the suggestion about publishing in the store a technical demo. Definitely something to be done in the future..

Great

Ah yes- that's what it was. In the docs I read about patching the .mm but did not notice particular versions being mentioned. It would be great if this step with an extra "Build" button was not necessary. It's so easy to forget. You should be able to use unity editor API to find the current build target, and hook into the build post-processor.

Yes, that step is annoying. Problem is that Unity does not expose a proper API for this (native applications are considered second citizens for Unity...) but we will find a way to make this transparent for the user.

Feedback about this (and everything) always welcome!