widget.newProgressView() Early comments/bugs/requests

Solar2D Composer
#1

I’m starting this since a) nobody else has and b)I’ve been busy slamming my head against this widget today. :wink:

Comments: This is going to sound like a laundry list of complaints, but Corona Labs, I swear this is just honest feedback! :slight_smile:

1. Bugs of note:
a. Does not seem to obey referencePoints properly right now. (#18503)
In the bug report I describe a workaround (set it outside the table!) but as it turns out that doesn’t work either.

b. The default value is less than 1% (#18505)
Easily tested; just :setProgress(0.01) after creation and you’ll see the progress build up). Basically, the default value is an unknowable, unreachable value.

c. Setting progress to 0 is the same as progress to 100 (or any thing 1.0+) (#18505)
Packed into the same bug, for some reason zero is clipped to 1.0.

2. Missing Features:
a. A way to set width of the meter (impossible currently without crafting custom images)
b. A way to set meter progress progressively (currently only absolute is supported)
c. A way to poll the current meter progress (object.progress would be great!)
d. A way to set the fill rate of the meter (currently impossible)
e. A way to poll the fill rate of the meter (currently impossible)
f. A way to set the initial progress (currently defaults to something?)

The fixed width meter really surprised me; as best I can tell the meter progress uses a classic leftcap->content->rightcap approach while the outside meter uses a hard-set image.

(For some reason the default assets artwork also uses a fairly long centerpiece so no matter what progress value you set, I believe the minimum it will display is around 10%)

3. Documentation needs work
Yeah, I know, it’s early, give it some time. But since I’m busy giving feedback, it would be great if:
a. The imageSheet specific vars were grouped together. The docs as they are written right now look like you need those values when not using a custom sheet.
b. Some basic info on minimum sizes would be great. I’m tempted to build a more flexible, 1-2px sheet but not sure how flexible its going to be, particularly since there are no warnings. [import]uid: 41884 topic_id: 32614 reply_id: 332614[/import]

#2

Will pass this on to the appropriate team members, thanks Richard :slight_smile:

Peach [import]uid: 52491 topic_id: 32614 reply_id: 129740[/import]

#3

Thanks Peach. I intend to follow up with the other widgets soon; sometimes the best feedback is just somebody trying to use your code in unexpected ways.

Re: #18503
It seems I may have been mistaken on this one. Clearly the x alignment is a bug, but the y alignment may be a seperate issue with Corona. I’ve noticed that in projects without config.lua, 2012.945 is always reporting the 3GS display.statusBarHeight instead of the iPhone4 height when I use the skin of the latter. Is this an intentional change? Or should I be filing another bug?

[import]uid: 41884 topic_id: 32614 reply_id: 129762[/import]

#4

Will pass this on to the appropriate team members, thanks Richard :slight_smile:

Peach [import]uid: 52491 topic_id: 32614 reply_id: 129740[/import]

#5

Thanks Peach. I intend to follow up with the other widgets soon; sometimes the best feedback is just somebody trying to use your code in unexpected ways.

Re: #18503
It seems I may have been mistaken on this one. Clearly the x alignment is a bug, but the y alignment may be a seperate issue with Corona. I’ve noticed that in projects without config.lua, 2012.945 is always reporting the 3GS display.statusBarHeight instead of the iPhone4 height when I use the skin of the latter. Is this an intentional change? Or should I be filing another bug?

[import]uid: 41884 topic_id: 32614 reply_id: 129762[/import]

#6

Hey Richard.

Thank you for your feedback. The default iOS progress view is structured like this in terms of the 0.0>1.0 range. That is what we based it off.

The bugs you mentioned will be fixed asap (and I mean that), and you have a lot of valid suggestions and good ideas overall.

I am the widget framework engineer so I want you to know I hear you loud and clear.

We knew that there might be a few kinks in our new widgets, so we are glad to hear any complaints, suggestions or ideas. Really appreciate the feedback. [import]uid: 84637 topic_id: 32614 reply_id: 129815[/import]

#7

Yeah, I totally understand why it was built this way from an engineering perspective; if you want a progressView that does exactly what Apple usually uses it for in the iOS framework. I just like to get the feedback out ASAP because a) as you say, feedback helps and b) I’ve spent at least a 3rd of my development career as a UI planner for games so I tend to have a different perspective. :slight_smile:

