On Friday 05 September 2003 20:06, Jason Stubbs wrote: > > I would really hate that. Then I would have to look for an other disto > > again. For some reason distos always seem to become more and more > > "userfriendly", that is harder and harder to use if you don't want to use > > the shiny gui interface they always seems to come up with. > > You are wrong. 'userfriendly' does not imply harder to use (for power > users). Just because all those that have tried so far have failed, there's > no logical step to say that it's impossible. Compare MS Exchange's method
It does not imply but it seems to be that way in practice. > of > configuration with Sendmail's - yes, we have postfix now but sendmail fits > what I'm talking about better. Exchange's interface is easy to use and will > set everything you want correctly - if the program doesn't work the way you > want it to it's due to a bug in the server, not the interface. Sendmail > will do everything you want it to but you have are much more likely to make > a configuration error. > > Most people will say to this, "but Sendmail is more powerful!" What's that > got to do with the price of fish? Exchange's real configuration lies > partially in the registry and partially in configuration files (in a > non-text format), either in it's application directory or active directory. > From a programming perspective, isn't attaching a user interface on to the > configuration files just as hard for either? With postfix, parsing and > configuring it from a gui would be much easier than either. Whether you use text files or non-text files to store the configuration does not make much of a differenct if you want to write a gui on top of it. What to note is that the gui is enfact on top of the configuration file so at best you can hope not to loose any expressive power. To keep the expressive power of the configuration files you can try to immitate the structure of the file in the gui, for a more complex program the probably will not make a good gui. To make a good gui you probably have to restructure it somehow and then make some more or less complex translation back to the configuration file. In that process you will probably loose some expressive power. That is anyway how it seems to be in practice. Only some part of what the program is capable of doing can be configured from the gui, that is the part that the GUI writer fount to be most important. But ofcause as long as the gui supports you every need to the program that is fine and I do prefer a gui to some simpler programs. Then there is the issue of being able to do the configuration by some other programe. It is i lot easier to make a script that outputs a configuration file that a script that interacts with a gui. Then you could just have the configuration files with the gui on top and let the the people that want a gui use the gui and the rest can just modify the configuration file by hand. That might be a good solution. The problem is that the way the translation from the gui to the configuration file often is implemented is by making some intermediat configuration file that maps closely to the gui and translate that to the real configuration file and as this approach gets implemented through out the system the system becomes very dependent on those intermediat configurations files and it becomes hard to be allowed, by the system, to edit some of the configuration files by hand. > The point of userfriendlyness is not to limit users in what they can do so > that they don't trip over themselves. The point is to make all options > available (and easily understandable) and prevent configurations that > meaningless in the domain of the application. That is one way to define userfriendlyness and it has some good points to it. For one it does not in any way imply that a gui is the better choise over a text file. -- Jesper 15:16:50 up 13 min, 1 user, load average: 0.83, 1.16, 0.74 -- [EMAIL PROTECTED] mailing list
