Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>There are pros and cons to both approaches:</p> <ul> <li><p>Having an installer is the proper way to install necessary system components, like drivers, libraries, COM components and so on. Since many of these activities need elevated permissions the install may be performed by the administrator, while the application can be used by all users.</p></li> <li><p>There may actually be requirements for a scriptable installation procedure in corporate environments.</p></li> <li><p>Not having an installer opens the way to portable applications. If the program has everything in a directory, then this can simply be copied to a USB stick and be run on any system. This may of course not make sense for your particular kind of app, but that is for you to decide.</p></li> </ul> <p>I'm not sure that the issue about corrupted settings is really important here. If settings are corrupted (why?) - how is the application to know what to do about it? OTOH the installer can of course also be written to not blindly overwrite any old settings. It all depends...</p> <p><strong>Edit:</strong> You write in your comment:</p> <blockquote> <p>Even portable apps require certain configuration/settings, Isn't it better to have the main app check that settings are valid/exist on each startup, and only prompt the user when needed.</p> </blockquote> <p>and again, it really depends on your needs. There are different types of configuration settings or preferences, and you have to decide individually:</p> <ul> <li><p>Per-user configuration settings will be missing if the application is run for the first time by the current user. It can be helpful to show a message that it is missing, and how to create it. For example in <a href="http://www.flamerobin.org" rel="nofollow noreferrer">FlameRobin</a> (a database administration program for Firebird) we have a message that is shown when no registered servers and databases are found on program startup, and how to register them.</p></li> <li><p>Per-user settings for UI behaviour will also be missing, but there are default values for them. The user will get the default behaviour of the application, and can later change things in the option dialog. Since it is best to minimize the number of such settings, and since the defaults should be what most users expect or what works best in the general case, there is also no need to bother the user at program startup.</p></li> <li><p>Some configuration may be not per-user, but per-program. This is generally stored in a location where standard users have no write access, so checking for this and prompt the user to enter it is not really helpful. What could be done is to start an external program, asking the standard user for the account with sufficient privileges and its password.</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload