Re: [gnome-db] Mergeant forms status

[Rodrigo Moya <rodrigo gnome-db org>]

On Fri, 2002-09-13 at 18:03, Vivien Malerba wrote:
> > cool, it looks much better! only one thing which is the size of the
> > buttons with the arrow. Can it be made smaller, so that it's got the
> > same height than the GtkEntry next to it?
> 
> I prefer when the button occupies all the height of the data entry
> because sometimes (depending on the plugin) the height can be bigger and
> the action widget can be farther on the left and so I think it is more
> homogenous like this. For example have a look at
> http://gasql.sourceforge.net/tmpdoc/Mergeant_Shots/mergeant_form4.jpg
> 
oh, ok

> 
> >
> > > > > >
> > > > > > Also, the dialogs that ask whether to run the SQL commands or not
> > > should
> > > > > > be removed. Or are those just displayed because of debug being
> > > enabled?
> > > > >
> > > > > For now they are enabled, but I want to convert this into a global
> > > > > option: whether to ask confirmation before SELECT, UPDATE, INSERT
> or
> > > > > DELETE calls (so each user can set wether he wants to check the
> queries
> > > > > before they are commited). The default would be no confirmation for
> > > > > SELECT, and confirmation for the others.
> > > > >
> > > > nice, leave that to me, since as I told you, I'll be working on a
> unique
> > > > preferences dialog, so I'll include this option also.
> > > >
> > >
> > > Ok. For this I will modify the ServerAccess object and issue a
> > > confirmation dialog whenever necessary from the user preferences.
> > >
> > what do you mean?
> 
> I was thinking of having the following preferences as booleans:
> - ask for confirmation before a SELECT query
> - ask for confirmation before an INSERT query
> - ask for confirmation before an UPDATE query
> - ask for confirmation before a DELETE query
> 
> and make the ServerAccess object checks those preferences before any
> query is sent to the DBMS and when necessary ask for a confirmation
> before actually sending the query. All the GUI will be in your settings
> dialog (I suppose this is the settings_get_show_confirmation_dialog
> accessor function you mention farther down).
> 
yes, I'll rename the file settingsdialog.c to settings.c and add there
all accessor functions.

> >
> > Also, what are you using for configuration right now? just the XML file
> > describing the connection? I think we should use GConf.
> 
> For now an XML file (for a given "document") holds: the database
> structure, the queries definitions, the forms (QueryEnv, etc)
> definitions, the layout of the relations widgets and the plugins
> association with data types and other objects (plugins can be associated
> to data types, table's fields and query's fields).
> 
> Also there are a few parameters which are stored in the old
> ~/.gnome/mergeant and ~/.gnome_private/mergeant. These parameters should
> go into GConf.
> 
ok, I'll look for that and replace them with calls to the accessor
functions in settings.c

> I think we should keep all the configuration parameters which are
> dependant on the contents of a "document" in the corresponding XML file
> (this is what is done now, no need to change it), and we should put all
> the parameters which are not dependant on the "document" in GConf.
> 
yes, makes sense.

> >
> > Also, I wanted to start looking at what config settings we want to have,
> > as soon as I finish moving the plugins configuration to the new settings
> > dialog, so, what do we want to have as preferences? I've thought so far
> > about:
> >
> > Interface
> >    Save window position on exit (yes/no)
> 
> This info goes into GConf keys.
> 
> > Database
> >    Connection preferences
> 
> The password and user names can go into GConf keys.
> 
oh, right, connection preferences are just for the current file being
opened in mergeant, right? If so, I think we should also keep the
username and password in the XML file. Of course, we should be crypting
the password.

> > Plugins
> >    The current plugin preferences dialog
> 
> This information goes into the XML file.
> 
hmm, why?

> Maybe also:
> - users management
> - saving a copy every <min> intervals?
> 
> I don't see any other for now.
> 
ok, I'll add the basic stuff, and then, as we need more options, we'll
add them.

cheers