gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] notes re ConfigRegistry


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] notes re ConfigRegistry
Date: Mon, 12 May 2003 19:48:57 +0200
User-agent: Mutt/1.3.22.1i

Hilmar

> >  ------------------------------------------------------
> > | 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.
It *is* that one (or intended to be). And I imagine your
Registry to life on one or possibly several tabs.

> 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.
But why can't it gain accessibility and convenience by living
on tab(s) ?

> 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 don't see why it cannot live on a tab.

> I believe that there is place for more than one config widget in Gnumed.
Certainly, but I think it is quite important to also have
*all* options accessible from *one* place. So I can tell the
user on the phone: "Go to the config editor." Period.

>> 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 ?
Not a text file but a config file.
And not me but Joe User who doesn't understand vi/emacs.

> On the other
> hand you can easily mess up an text config file by editing it by hand
> afterwards.
See, that's why Joe Smith wants gmConfigEditor.

> The only application I consider useful is something like a wizard that
> helps you create the config file (something like xf86config).
Hm, I have the strange feeling that end users might differ in
perception here.

> 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.
Yes.

> 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.
Yes, and it should pretty much stay that way.

> ( I know that gmArchive has a much larger config file. Shouldn't that
> data reside on the backend ?)
Yes and no. During Scan and Index you don't need to have
access to the backend. Particularly not if you run those
applications standalone. If run as plugin they *should* access
config options in the backend. I am still pondering how to
best solve that dichotomy.

> Plus you don't have any access control due to lacking 'owner' information
> using config files.
Yes you do:

$> ls -l ~/.gnumed
insgesamt 6
lrwxrwxrwx    1 ncq      users          66 Okt 22  2002 amis.conf -> 
/home/ncq/Projekte/GNUmed/gnumed/gnumed/test-area/gmDrug/amis.conf
-rw-r--r--    1 ncq      users        3642 Mai  6 14:10 gnumed-archive.conf
-rw-r--r--    1 ncq      users         377 Mai  6 16:03 gnumed.conf
-rw-r--r--    1 ncq      users         377 Mai  6 16:03 gnumed.conf.gmCfg.bak
lrwxrwxrwx    1 ncq      users          16 Dez  2 03:52 logs -> /var/log/gnumed/

> > 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.
Only if we can find a agreement on the above concept.

> I think that the *end user* should have a better config editor than
> ConfigRegistry.
Sure, but they need not have it today.

> IMHO all user-configurable application options should be
> set using backend stored parameters.
How does that relate to the frontend for it ?

> I will try to implent the low-level structure in a way that other config
> applications can reuse it.
Good.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]