Re: [gnome-db] Future characteristic

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2004-10-05 at 09:45 +0200, Vivien Malerba wrote:
> On Mon, 04 Oct 2004 16:48:55 +0200, Rodrigo Moya <rodrigo gnome-db org> wrote:
> > On Mon, 2004-10-04 at 09:54 +0200, Vivien Malerba wrote:
> > > On Sun, 03 Oct 2004 22:43:58 -0500, Daniel Espinosa Ortiz
> > > <esodan yahoo com mx> wrote:
> > > > I think we will need Widgets to manage a Fields, may useful when you
> > > > create a gnome_db_form.
> > > >
> > > > The you have gnome_db_text, gnome_db_date, and one for any GdaValue type
> > > > exist. this Widget may have an associated Label, and some methods.
> > >
> > > I've already created such a class, but for libmergeant (can't be used
> > > as-is for libgnomedb because it requires the data dictionnary
> > > libmergeant maintains). If you want to have a look, the classes are
> > > MgDataEntry (the actual base class for widget to be found in a form)
> > > and MgDataHandler (a base non widget class to convert between SQL,
> > > user and GdaValue some values).
> > > 
> > it looks to me much better to have a single class than a
> > GnomeDbDate/Int/Float, etc. Is that how it works in Mergeant?
> 
> Data handling in libmergeant is done using two different type of
> classes: the ones used to convert data representations between SQL
> strings and GdaValue structures (and human readable strings), and the
> ones which are GtkWidget and are data entry widgets (where the user
> can enter and modify data).
> 
> The first type of classes must implement the MgDataHandler interface
> (which are mostly the operations to make the data conversions), and
> the second type of classes must implement the MgDataEntry interface
> (with operations related to setting and getting values in the widget).
> 
> Libmergeant has some built-in actual classes which implement these
> interfaces (for all the most common data types: strings or text,
> numbers, booleans, dates), and some more can be created as plug-ins (a
> few exists like an entry for encripted password for example).
> 
> The programmer can then ask for a MgDataHandler or a new MgDataEntry
> to handle specified data types (being libgda's data types, or DBMS
> specific data types); the object responsible for finding or created
> the requested actual object instance which implement the MgDataHandler
> or MgDataEntry interfaces is the MgServer object, which saves its
> state in the dictionnary (an XML file).
> 
> Building a form is then as simple as asking for MgDataEntry widgets
> and packing them correctly. To ease that job, libmergeant has a
> specific widget: a MgForm.
> 
> Please have a look at the libmergeant's documentation in mergeant's
> doc/ (gtk-doc, available in devhelp as well).
> 
> > 
> > > If we want one day to make libmergeant and libgnomedb closer, then I
> > > think we should have a kind of framework for form entry widgets in
> > > libgnomedb which libmergeant will improve on (I say "improve" because
> > > it has a finer view of the data types, etc because of the data
> > > dictionnary it maintains).
> > > 
> > as we talked some time ago, libmergeant and libgnomedb should probably
> > be merged at some point in future. The current widgets-only approach of
> > libgnomedd makes it quite unattractive for many people, who prefer to
> > just use normal GTK widget bound to libgda data. So, I think we should
> > try to have libgnomedb/libmergeant be an extension to GTK, so that
> > people can continue using any kind of GTK widget with access to the rich
> > libgmergeant dictionary. That would make libgnomedb/libmergeant a much
> > more attractive library to use.
> 
> I've tried to do this in libmergeant whenever possible. The idea is
> that the developper can 'pilot' the GUI through the data and not
> through the widgets once the GUI definition is done.
> 
right, yet another reason to have all this replacing the current
libgnomedb library, which should only re-use GTK widgets and provide a
few DB-specific widgets (login, browser, etc)
-- 
Rodrigo Moya <rodrigo gnome-db org>