I'd love to see citations and proofs for these statements.

IMO, annotations is a mode that should be available only in PDF documents once we have a better annotation support.

By mode I mean switching from navigating/viewing mode to annotating mode.  In annotating mode there should be other actions available, such as, highlight text, free text, notes, rectangles, deleting annotation, editing annotations, etc.

However, this has nothing to do with customization.

Is the proof not self-evident? Isn't it clear that if you give users the ability to configure these things themselves, in an intuitive way, then they won't be asking programmers to make these adjustments for them? 

(In reply to comment #1)
> I'd love to see citations and proofs for these statements.

Annotations are already there--but discovering that is a multi-step process that is a pain in the rear iesp if you don't use this feature all the time:
1) view menu
2) choose side pane
3) pull-down side dropbox to annotations
4) choose add button
5) expand the (+) sign
6) click pencil button
7) try to remember what it was you wanted to annotate while you were reading because you were so busy trying to remember how to annotate!

(In reply to comment #2)
> IMO, annotations is a mode that should be available only in PDF documents once
> we have a better annotation support.
> 
> By mode I mean switching from navigating/viewing mode to annotating mode.  In
> annotating mode there should be other actions available, such as, highlight
> text, free text, notes, rectangles, deleting annotation, editing annotations,
> etc.
> 
> However, this has nothing to do with customization.

(In reply to comment #4)
> Annotations are already there--but discovering that is a multi-step process
> that is a pain in the rear iesp if you don't use this feature all the time:
> 1) view menu
> 2) choose side pane
> 3) pull-down side dropbox to annotations
> 4) choose add button
> 5) expand the (+) sign
> 6) click pencil button
> 7) try to remember what it was you wanted to annotate while you were reading
> because you were so busy trying to remember how to annotate!

That is one type of annotation and yet the implementation is not complete.

(In reply to comment #3)
> Is the proof not self-evident? Isn't it clear that if you give users the
> ability to configure these things themselves, in an intuitive way, then they
> won't be asking programmers to make these adjustments for them? 

It is not.  As in wikipedia: [citation needed].

When you empower people, they become less reliant.

As far as I can tell, that is the only type of annotation available.
The implementation would be way, way more complete if it were just easy to do.


(In reply to comment #5)
> (In reply to comment #4)
> > Annotations are already there--but discovering that is a multi-step process
> > that is a pain in the rear iesp if you don't use this feature all the time:
> > 1) view menu
> > 2) choose side pane
> > 3) pull-down side dropbox to annotations
> > 4) choose add button
> > 5) expand the (+) sign
> > 6) click pencil button
> > 7) try to remember what it was you wanted to annotate while you were reading
> > because you were so busy trying to remember how to annotate!
> 
> That is one type of annotation and yet the implementation is not complete.

