Eli Marmor <[EMAIL PROTECTED]> wrote:
> X Resources.
>
> Does it threat anybody?
> No? OK; Let's go on:
>
> There are several requirements that are critical for creating a good
> GUI.
>
> One of them is the ability to work against a working program, and not
> just a file.
Well, this has nothing to do with the configuration file format itself. It's a
communication protocol provided by the X/editres API (libXmu). But it's indeed
very important for a configuration _programming interface_. Unfortunately, the X
people didn't realize that the pathetic lack of standard configuration API in
the Unix world that had driven them to create the Xresources infrastructure from
the scratch was worth extracting it into a separate, X-independent API library.
> Of course, you need a bidirectional mapping (i.e. not only from the
> disk representation to the in-memory representation, but also vice-
> versa); Otherwise, the changes can't be translated to rules of
> configuration files.
Right, and the lack of these features (actually, the lack of decent API
providing them) distracted many even pure-X apps from solely using it; instead,
they load/store their configs from customly-formatted .rc files.
> You need clear definitions; Not definitions that may start anywhere in
> the line, with any number of leading/trailing spaces/tabs/etc. that you
> never know which are part of the value and which are not, with leveling
> that is based on semi-XML directives ("</directory />"), with ambiguous
> comments, with "ifdefs" that you never know if the leveling that is
> hidden by them is really hidden - or only the rules inside those
> levels, with too many ways to say "yes" (e.g. "tRuE", "oN", falling
> back to the default, etc.) and so on.
>
> There are many other formatting issues that ease or harden the ability
> to develop a good GUI.
GUI is important, but it's nothing compared to the API. I don't care about the
specific format of the configuration _storage_. Let it be a plain ASCII or XML
file or any binary one (not a propriate, of course). Do you care about the data
storage format when comparing e.g. MySQL vs. PgSQL? Of course, not. Does it
worry someone that the data format is binary? Of course, not. Well, a data dump
(to an ASCII file) utility is a must - for the backup purposes etc, but that's
all.
I need the well-defined API and its C implementation. Whatever
complicated/non-trivial format is choosen, the efforts of parsing it are spent
only once. From there on, everything is simple. The GUI config tool will use the
API, too. C++/Perl/Python/etc bindings are trivial. Look at CUPS. Nobody (except
those involved in its development) cares about the format/structure of the CUPS
config files. They provided the API. Period. Then somebody wrote the Qt/CUPS
widget, and now any Qt application (read - programmer) get the whole selection
of printing options provided by CUPS with zero efforts spent. Compare the
situation with lpr & friends. There is no API for parsing (let alone changing)
the rather primitive /etc/printcap file format. And then come sysv lp, lprng,...
each with its own config files and each with NO C API! As a result - how many
non-cups-bound applications can you count which provide the list of printers
present? Very, very few and far between. Even overloaded monsters like Netscape
dare not implementing it - taking into account the variety of existing printing
systems.
> People develop Open Source for their own fun. Or for their own use
Why, it's not Open Source related. It's a common Unix malady - the absense of a
kind of a centralized patronage (like W3C is for Web) during its development. As
a result - the lack of well-thought and -implemented APIs for everyday's tasks.
Configuration is just one of many.
> When there is a company (please don't force me to spell the name of
> Redmond's companies) behind the product, they have "balls" (sorry for
> the word...) and don't give a sh*t (sorry again) on their users, so
> they can replace formats whenever it is important for the evolution of
> their product.
The Company-Which-Is-Not-To-Be-Named did just what X programmers did - developed
a configuration API. And so Gnome developers did, BTW, with their quite decent
GConf API. The only difference is that Microsoft happened to be a force behind
an _OS_, while Xconsortium worried only about X applications and Gnome people
worried only about Gnome applications, so the configuration API provided by X is
of no use to non-X apps and GConf, as nice as it is, is useless to non-Gnome
developers, KDE people did something for KDE apps only etc. And there was/is no
"father" to worry about Unix as a whole, inspite of rich commercial vendors.
That's the sad fact. Hence the current situation with multiple duplication of
efforts with no satisfactory results.
> Many years ago, I developed a great GUI for X.
> You could take even a binary program, and change its screens, widgets,
> add more dialogs/forms/screens, etc. Fully WYSIWYG, of course.
> I used it (among other uses) for localizing Netscape 3/4 (although
> there were no sources), which involved not only translation, but also
> new screens and forms (for example - to choose the default direction,
> the default user interface language, help of the Hebrew support, etc.).
> I used it also for developing callbacks (without writing one C line!)
> and applying BiDi values to specific widgets (e.g. Visual/Logical).
That sounds nice. Any chance you'll release it as an open source soon?
Regards,
Evgeny
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
