Re: [gnome-db] Mergeant forms status

[Vivien Malerba <malerba gnome-db org>]

Le ven 13/09/2002 à 17:09, Rodrigo Moya a écrit :
> On Fri, 2002-09-13 at 15:33, Vivien Malerba wrote:
> > Le jeu 12/09/2002 à 19:11, Rodrigo Moya a écrit :
> >
> > > > I think it is better because it occupies less space in the form
(and
> > > > leaves more for the actual data). I just want to remove the
keyboard
> > > > focus for it and re-enable mouse sensitiveness.
> > > >
> > > well, I'm talking about something like
> > > http://primates.ximian.com/~rodrigo/extra-options.png. As you can
see,
> > > the little button with the arrow just occupies a little space, and
it's
> > > purpose its clearer to the eye of the user, I think. Then, once
pressed,
> > > we can present the menu, as the image shows and as you are already
> > > doing.
> >
> > Right this is what I've done and just commited. I've just read the HIG,
> > it's very helpfull: there will be more dialogs to rework to be conform
> > to it.
> >
> 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


>
> Sorry for bringing so many details, but the form is looking so nice,
> that I find the small problems very easily :-)

Well, this means we are starting to have a nice GUI!

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

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

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.

>
> My idea is to have the settingsdialog.c file I just added with lots of
> accessor functions for the different settings
> (settings_get_show_confirmation_dialog, for instance), so that the rest
> of mergeant just calls those functions to set/get the configuration
> settings.

Right.

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

> Plugins
>    The current plugin preferences dialog

This information goes into the XML file.

Maybe also:
- users management
- saving a copy every <min> intervals?

I don't see any other for now.


Thanks,

Vivien