03 10 | 2011

Viewers should stay in foreground

Written by Tanguy

Classified in : Homepage, Debian, Command line, Grumble

Traditionally, when you start a program to view a document, for instance xpdf resume.pdf, it stays in foreground, and only returns when it finishes, when you are done with the document. Of course you can still run it in background if you want.

Nowadays, several programs behave in a different way, for instance Evince. When you first start it, it stays in foreground as usual. However, if you launch it a second time while the first instance it still running, it will reuse this existing instance, asking it to open your document in a new window, and immediately return. Other examples are Firefox and LibreOffice.

This behaviour is certainly more efficient in terms of memory usage and speed, but it is non-standard and causes subtle problems. When you open the attachment of an email message, or when you open a document from the Web without saving it permanently, the mailer or the browser saves the document to a temporary file, and then run a viewer with that file. As this is a temporary file, so they cannot leave it forever in /tmp; in fact they should delete it when you are done viewing it. I think the usual way to implement that is to delete it when the viewer returns: with a program that returns immediately, this means deleting it even before it has had a chance to load it.

So, if you can no longer directly open a PDF attachment from Mutt, or if you are unable to view the compressed documentation of the LaTeX class Beamer with texdoc (which uncompresses it to a temporary file and calls a PDF viewer on it), you can blame your modern PDF viewer that returns before you are finished and start hacking your mailcap file. And if you are the author of such a program, please consider implementing a way to keep a lightweight process that does not return before the main process has closed the document or to disable process reuse.

Tags : document, viewer, return, tempfile, Evince, Firefox, LibreOffice

10 comments

tuesday 04 october 2011 à 06:44 Rémi Vanicat said : #1

There is another problem with those program that use dbus for internal communication: If you have a screen session that has survived across X session, then the environment variable used to connect to dbus will be stale, and some modern program will failed to start.

tuesday 04 october 2011 à 09:25 mirabilos said : #2

Yes, I noticed that with the default settings for Lynx’ external
image and PDF viewers on Debian/Kubuntu. Very annoying.

@dbus: didn’t know that; ouch… (same for the KDE stuff though);
this hurts, especially as I use GNU screen _specifically_ to
survive X server restarts…

Yay, modern design. Grml…

tuesday 04 october 2011 à 10:34 Andrew Shadura said : #3

Hmm. While I definitely agree that viewers should stay in foreground, I must admit that my experience regarding Evince is different; it never goes to background here. Maybe, that's a different (patched?) version, I don't know.

tuesday 04 october 2011 à 11:01 Matthias Urlichs said : #4

Personally I intensely dislike the stay-in-foreground behavior. When opening a PDF attachment from within mutt, I want to keep the PDF open when composing my reply. With stay-in-front that's impossible.

The loading problem can be fixed easily: wait for the dbus reply before terminating, and load the document before sending the reply. Problem solved. In fact I think most programs already do that; viewing HTML (firefox) and PDF (evince) used to be impossible from mutt, but no longer.

tuesday 04 october 2011 à 11:08 milosh said : #5

I've got mixed feelings about that: I am definitely seeing this in firefox (or any other webbrowser), not in evince. But I also really dislike the opposite: I want to read an html attachment, my browser is automatically launched with all my tabs and mutt waits for firefox to be closed to let me read my mails... So I don't like it to go immediately in background, but I don't like it to stay forever in foreground.

tuesday 04 october 2011 à 12:11 aukkras said : #6

Another problem is when using multidisplay setup, or X forwarding over ssh - when you want to display new window on other display than already running instance - e.g. when chromium instance runs on display :0.0 and you run
# DISPLAY=:0.1 chromium
it displays new window on display :0.0 instead of display :0.1

tuesday 04 october 2011 à 12:25 Lee said : #7

It's not just viewers. If you write a script that requires you to edit a file, then checks that it was actually edited before proceeding (think VCS commit messages), then gedit will do bad things.

I *like* the idea of programs working more like services, running one main program then communicating with that instance in future requests. But yes, the "client" part of the executables themselves should be more flexible, in allowing you to wait for return. And the default/tradition does seem to be to wait by default, then exit when the command does. For a viewer/editor, launching a document to view/edit, it makes sense to only return when that *document* is closed.

tuesday 04 october 2011 à 17:33 sytoka said : #8

> I *like* the idea of programs working more like services

It's a good false idea. Very dangerous arch for virus. I learn to program without to many global variable. Modern program do not take the good direction...

The OS has share memory, swap... It's to the OS to keep program and lib in memory if there is enought memory, not to the window manager !

tuesday 04 october 2011 à 17:52 sytoka said : #9

I'd like too idea of env variable and heritage from parent. I would like to change primary group width newgroup... I vwould like to launch many instance width different parameter.

Program service seems to open the world, they don't! I really think it's a dangerous way and a one thinking way. Let people do the way they want and imagine an open world that you have not think.

Sometime, service program can be a good thing, the good way is then the one use by vim or nedit.

wednesday 05 october 2011 à 08:33 Tanguy said : #10

@Matthias Urlichs, @Andrew Shadura : I used to see that with Evince but now that I am trying to reproduce it again, I cannot, so this feature may not be very reliable.

@Matthias Urlichs : Yes it is possible for you to have your viewer stay in background: any foreground program can be put to background (although it may not be implemented by Mutt), while the opposite is not possible.

But yes it would be ok for a viewer to go to background, but only after it has opened the file. Once it it open, the corresponding name can be unlinked without affecting the viewer.

Rss feed of the article's comments

Write a comment

What is the fourth letter of the word gwysty? : 

Archives