GNOME Bugzilla – Bug 758329
Allow Keybinding for highlighting annotation
Last modified: 2018-05-22 16:24:54 UTC
Adding annotations in Evince would be much easier if one could activate the highlighting tool with a keystroke. Activating can_change_accels in dconf does not seem to give access to the new-style menus, at least not on my machine (arch linux, running most recent gnome). Thank you!
It makes sense. can_change_accels was deprecated in gtk+ 3.10. It does not work anymore.
thanks German. Did something else replace can_change_accels, or is there no manual way to add bindings to evince?
No, as far as I know. The way to fix it is in the code. It should be straightforward, once we choose which key binding would be the best. Do you know which one is used on other related-applications? (to see whether we can get something consistent with other applications).
*** Bug 758884 has been marked as a duplicate of this bug. ***
I don't really know what other apps use. In Emacs pdf-view I set my own bindings. On Android everything is menu/tap driven... There are so many kind of annotations, it might be ince to have this user-customizable. For instance, I only really use highlights, but many people use underlining instead, I think.
The evince docs still point users to can-change-accels. Should a separate bug be created for the docs? An alternative to adding a keychord shortcut would be to add annotations to the context menu. This makes sense because highlighting text is normally done using the mouse.
(In reply to Nate from comment #6) > > An alternative to adding a keychord shortcut would be to add annotations to > the context menu. This makes sense because highlighting text is normally > done using the mouse. couldn't we do both?
(In reply to Nate from comment #6) > The evince docs still point users to can-change-accels. > Should a separate bug be created for the docs? Yes, please.
(In reply to Germán Poo-Caamaño from comment #8) > (In reply to Nate from comment #6) > > The evince docs still point users to can-change-accels. > > Should a separate bug be created for the docs? > > Yes, please. I went too fast. It is already reported in Bug 758246 :-)
(In reply to Germán Poo-Caamaño from comment #3) > Do you know which one is used on other related-applications? (to see whether > we can get something consistent with other applications). I read the documentation of Adobe/Acrobat reader for Windows and Preview for Mac. Acrobat has "<ctrl>+6" key binding for sticky notes and no key binding for highlighting, whereas Mac Preview has "<ctr>+<command>+T" for Adding floating text/comment and "<ctr>+<command>+H" for selecting highlighting tool.
I might have some time to hack on this over the holidays as I've never contributed to gnome before and this seems easy enough to do. I prefer <ctr>+H, but not <ctr>+<meta>+H since I use meta for my window manager.
Nate, beware that Sitaram Shelke might be already working on this, as I suggested him to work on this bug when on the evince mailing list. We can start with Ctrl+H (if it is not already in use), otherwise we can change it before the release. Sitaram Shelke: are you working on this?
(In reply to Germán Poo-Caamaño from comment #12) > Sitaram Shelke: are you working on this? Yes, and I was actually waiting for you to decide which key bindings to use. Ctrl + H seem good for highlighting. It is not being used as of now.
Hello German, So here is what I did: I am new to Gtk so I tried to figure out the solution for this bug in analogy with how <ctrl>+P must be working for printing the doc. I modified the shell/ev-application.c and shell/ev-window.c the patch files for ev-application.c is http://ur1.ca/oct0c and patch file for ev-window.c is http://ur1.ca/oct0f To summaries, ---- in ev-application.c I added { "win.annotation","<Ctrl>H", NULL, } entry below win.print to create a key and ---- in ev-window.c added a new function { ev_window_cmd_add_annotation(GSimpleAction *action,GVariant *state,gpointer user_data) } which calls ev_window_begin_add_annot() function with ANNOTATION_TYPE TEXT_MARKUP and bind this function with annotation key. Did I do it correctly?
Sitaram, may you attach the patches here?
The patches are not available anymore, probably they were already expired when I commented it in #c15.
Please implement a keys for activating the highlight and text annotation tools. Why this is very important: Having to re-click the buttons at the top of the screen totally disrupts my concentration and flow while reading complex material. Thanks!
just wondering if there's anyone from Gnome reading this bug... lack of this keybinding basically makes evince unusable for me; I do my reading and annotation in Emacs instead, even though evnice's presentation of PDFs is in every other way superior. I'd love to see some movement on this, and I think it's essential for any serious student or intellectual trying to read pdfs. Unfortunately I'm not able to ocntribute code but I'm sure there would be a a *lot* of gratitude from many users.
I'm not a Gnome developer, but I have had it on my todo list to fix this bug for quite some time. It's not a priority, so who knows when I will get to it. Maybe in spring?
Created attachment 369510 [details] [review] shell: Add Ctrl+H shortcut to add text annotation
Created attachment 369512 [details] [review] shell: Add "Insert" key shortcut to add text annotation
Created attachment 369513 [details] [review] shell: Add <Ctrl>H shortcut to add highlight annotations
The UX of the add highlight annotations shortcut is: 1. Press Ctrl+H 2. Select text Does someone think that it should be the other way around?
My instinct would be to reverse the order. One reason for this is that selection is not always perfectly precise, so I might want to select, take a closer look, and then select again. I find I do this a lot on PDFs, especially OCR'd PDFs with imprecise character identification. can't believe this is actually happening! Thank you!
(In reply to Felipe Borges from comment #23) > The UX of the add highlight annotations shortcut is: > 1. Press Ctrl+H > 2. Select text > > Does someone think that it should be the other way around? It could work both ways: if there is text selected apply highlighting on the selected text else toggle highlighting mode Applying highlighting when the text is selected looks straightforward. For the other one, you have to control the mode, and think a little about it. It allow nice things like highlight multiple texts. By controlling the mode, I mean we need to give the user a visual clue that the document is in highlighting mode. If the toolbar is visible, then leave the button in pressed state, but if the toolbar is not visible, should we show toolbar? Also we need to a method to leave the mode. Ctrl+H can do it, but also Esc. Unless, you have in mind Ctrl+H, select text, deactivate highlight right after the selection finished. In which case, I would find more intuitive select, and then Ctrl+H. I like the 'annotation mode', though :-)
(In reply to Matt Price from comment #24) > My instinct would be to reverse the order. One reason for this is that > selection is not always perfectly precise, so I might want to select, take a > closer look, and then select again. I find I do this a lot on PDFs, > especially OCR'd PDFs with imprecise character identification. Unless... you can select an annotation and extend it or stretch it at will! ;-) That is tricky, I am unsure the current machinery allows it, and I have not seen PDF applications than do it, either. I am just thinking aloud :-)
(In reply to Germán Poo-Caamaño from comment #25) > (In reply to Felipe Borges from comment #23) > > The UX of the add highlight annotations shortcut is: > > 1. Press Ctrl+H > > 2. Select text > > > > Does someone think that it should be the other way around? > > It could work both ways: > if there is text selected > apply highlighting on the selected text > else > toggle highlighting mode > > Applying highlighting when the text is selected looks straightforward. > > For the other one, you have to control the mode, and think a little about it. > It allow nice things like highlight multiple texts. > > By controlling the mode, I mean we need to give the user a visual clue that > the document is in highlighting mode. If the toolbar is visible, then leave > the button in pressed state, but if the toolbar is not visible, should we > show toolbar? > Also we need to a method to leave the mode. Ctrl+H can do it, but also Esc. > > Unless, you have in mind Ctrl+H, select text, deactivate highlight right > after the selection finished. In which case, I would find more intuitive > select, and then Ctrl+H. > > I like the 'annotation mode', though :-) German, I got lost here... I was thinking about this in bug 763943. With the basic functionality from this bug, solving this bug by doing what you suggests is easy... and also follows other UX patterns in inkscape or gimp, so it's not completely bogus... We could also ask Allan or other people from the Design team to give an opinion.
(In reply to José Aliste from comment #27) > [...] > German, I got lost here... I was thinking about this in bug 763943. With the > basic functionality from this bug, solving this bug by doing what you > suggests is easy... and also follows other UX patterns in inkscape or gimp, > so it's not completely bogus... We could also ask Allan or other people from > the Design team to give an opinion. I agree. I forgot that bug when I wrote my reply. That said, I think still the mode needs to be checked.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/635.