First, I would like to start with, on the technical side of this feature request tinypoodle, you appear to fully comprehend exactly what I am asking for and its implications for developers. However at no point in anything I offered was direction about how to implement this suggestion or intended for instruction to achieve what I desire, merely a working example that creates what I think would increase the user friendliness of TinyCore.
This entire thread was simply the request that a mechanic be instituted to allow wbar to see designated ondemand programs and display them.
I respectfully disagree, it would not require always being loaded to create this effect.
You seem to disagree with what i never said. Please read again what I did say.
I am not going to quibble over "English grammar and syntax, direct vs. indirect references". I am here for either of suggesting possible user friendliness or my technical education, the former for this post. This is a technology forum and I am not an English grammar and syntax instructor.
I have been loading the ondemand apps and copying the logo "/tmp/tcloop/[appname]/usr/local/share/pixmap"
This differs from your first post where the path gave an impression of some virtual filesystem (sometimes used by apps) which would display the content of an archive or a compressed filesystem.
I assume your mentioning of a virtual filesystem is refering to "[appname].tcz/usr/local/share/pixmap" and "/tmp/tcloop/[appname]/usr/local/share/pixmap". Well, simply put, yes, these are a virtual filesystems. Linux kernel accesses filesystems through common VFS to use TinyCore's default EXT4 partition and the TCZs, being in squashFS. "
http://commons.apache.org/proper/commons-vfs/". Linux kernel by default runs all file access through VFS. "
http://www.tldp.org/LDP/lki/lki-3.html"
to "/etc/sysconfig/tcedir/ondemand", then making sure it is porperly named. When TC first loads it pulls this and displays them, *without* loading the package.
Sure you can do that, but to copy a file out of squashfs extension, a prior loop mount is required (or unsquashfs) and results in file duplication.
Yes, I agree that how I currently handle it, and how I worded my suggestion, does create file duplication and a tedious mount/unmount scenario. My attempt was to explain my request in a detailed enough manner that anyone who was a source maintainer could implement this in a manner they see fit without concerns for a special case scenario. I know that here I have not earned, and may never, nor seek, special case handling in any development of this project. I merely suggested a concept that would increase user friendliness of TinyCore in a manner that leaves how to achieve such as open as possible to its developers with out having to cater to me.
Wbar pulls from the ondemand folder for apps to display; the requirement being a script that loads the program and a JPEG file with the same name + ".img" and it pulls right up on wbar. Doing this does not make the program always loaded, but does put the program on wbar.
Guessing you refer to a specific usage case with mount mode plus PPR.
If PPR refers to Persistance that is loaded at boot and then saved on a proper shutdown, yes, I am relying on default persistence settings, for now. Until I learn of a better way to handle this.
As far as a specific usage scenario goes, mine is two purposed. First, a simple system at home on an old desktop to allow anyone who comes over and wants to check their email, or some other mundane reason, can use a computer that is not mine, I am not fond of sharing mine, no matter what or how much security I have. Second evaluating the use of it as a kiosk in a business strategy at my work before we actually get rid of several dozen old computers. If the strategy does not have a 15 minute or less training requirement it just won't be worth it. So teaching people to access ondemand programs that are our least likely used programs, less than once a day, does not seem worth loading at boot. I bust my --- to create an enviroment where the learning curve for "in-house desktops" is at or as close to zero, leaving responsibility for education and use of our Java apps to the Training Department. Not exactly sure how either of these use scenarios help in describing my feature request.