Palette trackpad interaction: they don't close after clicking items

[greenfeld]

The buddy menu palette for other users in the Neighborhood view does not close or otherwise acknowledge menu items being selected in OLPC 13.1.0 os12.

It just stays on screen with no changes appearing after clicking, even if the "Add {Remove} Friend" button is clicked multiple times or the "Invite to {Activity}" button is clicked (this menu item sometimes features the shared activity's icon twice).

[garycmartin]

13.1.0 build 12, XO-1.75 and XO-4:

Clarification, on testing here, this appears to be for trackpad/mouse cursor interaction only. Testing with touch screen interaction, the buddy menu palette for other users correctly closes after making an entry selection (Add friend, Remove friend, Invite to {activity}).

[manuq]

This is affecting also other palettes, for example the owner icon one:

1. open the palette of the owner (central) icon
2. click on My Settings
3. close My Settings without opening other palettes

The palette is still there.

[erikos]

Replying to manuq:

This is affecting also other palettes, for example the owner icon one:

1. open the palette of the owner (central) icon
2. click on My Settings
3. close My Settings without opening other palettes

The palette is still there.

Hmm, I can not reproduce that all the time. In the case where I reproduced, the icon had as well the 'clicked'-state background colour which does stay even so the Palette is down now.

Actually the way of reproducing this for the owner icon is:

• open owner Palette with the mouse and click on 'My settings'

• close the CP with touch

• the Palette stays open then because the mouse is still over it

[erikos]

Actually see as well #4191.

[manuq]

Patch.

[manuq]

Replying to erikos:

Hmm, I can not reproduce that all the time.

The buddy palette is dismissed if another palette pops up. Probably the tooltip of the X close icon of the control panel is catching you. If I close the CP fast enough so that the tooltip does not appear, I hit the issue every time.

Actually the way of reproducing this for the owner icon is:

• open owner Palette with the mouse and click on 'My settings'

• close the CP with touch

• the Palette stays open then because the mouse is still over it

Yes, closing it by touch doesn't pop up the tooltip and you can always reproduce the bug too.

[manuq]

The attached patch fixes the issue for the Buddy icons, and #4191 is another case of the same issue but for the AP icons in the neighborhood.

The current implementation of the palette requires that we explicitly call the popdown method of the palette after each item is activated. This affects the mouse interaction, in touch interaction the palette
is dismissed correctly.

I hope we can get to a more general fix, although this might require an API change in the palette. I'm looking for this.

A more detailed description: With mouse interaction, palettes are not dismissed when an item is activated. But the callback is called, even if the change is not reflected in the palette left opened ("Remove friend" in neighborhood, for example). There is nothing special in the logs, the palette just stays.

One can be mislead because sometimes it seems to work: for example seems to work fine for "Remove friend" in groups view, but what happens is that the palette goes away with the icon.

[manuq]

Trying a more general solution, toolkit patch.

[manuq]

Trying a more general solution, shell patch.

[manuq]

Trying a more general solution: we could connect a callback for the item 'activate' signal in the palette, and call popdown from it. Unfortunatly this needs some API change, so I think we are safer calling the popdown explicitly (first patch).

Anyways, leaving a note here of what I've tried.

My first attempt: Palette.set_content() is always receiving a widget that is a Gtk.Container, like Gtk.VBox. So first I tried to connect the palette to the 'add' signal [1], so that each time an item is added, we connect its 'activate' signal to the palette. But turns out the callback is not called for pack_start/pack_end, only for add. So, there isn't a signal we can listen for when a widget is packed. Testcase: [2].

[1] ​http://developer.gnome.org/gtk3/stable/GtkContainer.html#GtkContainer-add
[2] ​http://dev.laptop.org/~manuq/shell-port/test_add.py

So I did a fix only for when the palette content is a PaletteMenuBox, and the PaletteMenuItems are added to it using the append_item() method. This requires API change. The two patches above shows this work for the Buddy palette.

[erikos]

Popdown the palette if an item in the content box gets activated (toolkit)

[erikos]

Adapt to PaletteMenu changes for popdown on item activation (shell)

[manuq]

Browse adapt patch.

[manuq]

Simon general solution is working great. I added a patch to adapt Browse.

[manuq]

Pushed Browse one as 343f6543 .

[erikos]

toolkit: f5fee8a1445f76d3b04497671a93179329fe1efb

shell: cb8b42ad069fbd067b4963c29993451b510b944d

browse: 343f65430a738bdf0b574be3fb47532f0a653fc7

[dsd]

I'll assume that Browse-149 is proposed for 13.1.0 inclusion as a result of this work. (see ​http://wiki.laptop.org/go/13.1.0#Activity_inclusion_process for how to request this at this point)

[dsd]

Maybe not. Browse-49 doesn't appear to be released as an activity bundle yet.

[manuq]

Replying to dsd:

Maybe not. Browse-49 doesn't appear to be released as an activity bundle yet.

Now it is, sorry about that, please include as per the reasonings above: sync with palettes change in toolkit, remove explicit popdown of palettes.

[greenfeld]

Browse 149 is in 13.1.0 os21 (os20 had 148) with Sugar 0.98.3.

In general palettes/menus seem to be closing properly.

[dnarvaez]

Milestone 0.98 deleted