GNOME Bugzilla – Bug 386292
window title should contain file name
Last modified: 2010-12-14 13:55:45 UTC
currently the window title for an evince window displaying a PostScript file only contains the text in the %%Title: section of the PostScript file -- which, when produced by certain applications, contains less than helpful information. For example, I use IDL (Interactive Data Language) to produce plots. The title it always places in the PostScript it produces is "Graphics produced by IDL". For me it would be much more helpful to have the name of the file in the title -- or maybe something like "filename.ps - title".
This is a document problem, not a viewer problem. I'm opting for WONTFIX, but I'll let others decide...
I disagree. There are many reasons why you might want to display the filename rather than (or in addition to) the title embedded in the document. Moreover, it is very burdensome on users (and in some cases not possible) to change that information in files. Others might argue that the file name is not useful information, but in the end the judgment ought to rest on what is best for users, not what document creating software ought to do. As another example, pdf documents that I download from a preprint server website (http://xxx.lanl.gov/archive/astro-ph/) have highly unhelpful titles embedded in them, e.g. "arXiv:astro-ph/0608585 v1 28 Aug 2006". I generally name the files after the authors instead when I download them.
I agree with comment #2; there are a large number of documents out there that have utterly useless titles in them. There should be an option to let the user decide if: (A) they want to display the document title, (B) they want to display the file name, (C) they want to display both, or (D) they want to display the document title unless it matches a regex, and then revert to displaying the file name. Of course, (D) would be the least used and probably doesn’t even have to be implemented, though it would be nice. I am a student at a distance learning school and the textbook materials provided to me have the title “untitled” in them. Not very useful, particularly when more than one of them is open; I would much rather see the file name. PDFs generated from OpenOffice.org also have this problem; they have the Title set to the name of the original document plus “.pdf”, which, if the document has been renamed, it becomes obsolete and useless. I attempted to look at the source for Evince and see if I could manage to add a preferences dialog and implement the behavior for it, but I have very little knowledge of Gtk+ programming and just enough understanding of C to get myself into a lot of trouble. I managed to add a Preferences option to the menu, but that is as far as I got before I realized that this is something that I likely cannot do. :-)
We have heuristics in ev-window-title.c and you should improve them instead. There will be no preferences dialog in evince.
After all, let's move discussion to single place. *** This bug has been marked as a duplicate of 312847 ***
Is it unreasonable to want to tell an application (as a user) that you have a preference to how it works? And I can not see how this is a duplicate of a “fixed” issue. I have a large number of files that I cannot alter their titles and the like, which have useless titles. Now, while it may be true that the application can detect things, what if I as a user want to force the application to only display file names? Why can there not be a preferences dialog for that? Why do you say “there will be no preferences dialog in evince?”
(In reply to comment #6) > Is it unreasonable to want to tell an application (as a user) that you have a > preference to how it works? Yes, that can be unreasonable sometimes. Evince has opted for a no-configuration policy and tries hard to do The Right Thing by default. > I have a large number of files that I cannot alter their titles and the like, > which have useless titles. Now, while it may be true that the application can > detect things, what if I as a user want to force the application to only > display file names? 1. Download the sources 2. Untar them 3. Hack a patch 4. Compile or (re)package 5. Install > Why can there not be a preferences dialog for that? > Why do you say “there will be no preferences dialog in evince?” Because it stimulates bloat. Evince is a complicated application, but the interface is deliberately kept pretty simple.
I have the sources, and I have been looking at them and find that I lack the capability. That won’t stop me from trying, and trying again. While I agree that simplicity is key when it comes to interface design, I don’t think that simplicity should ever be at the cost of valid user choice. I also think that while there are times when there is something that can be called the “Right Thing” that there isn’t one right thing for everyone; I know that if I had the option right this second, I would tell Evince to just display the file names. This makes me think of something else, though. Does Evince use Gconf for anything? Would it be possible to just add a list of strings in Gconf for the window title layout? maybe window_title_layout = ['file name', 'document title'] or something like that? Or perhaps boolean settings that are things like windows_show_file_name, window_show_document_title or the like? That would be acceptable at least to me; I don’t know about a person who would more closely match the definition of end-user.
Dunno whether that will make it. I'll reopen this bug and let others handle it.
Can I stir the pot again on this one? It's been om my wish list for ages. I view lots of journal articles that have as their titles "No Job Name" or some junk such as "PII: 0009-2614(95)00953-2". I currently have a dozen or so open windows with what might as well be random text as their titles. When I want to view a specific document, am I supposed to click on windows in the Window List until I find the one I'm looking for? Stupid. Even technically useful titles, such as a DOI identifier, don't help me find the window I'm looking for. A filename would. According to comment #23 of Bug 312847 the filename is the appropriate thing to put in the title anyway, according to GNOME policy! Perhaps the appropriate logic for the heuristics is: if it's been saved locally use the filename, otherwise use the title?
Created attachment 108348 [details] [review] Cleanup and alteration to follow the GNOME HIG This patch fixes ev_window_title_update() to comply with the GNOME HIG, Chapter 3, at http://library.gnome.org/devel/hig-book/stable/windows-primary.html.en As a result of this change, and the previously stated requirement that Evince not take on a preferences pane, the ev_window_title_sanitize_extension function is no longer necessary as it is not called anywhere else. The #defines for the backends, the struct BadExtensionEntry, and the array bad_extensions are also no longer necessary, and have been removed. This should apply against SVN trunk as well as 2.22.0. See LP 78584 for a debdiff to update Ubuntu's source package for Evince in Hardy. Diffstat: ev-window-title.c | 70 +++--------------------------------------------------- 1 file changed, 5 insertions(+), 65 deletions(-)
there is, for users of ubuntu hardy, a package available in my PPA that has this patch applied to it: https://edge.launchpad.net/~mtrausch/+archive
No thanks.
And why should the patch be rejected? Given that this patch purportedly fixes this application to be consistent with GNOME HIG I think the developer(s) could at least give some reason for rejecting the patch. If the developer(s) are intransigent with regards to changing this behavior, perhaps this project should be forked.
It's just a design decision, I hope you understand us, sorry.
If the reason for not having a preferences panel is to "just do the right thing," and the "right thing" is already prescribed by the HIG, why reject this? Is there a technical reason for rejecting this patch, because if so, I would like to know so that it can be fixed.
There is no any technical reason as I said. We simply belive that it's better to show the title than file name. HIG doesn't cover all cases, for example it says nothing about web browser title and so on.
Yes, but it makes sense in the Web browser to diverge from HIG, if that were indeed the case. However, there are a _large_ number of PDF documents that have badly/improperly set titles, and they cannot all be detected heuristically. Perhaps a compromise solution would be to include the PDF title element in the title bar if it exists, to the right of the file name? However, that doesn't solve everyone's problem. A very large percentage (I would say 80% or so) of the documents I receive have improperly set, automatically generated, or otherwise misleading titles that have no meaning to me, the user. Maybe the case for you is different, and I'd be a fool to assume that I can know your use case(s). If this patch is unacceptable from a design standpoint, then a preference should be added to the application such that a user can toggle between the two modes, maybe with something as simplistic as adding a checkbox option in the "View" menu that saves a persistent setting, defaulted to checked, that says "Prefer PDF title", or defaulted unchecked that says "Prefer file name." The View menu, however, is not a place that I would argue permits for much in the way of verbosity, and since there is no status bar at the bottom of the application, it'd be impossible to elaborate on what that menu option does, thereby adding confusion. If adding a preferences panel to Evince is also unacceptable from a design standpoint, then the options are indeed limited. I, for one, _need_ to have meaningful data shown in the title bar. Meaningless data in the title bar means meaningless data in the Window List, which means if I have 5 documents open with meaningless titles in them, there is no way for me to disambiguate them without switching through them all to see which one it was I needed to refer to in the first place, which is distressing to my work flow.
I second (and third, and forth, et al.) everything Michael has said about the absolute uselessness of PDF titles in the vast majority of documents. This design decision needs to be reviewed.
Could you provide the list of the crappy titles you have and the list of corresponding file names?
Sure. For documents I have open currently: doi:10.1016/j.carbon.2004.07.002 (~/Report/Published.pdf/EdgeCoal.pdf) Rsc_Cp_b614390c 331..343 (~/Report/Downloaded_PDFs/NonadiabaticModelling/Harvey.PCCP9.pdf) BEYOND BORN-OPPENHEIMER: Molecular Dynamics Through a Conical Intersection (~/Report/Downloaded_PDFs/NonadiabaticModelling/WorthCederbaum.ARPC55.pdf) PDF/24/aa2481-04.pdf.url (~/Report/Downloaded_PDFs/Astrochem/Flower.etal.AA436.pdf) [None, filename displayed for this one] (~/Report/Downloaded_PDFs/symmetry_notation.pdf) [None, filename displayed for this one] (~/Report/Downloaded_PDFs/Leiden/JaswalDilly.LiD.PRB15.pdf) doi:10.1016/j.cplett.2006.05.018 (~/Report/Downloaded_PDFs/CNO/Gogtas.CPL425.pdf) No Job Name (~/Report/Downloaded_PDFs/H2+CH/Mayneris.JPCA110.pdf) PII: S0009-2614(99)00198-0 (~/Report/Downloaded_PDFs/CNO/ReignierStoecklin.CPL303.pdf) [None, filename displayed for this one] (~/Report/Downloaded_PDFs/H2+CN/terHorstSchatzHarding.JCP105.pdf) I can give you a screenshot of my window list if you like ;-) So out of the ten PDFs I happen to have open at the moment, one has a useful title. Most PDFs distributed by the publishing houses relevant to my fields use at best a DOI in the title, more often an in-house identifier or simply no title. So once more I suggest that The Right Thing is to show the filename if the file's been saved somewhere in the $HOME tree (or at least not an obviously temporary filename used by a browser), fall back to the title otherwise.
Created attachment 108400 [details] [review] Always show filename in titlebar This patch takes a slightly different approach. It removes strange extensions from the window title (if any) and adds the filename between parentheses after the document title. E.g.: - Document Title (filename.pdf) for documents with decent titles - untitled (filename.pdf) for documents with "untitled.doc" as title - filename.pdf for documents without a document title at all
That patch won't help me; I use the file names in my window list at the bottom --- the "taskbar" if you will --- to find the window I need quickly. Anything wrong with file name first, document title in parens, if it _must_ be shown at all? Window title bar space is really limited, and I think that the most meaningful identifier of a file is the name itself. Even downloaded PDFs have more useful file names than they do title identifiers.
Created attachment 108430 [details] Testcases I decided we'll implement an intelligent method (with machine learning probably) for selection of title if it has sense or filename if it's sensible. Both can have garbage though. To do that we first of all need a database of a names to test algorithm performance. I'm attaching my data, please submit yours. The more the better.
Would this not add undue complexity to the program, as well as be confusing? It'd certainly be confusing to me. How would you teach it? Both can be garbage, but users already know how to work with files much more intuitively than they can learn extensions to applications. I respectfully disagree with that decision due to the bloat, increased usage of resources, the potential for confusion, and additional complexity it would introduce. I simply feel that it is unnecessary when there are much better, more elegant, and simplistic options available. I have text books that carry names like "jhtp6" broken out into several chapters. Useless. I have papers that have names like "57bcb55e-0d62-47d0-bb5e-735ca5065526" (a UUID). Equally useless. I have things that are labeled "Print job" or "Printer output" or some variant thereof. Again, useless. The answer isn't "teach Evince all about these broken documents" nor is it "everyone publish documents correctly." Neither of these things can ever be 100% carried out, and it's bound always get it wrong at least some of the time (from the point of view of the user, anyway, even if not in the POV of anyone else; the user is what matters). Therefore, adding complexity to Evince is, I feel, not the answer---it's the beginning of a never-ending goose chase, compared to simply showing the file names. If you show the file names, then you put the user in control, too, which is always a better choice than taking it from them. Some users have naming conventions---as I do---which make it easy to find files they want to work with no matter where they are, no matter what application they are in. It's best to be consistent with other document-oriented programs here and not go out to do something special when it changes the level of consistency with other applications, particularly since Evince is officially part of GNOME. The basic idea is that renaming the document can be done one of a hundred ways and doesn't require interaction with the Evince program specifically. Evince is just a document viewer; it should do that, and do that well (and IMHO, it does). It should leave the embedded metadata available in the properties, and use the file name in the title bar, which is metadata that the user can control. I would say that if this additional complexity must be added, then Evince should be able to use keys in GConf so that the user can fine-tune its behavior. If a preferences panel is out, fine, but at the very least give the user control of what goes in the title bar. Maybe even something like a "title_bar_format" key in GConf that uses format specifiers like "%f" for the filename, "%t" for the document title, "%c" for the custom guessing algorithm, and anything else for a literal value. Or, something as simple as a multiple choice string entry such as "filename", "doctitle", or "fancyguess", with the default for no key or an invalid value being one of those three choices. _Anything_ to give the user the choice.
Created attachment 108935 [details] Test Archive with the database, feature extraction python script and result of the training with weka. The quality is around 95%, though it's rather incorrect estimate. I hope to improve this soon and implement the decision tree in evince itself.
tit_em = True: False (607.0) tit_em = False | tit_unt = False | | tit_ext = False | | | is_micro = False | | | | title_rat <= 0.08: True (174.0/29.0) | | | | title_rat > 0.08 | | | | | file_rat <= 0.5625 | | | | | | file_rat <= 0.375: False (3.0) | | | | | | file_rat > 0.375: True (5.0) | | | | | file_rat > 0.5625: False (6.0) | | | is_micro = True: False (5.0) | | tit_ext = True: False (121.0/5.0) | tit_unt = True: False (78.0) The tree
I'd like to cast a vote of support behind Michael and say that I agree with pretty much 100% of what he has said here. However, I do applaud Nickolay on his attempt to come up with such a technical solution. But I am confused a little by looking at your data file - there are some which seem like they are actually good titles: 0 YCST-2004-03.pdf Flexibility in Dependable Real-time Communication 0 YCS-2004-380.pdf Workshop on Grid Security Practice and Experience 0 ws-secureconversation-1.3-os.pdf OASIS Specification Template 0 weinhold-diplom.pdf Design and Implementation of a Trustworthy File System for L4 0 voip-security-layered-approach.pdf VoIP Security - A layered approach - XMCO Partners 0 TUD-SERG-2007-013.pdf Trace Visualization Using Hierarchical Edge Bundles and Massive Sequence Views 0 thesis-sapan-2006.pdf Optimistic Compiler Optimizations for Network Systems 0 Thesis-2005.pdf Masters Thesis: A generic attack on hashing-based software tamper resistance 0 p1409-santos-neto.pdf Requirements for Information Systems Model-Based Testing There are many more like that. Anyways, the point I'm trying to get at is that even if you overcame the difficulty of making this logic system smart enough to figure out when to use filenames versus titles, it all relies on not having a flawed database, which seems like altogether too much effort to maintain.
Also found at http://bugs.debian.org/493266 : “Evince show the filename of PDF in the window title line, if the PDF does not have a title, otherwise the PDF title. If I open multiple PDF files with title, I cannot see which file I'm actually looking at. (I check the layout of multiple PDFs in foreign languages, that I do not understand myself.) It would be nice to have both the title and the filename shown. This is also inconsistent, as I can only see the filename, not the PDF title, in the history in the Files menu.”
This behavior of evince has always nagged me. I never reported the bug before because it seemed such an obvious bug that I just assumed that it would be fixed in "the next version". Tonight, after being unable to identify which document was opened in each window for the thousandth time, I decided to file a bug report. As expected, I found that the bug was already reported. I fully agree with the comments of Michael Trausch. Due to my work, I read many different PDFs from different sources each day. Hence, I know perfectly well that the titles of the overwhelming majority of PDF files are useless. Even when the title is nice, it is not always enough to identify the document. I have several files whose title is "Normalized execution time". I need to be able to differentiate them, but evince does not show the filename. It does seem to show the filename of some files, but I cannot see the pattern that it follows to decide whether to show it or not. This is very confusing. Why not put "filename - title" in the tiltlebar? This would allow to easily identify all files by their filenames and would still show the title for the few documents with a correct title.
Initially I was against showing the file name, but I have changed my mind: there as just too many files around with crappy titles (even PDF documents from expensive scientific publishers). (In reply to comment #30) > Why not put "filename - title" in the tiltlebar? This would allow to easily > identify all files by their filenames and would still show the title for the > few documents with a correct title. Something like this sounds good to me, although I would opt for "filename (title)", but that is just nitpicking. Nickolay, what do you think? I'm sorry to say this, but I think that using methods from artificial intelligence with many added heuristics is not the way to go here. Let's keep things simple.
> Nickolay, what do you think? I think if you can choose which way is correct together with Carlos :) I won't argue against, the ML was just a suggestions.
*** Bug 587636 has been marked as a duplicate of this bug. ***
+1 for file name in the window title bar. While getting the title from inside the document and coding heuristics is for sure quite funny, I personally never meet a use case where this brings me anything but confusion... But anyway, if this is the price for free software where developer have fun, I can pay it!
+2 for file name in window title bar. It is very annoying and dangerous when comparing very similar postscript files to lack the file name in the title bar. It could even lead to data loss if one removes the wrong file because they got confused which one they were viewing. Uh-hrm.
I support having evince display the file name in the window title bar, either by default or if necessary by a configuration file. This is in accord with GNOME Human Interface Guidelines 2.2.1 and more importantly improves usability and productivity. I often simultaneously deal with many (20 or more) research articles from publishers and academics around the world. In my experience the internal "Title" of the pdf document is usually unhelpful. Being unable to quickly select the correct article from the panel window list seriously slows down my work.
Adding a configuration file to show the filenames is only a work around for the problem that many pdfs outthere do not have a correctly set Title. The problem we should be fixing is that Evince or Nautilus (possibly both) should allow the user to change the Title of the Document... Although this is normally discouraged since PDF files are "read-only"... On the other hand, assuming that the filename is meaningful is not good neither, specially if the document you are seeing is a temp file, it could have a weird filename.
The whole point is that the user can control the file name of the document a lot more easily than the internal PDF title metadata. Some users can't even do that. Let's be honest here: the average user barely knows how to rename his or her files on the filesystem but they can be easily shown how to do so, and it is something that is universal. It applies to any type of file, not just PDF, and doesn't require any special learning or practice to do. After doing it a few times they might even remember. But they're not going to go do something highly specific to one file type in one viewer application and remember how to do it at all. If something so common and at the forefront of the UI (renaming files) is difficult for many users, it is certainly going to be difficult for them to fix the titles in their PDF applications. And they don't want to file bugs because some heuristic is guessing incorrectly. In fact, they won't. The sorts of people I am talking about are the mass majority who think that "it doesnt work" is a proper bug report, and that we programmers, system administrators, and desk-side support personnel can just divine the problem from those three words. There are best practices in the world of programming, and several of them are just flat out ignored here. The principle of least surprise being one; internal consistency with other document-centric applications present in GNOME being another. Engineering something complex for the sake of complexity is also something that goes against well-established best practices. I hate to say it, but it is issues like this that turn people off to a great deal of free software. In some projects, there is the very real problem of "not enough people to help", and that in itself turns people away, but not as many. People understand genuine resource limitations. They experience them in their daily lives. But when an end-user sees a bug report like this, they start to think that the developers just don't care about the users. That sort of sentiment is exactly why many of the people that I know have started using things like GNU, Linux and GNOME: because companies like Microsoft have proved time and time again that they don't truly listen to their users (despite what their advertisements might say). Little tiny niggling issues mean a lot to end-users. People like myself can write a patch to work around them or ignore them entirely, because at least I know how to navigate my system and do so well. But most end-users don't care. If it doesn't work, they move away. And I can think of nothing more discouraging to most end-users than some core piece of software in their desktop environment behaving in an unexpected manner, even if it is a small thing to fix. Furthermore, using heuristics and trying to be "clever" instead of doing the most straightforward thing is one cause of modern software bloat. Displaying the filename takes no extra effort, does not require a database of good/bad/indifferent names, does not require feedback from users, does not require additional effort on the part of the developers to support, and does not require any extra CPU effort. Believe me, nobody is going to notice the runtime of such an algorithm on a truly modern computer, but if someone is using a system that has 64 MB of RAM and a single CPU core running at sub-600MHz, on a slow hard disk, all of a sudden you're talking about an unacceptable increase of overhead when displaying a PDF is hard enough for such a system.
Let me comment in general first here 1. we all want to get this fixed. 2. The HIG does not quite apply here, so I asked advice from the GNOME usability team on this (the Hig does not apply because if the TITLE is meaningful, then it's far more important to have the TITLE in the window title than the filename.) 3. Please understand and respect that adding a configuration option (either as a preference or as a config file) to switch between showing the filename o the title is a NO-NO for Evince. So I kindly ask you to stop asking to add this a configuration option. 3.'This does not mean that we don't care about this issue. This means that the add-configuration option solution is not acceptable for Evince. 4. Personally (as a user and not an evince dev), I feel exactly as in comment #37 (also being a scientist my self), but this is an usability problem of the window-list panel of GNOME 2 that is going away in gnome-shell, so the main usability problems described in this bug are solved in GNOME 3. The main problem is that if the title is correct, then it's far more important the filename. Of course, there is no way of guessing whether the filename or the title are good... so in the end we probably need to show both. Now... (In reply to comment #38) > The whole point is that the user can control the file name of the document a > lot more easily than the internal PDF title metadata. Some users can't even do > that. I agree with that. But for me that's the main problem, users should be able to change the title of their documents as easily as they can change the filenames. Forgive my analogy: If you have an audio file, say mp3, without the proper metadata, then you don't ask your favorite's player vendor to show the filename, you fix the metadata of your file. > > Let's be honest here: the average user barely knows how to rename his or her > files on the filesystem but they can be easily shown how to do so, and it is > something that is universal. It applies to any type of file, not just PDF, and > doesn't require any special learning or practice to do. After doing it a few > times they might even remember. But they're not going to go do something > highly specific to one file type in one viewer application and remember how to > do it at all. So you miss my point. If what you are saying is true, then how come that adding the filename to the window title solves the problem for these users? since they do not know how to change the names of their files, they would end with window titles that have no meaning at all. That's exactly why putting ONLY the filename in the window title is not a solution, and that's why your patch was rejected in the first place > > If something so common and at the forefront of the UI (renaming files) is > difficult for many users, it is certainly going to be difficult for them to fix > the titles in their PDF applications. And they don't want to file bugs because > some heuristic is guessing incorrectly. In fact, they won't. The sorts of > people I am talking about are the mass majority who think that "it doesnt work" > is a proper bug report, and that we programmers, system administrators, and > desk-side support personnel can just divine the problem from those three words. > > There are best practices in the world of programming, and several of them are > just flat out ignored here. The principle of least surprise being one; > internal consistency with other document-centric applications present in GNOME > being another. Engineering something complex for the sake of complexity is > also something that goes against well-established best practices. I'll be polite and I will just recall you that Evince is developed by volunteers on their spare time. This chunk of comment has nothing to do with the bug itself. > > I hate to say it, but it is issues like this that turn people off to a great > deal of free software. In some projects, there is the very real problem of > "not enough people to help", and that in itself turns people away, but not as > many. People understand genuine resource limitations. They experience them in > their daily lives. But when an end-user sees a bug report like this, they > start to think that the developers just don't care about the users. That sort > of sentiment is exactly why many of the people that I know have started using > things like GNU, Linux and GNOME: because companies like Microsoft have proved > time and time again that they don't truly listen to their users (despite what > their advertisements might say). Again, this has nothing to do with the bug itself. The bug status is NEW, meaning that we WANT to get this fixed. > Furthermore, using heuristics and trying to be "clever" instead of doing the > most straightforward thing is one cause of modern software bloat. Displaying > the filename takes no extra effort, does not require a database of > good/bad/indifferent names, does not require feedback from users, does not > require additional effort on the part of the developers to support, and does > not require any extra CPU effort. Believe me, nobody is going to notice the > runtime of such an algorithm on a truly modern computer, but if someone is > using a system that has 64 MB of RAM and a single CPU core running at > sub-600MHz, on a slow hard disk, all of a sudden you're talking about an > unacceptable increase of overhead when displaying a PDF is hard enough for such > a system. Well, you don't have to worry about that. The plans to use very clever heuristics are dropped.
I really think that it just comes down to the question of which is easier for the user to change, the document title or the file name. It's true that in some cases the document title may be good (though in my experience rarely), but in that case the user can always change the filename to match that title. It doesn't work the other way around. Please make evince show the file name in the window title.
(In reply to comment #40) > I really think that it just comes down to the question of which is easier for > the user to change, the document title or the file name. It's true that in > some cases the document title may be good (though in my experience rarely), but > in that case the user can always change the filename to match that title. It > doesn't work the other way around. Exactly, we should fix that also! > > Please make evince show the file name in the window title. To make my self clear, I am not against showing the filename in the window title, I am against showing ONLY the filename in the window title, but we'll wait for gnome usability team to comment.
(In reply to comment #41) > (In reply to comment #40) > > I really think that it just comes down to the question of which is easier for > > the user to change, the document title or the file name. It's true that in > > some cases the document title may be good (though in my experience rarely), but > > in that case the user can always change the filename to match that title. It > > doesn't work the other way around. > Exactly, we should fix that also! Are you suggesting that evince (or maybe some other app) be given the capability of editing the titles in pdf files? That seems a bit outside the scope of this bug. And unless it's as easy as changing a file name then it's going to be less desirable to me. Currently if I click on the save button on a pdf I'm viewing in my web browser it asks me where to save it. I then give the file a meaningful name. I don't see how we could get anything as easy as that working with changing the document title of pdfs. Even for PostScript files, which are simple to edit in a text editor, it seems like too much trouble to me to do that by hand.
DRM'd documents cannot be modified, and most people that I know (excluding SA/NA/Programmer types who know better) aren't even aware that PDFs have a title other than the filename. They treat it as glorified electronic paper. Fortunately, that's its use case. You say that "the plans to use very clever heuristics are dropped", but the one normal, expected, straightforward, simple and consistent solution that every other document-centric utility in GNOME adheres to is being rejected? That does not make sense to me. Unless you do not consider Evince to be document-centric, but then we cannot possibly communicate. If my word processor, or my text editor, or my spreadsheet program displayed anything other than the name of the file, I would be hopping mad. And let me tell you, this bug makes me hopping mad when I have several documents open (**especially** several revisions of the same document). That's why I patched Evince in the first place back when I did, because at that time I was working with many, many documents all at once. I also get that Evince is developed by volunteers in their spare time. I get that absolutely. I've been around the block in this world for quite some time. That said, that is even more reason to do the straightforward thing: displaying the filename is the path of least resistance, it is consistent with other applications and the HIG, it is what users expect (clearly; look at virtually every post on this bug that isn't from someone labelled as an "evince developer"), and it doesn't take that much effort at all to do. And if the developers want to do something that isn't straightforward, than it is easy (and painless) to include *some* method to let the user opt out. Almost no extra private RSS code is required, don't even worry about implementing a preferences page or toggle option in the menu if you don't want to. But respect the user's wishes and at least let them set something in gconf or gsettings or whatever it is that GNOME is using these days. Also, what I said earlier about issues like this being problematic, that was directly in reference to this bug. User X comes along and expects to use his or her system in a way that makes sense to them; files a bug, gets told "not our problem, generate the document correctly", gets told "HIG doesn't apply", gets told "You're wrong, it's not broken". Yeah, that's an awesome way to keep non-programming users, sure. Honestly, I find it really unfortunate that there is any sort of metadata in PDF files. It's of very little use, especially since so many people and businesses that produce PDF files rarely bother to make any sort of use of the metadata fields that are available. The reality is that the metadata fields are almost universally useless, unless you have someone like myself that will actually put the metadata in documents when they are generated. The problem is exacerbated by the fact that nearly every PDF generation tool out there generates bad data for the metadata fields (an ID, some thing it thinks is a title, the first few words of the document, the filename of the source document, etc.) in a misguided attempt to be helpful. To my knowledge, Evince is the only document viewer where these misguided metadata generators have a negative impact. Yes, technically the problem is in the generation of PDFs. Realistically, users don't care where the problem is. It is within the power of the PDF viewer to be immune to such a problem in the first place. And that is why most all of them are (every single one that I am aware of; of course I am sure that I am not aware of all of them). I have had a few requests in my mailbox to keep up with packaging a fork of evince that behaves in a manner consistent with other document-centric applications; I guess I'm just going to grant that request. (Honestly, I'd rather not: I'd rather put my work upstream where I can.) But since neither my opinion as a long-time GNOME (and Evince) user, nor my code are welcome here, I'm out.
I tend to agree with the people asking for the file name in the window title. There are too many crappy PDF files around, even those from professional publishers (scientific papers). In a perfect world the title would be fine, but let's face reality: most PDFs are broken in that respect...
short version: I also agree that too many crappy PDFs out there. I also agree that we need the filename in the window title. What I don't agree to is that we don't display the title anymore. That's why I asked advice from usability team. long version: (In reply to comment #43) > DRM'd documents cannot be modified, and most people that I know (excluding > SA/NA/Programmer types who know better) aren't even aware that PDFs have a > title other than the filename. They treat it as glorified electronic paper. > Fortunately, that's its use case. You make very good points here. > You say that "the plans to use very clever heuristics are dropped", but the one > normal, expected, straightforward, simple and consistent solution that every > other document-centric utility in GNOME adheres to is being rejected? It is not being rejected, the bug status is NEW, which means is a valid bug. What I say is that I understand the point of following the HIG and having ONLY the filename in the window title but I also think that it is important to have the title always visible, so I don't know how to fix this bug and I asked advice of the usability team to know how to solve this. > > Also, what I said earlier about issues like this being problematic, that was > directly in reference to this bug. User X comes along and expects to use his > or her system in a way that makes sense to them; files a bug, gets told "not > our problem, generate the document correctly", gets told "HIG doesn't apply", > gets told "You're wrong, it's not broken". Yeah, that's an awesome way to keep > non-programming users, sure. See my answer above. Most pdfs out there are broken and we can't fix them all ;) So this is a valid bug. I take back the HIG does not apply, what I meant is: we also need to display the title as browsers do. > > Yes, technically the problem is in the generation of PDFs. So you agree with me there ;) > > Realistically, users don't care where the problem is. It is within the power > of the PDF viewer to be immune to such a problem in the first place. And that > is why most all of them are (every single one that I am aware of; of course I > am sure that I am not aware of all of them). Please file bugs about the issues you are aware of in Evince. > I have had a few requests in my mailbox to keep up with packaging a fork of > evince that behaves in a manner consistent with other document-centric > applications; I guess I'm just going to grant that request. (Honestly, I'd > rather not: I'd rather put my work upstream where I can.) But since neither my > opinion as a long-time GNOME (and Evince) user, nor my code are welcome here, > I'm out. I am sorry to read that. We need a lot of man power for evince. Again, your opinion is HIGHLY appreciated, having patches rejected is normal in every open source project :)
This report is slowly getting too long to be useful, so let's keep comments succinct and let's make progression. As far a I am concerned, this would do as the window title (this is wat my original patch also did iirc): Document title (filename.pdf)
I don't think I care if the title is displayed, as long as the filename is displayed first. For most use-cases, the first part is what is seen when looking at the task bar, a window list or menu, or ALT+TAB, Super+TAB, etc. > > Yes, technically the problem is in the generation of PDFs. > > So you agree with me there ;) Oh, absolutely. I just also think that the best place for the control is in the hands of the user, and that the shortest and most direct approach to that avenue is almost always the best one. And if it can be accomplished without adding anything to an application---or adding just the bare minimum---then all the better. What I can say is that the way I wrote it is the way that I would expect it to behave, and the way that most users that I am aware of expect it to behave. Obviously, the people I know are not a representative sample of all users or even all user types, but they are mostly in the end-user category. I don't often help non-end-users, so I can't speak for them (other than myself, mostly). > I am sorry to read that. We need a lot of man power for evince. Again, your > opinion is HIGHLY appreciated, having patches rejected is normal in every open > source project :) I'm not pained over having my patch rejected. Only about 2/5 to 1/2 of the patches I've written for any of a number of projects make it through. What I am irritated about is the things like the "name database"---which is provably going to be incorrect at least some, if not most, of the time---being called a "good idea" over just displaying the filename. I'd have no objection to something like: "file.pdf - The Document Title" in the titlebar. I'd have even less objection to it being reversible somehow so that users could decide which works best for them; I do know that title first would never work for me. I know that I don't operate the same way that everyone else does, and I see some pretty strange ways to use software, so I can certainly speak to the notion that options (when carefully considered and carefully placed) are a good thing. Going overboard and having tens or hundreds of prefs for an application that aims to be simple is obviously not a good idea, but the other end of the spectrum, going overboard and banning options entirely, is just as detrimental in some ways. Very rare is the application that truly fits everyone with zero configuration: in fact, I am not even sure that it is possible.
Created attachment 176108 [details] [review] Wouter's patch updated. Finally, I think that for consistency, I prefer the: "filename (Title)" version. the attached patch is almost Wouter's and it is updated to current git HEAD.
I am absolutely gob-smacked that this hasn't been fixed years ago. Years ago, a heap of users said "this is bad". The only response from the developers should have been to fix it, not tell the users that they're wrong. More than four years to even think about fixing an obvious and simple bug? Absolutely mind-blowing.
Please refrain from making additional comments bitching about the miserable state of things and how the world would've been a better place if this was fixed earlier. Thanks. Anyway, let's move this forward. Either order is fine with me. Using "filename.pdf - Title goes here" would be most useful I think. I guess the maintainers should ack this change. José, thank you for updating my earlier patchg. Can you take care of pinging the maintainers? Thanks!
Review of attachment 176108 [details] [review]: commit message says: Show the filename + title in the window title. but you are using title + filename. I agree with Wouter about using the filename first. Also you are using an invalid bug number in the commit message See bug #38692., it's bug #386292 ::: shell/ev-window-title.c @@ +147,2 @@ ev_window_title_sanitize_title (window_title, &title); + title = g_strdup_printf("%s (%s)", get_filename_from_uri (window_title->uri), title); get_filename_from_uri() returns a new allocated string, so you need to use a variable to free the memory.
I just pushed a corrected version (reviewed by Carlos in the IRC) to git master. So the fixed will appear in Evince 3.0.