c0de, that applies more to the ssApps, as sometimes we have one that installs to 'no directory' as it were. Then, if you don't indicate %ProgramFiles%\Nonething (which is one way of doing it) it will dump the SetupS auxiliary files (images, etc.) in the root of Program Files. I think RON forgot about that part, because we talked about it before several times, and the way I understood it is in order to give SetupS the power to write to any location we want, that also comes with a certain price -- namely that it will exactly do as you ask So the only thing we need to be aware of is what we're asking SetupS to do. I just corrected the MS Games Live Redistr ssApp as I noticed the aux files in the Program Files root, and sure enough, I did not supply %ProgramFiles%\Nonething in the <AppPath>, but instead had only %ProgramFiles% there. Thanks Freezer for your elaboration on the difference between the apps, it's almost philosophical! But that does help to put another perspective on it, especially the %SourcePath% vs %AppPath% stuff, that makes a lot of sense. As always: "saved"
Yes, take for example the ssApp "Kel's Runtimes". All it really does is register runtimes, it doesn't install to any Program Files location. So with an app like that you wouldn't enter any %ProgramFiles% location; but if you leave it open like that, SetupS will dump the images and .app file straight into Program Files root. We asked Freezer to allow this (he had it catch that originally) so that we'd have the freedom to install apps in unconventional ways. But that Nonething flag does not apply to regular ppApps like the one you tried it on.
yea but what if a user wants the folder to be changed , no biggie for me but just thinkin ahead for other who might want that changed
Hint: Don't use that flag for ppApps. It renders it invisible to all the ssTek tools. In fact, I can't think of a single reason why ppApps should even be using that flag. So perhaps going forward (in a future revision) SetupS should simply ignore that flag -- or ssEditor should not allow it to be added to the .app-file -- for ppApps
Me, I'm still trying to ponder why this is so. The installers are only at the %SourcePath% (ditto with the Patch folders/archives) so SetupS would simply ignore them anyway (because it can't find them at the %AppPath%). And it is already processing the sequence via the #Directives#.... So why can't we enable everything in <Assembly> ... ?!?
The why is probably a really small why, but it will probably knock all of RON's ppGames out of the water But I can't find any reason why, but that doesn't mean as much as when you can't find one...
What I don't like about the nonething flag is that since ssWPI does not know about the app, it will still show up in the list of apps to install even when you check the "Hide Installed" checkbox. When I first started using ssWPI I thought there was a bug until I noticed that they all use the nonething flag. I have not had the time to figure out what mechanism you use to determine if the app is installed already, but I imagine its just checking %AppPath%. Is it possible to use/make a directive to tell SetupS where (or what) to check to see if the app that uses nonething can check to see if its installed?
ssWPI's abilities to check if an app is installed are very limited. And of course it only bothers to check IF you have "Hide Installed" checked, otherwise why take the time to check if you're not going to use the information provided? And it only displays what it found if "Hide Installed" is NOT checked since otherwise you are hiding it. LOL If you care at all about previously installed apps, then check "Hide Installed". It can only check for an app if it has an installed location, and it ignores install paths %programfiles% and %programfiles%\nonething, so it can't check for things like "Kel's Runtimes". It assumes it is not installed. To ssWPI it is "Not Found", so ssWPI does not hide it. If nothing is in the install location, it assumes it is not installed. It does not check ANY other location than the install location, even though you might have 14 other versions of the app installed in other locations. (As sometimes happens with utilities like 7Zip and other things that are sometimes included as part of other apps.) To ssWPI it is "Not Found" so ssWPI does not hide it. If ANYTHING is in the install location, ssWPI will assume the app is installed, so ssWPI will hide it, since "Hide Installed" is checked. Now that ssWPI has checked for installed versions, you can uncheck "Hide Installed" to get a better idea on what ssWPI actually found. It can only check for version number if it was an ssApp/ppApp app because the <version> field of the .app file is what is checked for the version number. ppGames are not checked for version number. If a version number was found it will be displayed. This number will be whatever is in the <version> field of the .app file of the installed app no matter what it is - lower, higher, the same, right, wrong, total garbage - ssWPI does not try to evaluate it and compare it to the version of the app you have available to install. It's just a string of characters to ssWPI. If an .app file is found in the install path but no <version> field is in the .app file, then to ssWPI it is "Not Specified". If ANYTHING is found in the install location, but an .app file is NOT found, or it is a ppGame, then to ssWPI it is "Unknown". Essentially, ssWPI takes the approach that the install location is the only proper place for the app to have been installed, and if any version of the app has previously been installed it should be uninstalled before you proceed, but that exercise is left as an exercise for the user. ssWPI is really not very smart. Of course if you do not check "Hide Installed" then you can go ahead and select the app and ssWPI will tell SetupS to install the app. Freezer would have to comment whether SetupS cares if anything is already in the install location, but I don't think SetupS does. But the app's install routine might. I hope this explains things as to ssWPI's abilities.
Well... 1) it's not an uninstaller app 2) a good number of the apps we'd use Nonething on would not show up in an uninstaller app either.
Lots of good answers here... but I'm surprised BP didn't mention his pet idea of a central db/ini for ssTek. Regardless, that was the whole point of having the Nonething flag, wasn't it? If it did leave some sort of trace behind (short of the central db idea) then we'd be back to the original problem. The thing is -- and I hate to be a nag -- if the "overlays" and their associated .app-files were in fact constructed properly (and by that I mean SetupS-friendly) then there would be no need for such devices as "Safe Install" or the Nonething flag. Even ssWPI's "Hide Install" would work as it should. /mode(sermon)=off
Hmm, I'm finding a couple of bugs in SetupS Editor. At one point it totally screwed up the ssApp.app file, but I have not been able to reproduce it. There are two minor bugs that I can reproduce: 1) On the Shortcuts tab, if I click the "..." button for Default Menu and browse to a Start Menu folder that is 2 deep, it will only use the deepest folder. Example: I selected "Start Menu\Programs\Blender Foundation\Blender" folder and it only selected "Blender". The only problem with this is that it leaves the folder "Start Menu\Programs\Blender Foundation\Blender" will all of its icons. Workaround#1: It works if I select the "Blender Foundation" folder instead, but I'm not sure what the results would be if I also had a "Blender Foundation\{OTHER_PROGRAM}" folder. Workaround#2: Everything works if I edit the <StartMenuSourcePath> section of ssApp.app to "Blender Foundation\Blender". Can the code be changed to select everything after "Start Menu\Programs\" and then it will work betterer. 2) On the Shortcuts tab, if you change the Menu Catalog (delete current one and add another from the dropdown list), then the new one gets appended to the <StartMenuDestPath> section of ssApp.app file. Example: Changing it from "Graphics 3D" to "Game", shows only "Game" in the "Advanced Menu Destinations Catalog List", but this is in the ssApp.app file: Code: <Catalog> Game <StartMenuDestPath> 6 Graphics\6 CAD & Advanced Design|5 Games - Graphics\- 3D, Generating & Morph|- Games I have not tried installing with it like this, but I'm fairly sure this would create shortcuts in both locations. Maybe I'll try re-installing LastOS, but I've rebooted the VM several times, Reverting to Snapshot before this app got installed. Oh, this is even worse... I did not install SetupS since it gets installed with ssWPI, so now I just tried to install SetupS from "00OverlayISO_All\ssAppsInstalls\!!!SetupS.SendTo.Extension_ssApp\ssApp.app" and it just uninstalled SetupS without re-installing it. Now even SetupS.SendTo.Suite_v8.11.7.11_ssApp.exe does not install it. Hmm, I just reverted my VM back to snapshot again and it didn't work again. I'll re-install fresh and see if that helps. Can anyone else reproduce any of this? BTW, I had selected ssWPI to install from LivePE.
Yes, that's what I do. I'm not sure (because I don't use the SetupS Editor myself) but I think it may me made that way so you can easily 'add' start menu locations to <StartMenuDestPath>. Catalog is what is consulted first, so even if you leave out certain <StartMenuDestPath> entries but have the respective Catalog entries there (in the case where you would manually edit the .app file), then the Catalog entries will create those shortcut locations for you anyway. But as to the total picture of the back and forth between Catalog and StartMenuDestPath I am not completely sure.
ssEditor is the weakest member of the group. But both "bugs" are rather harmless and we can make a case for #1 that we are trying to get a more efficient StartMenu even if you decide not to use an advanced one. ssEditor will also allow editing directly in the default menu input box as well. So you could actually make it anything you wanted. The browse button merely gives you a leg up on that instead of typing it in And it's true what Trouba said about #2: the presence of <Catalog> supersedes <StartMenuDestPath>. But, you are right, it's definitely untidy having the extra entries like that.
Yeah, I was worried that it would put the icons at both <StartMenuDestPath> folders, but I just tested it and it doesn't. What does <StartMenuDestPath> get used for? Oh, nevermind, you are right that it is much more harmless than I at first thought it was. Hmm, "more harmless" doesn't sound right, maybe "less harmful" sounds better. Oh god, I didn't get much sleep last night and it is showing.
Maybe the words you were looking for were, "mostly harmless"... or how about, "mostly annoying"? Anyway, as I said, ssEditor isn't perfect. For example, peeps are building packages outside its scope but well within SetupS's -- more the exception than the rule -- which is one of the reasons the name was changed from ssBuilder to ssEditor. <StartMenuDestPath> was the old (or legacy) method of advanced startmenu placement. And it is still supported by SetupS to maintain some backward compatibility with old versions. Note, that the "|" character would have never actually appeared with the old versions but IF it were to encounter something like that then it would support it. So mostly now it is used as a handy reference to those viewing the .app-file as a text file (F4 from ssEditor, FYI) to see where the shortcuts are going to end up. Other than that, it serves no other function -- at least to me it doesn't. Regardless, I do find it irksome that ssEditor leaves those unwanted entries in <StartMenuDestPath> -- so expect a revision sometime in the future (such as when we are updating the help files, for example).
Absolutely. I for one have no intention (and I hope RON doesn't either) of removing <StartMenuDestPath> because as nice and convenient -- and forward thinking -- that <Catalog> is... it just has the unfortunate (and unintended consequence) of revealing no useful information on where to ultimately find the damn shortcuts-- doh! LOL
OMG, I didn't realize I was opening such a big can of worms... I'm new to this and didn't know if it was a new bug or anything. And, yeah, I wasn't planning on holding my breath, but I can imagine what a big undertaking it would be to update the help files with all the changes I've seen in the short period of time that I've been around here. I give you guys a lot of credit for doing as much as you have already.
Cans of worms is what we're all about! I wouldn't worry about it, Freezer is smart enough to have deflected your comments if he didn't want to work on it
... or silly enough to obsess over a slight flaw Because now I'm thinking of adding an indicator to ssEditor of the startmenu location (like we've got for "Install-to path" and the "Default Menu")
This reminds me of a clip I saw this morning.... "because it's there..." http://www.youtube.com/watch?v=HU2ftCitvyQ (just wanted an excuse to post this, lol)
