Re: [gnome-db] Re: gASQL status


¡This sounds like very good news!. 

I volunteered some days ago to help improving the user interface of the 
gnome-db frontend. I've spent sometime having a GNOME 2 enviroment and had 
just started reviewing the GNOME-DB frontend code. But I haven't started 
making any change yet and I guess it doesn't make sense any more ;-)

Vivian, If you want some help developing or improving the user interface of 
gASQL I'd like to help. Feel free to offer me something to work on. I have 
some (non-professional) knowledge of user interface design and usability, and 
I've been developing using C for serveral years. The bad part is that I don't 
have experience developing for GNOME nor GNOME 2 yet, but I'm looking forward 
to learn.


El Dom 19 May 2002 16:50, Rodrigo Moya escribió:
> Hi
> For everybody in the list, we've decided to merge gASQL into the
> gnome-db CVS module, so that gASQL will be the GNOME-DB frontend
> application, since it's better. We are going to put some of the stuff of
> gnome-db into the current gASQL sources, such as the SQL editor, and
> other things.
> This is a conversation between Vivien, current gASQL maintainer, and,
> from now on, new gnome-db maintainer, about the plans of all this.
> On Fri, 2002-05-17 at 18:29, Vivien Malerba wrote:
> > Hi!
> >
> > I've just commited the last cleanups I wanted to do. The whole thing
> > seems quite stable, and is probably a good base to start the porting.
> >
> > So, you can now get the CVS version of gASQL (just to make sure, the
> > latest revision of the query.c file is 1.26), and make a new branch in
> > Gnome-DB to start the porting.
> ok done. Although I screwed it up, since I did the import badly, and all
> the gASQL sources are now in gnome-db HEAD :-( I'm trying right now to
> clean it up, removing the front-end and some other things, and trying to
> leave it compillable.
> > Also, here is a short list of things I think are necessary to implement
> > (or finish implementing) after the porting to Gnome2:
> > - Printing
> this is a must. We need to support printing of data ASAP. One of the
> things on which we could start is on the GnomeDbGrid widget, which will
> allow to print rows of data, which should be a good starting point.
> Anybody with gnome-print experience?
> > - using the Gnome-DB grid
> As soon as I clean up the CVS mess I did, I'll start trying to make the
> current gASQL sources compile on GNOME 2 (which includes porting to the
> new libgda API also), and then, I think we can start switching the grid
> widget in gASQL.
> > - insert the SQL command window
> the widget is in libgnomedb, so I'll wait for you to come back home to
> tell me where to insert it in the gASQL code.
> > - add users and rights management
> do you agree with the simple API I proposed? With that, having a UI
> would be really simple.
> > - add creation of tables and other objects
> we should have all we need in the XML queries. Or, even better, we can
> use the new editable data models (see below).
> > - add creation and removal of databases
> I already added the create_database method on providers, so I'll just
> add a drop_database method, ok?
> > - finish the Glade dialog import
> > - implement the INSERT, UPDATE and DELETE queries as such
> > - ...
> for this, we should be using the new data models, which is the way you
> get the data from providers in libgda2 (instead of the old
> GdaRecordset). I added last week support for editing those data models
> in this way (for the data model stuff, providers implement a
> GdaDataModel-based class):
> * added a begin_edit signal, for which providers should, for instance,
> start a transaction
> * added a append_row method, so that clients can append a row to an
> existing data model. For this, providers would issue a INSERT command.
> * added a cancel_edit signal, which providers should use to ROLLBACK the
> changes done to the data model.
> * added a end_edit signal -> providers should COMMIT.
> It's missing, as you say, a remove_row method, which should make
> providers issue a DELETE command. Also, a update_row method is missing,
> which should be the equivalent of an UPDATE command.
> For uniquely identifying each row, providers store each row in a GdaRow
> structure, which can be associated a unique ID (OID in Postgres, ROWID
> in Oracle, etc), so that when clients pass back to providers that GdaRow
> to remove/modify, providers can uniquely identify it.
> All this is just started and needs some implementation on the providers,
> but it's just a matter of a couple of days' work. And, using the data
> models, we just avoid the complexity of sending specific SQL commands
> from clients to providers.
> Also, for creating tables, we could use the GdaTable class, which is
> also based in GdaDataModel and which represents a table in memory, with
> its definition and its data. We could just build a GdaTable object in
> memory, and use a:
> 	create_table (provider, GdaTable *table)
> method to be implemented for each provider. I think it is an easier
> solution than using the XML queries, which will involve creating the XML
> command, parsing it on the providers, etc.
> cheers
> _______________________________________________
> gnome-db-list mailing list
> gnome-db-list gnome org

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