GNOME Bugzilla – Bug 680880
Annotation list fails to navigate when annotation is already selected
Last modified: 2017-10-01 13:10:43 UTC
Specifics: [ ]create 1 annotation on page 144 of 168 page of pdf doc; [ ]expand annotation list for that page; [ ]click or Dclick on annotation icon; Observations: [ ]first time it does position to approp place in doc; [ ]BUT, if now hit FIRST_PAGE nav.button, takes you to first page //ok THEN if click on the existing expanded annotation icon, noted above THEN fails to navigate to actual target page; [ ]HOWEVER, IF one collapses the noted annotation list (only tested, with one annotation present) THEN clicks on the annotation list entry; ( you ARE taken to correct page holding the annot) [ ]Behaviour is hit or miss, if doc is saved, then retried, or if do it in same veiwing session... [ ] found if navigate to random page then do the above procedures Result is UnPredictable, and NOT consistent. Suggestion: [ ]make the icon in annotation list, have properties; goto; //default DClick on icon to be this hide [one, all] select, a checkbox. save [one, all, selected} as filename...
A bit hard to parse, but this is the idea: When you have annotations, you can use the annotation list in the sidebar to navigate through them. If you select an annotation, evince will navigate to the page with the annotation. It works fine if the annotation is not selected. If the annotation is been already selected (from a previous navigation during the session), it does not do anything. The workaround is to select another item, and select again the annotation. So, it seems the TreeView is waiting for 'changes', but not 'clicks' or 'selection'.
German: Yes I think that your summary is correct; I do think that the "Suggestions" would still be appropirate. Thanks,
(In reply to comment #2) > German: > Yes I think that your summary is correct; > I do think that the "Suggestions" would still be appropriate. Sure, but those are different bugs. See: https://bugzilla.gnome.org/show_bug.cgi?id=703286 https://bugzilla.gnome.org/show_bug.cgi?id=703287 Select an annotation is a medium to do something else, so it is not a feature by itself but an implementation detail. So, I did not file a bug for that.
Created attachment 274265 [details] [review] Add button press handler to sidebar-annotations This is the same issue as https://bugzilla.gnome.org/show_bug.cgi?id=703570. I have added a patch to add the button press handler. Removed this check from ev-view because it compares the new mapping to saved focused_element, which actually is no longer focused. - if (view->focused_element == element_mapping)
Review of attachment 274265 [details] [review]: ::: shell/ev-sidebar-annotations.c @@ +328,2 @@ static void +ev_sidebar_annotations_activate_result_at_iter(EvSidebarAnnotations *sidebar_annots, Space before the opening parenthesis @@ +368,3 @@ + selection = gtk_tree_view_get_selection (view); + + if (!gtk_tree_selection_path_is_selected (selection, path)) Free the path before returning, otherwise you are leaking memory.
Maybe consider a similar solution than Bug 703570 See also Bug 727277
Created attachment 360488 [details] [review] shell: Fix navigation with annotation already selected in sidebar This fixes the issue when an annotation is selected in the sidebar, the user navigates the document, and when if the user clicks on the same annotation, then nothing happens. But Evince should go to the page of the annotation selected.
Review of attachment 360488 [details] [review]: Ok