[Dextrose 2] Secondary palette appears too soon on Neighborhood view buddy icons

[FGrose]

Observed on Dextrose 2 build 1dx2 Dextrose 2 International running on an XO-1.

When hovering an XO figure in the Neighborhood view, the extended palette appears almost instantly. This can be distracting when the intent is only to determine the name of the Learner, and also obscures more of the view than necessary for the task.

I would suggest that a slightly longer delay (perhaps 0.5 second) before showing the secondary palette and a similar delay before the name palette disappears.

One should be able to hover until the name palette appears, then move the pointer away to avoid revealing the secondary palette. The name palette would then disappear after about a half second. This method works well in OLPC build 802.

[bernie]

This is an intentional change, the result of this experimental patch proposed by Michael Stone:

 http://git.sugarlabs.org/projects/dextrose/repos/mainline/blobs/master/rpms/sugar-toolkit/kill-the-delayed-menus-for-good.patch

Some people seem like it, some don't. The patch has been included in Dextrose long time ago to observe the reaction of users. I asked my 5th grade testers whether they liked it more this way or the way it was before, but they couldn't tell. Apparently, this change is too subtle for non technical users to consciously notice it.

The delay parameter is global for all palettes. Would you be ok if all menus became slower as they were in 802? You can experiment with the timeout by editing the value of _secondary_anim at approx line 106 of

/usr/lib/python2.6/site-packages/sugar/graphics/palette.py

After waiting for some feedback, I'd be ok with increasing the timeout of the secondary palette from 0.0 to 0.5.

[FGrose]

I've done some testing with Dextrose 2 build 1dx2 Dextrose 2 International running on an XO-1 and with Sugar 0.89.10 in a Xephr window on Fedora 14 beta (kernel 2.6.35.4-28.fc14.x86_64) in an 3.2-GHz, 3.3-GByte RAM workstation.

I tried these settings:

(in palettewindow.py) 0.0 to 0.6 seconds

self._popdown_anim = animator.Animator(0.6, 10)

The behavior varies with the processor and environment.

There is sufficient delay in system overhead for the primary palette popup,

self._popup_anim = animator.Animator(0.0, 10)

to use the 0.0 second delay and still allow one to move the mouse pointer casually over buddies or access points without revealing the name for every target annoyingly.

The popdown delay of 0.6 second allows one to hover a target, reveal just the name, and then move the pointer away, and still have sufficient time to read the name. (Setting this popdown delay to 0.0 second as proposed in  http://bugs.sugarlabs.org/attachment/ticket/1169/0001-Reduction-in-the-time-taken-for-loading-of-the-menu-.2.patch (ticket #1169) is too short to comfortably read the name before the palette is dismissed.)

I tried these settings:
(in palette.py) 0.0 to 1.0 seconds

self._secondary_anim = animator.Animator(1.0, 10)

Here the different processors and environments had a greater effect.

On the XO-1 the secondary palette could be delayed only 0.6 second and usually one could move the pointer away from the target to avoid showing the secondary palette, but in the Xephyr window, delays less than 1.0 second would usually cause the secondary palette to be revealed briefly, and distractingly.

In summary,

self._popup_anim = animator.Animator(0.0, 10)
self._popdown_anim = animator.Animator(0.6, 10)

self._secondary_anim = animator.Animator(1.0, 10)

are the settings I would recommend based on these tests.

The 1.0 second delay for the secondary palette popup is beyond the 0.5 second limit that was suggested, but does help with discoverability (as suggested in ticket #1169), and avoids the surplus exposure of information for the Neighborhood view use case.

[smparrish]

Bernie are you ok to go with the fgrose's recommended settings?

[bernie]

Replying to smparrish:

Bernie are you ok to go with the fgrose's recommended settings?

Sorry for not replying sooner. I was intending to try it out on my laptop first, but I can't seem to find the time.

I suppose we could tweak the values as recommended by FGrose and wait for you to issue the next test build to see what happens. To see if users notice any difference, let's not say anything in the release notes. Because these things are very subliminal...

[smparrish]

Made the change today and its included in os3dx2. Will wait a few weeks and if we get no complaints will close this issue.

[mtd]

Replying to bernie:

This is an intentional change, the result of this experimental patch proposed by Michael Stone:

 http://git.sugarlabs.org/projects/dextrose/repos/mainline/blobs/master/rpms/sugar-toolkit/kill-the-delayed-menus-for-good.patch

Some people seem like it, some don't.

Some discussion is here:  http://lists.sugarlabs.org/archive/sugar-devel/2009-October/020141.html