Re: [gnome-db] getting mergeant to 1.0



On Thu, 2003-09-18 at 09:41, malerba gnome-db org wrote:
> > Hi
> >
> > Now that libgda/libgnomedb 1.0 are out, apart from fixing things on
> > them, we should now concentrate on getting mergeant to a 1.0 state.
> >
> > So, since Vivien is being working on libmergeant, I have been thinking
> > on the UI.
> >
> > So, several things:
> >
> > * Vivien, is libmergeant supposed to be used by external apps, or only
> > by mergeant?
> 
> 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?

> >
> > So, I would like to discuss about several things:
> >
> > * the UI should be more document oriented, or, IMO, should just not use
> > a file at all. That is, since we use data sources, it just adds
> > confusion to have users opening a .mergeant file and then defining a
> > data source for that file. I think we should just use data sources.
> 
> 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.

> >
> > * the icon and label on the main window when no connections are open is
> > just too ugly. I think mergeant should start by asking the user to
> > connect to a data source, and just open a new window when the user has
> > established the connection.
> 
> 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.

> >
> > * there should be a clear way to open several data sources. I think we
> > could have something like galeon/epiphany, which lets you open pages
> > either in tabs or in new windows. We could have something similar.
> 
> Yes (maybe each connection in its own window to avoid user confusion).
> 
yes, I guess so.

> >
> > * we should think on including some scripting support from the
> > beginning, so that users can write their own code to manage forms,
> > reports, etc.
> 
> Forms are directly provided by the libmergeant library, so that feature
> should go into it.
> 
ok, perfect.

> >
> > I have been looking at some apps for Mac OS:
> >
> > FileMaker: http://www.filemaker.com/products/fm_home.html
> > CocoaMySQL: http://cocoamysql.sourceforge.net/
> > DBEdit: http://www.rubicode.com/Software/DBEdit/
> >
> 
> 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.

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

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

* 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

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.

cheers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]