Re: [LAF-devel] Re: Design

[Wesley J L. <wj...@ic...>]

On Sunday 10 August 2003 8:20 pm, David M. Brown wrote:
> Wesley J Landaker wrote:

> > I haven't tried any lately (which is why I suggested that we look
> > at the state of things now), but back when I tried them, most
> > geneology programs were sorely lacking.

> Ok, so my original idea for LAF was to be a PAF clone.  This
> especially goes for both ends of the software usage (GUI and file
> format, the former being most important (as long as we don't get into
> trouble)).  I wanted a PAF user to sit down and start using LAF from
> day one and not even know they were using LAF.  Sure, there are going
> to be some subtle differences, but as much as is feasibly possible
> make it a PAF look-and-feel-alike.  That was the first and foremost
> feature and all other features, as long as they don't detract from
> this first feature, would be considered.
>
> With that in mind...

I think this is a great way to do it. Not only does it mean it's easier=20
for the user, but it actually makes the developers job somewhat easier=20
as there isn't a lot of overhead investment in redesigning GUIs and so=20
forth. I think we agree pretty much here. =3D)

> >   - Be familiar to PAF users. That is, our GUI should work as much
> > like PAF as makes sense.
>
> Even a little into the "does that really make sense?" realm should be
> done.  In other words, there may be extra effort invovled (more than
> usual) to make it look like PAF so that PAF users are completely
> comfortable.

I think we agree here. My only concern would be if there was something=20
buggy/broken/lame about PAF we should fix it. I don't mean to change=20
things just for the sake of changing them, though.=20

> >   - Be *better* than PAF; be open and extendable. That is, if we
> > can do something better than PAF does it, or add new features that
> > PAF lacks, we should do it.
>
> Yes, but only to the extent that we don't take away from the PAF
> similarities.  I'll admit there are things in PAF that I would have
> done differently, but there will be some things that we'll have to
> implement that we won't like just to make it familiar to PAF users.

Again, I think we agree. What I would have it mind is that all the same=20
PAF functionality and feel would still be there, but we can enhance=20
things in the backend. While there may be some things we want to add to=20
the menus or something, I don't think the GUI would need to be very=20
different to handle things that the current PAF doesn't. For example,=20
we really ought to having full unicode support; the current PAF (last=20
time I looked at it) doesn't support this at all/very well. What if I=20
have an ancestor named =E7=94=B0=E4=B8=AD=E3=81=BE=E3=81=95=E5=AD=90? =3D)

> >>I think its important to have PAF compatibiilty. PAF is a big
> >> program with a large following. Our program should be able to AT
> >> LEAST import those files.
> >
> > I agree that importing PAF native files is important, *even if*
> > GEDCOM round-tripping is possible without data loss. However, this
> > may (or may not) require some reverse-engineering effort. We might
> > want to start off with GEDCOM support, but out file I/O subsystem
> > should be pluggable. =3D)
>
> Exactly.
>
> I'll start a list on SourceForge of the project goals as soon as I
> see a little more feedback on what we think the goals should be.=20
> Your email is a wonderful start (and is probably close to the
> finished list) for everyone to comment on.  At least we have a few
> people now on the list who can comment (more than we had before), but
> the number is small enought that I'd hope everyone would comment.

Yeah, that would be great if we can sort of "canonize" them on the SF=20
page somewhere. We can always update them as we go along if we need to,=20
but we just want to make sure that we are all trying for something in=20
common in the first place. ;)

=2D-=20
Wesley J. Landaker - wj...@ic...
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2