maemo.org Bugzilla – Bug 4619
Panning and selecting are mutually exclusive
Last modified: 2010-03-15 20:53:21 UTC
You need to log in before you can comment on or make changes to this bug.
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
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?
(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. ***
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.
*** 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 :)
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.
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).