(In reply to comment #8)
> As far as I can tell, that is the only type of annotation available.
> The implementation would be way, way more complete if it were just easy to do.

It is clear the current implementation is not handy.  However, customization the menu and the toolbar is just a workaround.

There are 2 different things here:
1. Improve the annotation use case
2. Customize the toolbar and menus.

You filled the bug for the second one without providing any link, pointer, documentation to support any of your statements.

What I would like to see is getting fixed the first one.  With a proper solution, the second one becomes irrelevant.

You are correct that these are 2 separate, (but arguably intertwined) use cases. I do not believe that the second use case obviates the first.  I am still not entirely clear about what you need from me, perhaps this helps:
Making the UI more configurable for end-users is not just a work-around--it would enable users to see the the components of Evince that are most relevant to them, in the place where they are most useful to them.
My use case may be different from others, so having a flexible UI, as mentioned previously, would solve multiple use cases.
That said, my particular use case is similar to many in academia:
When I am writing research articles, I need to annotate specific areas of the document (--for me, highlighting phrases and adding comments are most important). These would be most easily accomplished with a combination of left and right clicks--i.e select text with left click, then right click shortcut menu to chose what to do with selection (e.g. highlight or add comment).  
Adding annotations to PDFs is common in academia because acaddemic writers are constantly referencing literature--which is most often published in PDF form.  PDF annotations can be abstracted by utilites like Zotero and Docear for end-users to write papers from their abstracted quotes (highlighted text) and annotations.
With regard to a configurable interface, other users might find it handy to have 'add bookmark' in the right-click shortcut menu.
Likewise, while I am sure they are convenient for some, I personally have no need for the shortcut menu items 'reload' or 'autoscroll'...these only get in my way, and I would remove them from the shortcut menu if I could.
Does that help?

There is no more a menubar in evince master, and the toolbar editor that existed has been removed too. So I'm opting for WONTFIX here.

...and just like that, a developer single-handedly ignores the pain-points of a potentially very large user-base (academics) who by and large would like to use FOSS products like Evince--but all-too-often have experiences just like this and so move back to familiar proprietary software.  
You didn't address the merits of the use case at all.
Just because Evince lacks a specific feature doesn't mean there can't be a plan of action.
Very frustrating, it feels like your palm is up and you are saying, "...talk to that hand because the face ain't listening..."

You were asked several times to provide proofs for your assumption ([citation needed]). You failed several times and even continue in your last comment. See http://en.wikipedia.org/wiki/Wikipedia:WEASEL for this communication pattern.

(In reply to comment #12)
> ...and just like that, a developer single-handedly ignores the pain-points of a
> potentially very large user-base (academics) who by and large would like to use
> FOSS products like Evince--but all-too-often have experiences just like this
> and so move back to familiar proprietary software.  
> You didn't address the merits of the use case at all.
> Just because Evince lacks a specific feature doesn't mean there can't be a plan
> of action.

Your use case seems clear: easier way to add annotations (which was already reported in Bug 649045 and you added a comment on it).  It is also related with Bug 168304.

But also you insist in customizing the toolbar and menus as it is, instead of filing bug to fix them.  If you think a menuitem should or should not be there or it is confusing, then it might be a bug.

Before getting upset because I am repeating myself, please use the same criteria using in academia to address a research, you likely start by wondering "What is the problem you I trying to solve/understand?".  When you get to the actual problem, you try to find a solution.  The same applies here.

As it was stated, customize a toolbar/menubar is just a work around that hides the actual issue.

OK, clearly we are talking past each other.  First, thank you Germán for keeping a sane dialog open.  Secondly, thank you for citing Bugs 649045 and 168304. As a developer, your familiarity with the historical bug list trumps mine, to be sure.

Bug 649045 supports my assertion that discoverability is an issue, and having annotations "a click away" is important.

I didn't previously know about Bug 168304, but after reading it, it is clear that others would like to have a 'right click' annotation feature as well.


In answer to your question, "What is the problem you are trying to solve/understand?":
I filed this bug after commenting on Bug 649045 for 2 reasons:
1) annotations cannot be added to the toolbar that is otherwise configurable for many user actions
2) in the same way that the toolbar is configurable, the right-click menu should be configurable as well...it is not

You are correct in stating that it has been already stated: 
"customize a toolbar/menubar is just a work around that hides the actual issue."
Yet I believe that what I am suggesting actually would solve the problem I, and those who filed these other bugs, are having.

I have elaborated a use case where having annotations in the toolbar and menus would make them more discoverable and easier to use. Others in the bugs you cite concur.
Other than those bugs, I am not sure what you are looking for in terms of citation.
Also, can you please describe what you mean by "work around" vs. "solution"?

German and Andre, you've inspired a rant.

First, making an analogy between customizability of evince to scientific research is quite a stretch.

It's not rocket science, nor neuroscience, nor open heart surgery. People expect menubars and toolbars. This is how GUIs exist in the world outside of GNOME, even (still) in the OSX world. You want references? Pick a random piece of desktop software, open-source or closed, and see how it's designed. I think the onus is quite the other way around. To deviate from decades of menubars and toolbars, by getting rid of them, and preventing the more advanced user from customizing the toolbar, and to propose that this somehow increases usability, is an extraordinary claim. It's also arrogant, but this is nothing new for GNOME.

On another note, we've been waiting, patiently, for at least 8 years (Bug 168304), for evince to get the basic annotation tools (highlight, underline, call-outs, text boxes, maybe drawing) that are necessary when reading papers. I've personally given up hope. KDE is awful. Adobe Reader X doesn't exist for Linux, and probably never will. All that's left are windows programs like PDF-Xchange and Foxit which hog resources running in Wine and don't scroll as well. From what I can tell, the necessary support is there in Poppler. Is it really that hard to implement the front end?

