scroll events not forwarded to SdkTrays (except carousel)
OSX needs testing
Android/ NaCL/ WinRT/ iOS needs porting
tested on windows 7 with SDL2 from ogredeps
Why do you want to replace small, simple and stable library that is easy to understand with large, bloated, actively changing (i.e. "moving target") ? Breaking compatibility with many platforms at the same time?
I had experience porting SampleBrowser to WinRT - completely new platform from the point of input handling, not supported by OIS. It was done by constructing OIS events manually from OS depended data and passing to SampleBrowser, using only headers from OIS, without DLL - it is excellent example of simplicity and flexibility of OIS, exactly what is needed in sample code.
I`m not arguing that OIS should be used in real projects - it should not if there is alternative more attractive in some particular case, as can be SDL due to the audio support for example. But simplicity and small size of OIS make it the best choice for samples, IMHO.
One more point specific to the handling mouse/pointer/touch/multitouch/pen input. If your look at input handling in WPF - there are OnMouseXxx, OnTouchXxx and OnStylusXxx families of events, each family with own type of arguments, i.e. MouseDownEventArgs/TouchDownEventArgs/StylusDownEventArgs etc. And if you want to do simple drawing application for example - you need to hook enormous amount of events, Down/Moved/Up/CaptureLost for Mouse/Touch/Stylus. Actual code is very similar for each device - but could not be shared. This was the situation with Ogre two years ago. In WinRT Microsoft solves the problem by combining similar events from all kinds of devices into the one event, i.e. OnMouseXxx, OnTouchXxx and OnStylusXxx became OnPointerXxx. You still can determine the kind of pointer (i.e. Mouse, Pen or Touch) from event args, but in majority of cases you don't care. I bring this "pointer" idiom to Ogre's SampleBrowser and samples while ported it to WinRT, as it is really useful - but this patch reverses the situation
My opinion on that is that samples should resemble what one would use in real projects and that the should use common libraries that people are familiar with. Furthermore input handling is not even the driving force behind this change. The window handling and context creation of SDL2 is more sophisticated and more robust than our own. I think in the long term we should throw away the windowing code out of Ogre and just rely on external libraries for this.
Additionally the samples in Ogre2.1 use SDL2 already.
Regarding the porting to the new platform: you can also construct SDL events manually. However I suppose you would have to create compability headers for this. In fact I want to try to do this for android. But SDL2 already supports Android/ NaCL/ WinRT/ iOS and Emscripten. So maybe it is better to just take advantage of that instead of reinventing the wheel.
As of onPointer vs onTouch + onMouse: in the proposed implementation you can just always use onMouse if you dont care. However you most likely want to handle both because of absolute vs. relative positioning. This usually means that you use a different style of interaction.
As of onPointer vs onTouch + onMouse: in the proposed implementation you can just always use onMouse if you don't care
You should handle touchXxx events in addition to mouseXxx in each sample - as iOS devices don't pass mouseXxx events. That`s the problem - each sample should handle both families of events. You can take a look at
commit that simplified this handling.
However you most likely want to handle both because of absolute vs. relative positioning
OIS solves this by having inside OIS::Axis both relative and absolute displacements, so no problem here, all events could be combined.
You should handle touchXxx events in addition to mouseXxx in each sample
OIS solves this by having inside OIS::Axis both relative and absolute displacements
this PR already sends fake mouse events when getting touch events, so stuff works. My comment was more about switching interaction pardigms: mouse wheel vs. kinetic scrolling.
I don't want to undermine the changes but I have similar concerns. The changes are big, for a sample browser that already works.
Yes, Ogre 2.1 chose SDL2 for its samples, but the samples are much smaller and more simple when compared to the unreadable monster that is SampleBrowser.
Also Ogre 2.1 is not working yet on mobile, so this concern hasn't been fully taken into account, and my philosophy is to use alternate paths on platforms where it may make more sense, i.e. using native bindings on Android and iOS rather than SDL. The Ogre 2.1 samples are written in a manner that is almost agnostic of the SDL library (probably a few things will need to be adapted, but not much since like I said, these samples are small).
yes this pretty much boils down whether you want a SDL2 based sample browser for reasons.
I think breaking stuff in 1.10 is ok, there is always 1.9 if you want an OIS based sample browser. But thats just IMHO.