Re: gda config component

On mar, 18 avr 2000, you wrote:
> > I'm just now wondering about what should really go into the config component.
> > Tell me if I'm being wrong about all this, but here is my point of view:
> > 
> > The config component should allow the user to configure the corresponding DBMS
> > (with things such as creating, saving, destroying of complete databases,
> > creating, destroying and changing users rights, etc). As some DBMS may have
> > other things to configure, I want to create several components (one for users,
> > one for databases, etc) which can be called as independent components (with for
> > example "gnome-db-users", "gnome-db-databases"), and then create the global
> > config component as a grouping of all these individual components (in a
> > notebook). The benefits are that a client (such as gASQL) can choose to get
> > only one component, and at the same time a client can get the full config
> > component?  What's your opinion on this?
> > 
> Good idea, but, instead of having one component (process) for each of

I did not mean to have separate processes for each component but one config
process per provider which serves several different simple components, plus one
more complex component which is the global config component. 

> the 'profiles', why not have some kind of property where you can specify
> which data to be shown? This can be easily done with bonobo properties,
> which can be attached to the config controls. 

Yes! So as I see it each provider will have a config process which will offer
several small components accessible individually (such as f.e. management of
users) with almost no properties (to be defined for each component), and one
big global config component where there will be several properties (maybe
boolean properties to show/hide parts) to specify exactly what the config
component should display (so if for example I want to manage users, I can get
the 'user list' component, the 'groups list' component and 'users
capabilities'). Is that possible? What do you think of this?

>The only 'problem' I see
> with this is that more work is needed on each of the config providers.

Each provider will define several widgets (for the small components) and
"export" those widgets as controls and one big config component incorporating
several of these widgets. So not much more work is needed compared with only
one control component, and it is much more flexible.

> Definitely I think it's quite good to have something like this.




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