DOI field improvements #1072
DOI field improvements #1072
Conversation
|
I use doubleclick and think it is a quite neat feature. Especially when only a single field is available. |
|
Regarding browse I believe it can be useful in combination with filespecific fields (which we currently try to avoid, so I'm fine with the removal). |
|
Double-click might be a neat feature, but is neither intuitive from a UI usage perspective nor shown anywhere. So it is just a feature that can be used by insiders which is really not what I think is our intention. |
|
Maybe. What about a tool tip text then? I would expect requests to get it back if we remove it. |
|
Intuitive to me would be 2 options:
|
|
I use that doubleclick feature, too. It is natural to expect Jabref to open the link etc then. |
|
Ahh, I realise that I have been talking about the entry table and not the
entry editor (which I now realise the discussion most likely is about).
Still, I think that a tooltip might do the trick. One can also double click
the date field to set the current date and I think the owner field to
update the owner.
|
To be honest I've never experienced that double clicking a text input field opens a link or does anything with the text except marking it. |
|
@stefan-kolb I thought you meant the Entry Table DOI Field |
|
I mean this DOI field: |
|
I would propose to add an inline-button, in the textbox, similar to something like the clear symbol here |
|
@tobiasdiez We have already discussed with the "clear search" button. Unfortunately, this is no built in function of Swing and requires some quick ugly hacks to implement. But I agree, in general that would be the nicest solution. |
stefan-kolb
added
the
status: ready-for-review
|
Ok, this is ready for your comments! |
| @@ -171,14 +171,6 @@ public RightClickMenu(JabRefFrame frame, BasePanel panel) { | |||
| } | |||
| }); | |||
|
|
|||
| add(new GeneralAction(Actions.MERGE_DOI, Localization.lang("Get BibTeX data from DOI")) { | |||
There was a problem hiding this comment.
I so prefer it to stay here (as well). This has been one of my most used features recently.
There was a problem hiding this comment.
Next step would be to add #1098, so I prefer not to add it back in this context menu.
There was a problem hiding this comment.
Hm, maybe rename it differently using "autocomplete with BibTeX data from DOI"?
There was a problem hiding this comment.
I'm not really seeing the problem. A button somewhere else won't help the (superior) habit of right-clicking on an entry and selecting in a menu compared to double-clicking to open the editor, change to the right tab and clicking a button. Marking, click on another button is slightly better, but I still do not see what the problem with the right-click menu staying is. "New from DOI" is not going to end up in the right-click menu?
I thought the purpose of #1098 was to add e new entry (which IMHO would be better splitting web search and "add/fetch") so I do not see marking and clicking that button as a replacement.
The context here is that one do get slightly different information when searching and when adding information from DOI, so I usually do both at once. Not to mention improving all my old bib-files.
There was a problem hiding this comment.
No worries. :) Action in right click menu stayed in there. 🏆
The right click menu now only contains actions related to selected entries in the table. Hence, the "new from doi" was moved to the menu.
|
Looks good to me! I'd really like to keep the right-click menu though. With this PR the use of the entry editor has slightly changed from editing to actually using the information (although it was hidden there earlier through double-click). Not sure if it is worth thinking about what we really want the entry editor for. |
|
👍 LGTM |
Major changes of this PR
New Look