4.5 Official Beta Discussions Thread

[Dean Roddey]

I've finally got all the h/v browser ones working, with all the possible variations, and with the command driven scrolling. For the moment, the button driven list scroll commands are not doing any sort of sliding scroll, they just move to the next position. The scrolling is all inertial drag based now. Given that that's how all of the real gesture stuff is going to be done moving forward, I probably won't put back the sliding scrolls on the button driven scrolls.

So, anyhoo, moving on to the next widget type.

I think I'm going to get it all updated, but where I've not tried yet to simulate the inertia in the non-multi-touch gesture handler, and get that out there for folks who have MT monitors to test out and see how they like it. While they are doing that I can work on adding the inertial support in the faux gesture handler and incorporate feedback.

[Dean Roddey]

The toolbar didn't take long at all, since it's a simple scenario and I could go back to the previous version of the h/v browsers I did that didn't worry about the content being too large, and steal code from that, since the toolbar is one that doesn't have to worry about that. I have to go back and update the button driven scroll commands, but that'll be pretty quick and I'll be on the next one.

[Dean Roddey]

I got all of the toolbar scenarios tested out and working and moved on the overlay. I wasn't getting much cooperation from the backstage crew but I was finally making some progress here at the end, though still not quite there. It's one of the simpler ones in one way, but one of the more complicated ones in another, in that it actually has to fake all of its contained widgets into thinking that they are somewhere other than their actual locations. I changed it to work like the others I've done so far, but I'm thinking now that wasn't quite the best way, in terms of keeping up with how far it is scrolled. The way it was originally done was probably better, so I'll likely put that back tomorrow, and that should hopefully make things fall into place.

Then it's the adv media item browser and the media list browser and I should be happy. Those two are of the more complex type (might have lists too long to just draw into memory as a whole and pan around), but I have the h/v list browser example to go by when doing them.

[Dean Roddey]

Got the overlay finished. In this case I still have to retain my own scrolling in addition to the panning, since we have to support page mode stuff, which requires moving a fixed amount, instead of being driven by inertial panning stuff. So it had multiple complexities but it's working now.

So, on I guess to the advanced media item browser.

[pjgregory]

As you are deep into overlay scrolling, there is a related issue you could consider.

With fixed templates, it is relatively easy to position popups where you want them on the screen. I use up/down buttons on a small separate popup template to change the values in numeric fields. With page mode overlay scrolling you can still keep a track of where an overlay should be positioned. But with the ability to flick or drag an overlay to any position you want, then you need to add a new mode to the InterfaceVieweropup command to allow positioning relative to the overlay template rather than the screen. Alternatively, you make a runtime value that provides the origin of the currently displayed window so that the user can recompute the Popup display position.

The first option would be much easier on the user.

PJG

[Dean Roddey]

Once the dust has settled, I can look at that. If you set the popup (invoked by a widget from within an overlay) relative to the origin of that overlay, then it could just be done automatically, by treating the position as relative to the overlay, no matter where it happens to be. So that would be an option to explore.

[Dean Roddey]

I got the Adv Media Item Browser today. So that just leaves the list browser. Which hopefully I should get tomorrow. Then I'll do some testing and some other smallish new things that are on the list, and get a drop up for folks with MT hardware to play with.

[Dean Roddey]

As I was looking at what is required for the media list browser, which is different from anything else though similar issues will arise in the CAB if we get it away from page oriented operation, in that it moves vertically in a way that you want to do inertial dragging, but horizontally in a page oriented way. I.e. vertically you are moving through the categories, titles, items, etc... but horizontally you only flick to move back to the previous level. There's not a convenient way to deal with this given the way that the built in gesture stuff works.

What I really needed is a way for widgets to indicate to the gesture handler that they will accept different types of gestures in each direction, to avoid a lot of special case code. And there were other issues, such as inertial messages getting spit out even if they end up being not needed (i.e. you flick hard to the right when already at the right end and it spits out useless inertia message for a few seconds.) Or even just the overhead of setting up for a gesture when it ends up being not meaningful, same reason as I just indicated. There's no way to deal with this stuff using the standard scheme, which forces you to react before the user has committed to moving in a given direction, and you can't set different settings for horz vs. vertical.

