On Wed, 06 Jun 2001, Sven Neumann wrote:
 > David Monniaux <[EMAIL PROTECTED]> 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

 >> 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.


Gimp-developer mailing list

Reply via email to