PDA

View Full Version : Auto starting software



MichaelS-R
19th October 2009, 02:02 PM
I have a number of applications that I like to have start when I log in. Is there a way to have them automatically open in a specified workspace? For example, I normally keep my e-mail in workspace 2 ('E-mail').

Thanks,

Michael

Sagitter
19th October 2009, 02:06 PM
$ gnome-session-properties

MichaelS-R
19th October 2009, 02:20 PM
$ gnome-session-properties
Yes, that gets Evolution started but it doesn't allow me to specify workspace...

Thanks,

Michael

jpollard
19th October 2009, 02:32 PM
Of course there is.

Several in fact -
terminal login:
.bashrc
.cshrc
.login

GUI login - sometimes more effort... A custom X session is the most general (.xsession script). Just be sure to run
your desired GUI at the end of it. Use "exec <gui choice>" to save a process. Now getting applications in the
right workspace however.... That is up to the window manager, and how the window manager operates. Usually
it must be running before the application is started, or the application must be started by the window manager.

What is harder is termination. Since there are many ways for a login to be terminated, there is the tendency to
leave processes hanging. The X session method allows all processes to open a connection to the X server. When
a GUI logout occurs the X server resets - causing all applications to get a "broken connection" error, which can
be used to initiate an application shutdown.

Each GUI system has their own operation, some select applications that are attached to a bar (gnome has one
at the top of the display). These applications have a connection to the X display that may be active (such as the
clock), others just wait for direction (audio control, network control).

KDE has (or did have, I haven't used it in a while) a method automatically invoked - When the KDE window
manager is/was shutting down it would identify all active windows and ask if they are to be saved. When saved
they would be restarted on next login, and in the same workspace. One problem I had with it was that application
contexts would NOT be saved unless the application itself did something special. Firefox does for instance - if it
is aborted, it asks if the existing session should be restored, or a new one started.

Terminal logins, on the other hand, do not usually get such a signal when the terminal is closed. You can
have an open connection, but it is recommended that only stderr remain connected. If stdin is there then commands
can/will be misdirected, or blocked - usually the background process gets blocked. Some shells (csh) have a
.logout script run, but only if logout is voluntary. Aborts (as in a shell running over a network and having the
network connection fail) do not. These leave the process running after logout - sometimes it is exactly what
you want (putting a long running compile in background).

Likely more and less than you wanted to know :-)

troyatlarge
19th October 2009, 02:53 PM
Wow - this sounds like pretty cool stuff. I do not, however, really follow exactly to accomplish what is being asked for, or how to do the stuff mentioned later (like have a program running after log-off).

tho.mei
19th October 2009, 10:52 PM
for KDE:
place a desktop-link in /home/username/.kde/Autostart it works like the Windowz autostart directory.

Trann
19th October 2009, 11:18 PM
If you want to auto-start a service at boot up, you need to do:


$ ntsysv

and press the space bar alongside the appropriate service, so that an asterisk appears (*)

jpollard
20th October 2009, 07:10 PM
This is a low level approach, and not necessarily user-friendly.

The most reliable logout is the GUI logout handling. If you do a .xsession script to start the GUI, just wait until
the GUI terminates, then terminate whatever you have started. Something like:

$HOME/.xsession
----------------------------------
#!/bin/bash
... # setup, environment setup, whatever
somebackgroundprocess >logfile 2>&1 & # put the process in background, and log any output or error in logfile
pid_of_background=$! # the magic of bash - $! expands into the process id of the last backgrounded process

startgui # wait for it to terminate

kill -15 $pid_of_background # 15 is a "polite" kill, and allows process to do things before terminating
sleep 5 #give it some time to terminate gracefully
kill -9 $pid_of_background # now force it out. It doesn't matter if it has already terminated.
exit # this is the final, real logout
--------------------

Note, it is still possible to abort the .xsession process, which would leave the background process still running.

DavidMcCann
20th October 2009, 11:33 PM
All this stuff about logging out is very interesting, but what does it have to do with the original question?

I've seen this question raised before, and I don't think there's a solution, unfortunately. If you think about it, Michael, why would a desktop come with command-line tools to replace its normal functions?

