4.5 Official Beta Discussions Thread

[Mark Stega]

So it has to be this way. Not to mention that, in the MT world there's no way to do otherwise, because we don't even see a mouse press until the press and release is done, because it's hidden from us by the OS. Given that MT is the future, supporting anything else makes no sense anymore because it would just allow people to do things that can't be supported moving forward onto what is going to become the standard.

So does this mean that the Windows MT support is less then that of my Android or Windows phone (since they clearly support these other two events)?

[Dean Roddey]

I dunno about that. But the way MT works is that, if you press and release without moving, then the system generates a button down, a move, and a button up, all at once, after you release. That's how it knows to treat it as a button click, not a gesture. If you press and move, then we never see any button clicks, we just see the gesture.

I don't see how it could be any different. Of course the OS could say, the user is pressing down, then decide if it's click or a gesture, and then at the end say the user is releasing after the click or gesture. But that's not very useful, because you would have to trigger the action before you know what you are going to be dealing with. So you could trigger an action but then it turns into a gesture.

So I don't see the value in it even if it was available. And it's a simple scheme that should be supportable via mouse, non-MT touch screens, MT screens, and any sort of tablet client even if they don't provide separate touch/mouse events.

[Dean Roddey]

Well, my brain is starting to really hurt. I spent most of the day doing the above discussed changes and getting all that worked out. I removed quite a lot of code, which is good. It was really tedious to make all those changes but it's so much simpler.

I've just been testing and fixing and trying to get my head back above water. I'll get back to it tomorrow.

[Dean Roddey]

Well I wasted a couple hours last night and a couple more this morning for nothing. For some reason the horizontal list browsers seemed to be moving backwards during inertial drags. I debugged and debugged and finally re-working the strategy for keeping up with coordinates and it still was doing it. The latter wasn't time wasted necessary since it's a better way than before and I can apply it to some others, but still. It worked fine vertically but horizontally it was doing this backwards thing, and I could see no difference between the two scenarios.

Turned out it was just temporal aliasing. I used a macro to generate a long list of values to load into some test browsers, and they were just "Value 1", "Value 2", and so forth. When it's moving at a pretty good clip during scrolling, because they are all similar, it would seem like it was moving backwards (the old wagon wheel going backwards in a movie thing.)

Sigh....

[Dean Roddey]

OK, good forward progress is being made now. I got a lot done after my above temporal dyslexia. Things are looking good. There are still corner cases to deal with and the media list browser still to be done, and do some work to get the RIVA server back happy, but it's getting close. I got rid of beaucoup complexity, which is always a very gratifying thing.

I did some more tweaking of my inertia support and I think it's working pretty smoothly now, though of course let me know if you think it could be improved and we can look at it. I'm remembering the last 200ms of movement, then I sort the list and throw out the lowest and highest, to help smooth out variation. I add the rest up and divide to get an average, and that becomes the final delta that I then ramp down over time.

I'm using a power function to ramp down, and getting the power just right is key to getting the right inertial ramp down. It's set little lower for horizontal than vertical to stretch it out a bit more. And the scaling factor is set a bit higher for horizontal than lower, since horizontal stuff tends to need to move further than vertical stuff, to get the same amount of perceived movement.

[Dean Roddey]

I got the gesture engine abstracted so that it can work with both regular windows and can be used by the RIVA server, which we need until such time as a RIVA2 is available. The widgets that would generally report that they want an inertial drag just check whether they are in remote mode and request a flick instead. So this means very minimal differences between the real IV and RIVA clients for now. That avoids a lot of redundancy if I'd otherwise had to implement that gesture logic separately in the RIVA server.

Also, since it has to work with non-Windows now, I updated it to drive the inertia generation process itself, instead of depending on window timer messages as it did before. That demonstrated that a good bit of my issues with getting the inertial the way I wanted it was due to the fact that the timer messages aren't as strictly timed as would be desirable. Now that the gesture engine drives it in a timed way, it's more consistent and nicer.

I was just about done updating the RIVA server to use the gesture engine, and should finish that up quickly tomorrow.

I've got all of the drag to set widgets working correctly now with gestures, which is much more convenient than the old "press and hold, then drag" thing. Just touch and drag. I also updated the volume knob to use left/right and up/down drags to set the value, since all gestures are horizontal or vertical. So we can't do the old circular scheme anymore, and frankly the straight drags to set work better anyway.

So, though I'm running behind a bit, things are coming along pretty nicely now. So hopefully I'll get a drop out Monday sometime.

[wuench]

Have you ever looked at some of the cross platform development platforms out there?

Since your code doesn't have OS dependencies, you might be able to write the RIVA, AutoGen Client, or even the IV in one of those tools and deploy on all kinds of devices. Some look to be free if you release the app open source.

[Dean Roddey]

Mark was looking into some. I'm not sure if he ever came to any conclusion. We would certainly like to have a portable RIVA client. Of course, one issue with these things is sometimes they are fine to do the happy-clappy demo, but once you get into them they have all kinds of gotchas. But, at least one benefit of a RIVA client is that it wouldn't require a lot of functionality, since most of the heavy lifting is done on the back end.

The IV is pretty much a non-starter on this front. It's far, far too complex to undertake using a separate code base.

[Mark Stega]

My conclusion was that Xamarin was the most productive and solid tool set with demonstrable 'real' applications on Android and iOS. It is also expensive (at about $1K/platform/year/developer) for the level that we would need. It still requires some native code wrt the UI. The second choice would by Apache PhoneGap which gives a unified HTML/CSS/JS rnvironment and a promise of a write once experience. There are several commercial implementation based upon the open source Apache work (PhoneGap, etc.).

The issue becomes one of economics. Even very moderately priced (circa $20) apps for Android & iOS have proven to sell mere handfuls, not even enough to pay for a development platform.

Nothing is decided yet so all feedback is appreciated.

[Dean Roddey]

I think I'm pretty much there, though I'll need to do enough more testing that I won't get a drop out tonight. Getting the media list browser updated really game me fits and wasted a lot of time, though I eventually beat it into submission.

One thing that has become a casualty of this change is the Inc/Dec button. It just doesn't work within this new scheme at all. It'll still be there so as not to break anything, but to the extent that people actually need something like that, we'll have to come up with something else. It wasn't every really that great anyway, really. So retiring it wouldn't necessarily be a bad thing.

There's not any more smooth scrolling when sending commands by buttons, with a few exceptions. Given that gesture support is always there now, it's assumed that button based movement of scrollable widgets is soon to become a thing of a past, and therefore the considerable amount of effort required to add all that smooth scrolling code back in after things have changed so much just isn't worth it.

The exceptions are in those few places where flicks are still used in the gesture system (the overlay when in page mode, the calendar and cover art browser, i.e. the page oriented movements where inertial dragging won't work) and so where I still have to do my own smooth scrolling. In those cases, the scroll command sending buttons are effectively just calling the same code as is being used by the gesture system, So those will smoothly scroll, but it's just a side effect, not a deliberate thing.

If that's deemed too weird, I can always prevent the smooth scrolling in those special cases as well, when the commands are from buttons. But, to my way of seeing things, scrolling through command buttons just doesn't make a whole lot of sense anymore.