Is OnDemand popup menu option necessary in parallel to Applications option?

[frimical]

To simplify things, I think that onDemand apps can be listed directly in the Applications option in the popUp menu.
The behavior is hidden to the user: the app is here, either already installed or not it doesn't matter for him, what matters for him is that it's 'runnable' from the same place in the menu. 

regards 

[roberts]

Ah but it is necessary as an extension could have a multiple menu structure (not isomorphic to the extension name) which could not be known until actual loading of said extension.

[frimical]

Oh, I couldn't see it from that angle. thank you for the explanation.

(Actually I nearly never used it , eventhough I always thought that an OnDemand possibility is useful, kind of light install, but I kept fresh installing! a convenient habit probably ).

[roberts]

Perhaps with 4.0 the extension definition could be changed to support an even more modular approach. If .desktop items were separate then I could achieve a single Applications menu and, in fact, all extensions would be ondemand. Imagine how fast to boot and would make for a more simple system. It is something that I am toying with.

[gerald_clark]

What about extensions that have startup scripts called from bootlocal.sh?
They still need to be OnBoot, and not OnDemand.

[roberts]

I would consider only those extensions that have a .desktop item.
This typically would indicate an application since there exists a menu item and/or icon.
Still too early to assess the feasibility. I would like easier access to knowing when an extension represents a menu/icon driven application rather than daemons/libraries. But just a back burner item for now.

[hiro]

Perhaps with 4.0 the extension definition could be changed to support an even more modular approach. If .desktop items were separate then I could achieve a single Applications menu and, in fact, all extensions would be ondemand. Imagine how fast to boot and would make for a more simple system. It is something that I am toying with.

I've been thinking about this too. I'll just write down my ideas here:

Current ondemand is inconsistent, onboot.lst has a completely different structure.

Thus I propose these changes:
1. The tool ondemand is a shell script containing "tce-load -i $0".
2. For every extension there is a symlink pointing to the ondemand script. They all lie in a directory at the end of PATH.
3. In order to create the symlinks we can use e.g. ondemand.lst with the same whitelist/blacklist approach we already know from onboot.lst and copy2fs.lst.
4. Ondemand currently doesn't work well with copy2fs. So we put the ondemand tool and symlink dir somewhere in the root file system.


To complicate things further the script might also be able to find the right extension name for symlinks created from .desktop items.
And instead of .desktop files we could also use other means to find the extensions even of arbitrary executables: extension.lst files, provides.sh, user files.
One might even have one global ondemand.lst including all executables from every extension.

We may eventually want to maintain a buffer for mapping executables to extensions efficiently, but that should not be visible to the user!

[hiro]

See also:
http://forum.tinycorelinux.net/index.php?topic=6097.0