Richard Taylor wrote:
> [snip]
> I think there are two subtly different aspects to this:
>
> - firstly, where there is information about someone we are interested in
> and we just want to link to that information. Why not put the URL in
> as a repository and enter a source record against an attribute on the
> person. It seams to me that a Web site is no different to a library it is
> just another repository. We could even just be clever about parsing
> repository names and turn them into links if they look like a URL. Then
> not change would be nedded to the DB at all.
>
> - secondly, where we actually want to link two databased together accross
> the Internet. This would enable queries to run across many families if
> they happened to overlap. Web page format is not sufficient for this to
> work. The return from accross the web would have to be in a machine
> readable form (something like XML) and the access to the remote site
> would need to be a remote procesure call (something like SOAP). When we
> are working on our own database no Internet connection happens but when
> we want to do a query that could take in information from another persons
> database the Internet would be used automatically. There is of course lots
> of issues about letting user veto this, given appropriate user feedback
> etc. but that is all User Interface stuff.
>
I like this answer (setting them up as sources) even better. It should
be pretty easy to generate a hyperlink in the app that would popup the
default browser. If the link connects to a standard format file (like
GEDCOM), then we should be able to get formatted data back to display
natively.
[snip]
>
> I have had a peek at how XEmacs does it and it is horible. A better model is
> abiword. It appears there is three basic approaches to the problem:
>
> - write your own widget set and framework and make that portable accross all
> platforms. This is the Netscape (Mozilla) ways.
>
> - write an abstraction layer for the framework and use the native widgets
> where possible. This the abiword way. It does mean that you don't
> integrate well into the native environments well though.
>
> - write the data model and as much of the raw processing in a GUI
> independent way and then independantly write the GUI for each
> target platform.
>
> Personnally I prefer that third option. I like my applications to integrate
> tightly into the GUI I am using. I would like Bonobo support in GNOME, KParts
> support in KDE and OLE support in MS Windows. Sometimes this is a pain
> because the majority of the application is the GUI but for Genes I am not
> sure this is the case. I think the most work is in the Object Model, report
> engine and the database code. Most of the GUI is just dialogs and
> presentation.
>
Indeed, the third option that you mention is the one that I was hoping
to pursue. The problem is building the abstraction layer. For this
project, I anticipate that quite a bit of the processing could be
decoupled from the data display.
Here's a wild thought... Since both a monitor and a printer are simply
output devices, what if we build this abstraction layer to be able to
handle either output device with the same function calls from our data
processing routines? The functions that display data to the screen
would be defined as well to display data on a printer, but the functions
to retrieve data would not be implemented for the printer. Since users
are expecting rich output on both the display and the printer, this
would enable us to draw whatever widgets we need for either device.
--
Sean Lamb --- [EMAIL PROTECTED] Software Engineer
while( ) { s/$badcode/$goodcode/g; }
"A day without laughter is a day wasted." -- Groucho Marx
_______________________________________________
Genes-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/genes-devel
