Re: [gnome-db] Future characteristic

[Vivien Malerba <vmalerba gmail com>]

On Wed, 27 Oct 2004 13:05:09 +0200, Rodrigo Moya <rodrigo gnome-db org> wrote:
> On Wed, 2004-10-27 at 11:59 +0200, Vivien Malerba wrote:
> > >
> > > * 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.
> > 
> it stores just a few extra bits, like in which provider the error took
> place. Not really much, so removing GdaError and use GError everywhere
> might make sense.

Ok, I'll let it be for the time being, and mark it to be replaced by
GError after the merge.


> > Also there is a DbShell widget which is not used anywhere, I'll remove it.
> > 
> it's used in the gnome-database-properties application

Ok, I'd missed the line where it's used. I'll make sure it is private
to the library.

> 
> > >
> > > * 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?)
> > 
> I would remove them for now, and re-add them when we really need them.

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.
> > 
> I think all classes that might be useful for other applications make a
> lot of sense in libmergeant, so I'd put them in libgnomedb.

Ok, I'll put that into 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.
> >
> > 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.
> > 
> right, that makes a lot of sense, so that the dictionary classes just
> have to implemente the interface. Yeah, sounds pretty good.

Ok.

> 
> > >
> > > * 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.
> > 
> ok, might it make sense then in libgnomedb?

What making sense? If it's to put it into libgnomedb, then yes.

> 
> > >
> > > * "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.
> > 
> why do we need to work from a SELECT query? Can't we make it work from a
> data model instead?

Because a simple GdaDataModel is a list of data, with no way of
knowing where the data comes from, which is a pre-requisite if you
want to update that data in the database. The idea is to modify the
data in the GdaDataModel and make sure the data is actually modified
in the database as well (in a correct way).

> 
> > However we could create an interface which both GnomeDbGrid and
> > MgWorkGrid will implement, so the API can be the same for both
> > widgets.
> > 
> the data model one :)

I was thinking of an interface for the following functions:
_set_titel(), _get_title(), _set_column_title, etc

> 
> > >
> > > * "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!
> > 
> yes. I think there is no gain in having 2 libraries, so all the public
> things should be in libgnomedb. What we can do is have the dictionary in
> libgnomedb-dictionary, for instance, so that libgnomedb is small enough
> for simple applications. But all reusable stuff should be made available
> in one place.

Then we'll end up with libgnomedb quite unchanged, and
libgnomedb-dictionary quite the same as the current libmergeant. I
think it's better to have everything in the same library with a simple
API to use it.

I'll update the proposal document and send it again for comments.

Thanks,

Vivien