Bug 13725 - Revise All Showbriefly transitions on screen to fade in
: Revise All Showbriefly transitions on screen to fade in
Status: NEW
Product: SqueezePlay
Classification: Unclassified
Component: UI Skin
: unspecified
: Other Other
: P5 normal (vote)
: ---
Assigned To: Felix Mueller
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-27 12:45 UTC by ndijulio
Modified: 2011-01-14 06:15 UTC (History)
4 users (show)

See Also:
Category: Bug


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ndijulio 2009-08-27 12:45:24 UTC
Update showbriefly (pop-up window) from slide up from bottom to fade in.  We can adjust the timing of the fade, etc. later, however, we need to move to consistent transition for all popup's, context menus, etc.  The current behavior is a carry over from the original Jive skin...
Comment 1 ndijulio 2009-08-27 12:46:34 UTC
Matt- please revise the target/assign for this bug as you see fit...
Comment 2 Weldon Matt 2009-08-27 13:24:46 UTC
Agreed, this actually applies to all showbrieflies and context menus.  We probably want a very quick fade; not so long as to impact usability, but long enough to notice it's there.

It should feel "snappy."

Rough guess for a starting point: .5 sec? As noah implies, we'll need to play around with it.
Comment 3 Ben Klaas 2009-08-27 13:31:01 UTC
I'll have an initial checkin here after our bugzilla DB woes are fixed, but it won't be entirely what's desired.

I've got the pop-from-bottom removed, but the fade in transition doesn't work at all, and probably won't without some lower level work. The issue is that the fadeIn/fadeOut code is expecting a window of the same size as the previous window (hard to explain, but consider what's happening at the pixel level on a fade transition). Since the showBriefly is smaller than that, the transition code currently fails. Result is that it just appears immediately in the center of the screen, and disappears as abruptly.

If a real fade is important for the UI, I think this bug will have to get pushed to maybe Richard.
Comment 4 ndijulio 2009-08-27 13:38:40 UTC
This actually explains a lot!  Thank you Ben.  The level of refinement or control you describe below is exactly what we need moving forward in many areas.  This type of control is especially important for touch interfaces.  

Can we make sure this support is at the latest achieved by 8.0?  Not sure of the time it would take to implement...
Comment 5 Ben Klaas 2009-08-27 13:51:41 UTC
FWIW, the change from pop-from-bottom to no-transition is still a marked improvement IMO.
Comment 6 SVN Bot 2009-08-27 14:20:24 UTC
 == Auto-comment from SVN commit #7288 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7288 ==

Bug: 13725
Description: remove bottom up window transition on showBrieflies.

This may be as good as it gets for 7.4...I've specified the window transitions to be FadeIn and FadeOut, but they don't actually work because the showBriefly is not the size of the window below it, which causes the transition effect to not happen. So it just appears immediately on screen without a fade effect. Slide up from the bottom is gone though.
Comment 7 Jim McAtee 2009-08-27 15:34:08 UTC
I think this is a very good idea.  I would also suggest re-examining the need for transparency in any of the showbrieflies.  IMO, the transparency is distracting, with the background text often appearing like grayed text in the box.  With a fade in, the transparency effect is unnecessary.
Comment 8 SVN Bot 2009-09-09 13:14:14 UTC
 == Auto-comment from SVN commit #7478 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7478 ==

Bug: 13725
Description: volume and scanner popups no pop up/down from bottom. replaced with no transition, which IMO works much better after the toast redesign.
Comment 9 Ben Klaas 2009-09-09 13:16:27 UTC
I believe the last checkin pushes this off the P2 list.
Comment 10 Ben Klaas 2009-10-02 11:36:00 UTC
IIRC, FadeIn is not trivial with a window that doesn't take up the entire screen

Pass to Richard for comment
Comment 11 Chris Owens 2009-10-21 09:47:50 UTC
Moving these bugs to P4 to make room for moving P1.5 bugs to P2
Comment 12 Pat Ransil 2009-10-23 05:09:49 UTC
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Comment 13 Chris Owens 2010-03-08 11:33:12 UTC
Moving lower-priority bugs to next target