Ok.
Just could not remember me having such fun in Windows like I do in Puppy.
Maybe I should reboot it?
mikeb wrote:So are you basically making an sfs handler that appears to the user as a more standard package manager which can access software online or locally with dependancy checking as would be expected..... is that a rough description?
I'm not sure, if I do understand you the right way.
- making an sfs handler
Yeah, basically it is an SFS handler - somehow.
But I do see it more in way like a SFS development kit.
It can be used by users just for the use of local SFS Modules - private use/development somehow.
But it can also be used as a complete development kit by developers of Operating Systems to provide a still small OS with lots of additional applications coming as SFS Modules.
Though, SFS Modules have their limitations, but I'm sure -of course- it's the much smarter way to provide additional applications for an OS. Once a SFS Module is build for the OS there is no future hassle like is so much when installing .pet files.
Since the SFS P.L.U.S. can handle conflicting SFS Modules one can use applications that never will work, when installing them. The SFS Modules converted to SFS P.L.U.S. Format doesn't have only option to load dependent SFS Modules automatically. They can also unload conflicting SFS Modules (when loaded) before loading the wanted SFS Module.
The RunScripts -as you have seen- can be provided built in to the OS and also as Standalone RunScript RoxApp Directory.
So, the user could test additional applications by providing those Standalone RunScript RoxApp Directory. From those SFS Modules, the user wants to use and to keep them, the user can create easily RunScripts in batch mode to be included into the OS - then just do a remaster.
Hundreds of Megabytes of Software added by some KB scripts added to the OS.
Usable out of the box, without a save file etc.pp. usw.usf. ... ... ...
- appears to the user as a more standard package manager which can access software online or locally with dependancy checking as would be expected
No, not really a package manager - as it would be meant by the Puppy Package Manager.
Yes, it can and is supposed to access software online and/or locally.
Dependency checking not like the dependency check for installed packages. If there are dependent SFS Modules needed for its main SFS Module, these dependent SFS Modules has to be defined manually when creating the main SFS Module (eg. JWildFire and Java). Such defined dependent SFS Modules are checked, searched, downloaded and loaded automatically.
So, no hassle for a user to search for a needed Java, Python or what ever.
Such dependent SFS Module -of course- can include just some libraries or what ever is needed to run the application and should not appear in the main SFS Module or in the OS. The developer is completely free to set this up as he/she wants - even to put the Java into the JWildFire SFS Module.
I do prefer to create dependent SFS Modules to be loaded automatically, because several SFS Modules might need equal dependent SFS Modules - like Java.
Most of my Java applications have Java 1.7update13 defined as the dependent SFS Module, which is then loaded just once.
---
This
SFS P.L.U.S. SFS Development Kit will be provided like RSHs ScriptBox was offered here for some testings: as a RoxApp Application Directory that will prepare the current used OS for the use of this
SFS P.L.U.S. SFS Development Kit just by a single click onto the RoxApp Application Directory.