On 2011-05-08 "Thomas A. Schmitz"
On May 8, 2011, at 11:00 PM, Marco wrote:
Having a GUI installer for the minimals (to make it more user-friendly and enable the user to choose what modules and fonts to install).
Just a (maybe stupid) idea:
What about making the existing windows GUI install and/or update all available modules/fonts, since most windows users don't care about a few hundred MiB disk space.
Second, creating a repository for Debian/Ubuntu that enables Linux users to install the minimals using the system package manager. It's easy to create a package for the modules.
I have no idea how package management works for MacOS, if something like repositories exist or how software is installed/updated.
And leave the existing interface for the other platforms, since the vast majority uses either Linux, Windows or MacOS.
Just a few thoughts:
1. linux ≠ ubuntu/debian. Maintaining a repository for all different linux distros in their different package formats would be a nightmare.
ACK.
2. Maintaining a cross-platform GUI is incredibly difficult. gtk is an absolute non-starter on OS X.
If you say so. But anyway, we should not discuss about which GUI toolkit we use, since it is not at all decided that anything will change at this point.
3. Resources are limited. I would rather they go into development of luatex and mkiv then into eye-candy for mouse-pushers.
4. We now get reports from people (not necessarily, but sometomes newbies) going "I ran command X, and the output was Y." With a GUI we get: "I pushed the button, you know the one with the letters on it, and nothing happened." GUIs have a tendency to hide useful information, making debugging all but impossible. (I sometimes look at comp.text.tex on usenet - the number of people who confuse their editor and its shiny interface with the underlying TeX engine is staggering; the same would happen here).
I agree. My thought was the following: The installation/update of ConTeXt is not integrated into the systems default methods. How often do we get installation help requests on the mailing list (on every platform)! Supporting the default installation/update method of the operating system would not necessarily need a GUI and be easy for the users.
5. Even if it's "easy" to create a debian package for the modules, who's going to create and maintain it?
The creation of the package is scriptable. When the module developer uploads/updates a module a (not yet existing) script is called that creates the Debian package, which is saved in the repository. Of course a scriptable solution breaks when e.g. dependencies are not met.
6. Offering a GUI sends out a wrong message to new users: it pretends that this is just something that will work the same way as their word processor or office program works. But once people actually want to do useful things, they need to learn a minimum of coding techniques. Users will then feel deceived because the shiny GUI made them believe they could just write away and click buttons.
In sum: I see no compelling reason in favor of, but many important reasons against such an installer.
As said before: Supporting the native package installation mechanisms of the major OSs/distributions would be a big help. For the rest the present mechanisms work fine. Marco