Opened 12 years ago
Closed 12 years ago
#8024 closed enhancement (fixed)
New "Add key/value" dialog feature: Click on tag should apply it immediately
Reported by: | flaimo | Owned by: | team |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Core | Version: | tested |
Keywords: | Cc: | Don-vip, cquest |
Description
I just tried out the feature I requested for the first time. As it is implemented now it doesn't actually save me any time, since a click just prefills the two input fields. the way i meant is was, that a click on one of the recently used tags (or pressing one of the keyboard shortcuts) applies the tag immediately and also closes the dialog. Also the tags should be underlined or else a user will never know that he can click the tags (usability problem).
Attachments (1)
Change History (39)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Maybe something like following would be convenient:
- Shift-Click = apply and close
- Ctrl-Click = add/delete tag without closing
comment:3 by , 12 years ago
Actually "Apply and Close" should be the default without any modifier key. How big is the chance that is it necessary to review the tag after is has been copied to the two input fields. I would say probably near 0%.
comment:5 by , 12 years ago
It would be convenient to be able adding more than one tag once!
- A double click to add apply and close.
- Simple click to add without closing, another simple click too add another tag - or the same - without closing ... a doucle click to add the last tag or click apply button to close.
I often add multiple tag to a bunch of node/way and the possibility to do this easily via recent tag list may be a really good enhancement. clicking ADD button on the top right of the screen is not handy.
Another way possible, editing tag/value directly in the property box available in the right pane.
comment:7 by , 12 years ago
Cc: | added |
---|
I have implemented Add&Close on double-click and "multiple add" on shift-click.
@team, @Don-vip: Please could you check that I did not break anything (some refactoring was done to separate code that we needed to extend)?
Do we need to add some message or tooltip for this extra behaviour?
comment:8 by , 12 years ago
I like the double-click behaviour, it's fine :)
Concerning the Shift-click, it works, but clicking on Cancel button should cancel all changes we made from this dialog.
follow-up: 13 comment:9 by , 12 years ago
Concerning the help message, we should not use a JOptionPane directly but a subclass of ExtendedDialog instead. This would allow to link a "Help" button and save the window geometry (asked in #8012).
comment:10 by , 12 years ago
Cc: | added |
---|
comment:11 by , 12 years ago
I am finishing rough Panel -> ExtendedDialog conversion. Position is remembered correctly. Maybe some extra code rework will be needed after commit.
comment:13 by , 12 years ago
Replying to Don-vip:
Concerning the help message, we should not use a JOptionPane directly but a subclass of ExtendedDialog instead. This would allow to link a "Help" button and save the window geometry (asked in #8012).
@Don-vip: by your advice, I transformed dialogs to ExtendedDialog subclasses and added Cancel behavour.
Problems are:
- saving position of the windows without saving its size, see #8012
- not so good-looking windows as before (please, can someone add margins or something like that?)
- do we need correctly added Help buttons in these dialogs?
- There are possible hard-to find regressions (focus, Linux middle-click, Tab order, etc.). I did not notice them, but they are possible.
For now I stop committing to let others make the code better without conflicts.
comment:14 by , 12 years ago
Neither the position or size of the dialog are remembered on my laptop (Ubuntu 12.10, gnome 3 classic). I'm looking at it.
The Help button is definitively needed with all these new keyboard shortcuts :)
follow-up: 17 comment:16 by , 12 years ago
Did this also effect "edit" ?
Anyway, on the "change value" dialog the value
should be selected and not the key
.
comment:17 by , 12 years ago
Replying to skyper:
Did this also effect "edit" ?
Anyway, on the "change value" dialog the
value
should be selected and not thekey
.
The same after simply clicking on an item from list.
comment:18 by , 12 years ago
Selecting a key
from drop-down-list should should also change to value
.
follow-up: 21 comment:19 by , 12 years ago
I wonder if we need two different dialogs (add tag <-> change value) or if it could work with one. E.g. double clicking on the property or the "edit" button opens the "add tag dialog" but prefilled with the previous chosen key-value-pair. I often have situations where I what to add some properties but also change one or two.
follow-up: 23 comment:21 by , 12 years ago
Replying to skyper:
I wonder if we need two different dialogs (add tag <-> change value) or if it could work with one. E.g. double clicking on the property or the "edit" button opens the "add tag dialog" but prefilled with the previous chosen key-value-pair. I often have situations where I what to add some properties but also change one or two.
You are right, now Add dialog can be used for editing values too. But it seems that Edit dialog have some differen logic - autocompletion and so on. Maybe some people are used to it.
Thank you for good ideas. Selecting key
on Alt-E was a regression that I missed.
comment:22 by , 12 years ago
@Don-vip: I have finished. You can add Help button or improve something else in these dialogs. It seems we are not not in stabilization phase :)
follow-up: 24 comment:23 by , 12 years ago
Replying to akks:
Replying to akks:
Replying to skyper:
In 5656/josm:
Did not check the code but single Click on a recent tag from list should focus the value cause it is much more common to change the value instead of the key.
I wonder if we need two different dialogs (add tag <-> change value) or if it could work with one. E.g. double clicking on the property or the "edit" button opens the "add tag dialog" but prefilled with the previous chosen key-value-pair. I often have situations where I what to add some properties but also change one or two.
You are right, now Add dialog can be used for editing values too. But it seems that Edit dialog have some differen logic - autocompletion and so on. Maybe some people are used to it.
Did not realize much differences, so far.
Thank you for good ideas. Selecting
key
on Alt-E was a regression that I missed.
You are welcome. Thanks for coding.
follow-up: 25 comment:24 by , 12 years ago
Replying to skyper:
Did not check the code but single Click on a recent tag from list should focus the value cause it is much more common to change the value instead of the key.
It works this way, commit comment is buggy.
comment:25 by , 12 years ago
comment:26 by , 12 years ago
I did some update/clean-up on Help/Dialog/Properties and created Help/Dialog/AddValue (still incomplete).
Gonna try to finish the next days but input/adds are always welcome.
On Help/Dialog/Properties "key/value pairs" is often mentioned instead of tags but I am not sure what is better understandable.
follow-up: 30 comment:28 by , 12 years ago
This turns into a major enhancement. Thanks guys.
On little problem I have is the window border. My WM (metacity, gnome3) can not grab the edges nor sides to resize the window. Works with all other common dialogs (preferences, search, presets, upload ...) but not with "AddValue" nor "EditValue".
@akks:
Does this really belong to AddValue and not to EditValue which does not have a page, yet ?
comment:30 by , 12 years ago
@akks:
Does this really belong to AddValue and not to EditValue which does not have a page, yet ?
Oops, I was too fast again. Reverted :)
Replying to skyper:
This turns into a major enhancement. Thanks guys.
On little problem I have is the window border. My WM (metacity, gnome3) can not grab the edges nor sides to resize the window. Works with all other common dialogs (preferences, search, presets, upload ...) but not with "AddValue" nor "EditValue".
Replying to skyper:
Sorry one more shortcut:
Ctrl+Shift+<number>
might be nice too.
I'll se what I can do in near minutes...
follow-up: 33 comment:32 by , 12 years ago
Last change was mechanical adding one more action.
As I can see, resizing was intentionally disabled by Don-vip, because Add dialog has variable size (recent tag list).
If the size will be remembered after resizing, half-empty dialog can pop-up next time.
Do you really need resizing and have ideas how we need to change this?
comment:33 by , 12 years ago
Replying to akks:
Last change was mechanical adding one more action.
Thanks.
As I can see, resizing was intentionally disabled by Don-vip, because Add dialog has variable size (recent tag list).
If the size will be remembered after resizing, half-empty dialog can pop-up next time.
Do you really need resizing
No, not really.
and have ideas how we need to change this?
I see, then it is the minimal size which could be a little bit wider or/and definable through preferences.
comment:34 by , 12 years ago
Yes, this is intentional. We had some troubles with layout while implementing recent tags (see #7671 comments), I don't want to break this by allowing the dialog to be resized.
However, margins remain to be added to have a look closer to the original JOptionPane. I think this is the only thing to do before closing this ticket :)
comment:35 by , 12 years ago
Here is a margin-related patch. You can make it look better and commit :)
(and possibly add preferences for min size, which I can not manage)
by , 12 years ago
Attachment: | Margins.patch added |
---|
comment:38 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
That would close #8012 as well :)