ssTek

Still in planning stages, I thought I'd share what I have come up with in terms of a AIO ssApp.set file (this can be used for SetupS/ppApp/ppGame) they will be placed in the X:\ssApps or X:\ssGames folders (ppApps will be combined in with ssApps as there isn't a reason to separate them):



Pretty much all except the Title and Description is optional (But we'll get the Builder to do all the leg work, just made more sense to move the flags to each shortcut), Freeze let me know what you think or if you can spot other ideas. Remember we're not aiming for backwards compatibility with this design, this is as tho SetupS was never invented and we were really good at designing a Silent/Sorting app tool

Oh and the areas I haven't included, are gone - There isn't a reason to keep them with Catalogs and more complete Shortcuts Sections.

The main app title, catalog etc is for the ssWPI/Software Center - it is NOT used by the shortcuts unless no Defaultxxx = are given and not one for the shortcut item

---- A better way ----

If you can think of any way to make it look more grouped and less complex let me know how

Perhaps like this one instead?



By dropping LinkName = and using it as the header [here] - it separates them and makes you able to see it in a syntax highlighting.

This Method of putting all shortcuts information in one place, allows us to cleanup items we didn't install (like the post install cleanup feature, but after you install the Cleanup ssWPI item )

SetupS2 will NOT support stand alone inclusion in SFX, that will be left to the older SetupS to do (If anyone still used it for that).

Another Feature of Software Center would be the use the external database of apz pgz file names with it's title, arch, os, description, urls, etc etc (all the above information excluding scripts, reg, shortcuts and other actions (information only)). This allows us to include the DB, thrown the apz/pgz files in the ssApps and use SetupS or SetupS2 (depending on the source detected at the time of DB creation, or the post detected type of the included .set or .app in the temp folder).

The external DB generating of the installer will also allow the direct conversion of WPI config.js files, to the root of the Installer as X:\Installs\NameOfSFX.exe, this allows new Software Center users to take advantage of the Software Center with their Existing collections.

This will allow us to keep backwards compatibility but keep the technology separate. There is no reason we can not include SetupS.exe and SetupS2.exe to take advantage of.

Another idea that is affected by these technologies is making the Launcher Separate, scanning drives for ppGames But also scanning the Start Menu for ANY games you have in your Start Menu (any path or title with the word game in it's content/links). This should allow executing Non ppGames from the Launcher and still take advantage of the DB (Quick Load). Also Icons have been requested, should be possible to cache icons in the background as your using the Launcher and use the ones that are available for each game/category.
-------

These plans all knit together so we must consider each of them while designing the newer tech.

Seems pretty complete to me. I like the idea of incorporating the shortcut flags into the shortcut defs, also combining <OS> and <Architecture> into <System> using real text descriptors (instead of numbers). I had considered all the same things at one point on my stint with SetupS.

Just a couple suggestions, so far:

1. An <UnInstaller> section. Though I'm not sure how to implement it, you might want to leave room for it in the spec.

2. Avoid use of "[" or "]" characters. I had to learn that one the hard way. If I remember correctly, it was because <Registry> was already using them. Suggest "{...}" instead.

3. Keep shortcut paths relative to the <InstallPath>. Will look neater, IMO

4. Ditto with StartMenu paths. Keep them relative to the default one. For example, "LinkDefaultMenuPath=OpenOffice" and "LinkMenuPath=Tools", then startmenu final for that shortcut would be "OpenOffice\Tools"

I am wanting to take out as much logic from the methods and use brute data with this tech, I really don't want to rely on any previous sections of the ini files to allow easier generation and more speed processing the jobs. This will enable optional sections, easy addition to the db, less mistakes in logic processing and making it a lot simpler to code Just trying to take some of the guess work outta this one.

The case mode will be switched to Shortcuts, so the use of [ ] will be quite safe at that stage of processing.

I plan on getting all the jobs stored in arrays and flags to be executed in order after you load in the ini, by processing on the fly in SetupS 1 we introduced some issues in some cases.

Uninstaller I will add, I even know a way to take advantage of it

Keep the ideas and comments coming, we want to get this one perfect and as simple as possible.

Whatever we come up with, i will help with Help and Documentation

soporific16 wrote:Whatever we come up with, i will help with Help and Documentation

I could use a hand with the current SetupS-tek