Re: [gnome-db] getting mergeant to 1.0

[malerba gnome-db org]

> On Thu, 2003-09-18 at 09:41, malerba gnome-db org wrote:
>> The intent of libmergeant is to move as much possible functionnalities
>> out
>> of mergeant so that other programs can be built with libmergeant. For
>> example I've built a small program with 10 forms in about 400 lines of
>> code (and most of that is for menus, etc).
>>
> ok, cool! Although, without having seen the code, of course, I wonder if
> it's a bit redundant to have libmergeant and libgnomedb. Since apps will
> use libgnomedb, what do we win in having yet-another-library?
>
> I think, if we agree on having the cache in ~/.mergeant, that we can
> have that functionality in libgnomedb. We could have a specialized
> class, called GnomeDbDictionary (or whatever), and thus avoid a new
> library to be used by apps.
>
> What do you think?

I see Libmergeant as a library sitting on top of both Libgda and
Libgnomedb. As it requires a data dictionnary to be built, it is quite
'heavy' (in the way that it requires manipulating the XML file, etc) to
use, I think it's better not to 'impose' its usage for people wanting more
direct and simple access to the DBMS using only Libgda and Libgnomedb.

Maybe we can keep everything as it is now, and see how the libraries are
being used (and decide later if we want to merge Libgnomedb ands
Libmergeant or not). What do you think?

>> Libmergeant needs to store the 'dictionnary' it has built into an XML
>> file
>> (BTW, there is one such file for each data source to be used, the data
>> source is indicated within that XML file). I think we could make a nice
>> GUI which hides that file (in a ~/.mergeant directory if you want).
>>
> yes, with the cache plan, we can have a file for each datasource in a
> hidden directory. So, when you open a data source from mergeant, it
> reads that cache file and uses it, instead of having the user open a
> file.

Yes, that's good.


>> Right, it should 'remember' which data sources have already been used
>> (by
>> looking into ~/.mergeant for a 'dictionnary' file) and also propose to
>> use
>> another data source. If there is a 'dictionnary' file for a datasource,
>> then opening the connection to the DBMS is not required.
>>
> right, doing this, we can have a way of working offline/online. That is,
> if there's the dictionary file, you can allow the user to start working
> on the data without connecting to the database, and then allow him/her
> to go online (connect to the database).
>
> I guess a very nice feature addition would be to allow the user to sync
> the changes he's done while offline, but this needs more thought, so I'd
> start by making the UI read-only when offline to start. Then, we can add
> later on the syncing code.

That could be a nice feature but it needs to be more thought of.


>>
>> There is also TORA: http://www.globecom.se/tora/
>>
> I find it too cluttered. I think it is nicer to separate the UI, and not
> display so many things at the same time.

Yes, it's a bit difficult to use it and there are some things which can't
be done. One nice feature, though, is the data export/comare one.

>
>>
>> > Things that I've liked:
>> >
>> > * In CocoaMySQL, I like the left pane, where there is a combo box to
>> > select the kind of types being displayed. I think a UI like that one
>> for
>> > each tab (each open data source) might look ok. Or, we could use the
>> > Navicat's tree-based UI
>> > (http://www.mysqlstudio.com/img/mac_detail_interface01.jpg). I prefer
>> > myself COCOA's one.
>>
>> Yes, either have advantages and drawbacks (depending on what information
>> you need at the same time on the screen). Maybe offer both possibilities
>> ?
>>
> hmm, or maybe offer the possibility to have different views of the same
> data?

Yes, that's possible.

>
>>
>> Note about Libmergeant's status: I will put it into CVS on Friday (I
>> won't
>> have the time before that).
>>
> ok, perfect. Then, if you agree, I am going to start on the new UI in
> Mergeant. For this:
>
> * I'll branch the current code in HEAD, and start working in HEAD.
>
> * Since I suppose the current code in mergeant/src is going to suffer a
> lot of changes because of the libmergeant stuff, I am going to start the
> new work in mergeant/frontend.

I think starting again from scratch will probably be best because of all
the changes, and then it can be re-architectured correctly.

>
> * Things that I'll start working are:
> 	- window management: creation of the main window, management of
> 	  several windows, one per data source
> 	- workspace management: I am going to prepare the main UI to
> 	  have a workspace separated in 2. On the left, we'll have
> 	  either the tree or the CocoaMySQL-like UI, to be decided.
> 	  On the right, the detail of the currently selected object.
> 	- detail widget: to allow a better management of the code,
> 	  I am going to create an abstract class, ObjectDetail which
> 	  will have all the needed hooks for the main window to
> 	  talk to it. Then, we'll have widgets based on this one
> 	  for tables/views, procedures, etc

Seems to be a good starting point.

>
> And I guess that's all. My urge in starting is because we've got 6
> months till the next version, and since this is a huge plan (to get
> mergeant to 1.0) we really need to start working ASAP.
>
> So, if tonight nobody has said nothing against this, I'll start.

Ok with me!

If you want to start with Libmergeant right now, I've put at
http://malerbavintner.free.fr/libmergeant an archive of what will more or
less be in the CVS.

Cheers,

Vivien