From: Don A. <dal...@us...> - 2005-01-03 21:50:14
|
On Mon, 2005-01-03 at 20:17 +0000, Alex Roitman wrote: > > 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: > > > > - 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. > do not depend on the GUI. One do this: > $ cd src > $ PYTHONPATH=.:./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. Well, we're not fully there yet. Cleaning up some of this has been a goal in the 1.1. tree. Currently the RelLib module (which contains the core classes) imports DateHandler, which imports the Plugin module, and the Plugin module is not gtk free at this point. I've been wanting to separate this into a Plugins and a PluginsGUI module. It just cleans up the importing considerably. The database classes (GrampsBSDDB, GrampsXMLDB, and GrampsGEDDB) right now have a two functions that require GTK. These are for the handling of thumbnail images. We have to have some type of library handle this, and since we are already requiring GTK, it makes sense to use GTK to do it instead of requiring yet another package. However, this import is late binding, so it only gets imported in you attempt to use the thumbnail features. > > - other applications would be easy to write in Pythonic ways, like this > > mockup: > > > > ===================== > > from gramps import * > > family = gopen("familytree.gramps", "r") > > for person in family: # readline method > > if person.birthday() == today() and person.alive: > > email(person.email, "happy birthday!") > > ===================== > > Here: > $ cd src > $ python > >>> import GrampsBSDDB > Date parser for None not available, using default > Date displayer for None not available, using default > >>> database = GrampsBSDDB.GrampsBSDDB() > >>> database.load('/home/shura/Untitled_1.grdb',None) > 1 > >>> for person_handle in database.get_person_handles(): > ... person = 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. Alex is right. The API can do a lot of what you seem to want to do in the manner in which you want to do it. However, instead of focusing our efforts on making a generic set of libraries, we've developed a plugin infrastructure. The GIMP took the same approach. Instead of providing a bunch of libraries so you could roll your own graphics program, it provides a nice scripting interface to allow you to tie into the program. > > 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: > > > > - 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). > > > > - 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. > > > > - 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. > > > > - 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 conceptually > 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 hard > 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. I would agree with Alex here, and probably go a step further. While it might be possible to port GRAMPS to QT, TK, or wxPython, I just don't see the point. Rather than spending efforts to provide alternate toolkits, I would rather see efforts focused on improving the core program, the tools, and the reports. Providing multiple toolkit access does little to improve the program for the end user, and usually means you code the interface to the lowest common denominator, leading to an inferior program. I tend to live in a GTK/GNOME world under Linux and FreeBSD. However, it doesn't bother me that K3B is a KDE program, and I really don't see the need for the K3B project to build a GNOME interface. I'm still going to use K3B to burn CDs, and I am very pleased with it. > > 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. Yeah, it wouldn't be hard to provide a different backend here. Python has a nice interface to .ini style configuration files. At times, I've been tempted to dump the gconf stuff altogether. However, since we are a GNOME program, it has made sense for us to use it. While gconf can be a pain (in particular, having to kill the gconfd server after an installation), it does provide decent notification methods. > > 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 :-) This is where GNOME really helps us. The GNOME print/preview feature does exactly what you are asking. We also use the GNOME libraries here to access the MIME database (which is becoming the FreeDesktop MIME database, which will support KDE, GNOME, and other desktops). This is how we figure out if there is a handler for each file type. For example, is there a handler for PDF? If so, does the user want acroread, gpdf, kpdf, or xpdf? We don't want to reinvent the wheel here. > 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. This sums up my opinion as well. I'm not opposed to someone porting to a different toolkit, and we might do a little work here to help separate things out a bit. I just don't want us to loose the focus on the fact the most users don't care what the toolkit is - they want a solid program. Similarly, I have no problem with the Fink project porting GRAMPS to MacOS X or with people trying to port to GRAMPS to Windows. However, I cannot provide support to people with MacOS X or Windows specific problems. Don -- Don Allingham <dal...@us...> GRAMPS - Open Source Genealogy |