Adding myself to Cc

*** This bug has been confirmed by popular vote. ***

Idealy, there could be convenience functions to go enable two-tap selecting or
go into selection mode.

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.

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 2009-06-11 02:27:44 UTC

Adding myself to Cc

(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.

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. ;)

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?

(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.

(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
:)

Are there any updates on that? I'll have to make a decision soon on how to
implement that in my app.

(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.

(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?

(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.

(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?

(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 :).

> 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

(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.

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).

(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 :)

*** Bug 5360 has been marked as a duplicate of this bug. ***

Comment 23 Quim Gil 2009-10-14 08:16:22 UTC

Setting target milestone to reflect that we are looking at this.

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.

(In reply to comment #24)
> I am glad to announce that this is FIXED:

BTW, we did it by pressing Shift key.

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

(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 2009-12-10 15:11:54 UTC

*** Bug 6681 has been marked as a duplicate of this bug. ***

> 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

I had the same problem, Instinctively I tried to get the mouse by sliding in
from the let as you do in the browser.

(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.

(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 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/

(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?

(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 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).