Ticket #663 (closed defect: workaround)

Opened 11 years ago

Last modified 11 years ago

Document Viewer isn't in the Applications menu

Reported by: jdreed Owned by: jdreed
Priority: normal Milestone: Fall 2010
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

It totally should be, especially because Acrobat is becoming increasingly unreliable in our CUPS environment.

We should also report this upstream, though I bet they can tell us why we're Wrong(tm) to want this.

Change History

comment:1 Changed 11 years ago by andersk

Isn’t it more typical, intuitive, and faster to go double-click on the PDF from within Nautilus, rather than launching evince and going to File → Open?

comment:2 Changed 11 years ago by jdreed

In theory, yes, but we have several years of user inertia to overcome. It also emulates the Windows model of "If you want to launch an application, you go to the Start MenuWWApplications menu." (Whether or not the Windows model is good is debatable, but it's certainly popular.)

comment:3 Changed 11 years ago by andersk

I mean, I would have thought Windows users do the same thing (open the folder and double-click on the PDF file’s icon)…

The upstream bug that hid evince from the menu was  GNOME:312399.

comment:4 follow-up: ↓ 6 Changed 11 years ago by jdreed

  • Status changed from new to accepted
  • Owner set to jdreed

Windows users may do the same thing, but everything in Windows is also in the Start Menu. And particularly if users have messed up their file type associations, it's an easy way to get the application you want.

This is a trivial diversion (s/NoDisplay?=true$/NoDisplay?=false/) in /usr/share/applications/evince.desktop, and not having a trivial way to tell users to launch it over the phone is making life hard for OLC. Every single user I've talked to about printing their thesis has had much better luck with Evince. (There's a bigger issue of why Acrobat started to suck, but that's a separate ticket).

I propose doing this in locker-menu. We're already mucking with the menus, and I highly doubt anyone is going to complain about "Graphics" growing one extra item.

comment:5 Changed 11 years ago by jdreed

  • Status changed from accepted to development

comment:6 in reply to: ↑ 4 Changed 11 years ago by andersk

Replying to jdreed:

Windows users may do the same thing, but everything in Windows is also in the Start Menu. And particularly if users have messed up their file type associations, it's an easy way to get the application you want.

(Right-click → Open With Document Viewer?)

I still think that undoing an upstream usability decision in the name of perceived compatibility with Windows is dangerous and misguided.

But since this package is installed on non-cluster machines, I also have some concerns about the implementation: (1) it adds a diversion to something that isn’t a config package, and (2) it causes evince to show up in the menu even if evince is not installed.

comment:7 Changed 11 years ago by jdreed

It's not necessarily about perceived compatibility with Windows. I was merely using Windows as an example where people launch the same programs both by double-clicking and by menu browsing. The problem is there are 3 ways to tell people how to open a document in Evince. By far the simplest is "Applications->Graphics->Document Viewer", and that's what I would like to use. The next simplest is "in your terminal, type evince", but that is made up of many letters which translate poorly over the phone. The least simplest is "Go to the Places menu, choose Home Folder, locate your PDF, right-click on it, and choose Open With...".

The reason even "Right-Click -> Open With..." doesn't work is because the vast majority of Athena users are not used to the idea of using Nautilus to open their home directories. Additionally, all the documentation still refers to launching things from the command line. People are gradually exploring the menus, but they're not there yet.

As for the implementation concerns, noted. I'll back out my changes and make a new config package, or else move it into an existing config package and push it out for cluster machines. that having been said, I don't see how (2) is possible, given that it depends on evince (which it probably also shouldn't do.

This is all predicated on the fact that this was an arbitrary UI decision by upstream. If, in fact, there is a GNOME policy (or similar) stating that certain applications (e.g. eog, evince) shouldn't appear in the menus, then that's fine, and I'll WONTFIX this.

comment:8 Changed 11 years ago by jdreed

  • Status changed from development to committed

comment:9 Changed 11 years ago by jdreed

  • Status changed from committed to accepted

comment:10 Changed 11 years ago by andersk

Replying to jdreed:

This is all predicated on the fact that this was an arbitrary UI decision by upstream. If, in fact, there is a GNOME policy (or similar) stating that certain applications (e.g. eog, evince) shouldn't appear in the menus, then that's fine, and I'll WONTFIX this.

I don’t think it was arbitrary. See Ubuntu’s  menus-revisited specification:

“If an item is primarily launched by a specific MIME type and works with one file at a time, it can be hidden”

(Document Viewer was already hidden upstream at approximately the same time that specification was written, so it is not listed as a change in Ubuntu’s Implementation section, but others such as Image Viewer are.)

comment:11 Changed 11 years ago by jdreed

  • Status changed from accepted to closed
  • Resolution set to workaround
Note: See TracTickets for help on using tickets.