Re: [MiNT] OSMD - introduction

[Standa Opichal <opichals@seznam.cz>]

---------- Forwarded message ----------
Date: Tue, 21 Aug 2001 04:27:11 +0200
From: Guido Flohr <Guido.Flohr@t-online.de>
To: Standa Opichal <opichals@seznam.cz>
Subject: Re: [MiNT] OSMD - introduction
Resent-Date: Tue, 21 Aug 2001 04:32:27 +0200 (CEST)
Resent-From: OpichalS@seznam.cz
Resent-To: stop@idoox.com

Hi,

you replied to my mail address, not to the list.  On purpose?  Feel free
to forward my reply to the MiNT list if that was by accident ...

On Mon, Aug 20, 2001 at 11:00:11PM +0200, Standa Opichal wrote:
> On Mon, 20 Aug 2001, Guido Flohr wrote:
>
> > > At the moment I have rewritten and tested the KEMD setup script. It
> > > can do more than the half of above mentioned operations. I know this
> > > type of text installation is not much sexy but it is the only thing I
> > > can do. There are two other proposals (both from Jay Soft):
> > > 	a) do a text installation using tty dialogs
> > > 	b) do a GEM installation using GEMSetup or something like that
> > > What do you think as a MiNT large public? Any other proposals?
> >
> > What about c) do an installation completely based on VDI.
>
> Which is AES, isn't it? I think it is rather "masochism" to write AES
> stuff "only" to be able install OS.

No, it is not AES.

What I meant: One would need a simple GUI toolkit that is completely
independent of the AES and therefore doesn't need an AES to be
active.  You could use this toolkit even from the auto folder and it would
be ideal for MiNT installation or installation of the AES itself.

Even cooler would be a toolkit with all GUI functions completely
encapsulated.  On startup it would detect wether an AES is active and fall
back to plain VDI in case of absence of a working AES.

In fact I had once written something like this some time ago and the
result was nlogin.  nlogin uses newt which is an slang toolkit.  I simply
recoded the few newt functions I needed with plain old VDI and I could
switch between a graphical (VDI) interface and the curses version.

I wasn't able to really finish that because my graphics card had a bug
which made it impossible to open a physical workstation.  But actually
that approach should work flawlessly.  A lot of work however.

> Well, just now I'm thinking about to do everything what we can do, just
> before booting MiNT. i.e. by some normal GEM application under plain
> ROM TOS. There are some disadvantages using this way:
>
> * man don't get the root directory listing of the partition before it gets
> lost (no minix, ext2 driver) - RH solves this simply by using either
> autopartition, when all data is lost on the disc, or by manual partition
> tool, which allows to setup the disc partition sizes and types on users
> own.

And by a huge ramdisk.

> * The AES should be a part of the installation. Intended to be able to
> continue with the installation process after rebooting into MiNT. This
> would problably have a different look&feel, what is not very good for a
> user complient installation.

And besides most people still prefer N.AES to xAES.  But as long as the
N.AES folks refuse to give away N.AES for free (resp. publish the
sources) you cannot bundle with N.AES.

>
> The other proposal I've made was to use GEMSetup... (read the next
> mail)

The last time I looked at GEMsetup it was rather crappy compared to rpm or
other powerful package management tools.

>
> > Of course c) needs a toolkit for VDI GUIs which is not written. :-(
>
> Well, only one free... XaAES.

That is an AES, not a VDI toolkit (see above).

>
> > > will be able to prepare English and Czech versions (no matter what
> > > way of installation in point 1 will be chosen). We wil be glad if
> > > some of you will translate the script to German, French, ...
> >
> > Install the package "gettext" and try "gettext --help".  You don't need
> > separate scripts to internationalize your installation stuff, you only
> > need different message catalogs.  Once you support more than two
> > languages, you will not be very happy with your solution.
>
> Not with GEM complient solution. There is, however, much more convenient
> solution for this... just change the .RSC file ;) Anyway, is there any

A couple of years ago I have written an interface for GEM programs to GNU
gettext.  It is called gemtext (see for example the file README.gemtext in
the official distribution for GNU gettext on prep.ai.mit.edu).

IMHO RSC files are a bad idea when being abused for i18n (although most
Atari users will disagree here with me).  It leads to awkward programming
because even a silly form_alert() requires an object in the RSC file.  And
this leads GEM programmers to avoid as many form_alert()s as possible and
consequently too few error messages.

GNU gettext is much more convenient, both for programmers and for
translators.  Translators don't necessarily have an RCS, and if they do
have one, they may not have the skills to detect all translatable strings.
By contrary, gettext/gemtext don't suffer from these shortcomings.  They
allow you to maintain a database of translations, the system is smart
enough to automatically check for common errors that may make your program
crash (corrupted printf format strings for example) or other errors,
translators don't have to translate the same stuff over and over again
just because the author of the software has changed a typo in the message
(gettext does fuzzy comparisons and proposes a translation for strings it
thinks it knows).

RCS files for i18n may have been a good idea in 1985, but in 1990 already
they weren't.  I avoid them like the plague.

> need to have a multi language installation? How many users use MiNT and
> don't know English. Another waste of time? We all are saying "I was short
> of time" and doning nothing. I think the English language is good enough
> for _everybody_ using MiNT. Other users will translate it themselves.
> This my pu(oo)r(e) opinion, so don't take me for Gospel ;)

Sure. But internationalizing your software with gettext is so simple that
you don't really bother about the extra effort to make even only a few
people happy with a translation into their native language.

Ciao

Guido