Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: trinity on November 09, 2009, 02:02:12 PM
-
New to TC and have just downloaded TC v2.5 today.
Not all the apps I have installed made an entry in wbar (eg transmission.tcz) so I added the appropriate icon,title, cmd lines to /usr/local/tce.wbar
After right-clicking in the wbar it loaded the transmission icon and I could launch the app with it. Great.
My grub stanza has the lines:
title Tiny Core 25
root=(hd1,7)
linux /boot/bzImage tce=hdb8 restore=hdb8 home=hdb8
initrd /boot/tinycore.gz
However after a reboot the transmission icon does not show and I need to do a manual restore from the Control Panel.
Questions:
1. how can I set this up so that my system restores all the wbar info after a reboot?
2. is it common that apps don't automatically install into the tce.wbar file?
Thank you
-
Only items with /usr/local/share/tce.icons entries end up on wbar.
To make my own permanent entries, I edited dot.wbar (don't recall right now where that is) and added this file to my filelist for backup and restore. dot.wbar contains the default starting list for wbar (terminal, cpanel and appbrowser).
I found wbar very hard to master because the various files are scattered all over the file system.
-
Hi jur,
You say "Only items with /usr/local/share/tce.icons end up on wbar" but that can't be right as from what I said above I have had success with items in wbar added manually to /usr/local/tce.wbar It is where the bulk of all wbar itmes are located. By the way I did add "usr/local/tce.wbar" to the file /opt/.filetool.lst for restore.
(Also there isn't a /usr/local/share/tce.icons file in my version. I guess you meant /usr/local/tce.icons)
Perhaps you are saying that only those items in tce.icons can be restored?? In which case what I've read about restore before is wrong?
I do agree that wbar is not the easiest app to master and tweaking it does seem to vary between distros.
Anyone any ideas how I can get this working.
Thanks
-
/usr/local/tce.wbar gets written afresh at each boot and gets appended to at each adding of new app (this is my own guess of what is happening). So it doesn't work to mod that file (I know because my first attempts were also at editing and backing up that file). Editing dot.wbar worked.
If you can follow scripting language (i can't, yet :P ) you can take a peek at tce-load, desktop.sh and wbar.sh.
To see more options for wbar, type wbar -h. Made all the difference for me once I knew the options.
I am guessing the boot order is something like
load apps -> restore files -> generate tce.wbar -> load wbar.
So the restored tce.wbar gets overwritten.
I meant earlier that only items with tce.icons entries in their extension folders end up on wbar. You can see this by looking at an example extension's /tmp/tcloop/ stuff and you'll see the tce.icons folder there. Once an extension is mounted, the folders are merged and a new tce.wbar file generated from the merged tce.icons folder.
Disclaimer: All of this is spoken in much ignorance. I am a noob of just a few months.
-
Here is how I did it:...(works best after all the extensions you think you want
are installed/mounted)
copy ....tce.wbar... from .../usr/local/...to /home/tc/
edit the copied tce.wbar in .../home/tc/....changing or adding what you want, then
edit .... /usr/bin/wbar.sh.....in the second last line that begins with... wbar ...
change the pointer to the config file....from .../usr/local/tce.wbar...to (the new one
you edited)..../home/tc/tce.wbar...save file and .try out your changes by restarting wbar
finally ..add.... /usr/bin/wbar.sh ...to your backup .../opt/.filetool.lst
(this assumes you already backup /home/tc/...if not add .. /home/tc/tce.wbar...to backup
the drawback of this method is that if you install/mount a new extension ....the icon for the new extension ( if there is one) will not show up until you ...recopy tce.wbar from /usr/local/
to /home/tc/ ...and edit it once again
-
the drawback of this method is that if you install/mount a new extension ....the icon for the new extension ( if there is one) will not show up until you ...recopy tce.wbar from /usr/local/
to /home/tc/ ...and edit it once again
Yep, which is why I prefer my method of editing dot.wbar - completely transparent to additional extension installations.
-
jur and jwalter,
Thank you both for your helpful and informative posts.
I now have wbar set up to restore a full set of apps after every reboot.
I chose the jur method as I don't want to have to tweak anything each time I add a new extension.
However it doesn't allow me to position every icon where I want them as the ones in dot.wbar must preceed the others in tce.wbar But it's much better than nothing. :)
(by the way dot.wbar is at /usr/share/wbar/dot.wbar)
I guess the ideal solution would be to add files to the /usr/local/tce.icons folder. I'll give that a try.
Now ...if only I could find a search app then I'd be able to find my way around here.
Thanks for your help guys.
-
... it doesn't allow me to position every icon where I want them as the ones in dot.wbar must preceed the others in tce.wbar ...
That's right, and the ones following are arranged alphabetically, at least if they are loaded at boot time or something. So one has very little control over where things end up.
-
I guess the ideal solution would be to add files to the /usr/local/tce.icons folder. I'll give that a try.
Well I tried that but after a reboot my added entry was lost so I guess it's a similar story that restore points get wiped out when the wbar/menu is re-generated.
So one has very little control over where things end up.
In fact almost none. I just remembered that in crunchbang linux I made my wbar by home/user_name/.wbar and I could arrange the order anyway I wished. May try that later.
To be honest I'm a bit surprised it's designed this way. It wouldn't matter if all extensions were made to have a tce-icon entry but several don't seem to be.
eg transmission, asunder, gqview2, Xpdf....
Oh well.
Thanks for the help.
-
How about this (not tested):
Create an icon directory - mkdir /home/tc/my.icons
Copy the icons to your directory
Create a file - my.wbar and add it to home/tc
Format:
i: /usr/local/tce.icons/app_name.png
t: App_name
c: exec /usr/local/bin/app_name
Create a script and add it to bootlocal.sh
#!/bin/sh
cp "/home/tc/my.icons/*" /usr/local/tce.icons
cat /home/tc/my.wbar >> /usr/local/tce.wbar
wbar.sh
Caveat: running this after boot will result in duplicate icons.
-
combo3:
Thanks for your helpful sugestion.
I tried it but it neither resulted in duplicate icons nor did it add an icon I prepared your way. I may be wrong but I don't see how it would fix the issue of not being able to sort the icons the way I want to.
Thanks anyway.
Surely as wbar is "standard" with TC I can't be the first person to want to do this?? Surprised it doesn't work OOTB.
-
See my method above
You can edit order...change exec command..(ie..sudo emelfm...rather then emelfm)...or add your own icons
If and when you mount/install new app just manually add it to /home/tc/tce.wbar
and restart wbar
-
wbar does not remember icons because Tiny Core's default mode is to run with applications extensions that are dynamically loaded upon boot.
It is up to the extension maker to decide whether an application is of general use to include an icon or not. Since wbar is limited in size, it is prudent to make this decision wisely.
If icons are your thing, then perhaps using rox-filer or xfce which give up more icon choices.
But adding an icon to an exiting icon-less application extension is easy.
1. You need to grab the squashfs-tools extension.
2. unsquashfs -d appname appname.tcz
3. now relative to the appname directory make the directory structure:
cd appname/
mkdir -p usr/local/tce.icons/
chown root.staff usr/local/tce.icons
chmod g+w usr/local/tce.icons
4. Next using a text editor, edit/create the file to specify the wbar icon specifics, e.g.
usr/local/tce.icons/appname
enter the three lines as required by wbar:
i: /usr/local/tce.icons/appname.png
t: appname
c: appname
5. next remove the old extension.
cd ..
rm appname.tcz
6. mksquashfs appname/ appname.tcz
7. copy your new extension to your tce directory.
Of course, you can choose to ignore this, and hack your system, mixing static and dynamic content. But be aware, should you decide to remove an application your hacked icons will persist unless also hacked away too.
Edited to correct unsquashfs statement above.
-
Tried your procedure ...but got stuck
line 2...assume you meant unsquashfs...not unsquash
with unsquashfs ...got this message
can't find a squashfs superblock on emelfm.tcz
do I have an old version perhaps of emelfm.tcz??
-
@gwalther:
You could try the command file emelfm.tcz to get "a second opinion" about the file type (which requires file.tczl).
I'm getting as result
emelfm.tcz: setgid Squashfs filesystem, little endian, version 4.0, 22694143 bytes, 25 inodes, blocksize: 0 bytes, created: Tue Sep 22 20:11:44 1970
Ignoring for now the obviously wrong information about size and date, it at least gives you a chance to find out more about your emelfm.tcz.
BTW, the timestamp of this file on my local mirror is: 2009-10-26 08:28:09 UTC
-
Got a very different result using......file...
"Linux Compressed ROM file system data, little endian size 110592 version 2 ....".(more but no date)
my emeflm is working fine...guess I'll try to redownload it!
Thanks for the reply
-
Ok all is well now...downloaded new version of emelfm.tcz and it unsquashfs
made the changes and mksquashfs...ok
Can now return to dynamic wbar
Thanks to roberts for procedure...learning something every day with TC
-
roberts
Thank you for taking the time to explain the philosophy and mechanism behind this.
........It is up to the extension maker to decide whether an application is of general use to include an icon or not. Since wbar is limited in size, it is prudent to make this decision wisely
I understand. And I guess my opinion of what should have an icon and what shouldn't is just that; my opinion. It's the devs call. Fair enough.
..............Of course, you can choose to ignore this, and hack your system, mixing static and dynamic content...........
No, it was not wanting to have a mixed and/or hacked system that led to my orig post.
All is now clear.
Thanks again
-
wbar does not remember icons because Tiny Core's default mode is to run with applications extensions that are dynamically loaded upon boot.
It is up to the extension maker to decide whether an application is of general use to include an icon or not. Since wbar is limited in size, it is prudent to make this decision wisely.
If icons are your thing, then perhaps using rox-filer or xfce which give up more icon choices.
But adding an icon to an exiting icon-less application extension is easy.
1. You need to grab the squashfs-tools extension.
2. unsquashfs -d appname appname.tcz
3. now relative to the appname directory make the directory structure:
cd appname/
mkdir -p usr/local/tce.icons/
chown root.staff usr/local/tce.icons
chmod g+w usr/local/tce.icons
4. Next using a text editor, edit/create the file to specify the wbar icon specifics, e.g.
usr/local/tce.icons/appname
enter the three lines as required by wbar:
i: /usr/local/tce.icons/appname.png
t: appname
c: appname
5. next remove the old extension.
cd ..
rm appname.tcz
6. mksquashfs appname/ appname.tcz
7. copy your new extension to your tce directory.
Of course, you can choose to ignore this, and hack your system, mixing static and dynamic content. But be aware, should you decide to remove an application your hacked icons will persist unless also hacked away too.
Edited to correct unsquashfs statement above.
Was wondering why I can't seem to make this work for me so, Is this method valid anymore?
-
Nowadays we use the usual freedesktop files, the wiki may be able to help.
edit: The wiki just says where to put them, http://wiki.tinycorelinux.net/wiki:iconmenuinfo (http://wiki.tinycorelinux.net/wiki:iconmenuinfo) - grab an existing file from your system as a reference.
-
@coreplayer2, what you posted is a very old post, pre-freedesktop standard adoption and is no longer supported.
-
Thanks sometimes we have to dig far for answers, had figured the method was no longer valid and explains why I can't make an icon from a dynamically loaded extension appear in the same location alongside statically loaded system apps.
I'm curious though, to know the criteria which wbar uses to arrange/order user installed extensions and their icons on the bar. I suspect dynamically loaded using the app name from the desktop entry file, I don't think it's by category, but I could be wrong...
-
By load order, which is determined by your onboot.lst/ondemand.lst for the automatically loaded ones.
-
Thanks, was not expecting that answer. I was totally wrong! nothing to do with the freedesktop desktop entry file or it's contents, got it. thanks.
-
H'mmm the plot thickens, Shuffling the order of items in the "onboot.lst" made no change on the order of apps on the, thought those extensions were loaded by alphabetical order anyhow?? ABC...xyz etc
-
While it is true that onboot.lst controls the order of extension loading, it is not involved with wbar setup. With existing extensions is by alphabetic by name. When adding new extensions either onboot or ondemand extensions added tacked on to the end. Upon reboot will order by name.
-
Thanks Roberts, that surely is a clue.
to find out for myself I tried a few experiments, it seems changing the names of four extensions, listing them as A, B, C, D, or aa, ab, ac, ad, made no difference to the order or grouping of the apps displayed on the wbar. modifying the onboot list had no effect as Roberts stated, is definitely not related to wbar listing. uninstalled all extension between renaming and rebooted also,
the order of the apps listed on the wbar are currently locked in order since I last changed their names within the desktop entry file, so either the actual *.desktop file name or an entry within it holds the key I think. will have to revisit the desktop entry file I think, am not giving up though. :-\
-
I check if you have requested icons in startx. If so, I call a generic $ICONS_setup.sh
which in your case is wbar_setup.sh in fact if you are so inclined you may wish to read all the wbar interface scripts that provide wbar's dyanmic nature in Core.
-
Thanks, I was thinking reading the scrips would probably be the best way to understand the process.
-
Reading the scripts reveals all, Let's see if I got this right, at least in terms of my specific issues.
Static wbar system apps/icons can be restriced via the xwbar.lst file, normally located in the tce directory, in my case /mnt/sda1/tce/xwbar.lst this location can change aparently depending on the type of install. After a remastered ISO the controlling file was found /tmp/tce/xwbar.lst
Dynamic wbar apps/icons are placed in alphabetical order derived soley from the name of the xxx.desktop file
Sky's the limit now!!