Re: [Gnumed-devel] notes re ConfigRegistry

[Hilmar Berger]

On Mon, 12 May 2003, Karsten Hilbert wrote:

> Hilmar,
>
> I suggest the following layout:
>
>  ------------------------------------------------------
> | config file: <path>                                  |
> |------------------------------------------------------|
> | option | __input_field__ | description        | tab  |
> | option | __input_field__ | description        |------|
> | option | __input_field__ | description        |tab | |
> | option | __input_field__ | description        |------|
> | option | __input_field__ | description        |tab | |
> |------------------------------------------------------|
> |                                           |  ______  |
> | group description                         | | save | |
> |                                           |  ------  |
> |                                           |  ______  |
> |                                           | | load | |
> |                                           |  ------  |
>  ------------------------------------------------------
>
The layout you suggest is obviously similiar to the one used by
Sebastian's ConfigEditor in test-area. My ConfigRegistry (note the
different name!) is not intended to replace this effort. It's aim is
to be a quick and complete solution for the developer and experienced
user. It lacks the convenience of a notebook-like widget. On the other
hand it has some advantages over the latter:
- allows for display of more than one user/machine-combination at once
- allows for trees with more than one branching level (notebook allows
only for group/option)

I believe that there is place for more than one config widget in Gnumed.
In Windows, there are small,convenient config notebooks in every
application. These notebooks posess some magic to do constraint checking
and so on, and usually they don't bother the user with a multitude of
parameter names. They are designed for the ordinary user that just wants
to change some color, path or behaviour.

On the other hand there is 'regedit', aimed at the experienced user or
administrator, allowing access to the complete number of config
parameters. You can import/export the registry, add parameters, delete
them and so on. This is what ConfigRegistry will be like.


> The tabs are the groups/sections in the config file/database.
> Preloaded is gmCfg.gmDefCfgFile. <load> allows to load another
Why would you like to edit a text file using the config editor ?
I can't see any advantage over a normal text editor. The only difference
might be that you can check if the values entered are valid. On the other
hand you can easily mess up an text config file by editing it by hand
afterwards.
The only application I consider useful is something like a wizard that
helps you create the config file (something like xf86config).

Additionally I remember that we discussed the problem of what should go
into files and what into the backend in regard to config options. We
agreed that the config file should only work until the backend connection
is established. gnumed.conf does not hold many options right now, the
majority of which you can set by using the LoginDialog. The remaining
options (workplace name etc.) can be set by hand at gnumed installation.
( I know that gmArchive has a much larger config file. Shouldn't that
data reside on the backend ?)
Plus you don't have any access control due to lacking 'owner' information
using config files.

> file. The top line shows the name of the config file or the
> connected database. When displaying a tab with a section from the
If it's really necessary I can implement this easily.
> database your (sub)tree structure instead of the "option,
> field, description" triple would be used.

Well, I can as well transform group/option to a tree structure.

> Or something similar. The end user shouldn't notice much of a
> difference in handling either the file or the database but the
> option source should be shown very clearly.

I think that the *end user* should have a better config editor than
ConfigRegistry. IMHO all user-configurable application options should be
set using backend stored parameters.

I will try to implent the low-level structure in a way that other config
applications can reuse it. I hope the things we will learn from this
rather simple example will benefit further development.

Hilmar