I would seriously be willing to pledge US$200 on kickstarter towards getting this done, with a time limit of say 6 months. I bet heaps of others, especially academics that annotate on a daily basis, would be equally willing. Does something like this exist? Can someone start such a kickstarter campaign? If it takes a fork of evince, or a complete rewrite with no dependencies on GNOME to make it happen, then good riddance.

(In reply to comment #16)
 
> On another note, we've been waiting, patiently, for at least 8 years (Bug
> 168304), for evince to get the basic annotation tools (highlight, underline,
> call-outs, text boxes, maybe drawing) that are necessary when reading papers.
> I've personally given up hope. KDE is awful. Adobe Reader X doesn't exist for
> Linux, and probably never will. All that's left are windows programs like
> PDF-Xchange and Foxit which hog resources running in Wine and don't scroll as
> well. From what I can tell, the necessary support is there in Poppler. Is it
> really that hard to implement the front end?
Yes, it is... and takes time (free time of volunteers).  
> I would seriously be willing to pledge US$200 on kickstarter towards getting
> this done, with a time limit of say 6 months. I bet heaps of others, especially
> academics that annotate on a daily basis, would be equally willing. Does
> something like this exist? Can someone start such a kickstarter campaign? If it
> takes a fork of evince, or a complete rewrite with no dependencies on GNOME to
> make it happen, then good riddance.

