4.5 Official Beta Discussions Thread

[Dean Roddey]

A very, very long day today, but I almost got it all finished. I have the inertia done, and got most of the updates to the IV engine for the new scheme of things. I went back to the XP/Vista faux engine to get that working.

In this new scheme, there won't be any need for any of the weirdness that currently exists. Gesture support will always be loaded, whether on MT hardware or not, and it'll always use the left button when doing faux gestures (mouse or non-MT touch screen). The same left button will handle either clicks or gestures with a mouse, in the same way it does on a touch screen, i.e. press and release in place and it becomes a click. Press and drag and it becomes a gesture (assuming the target widget supports it.) There'll no longer be any such thing as mouse button and drag, it'll only be mouse click or gesture.

All of the draggable widgets (p.bar, slider, volume control, etc...) will be changed to use gestures, unlike now, so there'll be no need to press and hold in order to set them.

So, this way, I can just spit out (and you guys can build) auto-generated templates that are purely gesture based and there won't be any need to try to deal with buttons to send scrolling commands the like, since everyone will automatically get gesture support.

This means that the old CID_GESTHANDLER is no longer required, though you could, if you wanted to for some reason, still set it to None to disable gesture support.

Anyway, I'm very close. I have the faux gestures working fine now, and just have to finish up the remainder of updating the IV engine and doing the media list browser.

[pjgregory]

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.

You might have a look at my new House Controller templates here.

http://www.charmedquark.com/vb_forum/sho...post149187

I have been working on the same issues of scrolling and multiple aspect ratios over the last few weeks and this is my solution. Any comments or suggestions would be most welcome.

PJG

[Dean Roddey]

I'm talking more from the auto-generation point of view, where I have some options open to me that wouldn't be when building them by hand, i.e. I can programmatically modify content during the generation.

[Dean Roddey]

Another very long day but I've pretty much got everything working again but the media list browser. Once I got going on the IV updates, I found other ways to expose more features and make it more convenient, and of course found some glitches in my implementation, so I spent a fair bit of time on that. But it's all working quite well and is so much better than it used to be it's hard to even compare them.

So I'll do some more testing tomorrow and finish up the media list browser for draggability, then it's on to the other things and hopefully a new drop by Thursday hopefully, maybe Friday.

[Dean Roddey]

I got a lot done today, another long one. I didn't do the media list browser yet. I just didn't feel like messing with more scrolling stuff. So I just tested out all the other widget types and made sure everything seems to be working correctly, and worked out some more glitches and it's starting to look good now. And I tested out the RIVA clients to make sure that they are still working ok.

I also worked on other things that are on the list as well. One is one that I put on the list, which is that the Base widget attributes tab now queries the target widget being configured and asks it for context sensitive names for the colors, and displays those instead of the generic names. So now the color names say what they are for. And I went through and updated the widgets to be more consistent in how they use colors in order to this change work correctly (I update things on the fly so this shouldn't break anybody.)

So more testing tomorrow and I'll get the media list browser done, and work on the other remaining bits I have on the list for the next drop. I may luck up and get up a drop tomorrow night, since things are look better than I'd expected at this point.

[DaveB]

Dean - Sort of related, but is there any chance that you could make the opacity indication readable in % rather then Hex on the various widget tabs?

[Dean Roddey]

Shouldn't be too hard. I'll put it on the list.

[Dean Roddey]

I took a detour today. I had to work on a driver, and then when I got back to the IV, I had a wee epiphany that lead to some reworking of things.

Previously, there was a considerable amount of fairly complicated code that tracked mouse activity, in any of the interactive widgets. On a press, they would track what had been clicked on, and track the movement, and release and decide if something should be done.

But, now all of the interactive widgets will use gestures, even the 'drag to set' ones like the slider, volume knob, etc..., though the latter ones will be non-inertial. And, in the gesture world you only get a click if you press and release quickly without moving, so ultimately the only 'mousey' thing involved anymore is that simple click operation.

So I changed the gesture engine to handle that internally as well and just make a 'clicked' call to the window. So now gesture based windows work purely in terms of drag/flick gestures and this simple click. So I updated all the interactive widgets to get rid of all of that mouse tracking code.

The press, move, release bits were moved to the gesture handler, which is still a lot simpler to deal with because it's a lot less baroque than the previous mouse handling code, plus a simple 'clicked at this point' method. Since they don't hear about the click until it's done, they don't have to do any tracking, they just react to the mouse after the fact. They do a quick press, pause, release visual to provide feedback. But there's no more of that tracking the mouse and pressing/releasing as the mouse moves into and out of it while tracking.

Ultimately this simplifies things a lot, and was an unexpected benefit of all of this gesture stuff. So, though it cost me a day, it was a change well worth doing.

[Mark Stega]

For single touch screens the norm is to perform the action on the press (every one of my interfaces is coded that way in today's 4.4 world). I wouldn't want to lose that because that is the way of single touch screens, i.e., my bank ATM, several gas pumps, my wall mounted ELO touch screen, etc.

For multitouch it is more complex. On my Window 7.5 phone and my Android Kindle, actions are definitely taken when I finish the tap (so that is consistent with what has just been described). But there are two more actions that some applications react to. The first is a signal (?Screen touched?) that causes some applications to outline the selected item. The second signal (?touch and hold?) occurs when I touch and hold the touch for about a second. It is common for a context sensitive menu to be shown rather than the touch action.These aren't precluded by what is implemented now, but would be good enhancements. As an example, consider the media browser. OnSelectCollection could work on the tap/mouse click. The "screen touched" could outline the item touched. The "tap and hold" could display a context menu that included "browse this artist" and "browse this genre" (or "browse these genres" if multiple). I am sure other examples exist, these are just off the top of my head.

[Dean Roddey]

The touch and hold won't be used, within CQC anyway. We'll only use the quick touch and release. We can't do anything upon pressing down anymore anyway, because now that I'm using a single mouse button to do everything, we can't know it's a press-release until you actually release. Until then it could turn into a gesture. Same on MT hardware except the driver is the one doing that determination. The only place it could be different is on a standard mouse using different buttons, but I'm not going to maintain all that code and complexity for standard mouse usage, just to avoid the wee delay to invoke.

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. And I don't want to support a bunch of extra complexity in order to maintain this soon to be defunct scheme either.

I'm going to get rid of OnPress/Release for buttons and move anything in them automatically over to OnClick.

For things that you drag, there will still be all three, because in those cases you are pressing, moving it, and releasing, so there are legitimate reasons for it there.