Archive: What features/improvements do we want?
I suddenly have a lot more time on my hands, and will be doing some heavy development based on NSIS 1.43.
What features do you guys want to see in an installer? Any changes or new commands you want? Tell me and I'll see what I can do about it.
And of course I'll send all my changes to justin to see if he wants to stick them in the 1.5 series :)
I'd like to see CopyFiles flag the IfErrors error flag instead of barfing if the source file doesn't exist.
Thanks a lot!
David
ddyne, see your other thread! :)
http://forums.winamp.com/showthread.php?threadid=51540
Plugins
I mentioned this in http://forums.winamp.com/showthread.php?threadid=51275 , but I'l CP it here for consistancy.
CALLDLL plugin.dll C_FUNCTION_NAME (PARAMETERS)
Small SDK, and plugin writers can roll up specialized plugins, without necessarily bloat up NSIS. Maybe two NSIS forks might be needed. Plugged-In and Unplugged
-=Gonzotek=-
CopyFiles behavior has been fixed. Changes submitted to Justin.
As for plugins, two new commands:
CustomPreSelect "localfile.dll"
CustomPreCopy "localfile.dll"
These insert a custom splash screen. PreSelect goes before the components screen; PreCopy goes right before the actual file-copying screen.
This 'bloats' the header by an astonishing 0 bytes. I'm proud of myself. A mini-SDK for the plugin DLLs coming within a few days, hopefully. Requires working knowledge of C or C++, sorry :(
Requires working knowledge of C or C++, sorryI figured that would be a requirement. Seems I have semi-sucessfully argued to get a feature implemented that I can't possibly make direct use of :).
Hi,
My top ones are (all relatively simple):
1. A simple fix to the listbox to give it a horizontal scroller so the contents can actually be read!
2. At LEAST a $Comspec variable but I'd rather see generic access to environment variables.
3. Built in $ variables for all users related stuff.
4. Ability to specify "Comment" (affectively the tooltip) on shortcuts.
5. Named parameters for commands, this could be made backwards compatible with existing useage, see a previous post.
That will do for now...
Thanks
Dennis
The first two (horizontal scroll, $ENV('blah') special variable) are no problem.
The third one I don't understand ...
The forth (shortcut comment field) I have to check on, the shortcut field might not be exported via SHCreateShellLink or whatever the hell its called.
Named parameters are going to be a real pain in the ass - I may have to overhaul the parser, which will not be fun. This is dead last on my list of priorities because of the difficulty and the complications involved (it would not be back-portable to NSIS, I'd have to create my own code fork).
colors.
Now only the extraction of files used the installcolors, but it would be nice if "Choose directory" field, choose components, license, would use those colors also, the the installer would have a more coherent look.
Originally posted by Edgewize
>>The first two (horizontal scroll, $ENV('blah') special variable) are no problem.
Excellent!
>>The third one I don't understand ...
I probably should have said "ALL USERS" (in quotes), current NSIS has variables for the "CURRENT USER" (desktop etc).
>Named parameters are going to be a real pain in the ass -
>I may have to overhaul the parser, which will not be fun.
>This is dead last on my list of priorities because of the
>difficulty and the complications involved (it would not be
>back-portable to NSIS, I'd have to create my own code
>fork).
Dead last is fine that is where it was on my list :-)
However having done this myself it is actually not that hard and it could be done in a backwards compatible manner (ie support existing positional parameters) as described in a previous (recent) post of mine. It would make NSIS much easier to use for everyone. All you have to do is look at a command like the add shortcut to see the problem with positional parameters!
Thanks
Dennis
Aah, gotcha, "all users"!
I'll need to refresh myself on the registry locations for important folders, but that should be easy enough.
The ENV variable is going to be tougher than I expected, because of way Justin has made NSIS deal with variables. I might take some time on this in order to re-do his variable scheme completely. The upshot is that you will not be limited to the digits $0-$9 for user-defined variable names :)
I found your post about positional vs named parameters, and I'll admit that I like the idea very much. My gut instinct was that it would be an ugly rewrite of the exe header, but I realize that it is simply a compiler issue and shouldn't be terribly difficult. I will still need to rearrange the command parser to deal with the new argument style, however. I very much doubt that Justin would re-integrate this back into the official NSIS :/ Maybe if I throw in some buzzwords like 'XML compliant parser' he'll like it.
Originally posted by Edgewize
>>The ENV variable is going to be tougher than I expected,
>>The upshot is that you will not be limited to the digits $0-$9 for user-defined variable names :)
While I did suggest that the variables should not be restricted 0-9 previously, as a Quick and dirty the environment could be queried in the same way that the registry currently is (ie a command).
>>I found your post about positional vs named parameters, and I'll admit that I like the idea very much.
>>I very much doubt that Justin would re-integrate this back into the official NSIS :/ Maybe if I throw in some buzzwords like 'XML compliant parser' he'll like it.
I can't understand this as it does not change the size of the generated install code at all as the code you write is more usable and readable. The only "tricky" bit I can now think of (as I now guess that the parms are stored positionally internally) is the need for each command a ParmName->ParmPosn table and where this/these should be located.
CYA
Dennis
I'd really, really, really like to see a switch added to Section, so that a certain section can be unchecked by default.
That way, you can have, e.g.:
[x] Start Menu Group
[x] Desktop Icon
----------
[ ] Run Program When Finished
without creating InstTypes.
Another thing I'd like to see, although it really isn't as important as anything else seen hierrr...
Perhaps an extra command or switch somewhere, that allows you to bloat the minimum required disk space shown on the directory page?
You see, I have made an install program with a lot of BMPs. I've found that by turning them into JPEGs, and converting them at the other end, I can make the installer a lot smaller. But to this end, the minimum required space shown is false by about 6MB.
But yeah, that'd be nice...and besides, Inno Setup has it...ouch! I should stop referring to it here!
I'm adding a new command:
InstallDiskSpace [auto | set 012345 | oversize 012345 ]
Auto keeps it as-is, oversize increases the requirement, and set overrides it completely.
A section disabled flag should be pretty easy too. But can't you just make the default InstType (the first one) only match to some of the sections, and those will then be disabled by default?
Anyway, I'm gonna set a primary code release date of June 14 just because I need a deadline to get things done.
That's the thing, though, I'd prefer not to have to include InstTypes.
But thanks anyway, Edgewize!