Re: Touch selections

[Carlos Garnacho <carlosg gnome org>]

Hey Matthias,

On jue, 2013-01-17 at 22:32 -0500, Matthias Clasen wrote:
> Hey,
> 
> I've now taken a look at the code, here are some impressions:
> 
> GtkBubbleWindow looks interesting and somewhat similar to two things
> that have been discussed:
>     a) a "PopupWindow" class to replace grabs (e.g. on wayland)
>     b) a "popover" widget that behaves like a transient overlay
> (without being its own toplevel)
> We should keep this private until we've worked out how it
> overlaps/interacts with these usecases.

Hmm, indeed, bubble window sits a bit between both. As for a), some
aspects of the behavior defined in the whiteboard benefit from not
having active grabs (especially the "selection is manipulable when popup
is shown" bit), and otoh I think Wayland can't separate popup/grab
behaviors. Making it more similar to b) sounds worthwhile.

> 
> I'm not really convinced of some of the choices made in the
> GtkSelectionWindow class:
>    a) a toolbar may not be the right container for what the designers
> had in mind - there was some talk of scrolling

Right, on earlier stages I also found myself wondering what could fit
best here, the options seem to be:
  * Adding scrolling capabilities to toolbars
  * Making an entirely different widget

Given the requirement for scrolling is somewhat artificial (popup would
never be as wide as the screen) and that cramming enough items there is
a symptom of usability disaster, the second option seemed too far
stretched for the case. Probably an useless observation in the end, but
I see similarities between GtkPathBar scrolling and how it should
look/work here.

>    b) doesn't seem necessary to use a ui manager and actions here,
> since you are not even allowing addition of actions
>    c) adding a public getter for the toolbar will make it impossible
> for us to change the implementation strategy later

I made it this way so this is parallel to ::populate-menu, from all
possible compromises might have been the worst decision. As you mention
below, GMenuModel seems the hip way to go, but those don't map to
toolbars (Is there any rationale here? I seem to have missed this), the
third option is exposing UIManager bits to allow merging, but I'm unsure
about its life expectancy with GMenuModel in place.

>    d) I'm not convinced the special-casing of cut/copy/paste is really
> worth it - I would just have added these action in
> GtkEntry/GtkTextView
> I recommend dropping this widget altogether for now, and just
> construct the toolbar with the default actions directly in
> GtkEntry/GtkTextView.

I'm not against that, it struck me as slightly useful to have a default
ordering/toolbar style for those, it could also be made private for
those to use.

> 
> In GtkEntry, I think the use of g_timeout_add_seconds for popping up
> the selection is inappropriate - you don't want the delay to fluctuate
> depending on whether you touch early or late in the second.

Oh right, I'll change that

> 
> It would be nice if we could reuse the ::populate-popup signals to
> allow custom actions to be added; unfortunately, all existing users of
> this signal expect to add menuitems to a menu. One possibility might
> be to add a set_context_menu_model() function that takes a GMenuModel,
> which could be used to populate the traditional context menu, or to
> build something toolbar-like for your popup. Of course menumodel and
> toolbar is not a perfect fit, either.

And that last thing is the source of all dilemmas :)

  Carlos