Fluxbox 0.9.9
Forum: Other Help Topics
Topic: Fluxbox 0.9.9
started by: Patrick
Posted by Patrick on Sep. 20 2004,18:14
Hello guys,I just tried to install fluxbox 0.9.9 and after i ended x, started start_fluxdev, it all seemed to go right. I added fluxbox (home) to my filetool.lst but after a reboot all i got was the old version of fluxbox. I've got the lastest version of DSL on a usb-stick.
Anyone?
Posted by henk1955 on Sep. 20 2004,18:19
i think you should put it in the c:\ like you did with icewm.dslthen it autoloads
Posted by Patrick on Sep. 20 2004,18:21
I downloaded the -tar.gz file. I can't find a dsl-file of it (by the way, this fluxbox supports docking applications on workspaced)
Posted by henk1955 on Sep. 20 2004,18:36
it doesnt matter if the extension its a *.tar.gz or a *.dsl or a *.uci. put them in c:\the diference between *.tar.gz *.dsl *.uci is just a tecnical mater.
*.dsl are memory expensiv, *.tar.gz are cheaper, *.uci are the cheapest.
due to the way the are complied is it posible the person who makes the extension can select the best package method
Posted by ke4nt1 on Sep. 20 2004,20:36
What is " c:\ " ??If you lean your head to the right ,
it looks like a man with a goatee and a beret ..
Either format for extensions will load fine from the root of the CD ..
The DSL Live CD when first booted has 3 directories that are writable ..
Those are /home /opt and /tmp
The rest are read-only....but can be changed..
This change is what makes the writable filesystem grow, and begin to eat up valuable ramspace ..
The .dsl files actually do require the filespace to grow.
As henk stated, this is the space/place the author designed the program to run...
Many of the support files for some programs HAVE to be found in certain directories...
If a program REQUIRES one of it's executables to be in the /usr/bin directory,
a common directory for storing executables,
then the entire directory will be available as read/WRITE space in the ramspace you have in your box..
Read-only space requires no ramspace, just a scan to read data. ( like the DSL CD )
The "red" .dsl files OVERWRITE already existing DSL files.
The "yellow" .dsl files only ADD to the filesystem, but still make otherwise read-only areas writable.
The "green" .tar.gz files ONLY write to the /tmp /opt and /home dirs.
If you can get a program to be cooperative, either thru a command line prompt, or a wrapper,
to operate only in that space, then the filesystem remains unexpanded, and saves ramspace.
The extension .tar.gz is somewhat confusing to people who download sources, drivers, and other softwares
from other sites, who commonly use the .tar.gz for archiving.
The .tar.gz's at DSL are made for DSL, and other .tar.gz's will not work in the same way.
It is best to keep your extensions separate from your daily downloads..
The "blue" .uci files are a compressed loop format..
They "mount" like a cdrom or partition does ..
The advantages are great and it is very highly suggested you
use the .uci files when available..
There is no " loading " to speak of , like in .tar.gz or .dsl ..
It does not have to be untarred in its entirety, and written to
ramspace BEFORE executing.. For example ...
You download a 5 meg .dsl to your /home/dsl dir 5M
You click myDSL or run mydsl-load to untar it ..
It expands to 10 megs and writes to /usr/local/games
which has 10 megs of files already in it 10M + added ramspace for writable
Now the game , when executed, takes another 4 megs 4M
Total 20+ megs...
If it were a .tar.gz, there would not be any added ramspace
used up by making writable the directory of choice, since they
are already writable.. so it would only be the original 5M + the installed 10M + the executed 4M
Total 19 megs
Now, the .uci file is downloaded - same 5 megs as the .dsl or tar.gz
But it uncompresses on the fly, just like the DSL LiveCD does.. and it mounts like its OWN filesystem.. - so no " installing "
When executed, it uses the same 4 megs to run the app..
Total 9 megs...
This is not factually exact or accurate, but gives you the idea of the savings that can be had with ramspace
IF the program can be run inside only the writable areas of the filesystem..
73
ke4nt
Posted by Patrick on Sep. 21 2004,07:13
I HAVE put fluxbox-0.9.9.tar.gz in C: (/cdrom) and after a reboot i get a: script called: start_fluxdev in my home/dsl. (according to the manual i have to leave x and run the script) Then i automatically go back to x and i have a nice new fluxbox. BUT! After a reboot i still have the old fluxbox! (the script start_fluxdev is still present in my home/dsl)This is my filetools.lst:
opt/ppp
opt/bootlocal.sh
opt/powerdown.sh
home/dsl/filetool.lst
home/dsl/.fluxbox
home/dsl/.fluxbox/styles
home/dsl/.fluxbox/backgrounds
home/dsl/.xtdesktop
home/dsl/.xinitrc
home/dsl/.xserverrc
home/dsl/.dillo
home/dsl/.emelfm
home/dsl/.mplayer
home/dsl/.xine
home/dsl/.xmms
ramdisk/opt/fluxbox-0.9.9
etc/X11/fluxbox
home/dsl/.opera
opt/opera
home/dsl/.sylpheed
Maybey the mistake is in here?
Posted by henk1955 on Sep. 21 2004,07:17
i dont like fluxbox but i wil give it an other try.
Posted by henk1955 on Sep. 21 2004,09:13
this what i did:put flutbox.0.9.9.tar.gz in c:\
changed /home/dsl/.bash_profile to:
| Code Sample |
| #!/bin/bash export IRCNICK=DSL SSH=`env | grep SSH_CONNECTION` #if [ -z "$SSH" ]; then startx; fi start_fluxdev |
changed /home/dsl/.xinitrc to:
| Code Sample |
| # put X windows programs that you want started here. # Be sure to add at the end of each command the & grep enhance /proc/cmdline >/dev/null if [ $? == 0 ]; then enhance &>/dev/null & fi #dillo -f /usr/share/doc/damnsmall/getting_started.html &>/dev/null & #/opt/firefox/firefox & #icewm-session #wmaker fluxbox |
add /home/dsl/.bash_profile to the filetool.lst
and now the fluxbox-0.9.9. starts
Posted by Patrick on Sep. 21 2004,10:09
YES YES YES!!!!!Thanks man! It works!
Posted by henk1955 on Sep. 21 2004,10:26
i am happy for you.so now i can "uninstall" the flu T box from my system, and go back to my "speedy, simple, not getting in my way, clever windowplacement, intuative interface" windowmanager.
Posted by mikshaw on Sep. 21 2004,13:35
| Quote (henk1955 @ Sep. 21 2004,05:13) | ||||
| this what i did: put flutbox.0.9.9.tar.gz in c:\ changed /home/dsl/.bash_profile to:
changed /home/dsl/.xinitrc to:
add /home/dsl/.bash_profile to the filetool.lst and now the fluxbox-0.9.9. starts |
That works, but it's unnecessary to backup .xinitrc if you're using only flux-dev. It uses a copy of .xinitrc instead of the original. Simply changing the .bash_profile line to start_fluxdev is enough. This script is an alternative to startx, so that you can use it to start flux-dev, and fall back on startx for your regular window manager.
Posted by henk1955 on Sep. 21 2004,14:07
<edit>error in test procedure.
all below is BS
</edit>
a funny thing i found was:
even if there is an: export XINITRC=$HOME/....
and xinit man says:
XINITRC This variable specifies an init file containing shell
commands to start up the initial windows. By default,
.xinitrc in the home directory will be used.
it seems xinit first runs ~/.xinitrc and than $XINITRC
so if you have an ~/xinitrc make sure it doesnt point to an old windowmanager you dont want to use
Posted by mikshaw on Sep. 21 2004,14:30
This might seem to be the case, but it is not. $XINITRC tells xinit which configuration file to use. If that variable is not set, it looks for $HOME/.xinitrc.Startx apparently ignores $XINITRC, but I haven't verified this.
"by default" means that if there are no available alternatives, it falls back on .xinitrc...it doesn't mean that it uses .xinitrc always.
My $HOME/.xinitrc is not used whenever I load flux-dev or evilwm