[SOLVED] How can I get conky start automatically when I start fvwm?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How can I get conky start automatically when I start fvwm?
I use Opensuse 11 with fvwm. How can I get conky start automatically when I start fvwm?
I setup the conky under fvwm session for my Opensuse 11 but it won't start automatically. I am wondering how to write some kind of scripts to force it to start automatically and with a delay about 10 seconds after fvwm starts.
~/.xinitrc is definitely the primary option if you're running via 'startx' and possibly ~/.xsession otherwise, though ~/.bashrc wouldn't work unless you were doing a lot of stuff that wasn't a great idea in itself. The "fvwm way" would be something like
Code:
DestroyFunc StartFunction
AddToFunc StartFunction
+ I Test (Init) Exec sleep 10; exec conky
in your ~/.fvwm/config (or wherever your config file lives).
~sHyLoCk~ - I don't really know anything about that FDo stuff but I doubt that would work without a session/display manager or some other setup. I believe ggyyree is trying to start from a display manager, though, so maybe.
DestroyFunc StartFunction
AddToFunc StartFunction
+ I Test (Init) Exec sleep 10; exec conky
I am sure that you have a good reason to add the delay there, conky is pretty funky sometimes. However, as we are doing it the fvwm, let's do it fully that way
Code:
DestroyFunc StartFunction
AddToFunc StartFunction
+ I Test (Init) Schedule 10000 Exec exec conky
This will work regardless of how do you start X and fvwm (unless you explicitly tell fvwm to read an alternate config file with -f).
+ I Test (Init) Schedule 10000 Exec exec conky -o -y 0 -d
Now the problem solved; however, I want to dig into this in more details,
a. Do I really need steps 1 and 2 I did above? The reason I did step 2 'conky &' is because I want to run conky at the background. Otherwise, other application will lay behind the conky frame. Any better idea to do this?
b. How can we explain the '+ I Test (Init) Schedule 10000 Exec exec conky -o -y 0 -d'? Is there any syntax about writing these things? What is 'Test (Init)'? What is 'Schedule 10000'? Is 10000 in ms? And why there are two 'Exec exec'?
I don't know how to write things in other parts of themes-rc for fvwm as well. Any clues please tell me. Thanks a lot again.
I have no idea what this step is for. It serves no purpose in which regards fvwm, that's for sure. I know this is a desktop file, as per the freedesktop standard, but this makes fvwm no good at all. Only desktops looking into that directory will be aware of it. I can tell you fvwm does not.
Quote:
2. Then I add a script .conky_start.sh below,
Code:
#!/bin/bash
sleep 10 && conky &;
This creates a script, but you are not using this script in your fvwm StartFunction, so it just lies in your hd doing absolutely nothing.
Quote:
3. I did the change for ~/.fvwm/themes-rc
Code:
+ I Test (Init) Schedule 10000 Exec exec conky -o -y 0 -d
Now the problem solved; however, I want to dig into this in more details,
I can't tell for sure because I can't see the whole code, but, assuming this line is inside StartFunction, it does the following:
StartFunction runs on every time you start OR restart fvwm. The line starts with a test to check if it's a start (and not a restart). Without "Test (Init)", fvwm would launch the command on both starts and restarts, which means that if you restart the WM for some reason, a new conky will be launched, so you could end up having twenty of them in the desktop.
If it's a start (and not a restart), then it will continue running the command after that. In this case a Schedule command, which sleeps for a given interval (miliseconds) and then runs whatever. I assume this is done because conky needs fvwm to be fully loaded for some reason, I know conky can be a bad guy sometimes, this is probably to work around some glitch here.
Last but not least, Schedule invokes the "Exec" fvwm command. "Exec" launches any arbitrary command from fvwm. In this case we are using it to launch "exec conky -o -y 0 -d".
To sum up, that line checks if fvwm is starting AND NOT restarting, if true waits for 10 seconds, then launches conky.
Quote:
a. Do I really need steps 1 and 2 I did above?
Nope, unless you are using these for anything else. But, as said, they do absolutely nothing in which regards the fvwm capability to run conky. All you need is that line in StartFunction, assuming conky is installed and configured correctly.
Quote:
The reason I did step 2 'conky &' is because I want to run conky at the background. Otherwise, other application will lay behind the conky frame. Any better idea to do this?
...
[snip]
...
And why there are two 'Exec exec'?
The first "Exec" is an fvwm command, as said above, it instructs fvwm to run any arbitrary command in a shell, just like if you type it in the command line. In this case, Exec will instruct fvwm to run this on your command line:
Code:
exec conky -o -y 0 -d
This second exec is a shell command and it's very important that you realize that it has nothing to do with fvwm. Just run it in the command line and you will see the effect: when you use exec to launch a command, the shell forks the new process and then exits. In other words: if you open an xterm and then type the command above and press enter, conky will be launched, and right after that your shell will be closed (which in turn will also kill your xterm window).
When you launch a command under fvwm, fvwm opens a new shell (not a terminal window though) to run the command inside that new shell. There's no ill effect in that, however if conky is going to be running for hours or days, there's no gain in having the parent shell opened all that time when you are not going to use it. That's what all the "Exec exec" stuff is about.
I mean, this code would work exactly the same:
Code:
Exec conky -o -y 0 -d
But the parent shell session that fvwm opens to launch conky will stay on the background wasting memory. The second "exec" will fix that.
This has a sense in this case, in some others it doesn't, for example for commands that will just run and then exit, like if you want to use feh to set a wallpaper from the fvwm config files, then the second exec is not needed, it doesn't really save you anything because it's a command that will do a job instantly, and then exit:
Code:
+ I Test (Init) Exec feh --bg-scale filename.jpg
Just a random example.
Quote:
b. How can we explain the '+ I Test (Init) Schedule 10000 Exec exec conky -o -y 0 -d'? Is there any syntax about writing these things? What is 'Test (Init)'? What is 'Schedule 10000'? Is 10000 in ms?
Pretty much explained it above, if you want to know more, review the fvwm man page first, specially the part about StartFunction and the parts about the involved commands (Test, Schedule, Exec).
After that feel free to ask if you want to know more. However, writing your own config is a good exercise (instead of using fvwm-themes or fvwm-crystal) if you want to learn more about how to configure fvwm.
i92guboj, I really appreciate what you explained. It's much clearer to me now, and I will print it out for further referencing; however, two more questions about this,
a. If I delete what I have done in the step 1 and 2. Will it affect the gnome session? It runs smoothly under fvwm but I want to make sure it also runs for gnome session.
b. Will it run at the background? I have tested with both
Code:
#!/bin/bash
sleep 10 && conky &;
and
Code:
#!/bin/bash
sleep 10 && conky;
if I run conky itself without '&'. Then the conky frame will display above all other applications... I am wondering if there will be something like this happen after I delete the whole step 2.
i92guboj, I really appreciate what you explained. It's much clearer to me now, and I will print it out for further referencing; however, two more questions about this,
a. If I delete what I have done in the step 1 and 2. Will it affect the gnome session? It runs smoothly under fvwm but I want to make sure it also runs for gnome session.
I can't answer that one. I know little about gnome, however you can always move both files out of scope, and discover it by testing and trying.
Quote:
b. Will it run at the background? I have tested with both
Code:
#!/bin/bash
sleep 10 && conky &;
and
Code:
#!/bin/bash
sleep 10 && conky;
if I run conky itself without '&'. Then the conky frame will display above all other applications... I am wondering if there will be something like this happen after I delete the whole step 2.
Thank you very much!
Let me clarify again: steps 1 and 2 do nothing in fvwm, so *the only thing that really matters there* is the fvwm command in your StartFunction, the rest is a non-issue for fvwm.
So I assume you mean outside fvwm. Outside fvwm it greatly depends on your window manager and the conky configuration.
As said, I know little about gnome and I can't be sure 100% on how it's going to interact with conky. Conky has an option on the config (can't remind right now) that tells it to draw on the desktop OR using its own window. When it's drawn in the desktop it should always be on the root window, which is the lower window of all, the surface of your desktop, where your wallpaper is drawn.
If you configure conky to draw its own window, then it all depends on your window manager. The window manager is the one that controls the layering, and most of them let you raise and lower windows, I have no idea what the capabilities of metacity (the gnome WM) are these days.
Also, remember that a lot of people have had problem with conky when using gnome due to the way that nautilus manages the gnome desktop, that's gnome getting in the middle as always. So, if you have a concrete issue that only happens under gnome, you will need to find a workaround for that specific case.
Also, the fact that you run as usual or using '&' should be a non-issue in which regards the layering of the window. It's the wm who decides where a window will fit (maybe obeying the wishes of the window itself, but not necessarily). In this case you should use '&' probably the the same reason stated before: your script will not end until you close conky, which leaves a bash session on the background that's good for nothing but wasting memory. But other than that, it should have no ill effect.
Again, this is all outside fvwm. To use conky under fvwm all you need is what I described on my previous post.
PS: If you are using that script without '&' to start gnome, gnome will probably hang until you close that Window, becase the script will stop at that point preventing gnome from booting normally. Maybe that's what you meant. In this case, using '&' will also fix the issue.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.