jpollard
21st October 2009, 05:50 PM
All this stuff about logging out is very interesting, but what does it have to do with the original question?

I've seen this question raised before, and I don't think there's a solution, unfortunately. If you think about it, Michael, why would a desktop come with command-line tools to replace its normal functions?

I know this wasn't directed at me, but I did bring up the subject.

It depends on your environment - If it is a laptop and you logout, and shut the system down, then
any process currently running gets aborted. This CAN lead to corrupted data files (buffers incompletely flushed). Other places, logout just lets the processes run.

In the beginning... there was the command line....

It goes back to the origins of the UNIX environment. The command line can do nearly anything,
including GUI support. The command line can even operate independently of a user, which a GUI
cannot. Command lines entered into files are a script - but the commands are identical. Scripts may
be run either with terminal entry, or without. Scripts run in "background" are not directly attached to
the terminal, but instead are sill attached to the process group head which was established at login.
Note - if stderr is still connected to the terminal, it can still be aborted because on logout the terminal
is no longer owned by the user. If stdin, stdout, stderr are all redirected (though stdin may not be
open anyway) then these may continue.

Most environments allow such background processes to continue after the process group head
terminates, usually by making the command interpreter that is processing the script the new process
group head. Others will abort all processes on logout. (I seem to remember IRIX used to do this).

One advantage the command line tools have is to record errors. I can start a large compile, redirect
output (and error output) to a log file, and put it in background. If it will take several hours I can just
logout and go to lunch. Or come back the next day. Any errors are recorded. This is a
"poor-mans-batch" system, and is the most frequent use. There are shortcomings to this too - there
is no rescheduling, no restart, no resource control, and usually no further interaction.

Every UNIX or unix like system supports this. It is just that the side effects are not always handled...
I have had my large compiles fail because I shut the system down before they finished. This has
caused invalid object files to be left behind (long time ago) that prevented make from ever completing
(I had to find and delete the bad object file). If the compile was done in a parallel make... there could
be a LOT of bad files - It was usually easier/faster to just delete all object files and start over. A loss
of several hours.

You tend to notice such things...

When GUI functions were added (MIT and X window around 1984-8) the GUI was started after
login - sometimes by the .login script. To do this the .login would start the GUI with the "startx"
command, which invoked a script that started the X server, then (optionally) started a terminal
window, started the window manager - and waited for the window manager to terminate. When
the "startx" script terminated the .login script would then force a logout - though I usually
removed that - it allowed me to modify/fix things before the next login.

The only real change now is that X display sessions are supported (appeared around X11 release 2)
But they still work the same - the only difference is that now the script /etc/X11/prefdm is run at
boot time (when init enters run level 5). It is still a command line... though now the script runs a
specific program to start the GUI - kdm (KDE), gdm (Gnome), xdm (the original) or whatever. You
can still see the original if you use kdm and select the "failsafe" GUI - which really isn't a GUI. All
the failsafe option does is run the X server (in background...) and start an X terminal. The failsafe
script waits for the X terminal program to exit, then aborts the X server. You can look to see what
it actually does, but the effect is as described (The X server itself can run the script that starts the
X terminal, when that script terminates, the X server exits).

The current GUIs for linux have not changed the foundation, just made it fancier, and a LOT more
complex- added audio processes, clock processes, application startup, processes to alert you to
updates, network events, all kinds of things.

MichaelS-R
21st October 2009, 10:54 PM
If you think about it, Michael, why would a desktop come with command-line tools to replace its normal functions?

It is interesting that you say that - I can't really see why the GUI would preclude command line mechanisms to launch applications into particular workspaces (at start up or later on).

It is actually pretty annoying when you start an application in one workspace and switch to another that it is the workspace you are in at the end of app's initialisation that the app attaches to, rather than the one you were in when you started it. I tend to have 40+ documents and apps open at any given time and it is nice to keep them grouped on particular workspaces. The only saving grace is that you can drag them about in the workspace selector now (I don't remember being able to do that before but may be mistaken).

I must admit that I don't know enough about the internals of Gnome to know if there are any particular reasons why you could not attach a window to a specified workspace.

