https://tanguy.ortolo.eu/blog/article30/dont-return-document en a blog about Debian and self-hosting Wed, 05 Oct 2011 06:33:00 +0000 PluXml https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317796389-1 https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317796389-1 @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. Wed, 05 Oct 2011 06:33:00 +0000 Tanguy https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317743567-1 https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317743567-1 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. Tue, 04 Oct 2011 15:52:00 +0000 sytoka https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317742424-1 https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317742424-1 > 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 ! Tue, 04 Oct 2011 15:33:00 +0000 sytoka https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317723947-1 https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317723947-1 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. Tue, 04 Oct 2011 10:25:00 +0000 Lee https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317723060-1 https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317723060-1 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 Tue, 04 Oct 2011 10:11:00 +0000 aukkras https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317719298-1 https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317719298-1 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. Tue, 04 Oct 2011 09:08:00 +0000 milosh https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317718882-1 https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317718882-1 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. Tue, 04 Oct 2011 09:01:00 +0000 Matthias Urlichs https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317717270-1 https://tanguy.ortolo.eu/blog/article30/dont-return-document/#c1317717270-1 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. Tue, 04 Oct 2011 08:34:00 +0000 Andrew Shadura