Re: [gnome-db] Future characteristic

[Vivien Malerba <vmalerba gmail com>]

On Wed, 27 Oct 2004 02:24:23 +0200, Rodrigo Moya <rodrigo gnome-db org> wrote:
> 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.

Ok.

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

Ok.

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

As I understand it, the purpose of the GdaError object is to store an
error, and the GnomeDbError dialog displays lists of error stored in a
list of GdaError objects. The purpose of that is to ba able to
retreive all the errors which occured on a connection.
Libmergeant uses GError structures to report errors when some
functions are called. As Libmergeant uses libgda, the errors related
to the connection will also be in the list of errors managed by the
connection.

I don't see any problem in having the GdaError and the GError as they
don't do the same things. I've never used the GdaError, so I cant' say
how usefull they are.

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

Ok.

Also there is a DbShell widget which is not used anywhere, I'll remove it.

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

Ok.

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

I can't find any place where they are used, I'll remove them for now
(they may be needed later if we want to make some bonobo components,
no?)

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

Ok.

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

Yes. I don't think the Query, table and report editors whould be put
in libgnomedb because other applications built with libgnomedb will
probably either want to write other editors, or not use an editor so I
don't want to make Libgnomedb too big. Of course I might be wrong
here.

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

MgResultSet, as many of Libmergeant's objects inherits the MgBase
object which provides an extension to how the objects are destroyed (a
bit like the GtkObject for Gtk).
Let me explain: normal GObject objects are destroyed when their
reference count reaches zero. In Libmergeant, this mechanism is used
along with another one which enables to destroy an object even if it
still has a ref count >0 (and tell the entities holding a reference on
it to release it).

As a result, MgResultSet can't inherit GdaDataModel. However what
could be done is transform GdaDataModel into an interface (and have
the current GdaDataModel object be for example GdaDataModelBase) which
MgResultSet could implement, and all the dictionnary objects could
also implement. This is quite easy to do.

> 
> * 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 MgHandler in itself does not have any GUI part, but one of its
methods does create a GtkWidget, so Gtk is required. The same applies
to the rest of the dictionnary.

> 
> * "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 MgWorkGrid is not just a tree widget to display rows. It does not
work from a MgResultSet, but from a SELECT query, and allows edition
of the displayed rows: you can't ask a MgWorkGrid to display a
MgResultSet. This is why I want to keep the GnomeDbGrid as well.

However we could create an interface which both GnomeDbGrid and
MgWorkGrid will implement, so the API can be the same for both
widgets.

> 
> * "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

See my comment above; this is not applicable.

> 
> * "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

That would more or less be the current Libmergeant library!

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

Yes, as long as the GdaDataModel object is converted to an interface.

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

See my comments above for details.

> 
> The rest of the stuff looks ok, specially the cleanup of the libgnomedb
> API, which was really needed

Ok.

Thanks,

Vivien