Typical iOS framework meters:

  • Typically used to show downloads or file updates in progress
  • In progress from the moment they are spawned
  • Rarely stay onscreen for more than a minute
  • Usually have the same width for UI consistency

Typical Game meters (see: PixelJunk Monsters, probably a wide variety of FB games)

  • Typically used as a visually friendly version of “133 / 200”
  • Can go up or down periodically
  • Can stay at a static value (including zero)
  • Have a wide variety of sizes, based on importance
  • Can be on-screen as long as the game is running
  • Sometimes increase (scale) in width during gameplay to reflect an upgrade in maximum capacity.
    (not as common, obviously harder to pull off)

From a new user perspective, if I was just trying to use the widget out of the gate, width is probably the first value I would be looking for; I’d probably just assume I could use the iOS styling for now and switch that later, but I’d expect to see a width setting just because it’s the one thing I would assume is code adjustable without breaking the art assets. (Making a new sheet with meters of every width necessary isn’t impossible; it’s just unexpected)

Anyway, I’m excited to see the new widgets (it certainly makes the non-game app I have more viable by the day) and I’ll follow up on the other new widgets ASAP. [import]uid: 41884 topic_id: 32614 reply_id: 129822[/import]

#8

Hey Richard.

Thank you for your feedback. The default iOS progress view is structured like this in terms of the 0.0>1.0 range. That is what we based it off.

The bugs you mentioned will be fixed asap (and I mean that), and you have a lot of valid suggestions and good ideas overall.

I am the widget framework engineer so I want you to know I hear you loud and clear.

We knew that there might be a few kinks in our new widgets, so we are glad to hear any complaints, suggestions or ideas. Really appreciate the feedback. [import]uid: 84637 topic_id: 32614 reply_id: 129815[/import]

#9

Yeah, I totally understand why it was built this way from an engineering perspective; if you want a progressView that does exactly what Apple usually uses it for in the iOS framework. I just like to get the feedback out ASAP because a) as you say, feedback helps and b) I’ve spent at least a 3rd of my development career as a UI planner for games so I tend to have a different perspective. :slight_smile:

Typical iOS framework meters:

  • Typically used to show downloads or file updates in progress
  • In progress from the moment they are spawned
  • Rarely stay onscreen for more than a minute
  • Usually have the same width for UI consistency

Typical Game meters (see: PixelJunk Monsters, probably a wide variety of FB games)

  • Typically used as a visually friendly version of “133 / 200”
  • Can go up or down periodically
  • Can stay at a static value (including zero)
  • Have a wide variety of sizes, based on importance
  • Can be on-screen as long as the game is running
  • Sometimes increase (scale) in width during gameplay to reflect an upgrade in maximum capacity.
    (not as common, obviously harder to pull off)

From a new user perspective, if I was just trying to use the widget out of the gate, width is probably the first value I would be looking for; I’d probably just assume I could use the iOS styling for now and switch that later, but I’d expect to see a width setting just because it’s the one thing I would assume is code adjustable without breaking the art assets. (Making a new sheet with meters of every width necessary isn’t impossible; it’s just unexpected)

Anyway, I’m excited to see the new widgets (it certainly makes the non-game app I have more viable by the day) and I’ll follow up on the other new widgets ASAP. [import]uid: 41884 topic_id: 32614 reply_id: 129822[/import]

#10

I’m using build 1043 and have implemented progress view.  All works well with one exception.

When the progress view first appears, it immediately jumps to (approximately) 20%…then a moment later, it drops back to zero.  Then, it sits at zero until the actual download hits 10%.  At that point, the progress view jumps back to 10% and then works fine until the download reaches 100%.

