Re: [gnome-db] Future characteristic

[Rodrigo Moya <rodrigo gnome-db org>]

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.

> > 
> > * 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.
> 
it's used in the gnome-database-properties application

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

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

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

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

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

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

> > 
> > * "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.
> 
yes
-- 
Rodrigo Moya <rodrigo gnome-db org>