Bug 4619 - (int-139107) Panning and selecting are mutually exclusive
(int-139107)
: Panning and selecting are mutually exclusive
Status: RESOLVED FIXED
Product: Desktop platform
hildon-widgets
: 5.0/(2.2009.51-1)
: All Maemo
: Medium major with 25 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: Claudio Saavedra
: hildon-libs-bugs
:
:
:
: 5033 6158
  Show dependency tree
 
Reported: 2009-06-02 19:27 UTC by Cornelius Hald
Modified: 2010-03-15 20:53 UTC (History)
18 users (show)

See Also:


Attachments
Add support for a selection mode, initial proposal (9.26 KB, patch)
2009-06-12 14:51 UTC, Alejandro G. Castro
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Cornelius Hald (reporter) 2009-06-02 19:27:34 UTC
STEPS TO REPRODUCE THE PROBLEM:
Create a HildonTextView inside a PannableArea. Then try panning. Then try
selecting text using the touchscreen/mouse.

EXPECTED OUTCOME:
There should be a way to switch between the two modes. Selecting or panning.
This could be solved by:
1) Using a mechanism like the Diablo web browser. Tap and move is panning.
Double-Tap and move is selecting.
2) At least some API to easily switch between those two modes. Then a developer
could create a button that switches between those modes. Or he could use
selecting/editing in landscape mode and panning/reading in portrait mode.

ACTUAL OUTCOME:
Selecting text is not possible. Tapping the screen and moving it will always
result in panning, not in selecting text.

REPRODUCIBILITY:
always
Comment 1 Alberto Garcia Gonzalez 2009-06-02 19:48:27 UTC
Adding myself to Cc
Comment 2 Brent Chiodo 2009-06-02 20:16:09 UTC
*** This bug has been confirmed by popular vote. ***
Comment 3 Brent Chiodo 2009-06-02 20:20:51 UTC
Idealy, there could be convenience functions to go enable two-tap selecting or
go into selection mode.
Comment 4 Alejandro G. Castro 2009-06-02 20:35:00 UTC
Maybe you can get 2) setting to FALSE the enabled property of the pannable,
although it is currently limited the selection of the hildontextview even if
you disable panning. If 2) is ok we could create a textview property to control
the selection instead of just disabling it always.

Option number 1) will require a new mode in the pannable, apparently not
complex to implement, although playing with pannable events is always painful.
And of course we would have to change textview to allow selection.

Adding myself to CC.
Comment 5 Till Harbaum 2009-06-09 22:18:13 UTC
I've been told that the pannableareas "enabled" property can be used to switch
between selection/pan mode. 

Now the question is where to put the necessary switch. I really don't want to
waste screen space with this, so i'd prefer a little GtkToggleButton with an
icon (like in fremantles osso-xterm) placed on op the upper left corner of the
pannable area. But it seems gtk won't let me.

How do i place a button on top of the pannable area?
Comment 6 Valério Valério maemo.org 2009-06-11 02:27:44 UTC
Adding myself to Cc
Comment 7 Cornelius Hald (reporter) 2009-06-11 10:58:34 UTC
(In reply to comment #5)
> I've been told that the pannableareas "enabled" property can be used to switch
> between selection/pan mode. 

I was just testing this and it does not work.
If you set the "enabled" property to false, the scrolling is disabled, but
selection still doesn't work.
Comment 8 Alejandro G. Castro 2009-06-12 14:51:40 UTC
Created an attachment (id=1224) [details]
Add support for a selection mode, initial proposal

This patch adds support for a new mode in the pannable area (the attribute
selection_mode would be a proper property in the lats patch). Basically what we
do if selection_mode is on is that we detect the double click to avoid panning,
and just send the motion_notifies in that moment (probably this is not required
due to the grabs but I guess it could be safer for the widgets doing the
selection). I selection_mode is off the widget is what we have today.

Take into account if you want to test the patch you would have to modify the
textview button press and handle the GDK_2BUTTON_PRESS event properly to start
selection, and of course avoid using the GDK_BUTTON_PRESS to start selection.

Feedback welcome, comments, rants, etc. ;)
Comment 9 Cornelius Hald (reporter) 2009-06-16 12:49:23 UTC
Thank you very much for this patch. It's good to see that bug reports are taken
seriously :)

