Re: [gnome-db] Future characteristic

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2004-10-19 at 17:26 +0200, Vivien Malerba wrote:
> Here is a Libgnomedb/Libmergeant merge proposal; please give me your
> comments (the attached doc is an OpenOffice.Org file).
> 
some comments:

* gnome-db-util.[ch]: these are utility functions that should probably
not be part of the public API. I'm not sure if Mergeant uses any of the
functions here, if not, we should try to remove those uses and keep
gnome-db-util as a private header for libgnomedb use only.

* SQL editor: the idea of calling it GnomeDbEditor instead of SqlEditor
was because we intended to support any other language (PL/SQL, whatever)
any provider could support. So I'd keep it as GnomeDbEditor.

* GnomeDbError/ErrorDialog: this has "nothing" to do with using GError,
they are widgets for displaying the GdaError objects used in
GdaConnection. So, either we remove GdaError and use GError, or we make
mergeant use GdaError.

* GnomeDbWindow: this should be removed from the public API, yeah, but
we should keep it for internal use in libgnomedb, since it's used in a
few places, IIRC.

* GnomeDbGrayBar is used in GnomeDbGrid, so should be kept. Again, it
can be made a private header, and not part of the public API.

* Bonobo utilities: this should be either removed if not used, or be
kept as private API.

* GnomeDbGrid and gnome_db_model_to_gtk_tree_view: GnomeDbGrid is a full
featured widget, with searching, sorting, etc, while the function is
just a simple way to create a GtkTreeView to display a given data model.
It should be not part of the public API probably.

* when you say "Remove, to be put in mergeant", do you mean just in
Mergeant and not at all in libgnomedb?

* MgResultSet should be a GdaDataModel-based class, as all things
related to the dictionary. Thus, we don't need to keep 2 copies of many
widgets (GnomeDbGrid/MgWorkGrid, etc), since we just need to have a
widget that supports the GdaDataModel interface. This would make things
much more easier to write and understand, and will keep the number of
widgets to the minimum number.

* MgHandler, does it have any GUI part at all? If not, could it be part
of libgda? The same for all other supporting data types that have no GUI
relation at all.

* "The MgWorkGrid widget hides the GtkTreeView it internaly uses.
Exposing it to the developpers would improve possibilities."
again, we should keep just one of the grid widgets IMO and make it
support all kind of GdaDataModel-based classes. Then, with the one we
keep, it should probably be directly inheriting from GtkTreeView itself,
so that people can use all GtkTreeView API with it directly.

* "The MgWork* widgets hide the GdaDataModel which they use; should it
be revealed as well? (in that case more work is needed)."
If we base everything on GdaDataModel-based classes, the model should be
available in all widgets, as in gnome_db_grid_get_model/set_model

* "I think we should keep the usage of a data dictionnary in the future
Libgnomedb library optionnal:"
or we could have a libgnomedb-dictionary library, that provides all the
extra GdaDataModel-based classes

* "for example having a few widgets available to display a GdaDataModel
can sometimes be usefull as long as no data edition is required"
if we write the dictionary to be a data-model-based class, we can just
define, in the data model interface, the needed functions to do the
edition (which is in fact already available), and so have the widgets
adapt themselves to whether the data model can be edited or not.

So, conclusion, the big thing IMO is the data-model thing I've been
mentioning above. We have the data-model-based classes that are easily
extensible, so we can add any functionality we want on top of it. So
providing the dictionary and all supporting classes currently in
libgmergeant as GdaDataModel-based classes will make things easy, since
people will be using the same API mostly whether they're using a
full-featured dictionary or a simple SELECT_FOR_VIEW data model.
Also, having the extensions be data-models allow us to write only one
set of widgets that both support the simplest data models and the full
featured dictionary. It will avoid us having many almost duplicated
widgets in the API, and users of the lib having to use 2 different sets
of widgets when using a dictionary than when not using it.

The rest of the stuff looks ok, specially the cleanup of the libgnomedb
API, which was really needed
-- 
Rodrigo Moya <rodrigo gnome-db org>