If a widget needs to resize during transition then it would call
that method, otherwise, it would call the normal method:
widget.prepareForTransition(transition).
I think that doing the resize after the transition (either with a
hard-coded delay or a "transitionFinished" notification) is
not the right solution. If the transition involves a decrease in
height and some elements are relative to the bottom edge then you
would actually see those elements move upwards after the flip.
I think that the best solution is to make the resize part of the
transition. The transition needs to include the resize. I'll try
to write up an enhancement request, but I'm also interested in your
opinion on this.
Chuck
At 3:25 PM -0800 11/4/05, Matt Drance wrote:
It is a design flaw... you should make
your front and back match :-P
I think it would be dangerous to force
that behavior on all the widgets we have out there. Depending on
how someone has laid things out it could easily break dozens of others
depending on how they're laid out. However I don't do feature
work, so feel free to log the enhancement request. It never
hurts to ask.
That solution works great. Thanks. I had
actually tried that but I didn't use enough milliseconds.
I now have a workable solution, yet it
would be really nice if the height increase could be applied before
'window.widget.performTransition();' so that the resizing of the
widget would not be visible to the user. Seeing the widget snap to its
former size after back to front transition kind of looks like a design
flaw. Do you see what I mean? Should there be an enhancement request
for for resizing before performTransition? Or, would having a
"transitionFinished" notification make the resize much less
visible because of the improved timing?
Thanks,
Chuck
At 2:40 PM -0800 11/4/05, Matt Drance
wrote:
Hi Chuck,
You can use the Stretcher example to get
to the correct size before the transition. Since the Stretcher
has a callback for a completed stretch, you can do the following:
1) info button click starts the
stretch
2) stretch to desired size; stretch
callback performs transition
When going back to the front, you can do
a delayed "shrink" that will go back to the appropriate
front height after the front transition is complete, like below.
This is a little sketchy because it assumes a specific time interval
for the transition to be performed. There is already an
enhancement request for a "transitionFinished" notification
which would make this less sketchy.
This message is a little long - feel free
to just read the last paragraph.
I have a widget has a variable height on
the front and a fixed height for the backside. When the front is
taller than the back, I have a problem flipping the widget from back
to front.
It doesn't appear to be possible to
increase the height of the widget before preparing or performing the
transition from back to front. Because of this, the flip transition is
not smooth at all. I see the first half of the back to front
transition animation then the front suddenly appears.
The work-around to this problem is to use
the same height for the front and the backside whenever the front is
taller than the back. This is the approach that the Stocks widget
takes. The purpose of the resizedWhenFlippedOver boolean in Stocks.js
is to remember when the front is shorter than the back otherwise the
height of the backside is not resized during front to back
transitions. This can be verified by doing the following:
- use seven or more stock
symbols.
- flip the Stocks to its
backside.
- mouse down on the widget and
deactivate the dashboard to bring the widget to the desktop (you need
to have debugmode turned on).
- Capture the window using Grab.
Notice that the height of the backside
graphic equals the height of the front side.
The reason that I don't want to use this
work-around is because I need to have backside elements that are
offset from the bottom of the widget not the top.
Is it possible to increase the height of
the widget during back to front transition and have smooth animation
of the flip? The fact that the Stocks widget uses a special case to
avoid that scenario suggests that this is not possible. Does anyone
know otherwise? If not, I can file a bug report.
Chuck
_______________________________________________
Do not post admin requests to the list.
They will be ignored.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Dashboard-dev mailing list
(email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/dashboard-dev/chucks2%40veladg.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Dashboard-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/dashboard-dev/email@hidden
This email sent to email@hidden
