comp lang tcl Re proposal for alternate to the

Document Sample
comp lang tcl Re proposal for alternate to the Powered By Docstoc
					                    comp.lang.tcl: Re: proposal for alternate to the option database

  Re: proposal for alternate to the option database


From: Benjamin Riefenstahl (
Date: 10/24/04

Date: Sun, 24 Oct 2004 21:32:27 +0200

Hi Keith,

A few thoughts from the sideline:

Keith writes:
> Most users now expect, especially on Windows, to be able to
> configure a program from w/i the program, not by editing some text
> file somewhere.

I agree. I wouldn't even limit this to Windows users.

> And frankly, this is a better way of doing it. If a user wants to
> change the width and color of a road in my KLIMB program, it is much
> easier for him to do so in a dialog with widgets aiding him in his
> choices.

If the programmer wants configuration dialogs, they must be created
separately for every program. How do you think that Tk can help with
this? (This is a serious question.)

I don't think that configuration dialogs and the option database
target the same kind of users. Actually the option database is
probably more important for programmers than it is for end−users.

> First off, let me ask: how many Window users of programs that you
> write or sell understand how to use the options database to
> configure your program?

How many users/programmers would understand any other kind of
scripting access to the same information?

> I feel that the option database is one of the most over−complicated
> aspects of Tcl.

My main problem is that it is underdocumented. Probably because Tk
comes from an X11 background where this is documented in the X11

Re: proposal for alternate to the option database                                      1
                     comp.lang.tcl: Re: proposal for alternate to the option database
> I feel that it is not relevant to the 90% of my users who use Window
> and Macs, and of the 10% where it is relevant, many don't really
> understand the option database and those that do are the types who
> would just as readily hack the code.

You can probably for the most part consider it part of the code. In
code it seems a good idea to separate visual issues like colors from
the main code. And it gives not only end−users but also library users
(programmers) and integrators the ability to change visual aspects
without modifying the code.

It's not that I couldn't just as well change the code, it's that as a
user, hacking the code is not a good idea, because it creates a code
fork which I would have to maintain during updates.

> As a configuration mechanism, I think it's serverly lacking.

For an end−user? Probably. For a system integrator or library user?
Those folks can use it to adapt the library or program to the rest of
their system in some detail.

> To give the user fine−grained control, you have to publish your
> widget hierarchy−−but that's something I rather keep private.

You don't *have* to do that. But sometimes it's a good idea.
Especially if you are writing a library for others to use. And than
there are wildcards, so you don't have to publish every detail.

> To configure non−widget items you have to create and document a
> second hierarchy of options. Also, the naming convention with what
> is or is not capitalized, what has priority over what, when to user
> dots or asterisks is not something the lay user wants to worry
> about.

If you don't want that, you can always either use something else or
write wrappers for it that do whatever you consider the right thing.

I would think though, that in most cases a simple straight−forward use
of the database, ignoring most of the details, guided by some simple
examples, would go a very long way.

> Functionality wise, options have three aspects I find missing.
> First is you can't use them to configure a already runnng program.

Sounds like a good question.

> Second is querying for current default values. For example, I like
> my labelframe to use an emboldened version of the default font. I
> don't know the how to get the default font w/o first creating a
> labelframe. (Perhaps "option get" can do this, but the doc for it
> is less than clear for somebody not intimate with the options

Re: proposal for alternate to the option database                                       2
                     comp.lang.tcl: Re: proposal for alternate to the option database
> database.)

The real defaults can be dynamic. And they can depend on the rest of
the system, e.g. because of interactions with Windows' own defaults.
So this is maybe not as easy as it sounds. OTOH maybe it's just that
the programmer should put the defaults into the database himself, so
that they can be retrieved.

> The third aspect is temporarily setting then clearing a specific
> option (option clear clobbers everything).

Isn't that the same question as the last about defaults?

> How does BWidgets use options w/o affecting the master tcl script?

You know where to look... ;−)


Re: proposal for alternate to the option database                                       3