> Take into account if you want to test the patch you would have to modify the
> textview button press and handle the GDK_2BUTTON_PRESS event properly to start
> selection, and of course avoid using the GDK_BUTTON_PRESS to start selection.

I'm not sure I understand that. Would this procedure be only required for
testing now, or will we have to do that on the final version too? Or formulated
differently: Will the text view get patched too?
Comment 10 Alejandro G. Castro 2009-06-19 11:13:28 UTC
(In reply to comment #9)
> > Take into account if you want to test the patch you would have to modify the
> > textview button press and handle the GDK_2BUTTON_PRESS  event properly to start
> > selection, and of course avoid using the GDK_BUTTON_PRESS to start selection.
>
> I'm not sure I understand that. Would this procedure be only required for
> testing now, or will we have to do that on the final version too? Or formulated
> differently: Will the text view get patched too?
>

We will have to patch the hildontextview to start the selection with
the GDK_2BUTTON_PRESS, if we leave hildontextview as it is now or what
gtktextview is doing it is not going to work. Hildontextview is just
not doing selection at all, and gtktextview is doing selection using
motions events after the first click (using a grab) which will cause
problems to the pannable because motion events will not arrive pannable.
Comment 11 Cornelius Hald (reporter) 2009-06-19 11:39:52 UTC
(In reply to comment #10)
> We will have to patch the hildontextview to start the selection with
> the GDK_2BUTTON_PRESS, if we leave hildontextview as it is now or what
> gtktextview is doing it is not going to work. Hildontextview is just
> not doing selection at all, and gtktextview is doing selection using
> motions events after the first click (using a grab) which will cause
> problems to the pannable because motion events will not arrive pannable.

Thanks for the clarification! Then that sounds like a very good solution to me
:)
Comment 12 Cornelius Hald (reporter) 2009-09-09 18:49:26 UTC
Are there any updates on that? I'll have to make a decision soon on how to
implement that in my app.
Comment 13 Alejandro G. Castro 2009-09-10 11:33:21 UTC
(In reply to comment #12)
> Are there any updates on that? I'll have to make a decision soon on how to
> implement that in my app.
> 

I would like to have a clear answer about this but I'm afraid there is no
agreement about the gesture to start a selection, the other proposal I heard is
to activate a selection mode from the application. Currently using the keyboard
keys to copy/paste is the option in the toolkit when panning is present.

I hope it helps.
Comment 14 Cornelius Hald (reporter) 2009-09-10 14:50:00 UTC
(In reply to comment #13)
> I would like to have a clear answer about this but I'm afraid there is no
> agreement about the gesture to start a selection, the other proposal I heard is
> to activate a selection mode from the application. Currently using the keyboard
> keys to copy/paste is the option in the toolkit when panning is present.

Ok, I see that there seems to be no consensus on how exactly the switching
between the two modes should be implemented in an application. Well, I decided
(at least for now) to go with a simple button on the toolbar.

The problem is, that I cannot figure out how to enable the selection-mode at
all. I'm on the Beta2 SDK and I can disable panning on the PannableArea, but
still the selection does not work.

I tried it with:
g_object_set(area, "enabled", FALSE, NULL);

But all it does is disabling panning. How do I enable selection?
Comment 15 Alejandro G. Castro 2009-09-10 15:16:37 UTC
(In reply to comment #14)
>
> [...]
> 
> The problem is, that I cannot figure out how to enable the selection-mode at
> all. I'm on the Beta2 SDK and I can disable panning on the PannableArea, but
> still the selection does not work.
> 
> I tried it with:
> g_object_set(area, "enabled", FALSE, NULL);
> 
> But all it does is disabling panning. How do I enable selection?
> 

The selection has to be activated in the widget inside the pannable area, if
you are using a hildontextview there is no way to do it IIRC, the selection
code is not in the widget, you can check the button-press/release callbacks.
Recall that other parts of the platform will use the keyboard selection in this
moment, so I would say it is not a bad option to use it in all the platform.  

Anyway you could try to use gtktextview to avoid this (check if it is ok). I
guess hildontextview should have API to activate and deactivate it in the
future when we decide about how to implement the selection.
Comment 16 Cornelius Hald (reporter) 2009-09-10 15:52:54 UTC
(In reply to comment #15)
> The selection has to be activated in the widget inside the pannable area, if
> you are using a hildontextview there is no way to do it IIRC, the selection
> code is not in the widget, you can check the button-press/release callbacks.

You're right. Thanks for the information.

> Recall that other parts of the platform will use the keyboard selection in this
> moment, so I would say it is not a bad option to use it in all the platform.  

The browser is using a mouse gesture + button. Osso-xterm is using a button on
the toolbar. Other apps with selection I don't know, but there are many use
cases where it makes sense to select text without having the keyboard out.

> Anyway you could try to use gtktextview to avoid this (check if it is ok). I
> guess hildontextview should have API to activate and deactivate it in the
> future when we decide about how to implement the selection.

Using GtkTextView is not really an option. It looks bad (no round corners etc.)
and the panning does not work. Well, but at least selection is working :)

I think the API should be added to HildonTextView now. A simple property like
'panning' yes/no would be enough. If it's just an addition it shouldn't break
API nor ABI.
IMO it's much better to have this support in the API even if it's not
standardized how it should be used (from a HIG point of view). This property
can be used together with a button, a gesture, a menu entry or something else.
So I guess it would make sense to add it as soon as possible. What do you
think?
Comment 17 Alejandro G. Castro 2009-09-24 17:58:19 UTC
(In reply to comment #16)
>
> [...]
>
> > Anyway you could try to use gtktextview to avoid this (check if it is ok). I
> > guess hildontextview should have API to activate and deactivate it in the
> > future when we decide about how to implement the selection.
> 
> Using GtkTextView is not really an option. It looks bad (no round corners etc.)
> and the panning does not work. Well, but at least selection is working :)
> 
> I think the API should be added to HildonTextView now. A simple property like
> 'panning' yes/no would be enough. If it's just an addition it shouldn't break
> API nor ABI.
> IMO it's much better to have this support in the API even if it's not
> standardized how it should be used (from a HIG point of view). This property
> can be used together with a button, a gesture, a menu entry or something else.
> So I guess it would make sense to add it as soon as possible. What do you
> think?
> 

Sorry for the delay, we had a long debate about this with Nokia people. After
all the debate we are considering to check the shift+tap gesture to do the
selection inside the pannable area, we are already checking the widgets that
would have to be reviewed. This will mean you will not need that API in the
textview. Thanks for the comments and help so far :).
Comment 18 Cornelius Hald (reporter) 2009-09-25 10:28:18 UTC
> Sorry for the delay, we had a long debate about this with Nokia people. After
> all the debate we are considering to check the shift+tap gesture to do the
> selection inside the pannable area, we are already checking the widgets that
> would have to be reviewed. This will mean you will not need that API in the
> textview. Thanks for the comments and help so far :).

This is of course very good news, thank you very much - but (sorry for being an
ass) I still think that an API should be in place.

There might be use cases where someone wants to implement selection without the
need of a keyboard. For example someone reads a text. Now he wants to select
some important text and press the 'bold' button on the toolbar. With the
Shift+Tap solution he would first have to open the keyboard. But, for example,
a 'lock panning' button on the toolbar would be fine for this use case.

So please just give us a property to toggle between modes. You have to
implement the functionality anyways, so why not just expose it to us
developers? Please consider this.

Thanks!
Conny
Comment 19 Alejandro Piñeiro Iglesias 2009-09-25 13:19:08 UTC
(In reply to comment #18)

> So please just give us a property to toggle between modes. You have to
> implement the functionality anyways, so why not just expose it to us
> developers? Please consider this.

I bet that Alex suggested that for simplicity reasons, in order to have the
selection, and allow that the application developer wouldn't need to make extra
changes. 

But probably your suggestion is a good idea, have the "Shif+Click" as the
default way to activate the selection mode (on pannable+underlying widget), but
have a optional way to have that. Anyway, take into account that probably that
this will mean a API in both widgets, the pannable and the underlying one. 

We will consider it, although step by step, as adding this feature as
configurable could add some extra complexity.
Comment 20 Lucas Maneos 2009-09-25 13:25:08 UTC
In the long run there should be a way to toggle modes without shift or other
hardware buttons (there have been several hints dropped of future Maemo devices
without a physical keyboard).
Comment 21 Cornelius Hald (reporter) 2009-09-25 13:36:10 UTC
(In reply to comment #19)
> I bet that Alex suggested that for simplicity reasons, in order to have the
> selection, and allow that the application developer wouldn't need to make extra
> changes. 
> 
> But probably your suggestion is a good idea, have the "Shif+Click" as the
> default way to activate the selection mode (on pannable+underlying widget), but
> have a optional way to have that. Anyway, take into account that probably that
> this will mean a API in both widgets, the pannable and the underlying one. 
> 
> We will consider it, although step by step, as adding this feature as
> configurable could add some extra complexity.

Thanks, this is very much appreciated. And of course as default the Shift+Tap
is probably a good one :)
Comment 22 Lucas Maneos 2009-10-13 06:05:05 UTC
*** Bug 5360 has been marked as a duplicate of this bug. ***
Comment 23 Quim Gil nokia 2009-10-14 08:16:22 UTC
Setting target milestone to reflect that we are looking at this.
Comment 24 Xabier Rodríguez Calvar 2009-12-09 17:48:36 UTC
I am glad to announce that this is FIXED:

Committed to http://maemo.gitorious.org/hildon/hildon/commits/master and
http://maemo.gitorious.org/hildon/hildon/commits/hildon-2-2 .

GtkHTML patch was committed too.

I guess the bug will be closed when this is integrated.
Comment 25 Xabier Rodríguez Calvar 2009-12-09 17:51:20 UTC
(In reply to comment #24)
> I am glad to announce that this is FIXED:

BTW, we did it by pressing Shift key.
Comment 26 Till Harbaum 2009-12-09 21:35:23 UTC
Is there a property to switch between selection and panning? I e.g. like the
idea to use the tap-n-hold feature to switch between both modes and this would
also work on machines without keyboard or with the keyboard being closed.

Anyway, this is great news and GPXView will really have a use for this (and
also for the gtkhtml solution). And idea then we'll see this via SSU?

Till
Comment 27 Xabier Rodríguez Calvar 2009-12-10 14:45:24 UTC
(In reply to comment #26)
> Is there a property to switch between selection and panning? I e.g. like the
> idea to use the tap-n-hold feature to switch between both modes and this would
> also work on machines without keyboard or with the keyboard being closed.

No, this is not possible in HildonPannableArea nor HildonTextView. Shift stops
panning in the pannable and it is also necessary to press shift to select in
the textview even when it is not attached to a pannable. This was made this way
because any other solution would require API changes either in the textview or
pannable (or dirtiest hacks ever) as pannable would need to tell the textarea
that it is contained in a pannable or viceversa.

Do you mean a property so that the programmer can force it? I don't think it is
a good idea as you'd need to add the property both in the pannable and textview
and handle both at the same time because of the reason I explained above and it
could lead to big problems.

> Anyway, this is great news and GPXView will really have a use for this (and
> also for the gtkhtml solution). And idea then we'll see this via SSU?

And now you mention it, the property would also require changes in GtkHTML too.

About it in SSU, I'll guess it will be sooner or later.
Comment 28 Andre Klapper maemo.org 2009-12-10 15:11:54 UTC
*** Bug 6681 has been marked as a duplicate of this bug. ***
Comment 29 Till Harbaum 2010-01-07 18:05:13 UTC
> pannable (or dirtiest hacks ever) as pannable would need to tell the textarea
> that it is contained in a pannable or viceversa.

Dirty hacks? It's my understanding that this is pretty normal as e.g. textviews
embedded into scrolledwindows also establish some kind of direct link to e.g.
allow the textview to request the scrolledwindow to scroll to a certain row.
That's why e.g. textviews inside some other container which in turn reside
inside a scrolledwindow will not correctly work anymore.

I don't see a fundamental difference when creating a similar mechanism to make
the pannablearea and the textview/gtkhtml view know each other.

I do understand that this is additional work. But it seems that any burden
taken from application developers to the framework developers has several
advantages:

- It reduces the total development cost (as everything only happens once inside
the framework)

- It will give users a consistent experience as everything works the same
everytime. Any functionality not provided by the framework will result in app
developers creating individual solutions/workarounds. It seems to be your hope
that people will accept limitations like this instead of working around them,
but that's imho not true and i myself will e.g. try to make my apps finger
friendly and allow copy'n paste without the need to use the keyboard
Comment 30 Tim Watt 2010-01-11 05:54:28 UTC
I had the same problem, Instinctively I tried to get the mouse by sliding in
from the let as you do in the browser.
Comment 31 Xabier Rodríguez Calvar 2010-01-11 10:59:07 UTC
(In reply to comment #29)
> Dirty hacks? It's my understanding that this is pretty normal as e.g. textviews
> embedded into scrolledwindows also establish some kind of direct link to e.g.
> allow the textview to request the scrolledwindow to scroll to a certain row.
> That's why e.g. textviews inside some other container which in turn reside
> inside a scrolledwindow will not correctly work anymore.

Widgets exchange adjustments with parent containers and that's the
general mechanism which happens between a general container and a
widget. Doing what you proposed (and we had already discussed and
discarded), would need to check in this process of setting adjustments
that we explicitely check packing the textview inside a pannable and
then disabling the selection without shift which would be a dirty hack
(at least, IMHO). Other issue is what do we do with complex container
widget/structures? Should we transverse the structure checking if it
is valid por panning or for selection without shift? That would be for
sure the dirtiest hack ever.

> I don't see a fundamental difference when creating a similar mechanism to make
> the pannablearea and the textview/gtkhtml view know each other.

I already thought about this too. We wouldn't need an api change but
we should let apps decide how the text view would behave (panning or
selection) thru a property, for example. The problem would be what
would be the default behavior when we have so many apps already
built. If you say that default is selection, then you would have bugs
as many apps would stop working and if you do the opposite, when you
wouldn't be giving many apps the feature of selection unless they
change it, so it wouldn't be just something done in the framework and
it would require any action by apps developers. That's the reason why
we decided for the intermediate solution, which was giving selection
with shift, which doesn't cause any problem.

> - It will give users a consistent experience as everything works the same
> everytime. Any functionality not provided by the framework will result in app
> developers creating individual solutions/workarounds. It seems to be your hope
> that people will accept limitations like this instead of working around them,
> but that's imho not true and i myself will e.g. try to make my apps finger
> friendly and allow copy'n paste without the need to use the keyboard

I am not sure if the experience would be consistent enough because in
some cases, you would have selection and in other cases (when the
widget is inside a pannable, you would have to press shift) and think
of a case of a text view meant to grow a lot. You would need to pack
it inside a pannable so that user can pan and see the bottom, but at a
first glance nothing would stop you of thinking that selection would
be perfectly possible and that would indeed create a feeling of
inconsistency.

Sorry for the delay. I already had answer this but something happened
and the comment did't get posted.
Comment 32 Cornelius Hald (reporter) 2010-01-11 18:03:33 UTC
(In reply to comment #31)
> I already thought about this too. We wouldn't need an api change but
> we should let apps decide how the text view would behave (panning or
> selection) thru a property, for example. The problem would be what
> would be the default behavior when we have so many apps already
> built. If you say that default is selection, then you would have bugs
> as many apps would stop working and if you do the opposite, when you
> wouldn't be giving many apps the feature of selection unless they
> change it, so it wouldn't be just something done in the framework and
> it would require any action by apps developers. That's the reason why
> we decided for the intermediate solution, which was giving selection
> with shift, which doesn't cause any problem.

I think the default should be that the selection is off, like it is now. As you
said, if you would change the default, many existing applications would break.

But having a property turn on selection would be great. If there would be such
a property, I would reimplement this slide-from-left behavior of the browser
and add it to Conboy. I actually have many complaints that it does not work or
even requests on how to select text at all.

Of course it´s then still the responsibility of the application developer to
expose this feature somehow (add a button somewhere) but I think many
developers would make use of it. At least I would :)
Comment 33 Andre Klapper maemo.org 2010-01-12 13:18:18 UTC
This has been fixed in package
gtkhtml3.14 3.24.4-osso16+0m5
which is part of the internal build version
2010.01-6
(Note: 2009 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 34 Cornelius Hald (reporter) 2010-02-10 11:18:52 UTC
(In reply to comment #33)
> This has been fixed in package
> gtkhtml3.14 3.24.4-osso16+0m5

What about HildonTextView? It is part of Hildon not of GtkHtml. Is it fixed as
well or is only the GtkHtml part fixed?
Comment 35 Xabier Rodríguez Calvar 2010-02-10 11:28:13 UTC
(In reply to comment #34)
> (In reply to comment #33)
> > This has been fixed in package
> > gtkhtml3.14 3.24.4-osso16+0m5
> 
> What about HildonTextView? It is part of Hildon not of GtkHtml. Is it fixed as
> well or is only the GtkHtml part fixed?

It should be included in hildon-widgets, but I guess it would be included in
the release too.
Comment 36 Andre Klapper maemo.org 2010-03-15 20:53:21 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).