Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
4.4 Beta Discussion Thread
I have been working on a horizontal scrollable overlay with 4_3_930, using command buttons and the action command. To make the template (2400 long) scroll in the overlay window (1200 long), I either have to have a solid background colour or an image in the overlay window. If I have either a vertical graduated fill or a transparent background, the overlay will not scroll. Is this as it should be?

As a workaround, I have taken a screen shot of the graduated fill, then turned it into an image. However, the image must be the length of the longer template, not the size of the window.

Also there is a page scroll check box on the overlay attributes. If checked, the scrolling works as expected. If unchecked, there seems to be no way of setting the % of the template that I want to move. The default seems to be a little less than a full page.

PJG
Currently you have to have an image background or solid fill. The problem is that, in order to do the scroll remotely efficiently, we want to be able to pre-draw the contents in memory. In order to move it over a non-constant background, that means that every widget type would have to be able to draw itself transparently (text included), so that it could be repeatedly layered over the background. That's currently not possible.

Either that, or redraw the contents for every scroll position, which would be very piggy. Requiring the filled background means that the background never changes wrt to position, so I can pre-fill the scrollable area and draw the contents over it once, and then just scroll that whole thing across the screen as is.

The scrollable widgets do that special case work to support that, but they have very limited content and it wasn't too crazy to deal with that for them. But to do it for every widget type will take a while.

In theory I could allow scrolling in the consistent direction of a graduated fill, but currently I'm not trying to be that fancy.

The check box is supposed to work as you describe it. You can either do a page at a time, or just depend on velocity to move it. If you are doing the scrolling via buttons instead of gestures, then it's about 85% as a default amount to move. We did allow for percentages for a short period there, but ultimately I didn't want to have to support that moving forward. The scrolling, dragging, inertia, etc... stuff is going to be complicated enough as it is, and I didn't want the RIVA clients to have implement a specific percentage. And it would have been more difficult to do once we move toward real inertial dragging type of functionality.
Dean Roddey
Explorans limites defectum
Dean Roddey Wrote:Currently you have to have an image background or solid fill. The problem is that, in order to do the scroll remotely efficiently, we want to be able to pre-draw the contents in memory. In order to move it over a non-constant background, that means that every widget type would have to be able to draw itself transparently (text included), so that it could be repeatedly layered over the background. That's currently not possible.

So why does drawing over a tiled image (like the brushed aluminum) or image work? It would seem to be the same as scrolling a gradient fill in the 'with the grain'. So it would seem that you could add configuration with three choices:
"Gestures Right/Left" would allow a vertical gradient
"Gestures Up/Down" would allow a horizontal gradient
"Gestures Both" would disallow gradient fill.

Dean Roddey Wrote:The check box is supposed to work as you describe it. You can either do a page at a time, or just depend on velocity to move it. If you are doing the scrolling via buttons instead of gestures, then it's about 85% as a default amount to move. We did allow for percentages for a short period there, but ultimately I didn't want to have to support that moving forward.

At least for scrolling templates in overlays I would find a third option very useful and that would be an "Full page mode" that scrolled precisely on the width of the overlay. The way I use the templates in the overlay is conducive to have known boundaries (like doing a template 3096 pixels wide with a destination of an overlay that is 1024 pixels wide to have three flicks to scroll across pages).
Mark Stega
The problem with the gradients is that we are about to move to support dragging, instead of just flicks. Once we do that, the user can change mid-stream and drag in the other direction. So, unlike flicks where we get the whole gesture before we even start, and just ignore something in a direction we can't support, the drags are arbitrary. And, in the case of the overlays, since it can go in both axes, that means they can drag it all around.

The paged mode check box on the overlay will make it do full overlay width (or height), so that should give you want you need.
Dean Roddey
Explorans limites defectum
It looks like I will be able to deal with the gradients. I've been working on improving the low level gesture support to support real inertia when the time comes. When the gesture starts, the window can set gesture options based on the gesture start position, and can limit dragging to horz and/or vertical. So I can look at the background fill on the overlay and limit dragging in the valid areas. I will have to implement similar h/v limits on the faux gestures stuff as well but that's easy enough. That same scheme will also be used to disable inertia if you start a gesture on an overlay in page mode.

I've got the low level stuff working now with the real inertia in a little test program. It can be configured without, which is how it'll be set up for the 4.4 release. But it's ready to move forward to get the real dragging working.

The built in inertia is way too sensitive so I've added an ability for me to scale it as desired. It tracks your finger as is, but once you lift your finger and purely inertial messages start coming in, it can scale the movement to reduce the distance traveled. With the 'pen and touch' settings in the control panel set such that inertial resistance is at its default, a flick type movement with even a moderate velocity will throw it half way or more across a 1920 screen. I'm scaling it down to a quarter of that, and it's still a good bit of movement.

It'll be a little tricky in the interim, post-4.4 when I add the inertial dragging stuff but before RIVA 2, since I'll have to support both flicks and real dragging stuff. Even on MT systems, if on an overlay in page mode, it's easier to just use the per-gesture configuration setup discussed above to turn off inertia for that that gesture and process it as a flick. So, in that one case, we'll still need that page mode scrolling stuff there even after RIVA 2. That'll mean I still have to use my own inertial scrolling for that. So, kind of messy, but unavoidable. I'll have to do some exploration as to how to most cleanly deal with these special cases.

I'll have to see if I want to try to just avoid some special cases by emulating the inertial messages in my faux gesture handler. I probably will, since that means a lot less weirdness on the IV side.
Dean Roddey
Explorans limites defectum
Dean - I am having issues getting a sliding weather forecast panel to slide. I basically used your method from the Auto Gen interface and integrated it into my interface. The difference is that mine if horizontal. Other than that, everything is nearly identical including fields and widgets. The only other difference is that the overlay is on top of my weather overlay. Would that possible be an issue? See the shot below. I highlighted the area containing the overlay for now. I also can not get my text forecast boxes to roll with a flick. Other lists and all work fine throughout the interface.

[IMG]http://www.charmedquark.com/vb_forum/[Image: Weather_Scroll_zps7e01cb22.png][/IMG]
Thanks,
Dave Bruner
Cool
I figured it out after re-reading various posts concerning flicks and all. The containing overlay can not currently have a transparent background. As soon as I made it solid, everything started to work. That schema does not really look good with my current design, so I will need to think through this.
Thanks,
Dave Bruner
Cool
I'll deal with the gradient fields in the followup release.
Dean Roddey
Explorans limites defectum


Possibly Related Threads...
Thread Author Replies Views Last Post
  MQTT support discussion Dean Roddey 30 398 9 hours ago
Last Post: Dean Roddey
  Official 5.4 Beta Discussion Thread Dean Roddey 340 22,892 02-19-2019, 08:27 PM
Last Post: kfly
  Official 5.4 Beta Release Thread Dean Roddey 35 3,339 02-18-2019, 05:00 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 120,086 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 6,229 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 77,691 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 7,684 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 176,933 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 17,561 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 455,131 11-09-2016, 04:34 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)