Sounds weird, I know…but that’s what happens.  I output the percentComplete (see code below) and it outputs flawlessly so I know that the progress view is being fed the right info…it’s just not displaying correctly.  Here is my code:

First I load up the progress view and add it to a scrollview -

local progressView = widget.newProgressView { top = 35, left = -50, width = 100, height = 40, isAnimated = true, fillXOffset = 0, fillYOffset = 2 } scrollerGroup:insert(progressView) progressGroup[productId] = progressView

Then, once the download is ready to start, I do this -

local progressView = progressGroup[productId] progressView:setProgress( percentComplete ) if bytesEstimated==bytesTransferred then tar.untar(productId..".tar", system.DocumentsDirectory, dest\_path, onExtractComplete) progressView:removeSelf() progressGroup[productId] = nil progressView = nil end

Am I doing something wrong?

#11

Hi your not doing anything wrong. We found a few bugs in progressViews whilst working on expansion file support. The good news is that they are fixed and the fixes will be in your hands shortly :slight_smile:

#12

Sweet!  Thanks Danny!

#13

I’m using build 1043 and have implemented progress view.  All works well with one exception.

When the progress view first appears, it immediately jumps to (approximately) 20%…then a moment later, it drops back to zero.  Then, it sits at zero until the actual download hits 10%.  At that point, the progress view jumps back to 10% and then works fine until the download reaches 100%.

Sounds weird, I know…but that’s what happens.  I output the percentComplete (see code below) and it outputs flawlessly so I know that the progress view is being fed the right info…it’s just not displaying correctly.  Here is my code:

First I load up the progress view and add it to a scrollview -

local progressView = widget.newProgressView { top = 35, left = -50, width = 100, height = 40, isAnimated = true, fillXOffset = 0, fillYOffset = 2 } scrollerGroup:insert(progressView) progressGroup[productId] = progressView

Then, once the download is ready to start, I do this -

local progressView = progressGroup[productId] progressView:setProgress( percentComplete ) if bytesEstimated==bytesTransferred then tar.untar(productId..".tar", system.DocumentsDirectory, dest\_path, onExtractComplete) progressView:removeSelf() progressGroup[productId] = nil progressView = nil end

Am I doing something wrong?

#14

Hi your not doing anything wrong. We found a few bugs in progressViews whilst working on expansion file support. The good news is that they are fixed and the fixes will be in your hands shortly :slight_smile:

#15

Sweet!  Thanks Danny!

#16

Hi,

 I would like to use newProgressView  in a game where life, time… etc is counting down.

 Is it possible to decrease the progressview bar value?

First tests indicate that increasing works but decreasing not. Is this a bug or is this intended functionality? 

Thx,

Ivo

#17

Hi Ivo,

At this time, ProgressView isn’t designed for counting down, only up. You can probably add this feature yourself (in the open-sourced widget code), but I’d suggest you just build a custom life/time countdown bar. There are various tutorials out there if you need them, or you can just design it yourself without too much difficulty.

Regards,

Brent

#18

Hi Brent,

Thanks for your explanation.

I will build my own countdown bar then.

However it would be nice if the widget was extended in a way that it could be used as a countdown bar.

Thx again,

Ivo

#19

Hi Ivo,

I apologize, I actually cited this incorrectly. ProgressView, in fact, can be used to “count down” using the following code:

[lua]

object:setProgress( object:getProgress() - amountToReduce )

[/lua]

Obviously, “object” is your ProgressView widget, and all you need to do is get the current value (using “:getProgress”), subtract a value, and the set the progress again using “:setProgress()”.

Take care,

Brent

#20

Hi,

 I would like to use newProgressView  in a game where life, time… etc is counting down.

 Is it possible to decrease the progressview bar value?

First tests indicate that increasing works but decreasing not. Is this a bug or is this intended functionality? 

Thx,

Ivo