GNOME Bugzilla – Bug 358137
Drag and drop on trivial edits is obstructive and probably without use.
Last modified: 2018-02-10 04:34:42 UTC
Whilst drag and drap within a text area of an editor is fine, it's presence on trivial inputs like image dimension inputs on dlgs does not make much sense. In addition it is obstructive since an attempt to select part of the entry for editing tends to result in it going into drag mode. This unexpected behaviour is confusing. It also requires an extra manipulation each time. This is an omni-present annoyance and hinderance to work flow at every step. I suggest dnd is disabled Other information: snip from [Gimp-developer] UI improvements: > 1b/ I pull up a dlg. the first text entry is highlighted so I can type to > replace , fine. But if I want to edit it eg 100 to 400, I go to select the > "1" with the mouse and the editted text gets dragged. Huh? So I have to > click to deselect the reselect the bit I want.
GtkEntry would have to allow to disable this. Reassigning to Gtk+.
OK, it took me about 30 min to locate, modify and install some code in gtk+ to add this as a modifiable property in gtkEntry. I have spent the last three hours climbing in and out of the onion rings of gimp objects trying to find where I can modify that new propperty. Apart from discovering that these gtkEntry derived objects seem for some obtuce reason to be called "spinbuttons" I am now going round in circles. (Hence the name perhaps.) Can s.o. familiar with the code suggest where these little critters are created so I can add the one line of code needed to achieve this simple result. TIA.
Created attachment 73641 [details] [review] patch to expose a new propertry gtkEntry->dragable this simply adds dragable as a property that can then be set in programs using gtkEntry. Since this feature is often an obtruction on very small input boxes it makes sense to provide a means for the application, like the GIMP, to determine whether it is needed depending on the context.
In gimp, that would be the function gimp_size_entry_new(), but please open a different gimp bug about using this property, and unfortunately we can use it only if we depend on gtk 2.12, which isn't even released yet. WRT the patch, it introduces a lot of whitespace changes and breaks indentation, it also includes all your other local gtk changes. Also, i don't think that setting the property should do anything but setting entry->dragable. And it's "draggable", not "dragable".
... given this patch is accepted of course, otherwise it makes no sense to prapare a GIMP patch based on it :)
Created attachment 73662 [details] [review] tidy up of gtkentry->dragable patch hmm, editor created lots of false hits on last diff by removing end of line spaces sorry I missed that. This ones a few thousand lines shorted and does the same job. ;)
Unfortunately you got rid of the property registration as well :) And it's "draggable", according to the native speakers in #gimp.
Created attachment 73663 [details] [review] prop reg and sp chk. I'm native as well, just a lousy speller and a bit tired of battling silly with my editor. I know it's a long road for this sort of thing to filter through but if it's not done now we'll be looking at two years before we can use it, so gave it top priority. >> Also,i don't think that setting the property should do anything but setting >> entry->dragable. What are you refering to? Clearing drag.stop and start or changing the button click handler. Surely the latter is whole point here , to prevent the first mouse down starting the drag event and just letting it clear the highlight. If the property does nothing I dont see it will be of use. I must have misunderstood your comment.
I'll wait to see whether this gets accepted before looking at modding Gimp in the respect but at least it in the system. I'm going patch this to default to false locally , this feature has always seemed like more of a hinderance to me in a single line edit. Nice in text area of course. Hopefully those millions of wasted clicks I win back will repay the time I spent preparing the patch. ;)
Created attachment 73674 [details] [review] patchable and draggable Final tidy up. Name corrected , property reg. included. Tested to have the desired effect. The submitted patch has draggable=TRUE and so does not alter existing behaviour. Rebuilding gtk+ with draggable=FALSE makes gtkEntry widgets resond directly to text deselection/selection without the extra click needed to prevent going into drag mode. This established that the property works as expected. Once (if) this is adopted into gtk+ , applications using the library will be able to determine whether this behaviour is used or not.
What I meant is that in set_property(), you probably don't need to do anything but "entry->draggable = g_value_get_boolean (value)" I don't think that we need to take care of the case where the property is changed while a drag is happening. The patch looks goot to me otherwise.
yes , I was probably erring on the side of caution rather than spend hours examining every detail of the code with which I am not familiar. I'm sure you're right.
I don't think turning off dnd is a good solution. Before considering it, I'd first like to understand better why you find it annoying. If it is just the initial selection on focus in that is the problem, we already have a way to turn that off.
No, it's not the select on focus which is helpful but this does also leave the edit in a state where the inconvenience occurs. I'll take a precise example to illustrate the point. Gimp has many occurances of a small gtkEntry to enter image size or scaling/rotation figures. This is typilcally 3 or 4 digits. Obviously dnd within a tiny field like that serves little purpose. The inconvenience is if I want to change say 100% to 400% or 2.052" to 2.0" Here I want to select a part of the text and hit one key: 4 or delkey. What happens in general is that whole field goes into drag. Once the user realises what this is about he has to click once to cancel the selection then do his select and continue. So what we see is that dnd , which makes little sence here is an obtruction rather than a useful feature. A work around would be to disable the select on focus but that would be a retrograde step (at least in the Gimp) since the default size (=current size) is _never_ needed so will always be changed by the user. I find it hard to see where dnd may be of use on small edits. It seems like a case of over-featuring being counter productive. At least this should be available as a prop so that any software written on gtk+ can chose whether it makes sence in the program context. That's what my patch provides.
No, making this a property would be a cop out. We need to find a sensible default behaviour.
For my money the sensible default would be to not have dnd on these trivial edits. It is over-featured. I have applied the patch locally but with default draggable=FALSE. That seems the most appropriate choice for me. Exposing this as a property would allow any progs where the developer thinks this is in fact an asset in a specific context to have it enabled, rather than dictating a one-size-fits-all solution from above. It could even be a gconf entry so the user could activate the default the feature locally. Setting dnd off by default and exposing it as a prop would, far from being a cop-out, be transfering control to the program using it. This is ultimately the only place where its suitability can be correctly judged in the context where it is used. Done in that spirit I think it would be an asset rather than a cop out.
>> We need to find a sensible default behaviour. I outlined one specific case where this is simply obstructive and offers no useful function, where is dnd in a one-line edit a useful feature? Taking a context where the line could be long where it may have occassional, limited usefulness, it offers very little economy of effort compared to cut and paste of the selected text segment. Could someone suggest a context in which this is really useful so that we can weigh up the pros and cons and find a "sensible default " ? thx
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.