Re: [gnome-db]GUADEC decisions


On Wed, Apr 11, 2001 at 06:41:55PM +0200, Rodrigo Moya wrote:
> On 11 Apr 2001 12:23:19 +0200, Holger Thon wrote:
> > Hi,
> > 
> > On Mon, Apr 09, 2001 at 09:34:15PM +0200, Rodrigo Moya wrote:
> > > Hi all!
> > > 
> > > * user interface: currently, it is a crap, very confusing, and not very
> > > user-friendly. Things to do are to use wizards for configuration stuff,
> > > add keybindings, and rework some of the widgets. I would be very
> > > grateful to people suggesting UI stuff, even what would be great is to
> > > provide me with a .glade file, which is very easy to do. But well, just
> > > suggestions would also be welcomed :-)
> > 
> > I think the following things would be great
> > - Binding keys to user-definable default xml/sql queries
> yes, great idea. As soon as I realize how to use keybindings with GTK,
> I'll start adding this, and asking in the list about key sequences for
> each binding.
> > - gda-source im-/export (using xml config files or others, optinonally w/wo
> >   password)
> yes, this is what the GdaXmlDatabase object is for. It's unfinished but
> the basic framework is there, so I think we can continue working on it.
> > - Predefinable reports using the report engine
> > 
> yes, that are the templates. Or do you mean a set of templates
> distributed as part of gnome-db?

No, not yet. But that reminded me of the following: 
A kind of report wizard using e.g. gnome-druid might be a nice thing for 
gui users.

> > Perhaps, also extensions like a batching module would be great, but its
> > beyond the basic which have to be implemented first, of course. ;-)
> I've started a batch module for the database component, although I'm not
> happy yet with the UI, so I don't want to write more code until the UI
> is decided. That's why I'd like really much to have somebody sending a
> .glade file for that (and for other things) :-)
> > What i think of is a kind of scripting possibility for the frontend, which
> > allows automated issuing queries to the servers, generating reports, calling
> > external gnome/gnome-db modules through CORBA, etc. The "scripts" could be
> > stored in xml-files and possibly even distributed through CORBA-components.
> > This would make gnome-db a powerful tool. 
> > 
> yes, definitely a very good idea. I've thought myself some time ago
> about this, and I had a look at both perl and python integration
> possibilities. For both languages, integrating an interpreter in the FE
> is quite easy. The same happens, if I'm not wrong, with guile.
> So, what language(s) should we be using for scripting stuff?

I'd prefer perl as most admins are familar with it. Additionally, perl is
on every linux machine. And perl is very powerful in manipulating text data,
so it would be pretty easy to work along with resultsets returned by 
components. As there are plenty of modules available for perl, one could
do much more than just using gda-component calls.

Though, python might be more powerful on complex solutions and has more 
gnome-bindings, i've been told. As i don't know python much, i don't know 
other pros/cons for choosing between them, though.

> > > gnome-print, so that the XSLT returned by the engine can be easily
> > > accessed and used by clients.
> > 
> > I think at least ps and xml output should be implemented, so
> > the gnome-db frontend can print results of queries using the 
> > report-engine. Or is this intented for a separate report-engine?
> > 
> I think the basic printing stuff (sending a report to the printer)
> should be in libgda, since we want also non-UI clients to be able to
> print. This is not a problem, since our printing architecture
> (gnome-print) is been separated into non-UI and UI parts.

> gnome-db itself should provide UI frontends for the printing stuff
> (preview, setup, etc)

and can make use of the libgda-functions, then. :-)
> > I don't know XSLT, so i don't know how easy conversion would be, though. ;-)
> > 



Attachment: pgpRe5jOYC0Gi.pgp
Description: PGP signature

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