On Wed, 06 Jun 2001, Sven Neumann wrote: > David Monniaux <David.Monniaux@xxxxxx> writes: >> The installation process is frightening: >> >> 1. The user is presented with a dialog box "Welcome to GIMP" that is half >> full of legalese (NO GUARANTEE etc...). > > actually our first version had an "Accept" button at the bottom ;-) > > The GPL wants you to put a visible notification about the license into > your program. This notice should be seen whenever you start Gimp. We > only show it on user installation and one day RMS will come and get us > for this lazyness.
Well, I doubt that RMS would blame us for that. The notice must not be displayed every time the program is started, as long as it can be accessed easily using some command-line option or dialog box that is commonly used to display some information about the program (such as --help, --version or some About dialog for graphical programs such as the Gimp).
> I think the license part should stay and we should add an additional note > about the GPL to the About dialog.
Yes, adding a notice about the GPL in the About dialog is a very good idea and would satisfy the requirements of the GPL. However, the part about the license in the first installation window could be softened a bit, as David suggests. There must be at least a pointer to the GPL and the usual wording about "use at your own risks", but this could come after a user-friendly text that explains in a few words that the Gimp is free software. I have no precise ideas about how this could look like; suggestions are welcome...
[...other good replies snipped...] >> 4. Adjustment of parameters >> Another frightening dialog box. We should really convey the idea that >> the default settings are OK, and that those settings can be changed >> at any time afterwards (otherwise the users may spend time pondering what >> to say here). > > It is indeed possible to change this later, but we moved it into the user > installation since experience shows that these values will never be adjusted > later. Setting the tile cache correctly is viable for a good user experience > so I expect the user to spend some time here pondering what values to choose.
I agree. However, the reports in various newsgroups and mailing lists show that many Linux and Windows users did not pay enough attention to these settings, maybe because they did not fully understand the consequences. Or maybe because they wanted to try the program quickly and they pressed "OK" or "Next" on all installation windows, assuming that the defaults are fine and that only the experts need to change them.
>> a) The default tile cache size should be adjusted with respect to the >> installed RAM size. This should fulfill the need of most users >> (PCs with one console user). In the case of multi-user systems, >> the system administrator should be able to set other default values >> (maybe depending on the machine). > > Yeah, we had that discussion before quite often and everyone agreed that > it should be as you say here, but until today noone found it important > enough to change the code.
Here is a suggestion. I doubt that I will implement it, but maybe David can do it since he wants to improve the installation process. Keep the current dialog as it is (telling the user to adjust the value as needed), but try to change the default value of 32M on the systems in which the available memory is easy to guess. This means that the users of other systems will still have to change the tile cache size from the default of 32M, but at least those who are using one of the common configurations (e.g., Linux 2.2 or 2.4 on a single-user machine) will get a more sensible value by default.
The default value could be computed like this: if /proc/meminfo exists, then open it, read the MemTotal value, substract 42M and round to the nearest multiple of 16M to have a nice number. Use the result as the default tile cache size, with a minimum of 32M. If there is no /proc/meminfo, then use 32M as before. A similar thing could probably be done for Windows, although I do not know much about that.
[...]
>> b) The setting of the swap file in .gimp-x.y/tmp is a problem on
>> NFS-mounted accounts (universities, for instance). Why not /tmp by
>> default?
>
> Since /tmp is not always a good choice, it might even not exist?! For that
> reason we say:
>
> "All image and undo data which doesn't fit into the Tile Cache will be
> written to a swap file. This file should be located on a local filesystem
> with enough free space (several hundred MB). On a UNIX system, you
> may want to use the system-wide temp-dir ("/tmp" or "/var/tmp").
>
> Don't you think this is enough to help the user make a good decision?Using the same point of view as above, we could try to provide a better default value if possible. The user will still have to pay attention to this value and change it in order to get the best results, but we could provide more sensible defaults.
Making a good guess will probably be a bit tricky. I think that in most cases, /tmp could be a better default choice than the user's home directory but there is of course the problem of disk space. In some cases, there is not much space available in /tmp. In some other cases (especially on shared systems with NFS-mounted home directories), there is limited space in the home directory but plenty of space in /tmp. I think that the only way to check that automatically is to run "df" and parse its output. This is not very elegant, but I cannot think of a better solution.
Here is how it could be done: run "df $TMPDIR", "df /tmp" and "df $HOME". Ignore the result if "df" fails or if the second line of the output does not start with "/dev/" (which indicates that the directory is mounted from another host). If there is anything left, then use the directory that has the largest value in the "available" column. If there is nothing left, then use the old default value. The user will still be able to edit it anyway.
>> Now for the main UI. We should have a way to remind people to use the RIGHT >> BUTTON on the image. I bet many people think Gimp is some kind of small >> MS Paint-like program because they have never been able to reach the filters. >> Yes, I know this is the second tip, but...
Actually, this is the very first tip (unless someone has changed the tips file recently). If you can think of a way to make this even more obvious, then feel free to post some suggestions (or patches). But as Sven said, I do not think that we should invest too much time on that.
-Raphael