Does nobody else suffer from these problems? Or do you all have half a dozen monitors in a bank in front of you? :)

Michael

jpollard
22nd October 2009, 01:33 AM
It is interesting that you say that - I can't really see why the GUI would preclude command line mechanisms to launch applications into particular workspaces (at start up or later on).

It is actually pretty annoying when you start an application in one workspace and switch to another that it is the workspace you are in at the end of app's initialisation that the app attaches to, rather than the one you were in when you started it. I tend to have 40+ documents and apps open at any given time and it is nice to keep them grouped on particular workspaces. The only saving grace is that you can drag them about in the workspace selector now (I don't remember being able to do that before but may be mistaken).

I must admit that I don't know enough about the internals of Gnome to know if there are any particular reasons why you could not attach a window to a specified workspace.

Does nobody else suffer from these problems? Or do you all have half a dozen monitors in a bank in front of you? :)

Michael

I'm very familiar with that limitation, and it is easily explainable -

The workspace assignment is done by the window manager, which cannot assign the workspace
until the application connects to the X server and opens a window. Once the window is opened, but
before it is displayed (or as it is displayed) the window manager is notified by the X server. This
notification causes the window manager to complete the assignment and resume the "mapping"
(directing the X server to display the window) of the window to the display.

Normally, only the current workspace identifier is available, so the window is assigned that id. When
you switch workspaces the window manager sets a new current workspace, and unmaps (hiding) all
windows that do not have that identifier associated with it. The delay between application startup
and the time the window first attempts to be displayed is what allows you to switch workspaces
before the application gets assigned the workspace. This is an application problem, and could be
artificially worked around if the application would open a small token window right away... then
resize it later. Unfortunately that would introduce some odd looking anomalies in the display that
most people would not like.

Some window managers have a configuration file that allows you to assign window titles to specific
workspaces. When the application is started you use the "name" X option to name the window. When
the window manager sees the title it matches, then it assigns the workspace id, then either maps or
unmaps the window depending on whether the current workspace id matches. ((( it is possible it
is the "title" option, but I haven't used it for over 7 years... and as a geezer, I don't remember which)))

I know of no way to make such specifications to the gnome window manager. If you would like an
example of such a window manager google for "ctwm".

jpollard
22nd October 2009, 01:53 AM
I just found something for you -

Under System->Preferences->Startup Applications (I had to scroll way down the list to find it).

Is an utility that allows you to define programs to be started. It doesn't define what workspace they would go into
though. Also the Options tab has a flag to "automatically remember running applications when logging out".
If this is enabled, then these same applications will be restarted when you login next time. This is a "poor-mans"
suspend, as I don't think the applications will remember all context information you may have set (terminal windows
with a current working directory set to non-default locations may go to the home directory).

By default this is disabled.

MichaelS-R
22nd October 2009, 03:48 PM
I just found something for you -

Under System->Preferences->Startup Applications (I had to scroll way down the list to find it).

Thanks but I know about this already. It is really the ability to make applications start in a specific workspace that I was trying to achieve.

I am sure that there must be a way to attach an application to a particular workspace...

DavidMcCann
29th November 2009, 11:55 PM
Have a look at the program wmctrl: it sounds like it could be what you need.

http://tripie.sweb.cz/utils/wmctrl/

enteFinal
30th November 2009, 12:15 AM
'Startup Applications' for to open automatically; Devil's pie program for the rest
http://burtonini.com/blog/computers/devilspie/

See here
http://ubuntu-tutorials.com/2007/07/25/how-to-set-default-workspace-size-and-window-effects-in-gnome/


EDIT: It is on Fedora's repo


su
yum install devilspie gdevilspie

gdevilspie is optional; it's a GUI for devilspie

MichaelS-R
30th November 2009, 12:13 PM
David

Thanks for that, looks promising! I am giving it a try. Will let you know if it works.

Michael

DavidMcCann
8th March 2010, 12:05 AM
In case anyone wants an answer to this in future (even the OP!), the Fluxbox window manager enables applications to be associated with a particular workspace and it can replace Metacity with Gnome.