And, since I was going to end up having to simulate the inertial drag stuff for XP/Vista anyway, I decided to go back and do a better abstraction of gestures and use my own inertia instead of the system's. I'll still use the gesture messages on MT hardware of course, but just not ask the system to generate inertia.

This provides me a lot of benefits that I didn't have before. I can eat the start of gesture and only tell the target window about it after the first move. At that point I known which direction it's going in and lock that in and tell the window which direction to expect, so it can avoid setting up for gestures it knows it won't do anything with. And it can separately indicate for each direction now if it wants nothing, flicks, gestures, or gestures with inertia, since I'm providing processing for those options myself.

And I incorporated the flick gesture handler into the low level handler as well so that it can do all the processing, and only tell the window anything if something useful happens. And I can cancel inertial msgs immediately when I hit the end of the scrollable content, instead of having useless inertia msgs pouring out and preventing further user interaction for no visible reason. It also allows me to have the bulk of the handling in the common gesture handler base class, instead of having a lot more of it per-hardware gesture support style.

So it will be all around better, and will allow me to be much more efficient and have better control. I've got most of the way through the changes. I'll get it first handing handling all of the basic drag and flick stuff correctly tomorrow, then implement the inertia. Then I'll go back to the IV engine and update it for these changes, which won't be much, then update the media list browser to support drags now that I have this new stuff in place.

This means also that the next drop will have updated support for both multi-touch hardware and faux gestures as well. It's a little side step, but will be far better all around for me internally.

[Dean Roddey]

I always thought this touch screen was a bit overly sensitive to touch. I was just sitting here working and suddenly programs started activating themselves and doing stuff on their own. I couldn't figure out what was going on. Then I saw that there was a gnat, literally a semi-microscopic sized one that I could barely see, flying around on the screen. It was bouncing all over the screen like crazy, and every place it touched down, the screen registered as a click.

That's sort of something to think about wrt to a touch screen for automation purposes I guess.

[Dean Roddey]

OK, a long day, but I got the point where I was starting to work out the inertia stuff, but I got the rest of the low level gesture/flick stuff all working as described above. It's far and away better this way. Oh that foresight worked from the past, since I could have gone straight to this many moons ago. But, it was a big learning experience to get to this point where I understand everything well enough to work it all out.

But now there's just a wee bit of code in the Win7-8/XP-Vista dynamically loadable DLLs, and almost everything in the base gesture engine class. Incorporating the gestures and flicks all into that base class makes things so much easier on the consuming code, since everything is handled down there where it's done once for everyone, and all they have to do is report what they are willing to accept given the direction/orientation that the gesture has started moving along.

I'll get the inertia stuff worked out tomorrow and get the IV engine updated to use this new stuff and work on the media list browser, and that'll be the necessary gesture work (sans things that need to be fixed) to get us fully up to modern times.

What I'm going to do for a follow-up release, before we move on to working on 5.0, is get this stuff working (address the outstanding issues of course that have come up since the 4.4 release), and then do a new set of auto-generated templates (with some more room config improvements to help get done what I want to do for this follow-up.) The look will be significantly different, and it'll be a lot slicker and incorporate all of this gesture stuff at a fundamental level.

As a look, I'm thinking about something minimalist and modern like the 'control surface table' in the movie Oblivion if you have seen that. It's graphically simple, but looks very nice, and should be neutral to almost any color scheme really. I may make it a bit more 3D than that, I'm not sure. Maybe not. It looks really cool a it is and it will be light on the graphics processing side of things and will allow for efficient panning since everything is basically on a flat, black background.

I've been thinking about how to use the panning stuff and some other tricks to better deal with multiple aspect ratios, which should reduce the burden of supporting more resolutions as well. And the sort of 'segmented' look that I'm planning to emulate lends itself well to having bits that can be pieced together as required.