From: Alex R. <sh...@al...> - 2005-01-03 20:17:51
|
Doug, I have received two emails which seem almost identical, but I'm responding to the latest -- it has a little more bytes :-) Short disclaimers: (1) below is my personal opinion, and (2) code examples refer to the unstable tree -- a move to database was a big enough change so that lots of other changes went in at the same time. On 01/03/2005 12:10:26 PM, Douglas S. Blank wrote: >=20 > I've spent the last day poring over the latest code from CVS, trying to > acclimate to gtk and gramps. I've worked on large-ish Python projects > before, and would like to help develop a genealogy project. I very much > appreciate all of the work that has brought Gramps to this point. I also > have some suggestions. I read the FAQ, where it very politely suggests > that one might want to start their own project, and I can appreciate > that suggestion :) Correction -- only if the developers are not convinced after few emails :-) > 1. I think that the gtk code and all of the GUI specifics should be > separated from the main genealogy functions. If the main functions were > available as a library, then: >=20 > - report writing would be much simplified, because it would use the same > code as the rest of the project. Ages (for example) would be computed in > exactly one way. The separation is there for the most part. The core modules: RelLib, GrampsDbBase, GrampsBSDDB, Date, BaseDoc, GenericFilter, etc.=20 do not depend on the GUI. One do this: $ cd src $ PYTHONPATH=3D.:./plugins:$PYTHONPATH python >>> import RelLib >>> import Date >>> import GrampsBSDDB >>> import ArgHandler without any problem. I only added ./plugins to the path so that any plugins can also be imported: >>> import TimeLine although most of the plugins do involve GUI code as well. > - other applications would be easy to write in Pythonic ways, like this > mockup: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > from gramps import * > family =3D gopen("familytree.gramps", "r") > for person in family: # readline method > if person.birthday() =3D=3D today() and person.alive: > email(person.email, "happy birthday!") > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here: $ cd src $ python >>> import GrampsBSDDB Date parser for None not available, using default Date displayer for None not available, using default >>> database =3D GrampsBSDDB.GrampsBSDDB() >>> database.load('/home/shura/Untitled_1.grdb',None) 1 >>> for person_handle in database.get_person_handles(): ... person =3D database.get_person_from_handle(person_handle) ... print person.get_gramps_id() ... I30 I16 I25 [snip] So with the knowledge of the API it is not all that hard. You can easily get relatives, fmaily members, dates of events, etc. For details, on e.g. Person class, see http://gramps.sourceforge.net/api/public/RelLib.Person-class.html > - we would then be making a tool for people to use, rather than a > monolithic application that must do it all. Sure, and the plugin architecture should be a good way of getting there. > 2. Relatedly, gtk shouldn't be the only interface available. I've used > Linux since the beginning, and I had a hard time getting all the pieces > in place for Gramps to work right. If the GUI were separate from the > main code, it would be trivial to: >=20 > - have a console interface, or at least a curses interface. Most of the > information we deal with is text. Why not have a simple interface that > is fast with no additional requirements, beyond Python? (Python has a > natice ncurses library). >=20 > - have a Tk interface. Tkinter could do a good job, and all of those > Windows users could take advantage of our hard work. I only use Linux, > but I'd like my parents and other family members to share our genealogy > information. This would be easy to have running on other OS's. >=20 > - if others wanted to work on .Net, wxPython, Commadore64, PalmOS, etc. > their work could be a part of the Gramps project. It would develop in > parallel next to the core code. >=20 > - those interested in the latest and greatest gtk/gnome accessories > could continue working on it, independent of the core code. This evokes mixed feelings for me. On the one hand, it would be conceptuall= y right to have GUI completely separate from the other code. On the other hand, most of the gramps' code is interface related. The genealogical operations are trivial (find ancestors, descendants, relatives, etc). The h= ard parts are (1) think up and implement a sparse, intuitive, and powerfull interface to enter and manipulate the data; (2) import/export, and (3) producing human-readable reports (i.e. back to the interface in some sense). As for the portability to all the other beatiful toolkits -- I'm all for it= , but at the moment our hands are pretty full with one of them :-) Not to discourage people, but until somebody actually starts up on porting gramps to Qt, Tk, wxPython, etc, it's not likely to happen. There's so much stuff we're behind on, and adding the effort of porting to and maintaining a couple of more toolkits is not something I am personally looking forward to. I would not work against somebody doing that, by all means, but except for refactoring the code I'm not sure I'd be able to help a lot. > 3. All of the information keys stored via gtk/gnome functions can easily > be stored in .ini files (Python can read/write those easily). A move from gconf to whatever other storage could be done with rewriting a single GrampsGconfKeys module. All other parts are using this module to access/store config data. Naturally, the gnome version uses gconf, but other ports can use whatever they're comfortable with. > 4. These issues shouldn't effect moving to a database (which is a great > idea!) In fact, these moves would be more moves to a modular system. The underlying database is already format-independent, see the unstable tree (CVS HEAD). > 5. Reports should have a way of producing viewable data immediately, > without naming a file, then executing a file to see it. This could > simply be shelling out to a viewer (ggv, mozilla, acroread, etc) or it > might involve viwing text, or using native Python drawing code (Tkinter, > gtk, wxPython, etc). I'm not sure naming a file is such a huge task. Use "Print..." format and the filename becomes irrelevant. OK, ok, we may disable filename selection in that case, I know :-))) Then you get gnomeprint Print/Preview dialog. Apart from that -- how can we lay out the report if the paper details are not available to us? What if there's no viewer for a particular format? These are all good questions, but, ironically, making all the choices on the user's part is more in line with gnome philosophy :-) A summary of my opinion: 1. Separation is good, and for the most part it is there (although not complete). 2. Should somebody decide to work on another toolkit, we may work out how to help this by further refactoring the code. 3. Our manpower is small, so cnotributing to another toolkit port would probably be too much. So, if somebody (you?) is serious about either a particular port or a general portable version of gramps, and is willing to put the code whether his mouth is, probably a fork would work out the best. Nobody says that we cannot merge at some point, and nobody says that we should ignore each other. I would think we would cooperate on UI-independent issues and borrow from each other on UI-related ones. But I just don't see us porting and maintaining the port right now :-) Just MHO. Thanks for bringing this up! Let's see if there're other opinions. Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |