restore doesn't remember all wbar settings

[gwalther]

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

[gwalther]

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

[trinity]

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

[coreplayer2]

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?

[curaga]

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 - grab an existing file from your system as a reference.

[roberts]

@coreplayer2, what you posted is a very old post, pre-freedesktop standard adoption and is no longer supported.

[coreplayer2]

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...

[curaga]

By load order, which is determined by your onboot.lst/ondemand.lst for the automatically loaded ones.

[coreplayer2]

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.

[coreplayer2]

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 

[roberts]

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.

[coreplayer2]

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. 

[roberts]

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.

[coreplayer2]

Thanks, I was thinking reading the scrips would probably be the best way to understand the process.

[coreplayer2]

 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!!