You are welcome to provide patches/start campaigns, etc, to get annotation support into Evince. This is a volunteer project and we use any help we can get (and if we can't use it, you are always free to fork, evince is gpl)

Anyway, this is deviating from the issue. We can continue the conversation privately if you want/need so.( jose.aliste at gmail.com)

Thank you for the most passionate argument Martin. It seems pretty clear that I am not the only one who believes that this functionality would be extremely useful.

Lest we get side-tracked, 2 important questions remain:

How much more, and what kind of "proof" do the developers need in order for this request to be taken seriously?

If the core Evince developers feel that the GUI functionality that I have suggested are  mere "work arounds", then please explicitly elaborate--because clearly at least a few of your end-users are not seeing this as being the case.

(In reply to comment #15)
> [...]
> I have elaborated a use case where having annotations in the toolbar and menus
> would make them more discoverable and easier to use. Others in the bugs you
> cite concur.

I certainly agree.  

However, notice there is a difference between "having annotations in the toolbar and menus" than "menus and toolbars are not easily configurable by users".

All this discussion has been because you insisted in the second, which is not the problem.

> Other than those bugs, I am not sure what you are looking for in terms of
> citation.

The citation part started with statements like in #c1:

   "Giving user configurability at this level would greatly enhance usability and
    obviate the need to respond to many other feature requests."

That is weasel.  Without any reference (other projects, other UIs, usability studies, whatever), it can be interpreted that this should be implemented because you say so.

> Also, can you please describe what you mean by "work around" vs. "solution"?

A workaround is a temporary fix, that might lead to a bigger problems or eventually to a regressions once a final fix (solution) is implemented.

http://en.wikipedia.org/wiki/Workaround.

(In reply to comment #16)
> German and Andre, you've inspired a rant.
> 
> First, making an analogy between customizability of evince to scientific
> research is quite a stretch.

If there was an analogy it was about how to make questions and how to report bugs.  Given the insistence of "academia" use case, I put it in terms that would be easier to understand from somebody from academia.

> On another note, we've been waiting, patiently, for at least 8 years (Bug
> 168304), for evince to get the basic annotation tools (highlight, underline,
> call-outs, text boxes, maybe drawing) that are necessary when reading papers.
> I've personally given up hope. KDE is awful. Adobe Reader X doesn't exist for
> Linux, and probably never will. All that's left are windows programs like
> PDF-Xchange and Foxit which hog resources running in Wine and don't scroll as
> well. From what I can tell, the necessary support is there in Poppler. Is it
> really that hard to implement the front end?

From what I can tell, to implement most the annotations you mentioned, we still need support in poppler support to that.

See: https://bugs.freedesktop.org/show_bug.cgi?id=51487

> I would seriously be willing to pledge US$200 on kickstarter towards getting
> this done, with a time limit of say 6 months. I bet heaps of others, especially
> academics that annotate on a daily basis, would be equally willing. Does
> something like this exist? Can someone start such a kickstarter campaign? If it
> takes a fork of evince, or a complete rewrite with no dependencies on GNOME to
> make it happen, then good riddance.

Don't wait for someone, you can start a kickstarter campaign by yourself.

Micro$ft has had configurable menus/toolbars in all office products as far back as 1997:

http://windowssecrets.com/forums/showthread.php/11217-Custom-Shortcut-menu-bars-%28Access-97-SR2%29

http://www.tech-archive.net/Archive/Word/microsoft.public.word.vba.general/2006-10/msg00984.html

I know what a workaround is in general. What I am suggesting is quite the opposite:  Development of a GUI where users can configure the interface to their own liking/needs means that developers won't have to waste their time trying to guess what the "best" configuration is for most users. 

Reference recent technology trends toward personalization: http://en.wikipedia.org/wiki/Personalization

On the contrary, no developers on this list have stated how my suggestions are a workaround in THIS CIRCUMSTANCE...instead  they have just repeated themselves that it is a workaround without providing any logical reasoning..now that is weasely.

Are these proof enough?
Can you elaborate on how my suggestions are a workaround without name calling?

(In reply to comment #18)
> Thank you for the most passionate argument Martin. It seems pretty clear that I
> am not the only one who believes that this functionality would be extremely
> useful.

This is not a forum to cheer up for bug reports.

> Lest we get side-tracked, 2 important questions remain:
> 
> How much more, and what kind of "proof" do the developers need in order for
> this request to be taken seriously?

Please, do not mix things here.  This bug was badly reported, which is ok because it was your first one.

> If the core Evince developers feel that the GUI functionality that I have
> suggested are  mere "work arounds", then please explicitly elaborate--because
> clearly at least a few of your end-users are not seeing this as being the case.

In spite I am not an Evince developer, I do not see nothing to elaborate.  If you want to see how annotations are going to be implemented and make them easy to use, then I would suggest to follow the component 'pdf annotations'.

https://bugzilla.gnome.org/buglist.cgi?product=evince&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=pdf%20annotations

(In reply to comment #21)
> [...]
> I know what a workaround is in general. What I am suggesting is quite the
> opposite:  Development of a GUI where users can configure the interface to
> their own liking/needs means that developers won't have to waste their time
> trying to guess what the "best" configuration is for most users. 
> 
> Reference recent technology trends toward personalization:
> http://en.wikipedia.org/wiki/Personalization

So, what you are suggesting goes to the opposite direction of:
http://ometer.com/free-software-ui.html

Anyway, this is my last comment.

> (In reply to comment #18)
> > Thank you for the most passionate argument Martin. It seems pretty clear that I
> > am not the only one who believes that this functionality would be extremely
> > useful.
> 
> This is not a forum to cheer up for bug reports.

I was merely pointing out that I am not the only end user that notices this bug.

> 
> > Lest we get side-tracked, 2 important questions remain:
> > 
> > How much more, and what kind of "proof" do the developers need in order for
> > this request to be taken seriously?
> 
> Please, do not mix things here.  This bug was badly reported, which is ok
> because it was your first one.

If you would like bugs filed a different way, is there some documentation about how you would like this to occur? 
(Or shall I file a bug about that too?)

> 
> > If the core Evince developers feel that the GUI functionality that I have
> > suggested are  mere "work arounds", then please explicitly elaborate--because
> > clearly at least a few of your end-users are not seeing this as being the case.
> 
> In spite I am not an Evince developer, I do not see nothing to elaborate. 
"do not see nothing to elaborate" ...? Your meaning is quite unclear..
 
> If you want to see how annotations are going to be implemented 

This implies that you have already decided how these things are going to be implemented without wanting input from users.

> to use, then I would suggest to follow the component 'pdf annotations'.
I have looked at this list:
Bug 649045 almost 2 years old with no developer response
Bug 168304 no developer comment for over 1 year

While I understand if there is perhaps a labor shortage on this project, looking at the list as you suggest, demonstrates that the developers have no interest in delivering what many end users are asking for, or at the very least, don't want to talk about it.  Or am I missing something?

(In reply to comment #24)
> what many end users are asking for

Running in circles, see comment 13.