From: Luke-Jr <lu...@da...> - 2005-02-27 22:34:27
|
What has changed for the better in the 1.1 branch? From what I can tell, it has the ability to edit certain objects in more detail (like names), but that shouldn't be too difficult to backport... What was the reason behind abandoning a nice XML format? I see that 1.1 will still give me the option to save as GRAMPS XML, but the output is not actually XML, but gzipped XML (which is much less diff-friendly). The old option to not gzip the file is gone. :( Is the 1.0 branch still in development? |
From: Alex R. <sh...@al...> - 2005-02-27 22:42:01
|
On 02/27/2005 04:35:55 PM, Luke-Jr wrote: > What has changed for the better in the 1.1 branch? From what I can tell, = it=20 > has the ability to edit certain objects in more detail (like names), but = that=20 > shouldn't be too difficult to backport... See NEWS file in the top level dir. Mainly, it's a database backend and a lot of efficiency/performance improvements on large databases. > What was the reason behind abandoning a nice XML format? The performance limitations on large databases. For databases under few thousand people the XML is OK, but over 10K it is unusable, at least with the common memory sizes these days. > I see that 1.1 will=20 > still give me the option to save as GRAMPS XML, but the output is not=20 > actually XML, but gzipped XML (which is much less diff-friendly). The old= =20 > option to not gzip the file is gone. :( I guess we can put this back in. For now you may just tweak src/WriteXML.py. > Is the 1.0 branch still in development? The 1.0.x branch is going to be obsoleted soon, once the stable 2.0.0 is released. 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 |
From: Luke-Jr <lu...@da...> - 2005-02-27 23:01:36
|
On Sunday 27 February 2005 22:41, Alex Roitman wrote: > On 02/27/2005 04:35:55 PM, Luke-Jr wrote: > > What has changed for the better in the 1.1 branch? From what I can tell, > > it has the ability to edit certain objects in more detail (like names), > > but that shouldn't be too difficult to backport... > > See NEWS file in the top level dir. Mainly, it's a database backend > and a lot of efficiency/performance improvements on large databases. In regards to the elimination of alphabetical tabs... is it possible to enable them with 1.1? One long list makes it harder to locate people by name. > > > What was the reason behind abandoning a nice XML format? > > The performance limitations on large databases. For databases under > few thousand people the XML is OK, but over 10K it is unusable, > at least with the common memory sizes these days. I don't know much about Berkley dbs... is it likely that it may become possible to have a single GRAMPS server with many clients accessing it at once? Would version control/history be very complex? |
From: Alex R. <sh...@al...> - 2005-02-27 23:16:11
|
On 02/27/2005 05:03:04 PM, Luke-Jr wrote: >=20 > In regards to the elimination of alphabetical tabs... is it possible to e= nable=20 > them with 1.1? One long list makes it harder to locate people by name. Start typing in the people view and you will jump through the right person. Future plans include the ability of splitting the People view in two halves. That way you can e.g. compare Zimmerman and Tsimermann without having to scroll back and forth or having to switch tabs. > I don't know much about Berkley dbs... is it likely that it may become=20 > possible to have a single GRAMPS server with many clients accessing it at= =20 > once? Would version control/history be very complex? I am not sure this will work well with BSD DB, but at this moment the data acces in GRAMPS is abstracted enough so that other database backends are possible. From time to time we get requests to have a MySQL/Postgres backend with server and clients accessing it through the web. This is not impossible, so if somebody has an interest in doing it, please come forward :-) That said, both Don and I on numerous occasions expressed in no uncertain terms that such a thing is not in our immediate focus :-))) We see gramps as the personal program first and foremost, not the database-driven server-oriented client-accessible app :-) While everybody is entitled to their own opinion and interests, this does not mean that we have to necessarily implement everybody's wishes, sorry. As for the version control, my best bet will still be on exporting to uncompressed XML and keeping it under CVS on my own. I hate reinventing the wheel, and trying to figure out version control under binary and arch-dependent format would be just that. The XML is a good format. It's just not too effective, that's all. There's nothing wrong with saving XML every so often, and using it for backup. There's no information loss involved. It's just like a backup procedure when your database is huge: slow, but prudent. 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 |
From: Don A. <don...@co...> - 2005-02-27 23:20:46
|
On Sun, 2005-02-27 at 23:03 +0000, Luke-Jr wrote: >On Sunday 27 February 2005 22:41, Alex Roitman wrote: >> On 02/27/2005 04:35:55 PM, Luke-Jr wrote: >> > What has changed for the better in the 1.1 branch? From what I can tell, >> > it has the ability to edit certain objects in more detail (like names), >> > but that shouldn't be too difficult to backport... >> >> See NEWS file in the top level dir. Mainly, it's a database backend >> and a lot of efficiency/performance improvements on large databases. > >In regards to the elimination of alphabetical tabs... is it possible to enable >them with 1.1? One long list makes it harder to locate people by name. The alphabetical tabs produced several major problems. You can multiple selections on different tabs, and there is no way of knowing which of the selected items on each pages the user intended on selecting. While it might seem convenient, it introduces several major problems. Fortunately, the lists scroll quickly, and you can use the new interactive "search" feature (Ctrl-F). > >> >> > What was the reason behind abandoning a nice XML format? >> >> The performance limitations on large databases. For databases under >> few thousand people the XML is OK, but over 10K it is unusable, >> at least with the common memory sizes these days. > >I don't know much about Berkley dbs... is it likely that it may become >possible to have a single GRAMPS server with many clients accessing it at >once? Would version control/history be very complex? > This is a possibility, however, the Berkeley DB may not be the best for this. The advantage of the Berkeley DB is that it is standard with python, so easy for the average user to use. We have tried to make the backend fairly modular, which should allow for a database like mySQL to be integrated in. While this isn't for the average user, if you are looking for multi-user access with versioning, you aren't the average user. Don |
From: Luke-Jr <lu...@da...> - 2005-02-28 00:24:33
|
On Sunday 27 February 2005 23:21, you wrote: > On Sun, 2005-02-27 at 23:03 +0000, Luke-Jr wrote: > >On Sunday 27 February 2005 22:41, Alex Roitman wrote: > >> On 02/27/2005 04:35:55 PM, Luke-Jr wrote: > >> > What has changed for the better in the 1.1 branch? From what I can > >> > tell, it has the ability to edit certain objects in more detail (like > >> > names), but that shouldn't be too difficult to backport... > >> > >> See NEWS file in the top level dir. Mainly, it's a database backend > >> and a lot of efficiency/performance improvements on large databases. > > > >In regards to the elimination of alphabetical tabs... is it possible to > > enable them with 1.1? One long list makes it harder to locate people by > > name. > > The alphabetical tabs produced several major problems. You can multiple > selections on different tabs, and there is no way of knowing which of > the selected items on each pages the user intended on selecting. So a proper solution would be an alternate widget that makes it appear to be a single list in code, but..... > While it might seem convenient, it introduces several major problems. > Fortunately, the lists scroll quickly, and you can use the new > interactive "search" feature (Ctrl-F). it's not worth the trouble to do so. :) > >> > What was the reason behind abandoning a nice XML format? > >> > >> The performance limitations on large databases. For databases under > >> few thousand people the XML is OK, but over 10K it is unusable, > >> at least with the common memory sizes these days. > > > >I don't know much about Berkley dbs... is it likely that it may become > >possible to have a single GRAMPS server with many clients accessing it at > >once? Would version control/history be very complex? > > This is a possibility, however, the Berkeley DB may not be the best for > this. The advantage of the Berkeley DB is that it is standard with > python, so easy for the average user to use. So basically, the user doesn't need to know how to configure it... in the end, usage would be the same. I wonder if multiple GRAMPS instances could 'load' the same database cleanly? Then, add loading it over SSH and multiuser would work. > > We have tried to make the backend fairly modular, Too bad the GUI isn't very modular to allow for ports to Qt/KDE, Windows, and/or OS X. > which should allow for a database like mySQL to be integrated in. While this > isn't for the average user, if you are looking for multi-user access with > versioning, you aren't the average user. I don't see why that would be so unusual a usage... If PersonX from FamilyA is interested in genealogy, chances are PersonY from FamilyA and PersonZ from FamilyA are also. Why should they have separate databases instead of sharing one? |
From: Douglas S. B. <db...@br...> - 2005-02-28 02:54:14
|
Alex Roitman <sh...@al...> said: [snip] > > Too bad the GUI isn't very modular to allow for ports to Qt/KDE, Windows, > > and/or OS X. > > You may want to touch base with the gramps-tk project, see > http://emergent.brynmawr.edu/index.cgi/Gramps_2dtk > > We've been through this many times. There's never a shortage of suggestions > of porting things to one or another interface, and it rarely gets past > the talking stage. The gramps-tk got farther than most, but I don't think > it has been very active lately. > > My opinion on this is that most of the code in GRAMPS is the interface. > It's largely meaningless to abstract interface from itself. The genealogy- > specific code is modular, and fairly trivial. Whoever wants to "port" > gramps to another interface is really facing the task of writing it. > There's not much to port. Alex is correct: most of the code in GRAMPS is in the interface. But I hope for GRAMPS-tk that that will not be the case. The GRAMPS-tk project is aimed at getting a minimal interface in place that can at least do all of the edits and additions to every attribute the full database. It uses all of the latest GRAMPS database backend code, and none of the GRAMPS gui code. I'm hopeful on the prospect of using the reports infrastructure. BTW, I've been working on a network connection to interface with a GRAMPS database (whatever kind you want). The idea is that when you are selecting a database to open, you point it to a URL. GRAMPS (or GRAMPS-tk) will run in a server mode listening on that address/port. When the connection is made, the GRAMPS server passes the data to the GRAMPS client, like a browser. I don't think it will be too difficult to complete (easier than it was separating the GUI from DB). [snip] > Oh, they would be interested. The question is whether we can help them there. > It takes a very computer literate person to set up a database server > acepting input from clients. For once, I'm not such a person. I guess > I could read the docs and figure it, but it would be a whole new story, > and I'd rather focus on a traditional desktop app. I think it could be as easy as: gramps --database FamilyTree.grdb --server --port 8900 Password: ****** GRAMPS is serving data on port 8900 connection made from 10.0.0.34 Even Aunt Sally could do that :) -Doug |
From: Luke-Jr <lu...@da...> - 2005-02-28 03:05:55
|
On Monday 28 February 2005 02:53, Douglas S. Blank wrote: > Alex Roitman <sh...@al...> said: > > BTW, I've been working on a network connection to interface with a GRAMPS > database (whatever kind you want). The idea is that when you are selecting > a database to open, you point it to a URL. GRAMPS (or GRAMPS-tk) will run > in a server mode listening on that address/port. When the connection is > made, the GRAMPS server passes the data to the GRAMPS client, like a > browser. I don't think it will be too difficult to complete (easier than it > was separating the GUI from DB). I'd be interested in testing or helping with this... Sounds almost exactly like what I was suggesting. Any ideas for the protocol yet? > > Oh, they would be interested. The question is whether we can help them > > there. It takes a very computer literate person to set up a database > > server acepting input from clients. For once, I'm not such a person. I > > guess I could read the docs and figure it, but it would be a whole new > > story, and I'd rather focus on a traditional desktop app. > > I think it could be as easy as: > > gramps --database FamilyTree.grdb --server --port 8900 > Password: ****** > GRAMPS is serving data on port 8900 > connection made from 10.0.0.34 > > Even Aunt Sally could do that :) Right now, I just host a Genealogy.vnc file that Windoze-users download and click on. It opens in TightVNC to a login screen. Once they login, it gives them the CVS options (update, revert, commit) and a GRAMPS button. I'm sure it wouldn't be very hard to support loading a commandline from an INI file or similar... |
From: Alex R. <sh...@al...> - 2005-02-28 03:09:25
|
On Mon, Feb 28, 2005 at 02:53:30AM -0000, Douglas S. Blank wrote: >=20 > Alex is correct: most of the code in GRAMPS is in the interface. But I ho= pe > for GRAMPS-tk that that will not be the case. The GRAMPS-tk project is ai= med > at getting a minimal interface in place that can at least do all of the e= dits > and additions to every attribute the full database. It uses all of the la= test > GRAMPS database backend code, and none of the GRAMPS gui code. I'm hopefu= l on > the prospect of using the reports infrastructure. The present Report.py is heavily interface-oriented. However, there's already a command-line report building ineterface that works, so re-using that part should be a reasonable effort. > I think it could be as easy as: >=20 > gramps --database FamilyTree.grdb --server --port 8900 > Password: ****** > GRAMPS is serving data on port 8900 > connection made from 10.0.0.34 >=20 > Even Aunt Sally could do that :)=20 I suppose :-) 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 |
From: Alex R. <sh...@al...> - 2005-02-28 01:04:43
|
On Mon, Feb 28, 2005 at 12:25:58AM +0000, Luke-Jr wrote: > > > > The alphabetical tabs produced several major problems. You can multiple > > selections on different tabs, and there is no way of knowing which of > > the selected items on each pages the user intended on selecting. >=20 > So a proper solution would be an alternate widget that makes it appear to= be a=20 > single list in code, but..... Actually, that's planned too: something like a set of buttons with letters such that clicking a button "B" will scroll you to the first tree node starting with B, and so on. I strongly want the buttons, though, and not the tabs, since the idea of multiple tabs is just not working, however appealing it might be on the casual glance. > > Fortunately, the lists scroll quickly, and you can use the new > > interactive "search" feature (Ctrl-F). >=20 > it's not worth the trouble to do so. :) Sure, just skip the Ctrl+F portion and type H -- you're at the first H node :-) Nothing can beat this, if you ask me. > I wonder if multiple GRAMPS instances could 'load' the same database clea= nly?=20 > Then, add loading it over SSH and multiuser would work. Nope, you can't cleanly load the same Berkely db twice, I don't think so. > Too bad the GUI isn't very modular to allow for ports to Qt/KDE, Windows,= =20 > and/or OS X. You may want to touch base with the gramps-tk project, see http://emergent.brynmawr.edu/index.cgi/Gramps_2dtk We've been through this many times. There's never a shortage of suggestions of porting things to one or another interface, and it rarely gets past the talking stage. The gramps-tk got farther than most, but I don't think it has been very active lately.=20 My opinion on this is that most of the code in GRAMPS is the interface. It's largely meaningless to abstract interface from itself. The genealogy- specific code is modular, and fairly trivial. Whoever wants to "port" gramps to another interface is really facing the task of writing it. There's not much to port. > > which should allow for a database like mySQL to be integrated in. While= this > > isn't for the average user, if you are looking for multi-user access wi= th > > versioning, you aren't the average user. >=20 > I don't see why that would be so unusual a usage... If PersonX from Famil= yA is=20 > interested in genealogy, chances are PersonY from FamilyA and PersonZ fro= m=20 > FamilyA are also. Why should they have separate databases instead of shar= ing=20 > one? Oh, they would be interested. The question is whether we can help them ther= e. It takes a very computer literate person to set up a database server acepting input from clients. For once, I'm not such a person. I guess I could read the docs and figure it, but it would be a whole new story, and I'd rather focus on a traditional desktop app. But, having said all that, by all means, if somebody comes forward and writes MySQL backend we would be very forthcoming. It would be a good start, let's see it happen. 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 |
From: Luke-Jr <lu...@da...> - 2005-02-28 01:57:51
|
On Monday 28 February 2005 01:04, Alex Roitman wrote: > > I wonder if multiple GRAMPS instances could 'load' the same database > > cleanly? Then, add loading it over SSH and multiuser would work. > > Nope, you can't cleanly load the same Berkely db twice, I don't think so. I was (incorrectly?) thinking that the berkely db was being used to do everything on disk instead of in memory, in which case something like this might work... If the database is actually *loaded* into memory, the argument for its usage seems to disappear, since it would be possible to dump the same memory to XML... > > Too bad the GUI isn't very modular to allow for ports to Qt/KDE, Windows, > > and/or OS X. > > You may want to touch base with the gramps-tk project, see > http://emergent.brynmawr.edu/index.cgi/Gramps_2dtk Why are they a separate project? > We've been through this many times. There's never a shortage of suggestions > of porting things to one or another interface, and it rarely gets past > the talking stage. Just grepping for gtk in the GRAMPS sources suggests that it is not designed to be ported without much effort. If all the GTK stuff was restricted to a GrampsGtk module or such, I think such efforts would probably get much futher, if not complete. > The gramps-tk got farther than most, but I don't think it has been very > active lately. It certainly doesn't run anymore... though if it had been part of the main CVS (as a branch?), it would likely have picked up changes. > My opinion on this is that most of the code in GRAMPS is the interface. > It's largely meaningless to abstract interface from itself. The genealogy- > specific code is modular, and fairly trivial. Whoever wants to "port" > gramps to another interface is really facing the task of writing it. > There's not much to port. It's not the interface that should be abstracted, but the toolkit. The same interface could work fine with most toolkits. > > > which should allow for a database like mySQL to be integrated in. While > > > this isn't for the average user, if you are looking for multi-user > > > access with versioning, you aren't the average user. > > > > I don't see why that would be so unusual a usage... If PersonX from > > FamilyA is interested in genealogy, chances are PersonY from FamilyA and > > PersonZ from FamilyA are also. Why should they have separate databases > > instead of sharing one? > > Oh, they would be interested. The question is whether we can help them > there. It takes a very computer literate person to set up a database server > acepting input from clients. It doesn't need to. It would involve mainly two steps: 1) keeping the database code separate from the interface code (which is likely already done), and 2) converting the Python API to a network API/protocol. > For once, I'm not such a person. I guess I could read the docs and figure > it, but it would be a whole new story, and I'd rather focus on a traditional > desktop app. I wonder if there's any automated way of doing this... it's theoretically possible to automate it at some point in the Python interpretation, though it might be a bit slow if done this way. Basically, the client could simply have a wrapper for the database accessing module. The server would do the opposite, and load the real database module to interface with API calls from clients. > But, having said all that, by all means, if somebody comes forward and > writes MySQL backend we would be very forthcoming. It would be a good > start, let's see it happen. MySQL might (or might not o.o) be the best way to do this, but it is certainly not the *only* way. |
From: Alex R. <sh...@al...> - 2005-02-28 02:26:23
|
On Mon, Feb 28, 2005 at 01:59:18AM +0000, Luke-Jr wrote: > > > > Nope, you can't cleanly load the same Berkely db twice, I don't think s= o. >=20 > I was (incorrectly?) thinking that the berkely db was being used to do=20 > everything on disk instead of in memory, in which case something like thi= s=20 > might work... I might be wrong. I think there might be some caching issues preventing this, but I'm not really sure. The present gramps interface though is not equipped to deal with data changes occurring outside its own instance. E.g. if you add a person to the database that I have opened, my instance of gramps would not know that it needs to redraw people view. > If the database is actually *loaded* into memory, the argument for its us= age=20 > seems to disappear, since it would be possible to dump the same memory to= =20 > XML... No, in 1.1.x the database is not loaded into memory :-) Great pains were taken to get rid of "data in memory" state of things. > > You may want to touch base with the gramps-tk project, see > > http://emergent.brynmawr.edu/index.cgi/Gramps_2dtk >=20 > Why are they a separate project? Because they proposed to do what we did not feel like doing. The consensus was that the fork will work out the best. > Just grepping for gtk in the GRAMPS sources suggests that it is not desig= ned=20 > to be ported without much effort. If all the GTK stuff was restricted to = a=20 > GrampsGtk module or such, I think such efforts would probably get much=20 > futher, if not complete. [snip] > It's not the interface that should be abstracted, but the toolkit. The sa= me=20 > interface could work fine with most toolkits. I would challenge this statement. But even if it were possible, the amount of code to replace would be about 99%. Look at any of the editor's modules: EditPerson, EventEdit, etc. They all consist of 99% interface code. Replacing every line with the toolkit-independend line will lead to a massive duplication. I am not saying that this could not or should not be done. I won't be the one doing it, that's all -- because I don't see good enough reasons and lack motivation. I think if somebody with such inclinations would put their money (code, actually) where their mouth is then it would get somewhere. Otherwise, there's little reason to bother setting up a CVS branch or tweak main trunk code, just to pat somebody's ideas. That's how I see it, personally. > > Oh, they would be interested. The question is whether we can help them > > there. It takes a very computer literate person to set up a database se= rver > > acepting input from clients. >=20 > It doesn't need to. It would involve mainly two steps: 1) keeping the dat= abase=20 > code separate from the interface code (which is likely already done), and= 2)=20 > converting the Python API to a network API/protocol. The (1) is already done. The GrampsBSDDB.py and other backends are complete= ly interface free. The (2) must be done by somebody with interest. Let's wait for the volunteer to start on it :-) > I wonder if there's any automated way of doing this... it's theoretically= =20 > possible to automate it at some point in the Python interpretation, thoug= h it=20 > might be a bit slow if done this way. > Basically, the client could simply have a wrapper for the database access= ing=20 > module. The server would do the opposite, and load the real database modu= le=20 > to interface with API calls from clients. [snip] > MySQL might (or might not o.o) be the best way to do this, but it is cert= ainly=20 > not the *only* way.=20 Sorry, I simply have no opinion on this -- not a database person :-) 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 |
From: Eero T. <eer...@ne...> - 2005-02-28 19:03:17
|
Hi, > > > Too bad the GUI isn't very modular to allow for ports to Qt/KDE, > > > Windows, and/or OS X. > > > > You may want to touch base with the gramps-tk project, see > > http://emergent.brynmawr.edu/index.cgi/Gramps_2dtk > > Why are they a separate project? Just see the mailing list archives. There was quite a lot mails about this and what things in Gramps are Gnome dependent (it's *not* just toolkit). See for example the "Suggestions" thread last month. - Eero |
From: Luke-Jr <lu...@da...> - 2005-02-28 03:00:51
|
On Monday 28 February 2005 02:26, Alex Roitman wrote: > On Mon, Feb 28, 2005 at 01:59:18AM +0000, Luke-Jr wrote: > > If the database is actually *loaded* into memory, the argument for its > > usage seems to disappear, since it would be possible to dump the same > > memory to XML... > > No, in 1.1.x the database is not loaded into memory :-) Great pains were > taken to get rid of "data in memory" state of things. Is it possible to use the berkely db only as a working space (a file in /tmp) and have Load/Save interface with the XML? > > > You may want to touch base with the gramps-tk project, see > > > http://emergent.brynmawr.edu/index.cgi/Gramps_2dtk > > > > Why are they a separate project? > > Because they proposed to do what we did not feel like doing. So if you don't feel like doing it, it is not a welcome feature? > > Just grepping for gtk in the GRAMPS sources suggests that it is not > > designed to be ported without much effort. If all the GTK stuff was > > restricted to a GrampsGtk module or such, I think such efforts would > > probably get much futher, if not complete. > [snip] > > It's not the interface that should be abstracted, but the toolkit. The > > same interface could work fine with most toolkits. > > I would challenge this statement. But even if it were possible, the amount > of code to replace would be about 99%. Look at any of the editor's modules: > EditPerson, EventEdit, etc. I did. I'm even more confident that it's possible by changing less than 1% of the lines. > They all consist of 99% interface code. But not 99% of toolkit-specific code. > Replacing every line with the toolkit-independend line will lead to a > massive duplication. Have you thought of this? A module that implements the GTK calls made in GRAMPS, then just change gtk.* to const.toolkit.* or similar. > I am not saying that this could not or should not be done. I won't be the > one doing it, that's all -- because I don't see good enough reasons > and lack motivation. I think if somebody with such inclinations would > put their money (code, actually) where their mouth is then it would get > somewhere. I might consider it, though it's not very likely since 1) I don't know Python, 2) I translate GTK API calls to Qt later on at the C-library level anyway, and 3) I don't know Windows APIs... ^^; > > MySQL might (or might not o.o) be the best way to do this, but it is > > certainly not the *only* way. > > Sorry, I simply have no opinion on this -- not a database person :-) Neither am I, hence the idea to make some new protocol ;) |
From: Luke-Jr <lu...@da...> - 2005-02-28 05:52:55
|
On Monday 28 February 2005 03:28, you wrote: > On Mon, Feb 28, 2005 at 03:02:19AM +0000, Luke-Jr wrote: > > Is it possible to use the berkely db only as a working space (a file in > > /tmp) and have Load/Save interface with the XML? > > Sure -- place your grdb file in /tmp, import your data from XML when you > start and export into XML when you finish your session :-) I meant in a way that it was invisible to the users. Most people aren't going to see why they need to use Import/Export at all. > > > > Why are they a separate project? > > > > > > Because they proposed to do what we did not feel like doing. > > > > So if you don't feel like doing it, it is not a welcome feature? > > If from the project manager's point of view it's not a useful feature > for the majority of the users Other toolkits would be useful for the new users who need it, which may be a large percentage of resulting total users. > and if it requires lots of change in the code then yes, I would say it > warrants not accepting it into the CVS. The purpose of CVS is to manage changes to code. Even if the change was too large to make it into HEAD, it could still be a branch without interfering with the rest of the project. > > Have you thought of this? A module that implements the GTK calls made in > > GRAMPS, then just change gtk.* to const.toolkit.* or similar. > > Yes, Doug has proposed this some time ago, and we rejected this idea. > Our reasoning was that it brings some maintanence burden with it > and that it should not be carried by gramps, until we believe that > this change is for the best of gramps and its existing users. This is a looping effect. If the existing users needed such features, they would not qualify as users in the first place. Once such features are added, however, the user base increases to include those who find it useful. > Why is it so important that gramps satisfies everybody's wishes? It isn't, but the number of people who would be able to make use of ports is significant. > The code is free, the CVS is publicly available with just a few hours > delay, and it's easy to automatically draw from it and to pick up all the > changes. But without their changes being included in the CVS tree, such changes will be more likely to break when the main code changes. > If somebody comes tomorrow and wants to have the whole thing redone in C++, > would we be expected to do that too? Or at least provide a > language-independent project? :-) Of course not. That is not even a decent analogy. If someone rewrote the whole program in C++, would it be refused from the official project? > > I might consider it, though it's not very likely since 1) I don't know > > Python, 2) I translate GTK API calls to Qt later on at the C-library > > level anyway, and 3) I don't know Windows APIs... ^^; > > OK, so even if the interface were toolkit-independent, you would not be > doing the Qt port. Then what's the problem? No problem for me. However, I think you might find a number of people who consider lack of Win32 support a deciding factor when considering to use GRAMPS. Insisting that people fork the project to add compatible features certainly isn't going to encourage developers to work on things, either. > Let's talk to somebody who is seriously thinking of the Qt port. Actually, after looking at those two files, I don't think it would take more than a few hours or so to convert the code to use Qt. > It is my humble opinion that, if such person comes up and the Qt port > happens, we will see exactly how much can be factored out into > toolkit-independent modules and how much will have to stay as is. So far the > task of making things toolkit-independet seems idle and speculative to me. > Sorry, I don't know Qt, but I would suggest going from necessity rather than > the "it should look nice" side of things. Qt isn't just a matter of looking nicer. GTK is only supported under X11 now (unless someone's re-ported it to Win32/Mac since I last checked) whereas Qt works under not only X11, Win32 and Mac, but also on many embedded devices. |
From: Douglas S. B. <db...@br...> - 2005-02-28 06:24:37
|
Luke-Jr <lu...@da...> said: > > > Have you thought of this? A module that implements the GTK calls made in > > > GRAMPS, then just change gtk.* to const.toolkit.* or similar. > > > > Yes, Doug has proposed this some time ago, and we rejected this idea. > > Our reasoning was that it brings some maintanence burden with it > > and that it should not be carried by gramps, until we believe that > > this change is for the best of gramps and its existing users. Luke-Jr, this is exactly what I proposed and implemented. GRAMPS-tk now pre-processes GRAMPS code by going through and making these replacements automatically. As proof of the concept, you can still run GRAMPS in GTK mode in GRAMPS-tk, but you can also switch to other Gui's. You should head on over to http://emergent.brynmawr.edu/emergent/Gramps_2dtk GRAMPS-tk isn't a fork in the normal sense because all of GRAMPS code is still there (some have called it a spoon, and I like that). GRAMPS-tk just does that little transform you mention, and adds the code necessary to make it work for Tkinter (Tix actually). Future posts along this line should probably continue over on the GRAMPS-tk mailing list. -Doug |
From: Luke-Jr <lu...@da...> - 2005-02-28 06:42:01
|
On Monday 28 February 2005 06:24, Douglas S. Blank wrote: > Luke-Jr <lu...@da...> said: > > > > Have you thought of this? A module that implements the GTK calls made > > > > in GRAMPS, then just change gtk.* to const.toolkit.* or similar. > > > > > > Yes, Doug has proposed this some time ago, and we rejected this idea. > > > Our reasoning was that it brings some maintanence burden with it > > > and that it should not be carried by gramps, until we believe that > > > this change is for the best of gramps and its existing users. > > Luke-Jr, this is exactly what I proposed and implemented. GRAMPS-tk now > pre-processes GRAMPS code by going through and making these replacements > automatically. As proof of the concept, you can still run GRAMPS in GTK > mode in GRAMPS-tk, but you can also switch to other Gui's. Interestingly, I was unable to get it to work properly when I tried several hours ago... :/ |
From: Alex R. <sh...@al...> - 2005-02-28 13:55:16
|
Hi, I think this toolkit discussion is getting us into the dead-end. I'm going to respond just once more, since I think we made our positions clear and discussing it untill the end of the world is not going to change things. I also should make a disclaimer that this is my personal opinion, and other users and developers may definitely have a different one. The project leader is Don Allingham, and I hope he will chime in sometime soon, and his word would be the one that ultimately counts :-) On Mon, Feb 28, 2005 at 05:54:22AM +0000, Luke-Jr wrote: > On Monday 28 February 2005 03:28, you wrote: > > On Mon, Feb 28, 2005 at 03:02:19AM +0000, Luke-Jr wrote: > > > Is it possible to use the berkely db only as a working space (a file = in > > > /tmp) and have Load/Save interface with the XML? > > > > Sure -- place your grdb file in /tmp, import your data from XML when you > > start and export into XML when you finish your session :-) >=20 > I meant in a way that it was invisible to the users. Most people aren't g= oing=20 > to see why they need to use Import/Export at all. No, without tweaking the code you can't have database backend plus native "Save" into XML, simply because there's no "Save" button. The code can be changed though. However, your users may simply open XML database directly. This would still keep all the data in memory, just like in the 1.0.x version, and it would automatically save on exit. Avoiding the automatic save is only a matter of "Abandon your changes and quit" in File menu. > Other toolkits would be useful for the new users who need it, which may b= e a=20 > large percentage of resulting total users. [snip] > The purpose of CVS is to manage changes to code. Even if the change was t= oo=20 > large to make it into HEAD, it could still be a branch without interferin= g=20 > with the rest of the project. [snip] > This is a looping effect. If the existing users needed such features, the= y=20 > would not qualify as users in the first place. Once such features are add= ed,=20 > however, the user base increases to include those who find it useful. You may be right in this. But the project has started as a personal program. We have interests in working on a personal program. We have users who use a personal program on their personal computers. Why should we suffer changes in the code and make debugging and maintaining it more difficult if it's not what we want to do? Maybe other users of other projects would appreciate this, but we don't have to. > > Why is it so important that gramps satisfies everybody's wishes? >=20 > It isn't, but the number of people who would be able to make use of ports= is=20 > significant. So here we go to the other extreme. The whole thing started when Don created the project and said: "Hey, I have this software! Please come and use it and feel free to improve it." He didn't say "Please come and make me do whatever you feel that I should do!" > But without their changes being included in the CVS tree, such changes wi= ll be=20 > more likely to break when the main code changes. Do you have the code to offer? Doug managed to work around this, so it ended up not being a huge problem for gramps-tk. > > If somebody comes tomorrow and wants to have the whole thing redone in = C++, > > would we be expected to do that too? Or at least provide a > > language-independent project? :-)=20 >=20 > Of course not. That is not even a decent analogy. > If someone rewrote the whole program in C++, would it be refused from the= =20 > official project? Oh yes -- I'd hate to be maintaining the C++ code. I would not know where to start when fixing bugs :-) But mind you, rewriting would have to be definitely done outside our CVS :-) > No problem for me. However, I think you might find a number of people who= =20 > consider lack of Win32 support a deciding factor when considering to use= =20 > GRAMPS. > Insisting that people fork the project to add compatible features certain= ly=20 > isn't going to encourage developers to work on things, either. It's not quite that. We're not insisting that people fork any little change. Usually, when person is interested in getting somewhere, he starts sending patches. The more patches and heavier patches, and then he gets the CVS access, once his patches are making sensse to us and the interest persists. Other people create plugins and contribute them. But yet sometimes there's somebody suggesting the complete new direction and almost complete rewrite. And in this case we're being cautious. > Actually, after looking at those two files, I don't think it would take m= ore=20 > than a few hours or so to convert the code to use Qt. Listen -- I believe it when I see it. Sorry, but I'm just such a jerk. It would probably take you just a couple of weeks to prove me wrong, and to get the whole thing working under Qt, so let's see. > Qt isn't just a matter of looking nicer. GTK is only supported under X11 = now=20 > (unless someone's re-ported it to Win32/Mac since I last checked) whereas= Qt=20 > works under not only X11, Win32 and Mac, but also on many embedded device= s. I did not want to get started on this, but here we go now. I personally have no interest in running gramps on win32/mac/whatever else. Sorry, but I don'= t. I think Don does not either. I also don't have an ambition to lure windows users into Linux by hooking them up on gramps and then using it as a leverage to convert users to the free world. I don't exactly want to maximize number of gramps users by embracing all platforms. It might not bode well for grandmas and grandpas who are stuck running windows, but if their kids wish them well they can fix this. From where I am standing, X11 is perefctly good place to be at, and if somebody needs to work to get elsewhere -- it's their call and their effort. And again, I also have to say that I have nothing against gramps running on win32 -- I simply don't care enough to help with that, and don't have ti= me and resources. If somebody develops that one way or another, then we will see about accepting it in the future. I definitely would not want to mainta= in half-done port to Qt. 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 |
From: Don A. <don...@co...> - 2005-02-28 17:30:30
|
Alex Roitman wrote: > Hi, > > I think this toolkit discussion is getting us into the dead-end. I'm going > to respond just once more, since I think we made our positions clear and > discussing it untill the end of the world is not going to change things. > I also should make a disclaimer that this is my personal opinion, and other > users and developers may definitely have a different one. The project leader > is Don Allingham, and I hope he will chime in sometime soon, and his word > would be the one that ultimately counts :-) > I guess it is time for me to chime in. But first, I want to correct a slight misstatement that Alex made above. If you look at the GRAMPS project page at SourceForge, you will notice that there are two project managers for GRAMPS - me and Alex. Alex tends to want to defer to me for final declarations, but I see Alex as having just as much authority over the project as I do. Fortunately, we usually tend to agree on issues - with the exception that Alex tends to pull his Monty Python quotes from the "Flying Circus" TV show, while I tend to pull mine from the Monty Python movies :-) One of the things we have been deficient on is publishing the goals of the project. Those of us involved with the project for a long period tend to take for granted that everyone else understands them. I'll try to correct this in the near future. When I started this project almost 4 years ago, the goal was to fill a void for Linux users - an easy to use, open and standards compliant personal genealogy software package that would be usable by the power user and by Aunt Martha, who is still trying to figure out how to use a mouse. To this end, GNOME was chosen as the interface. Why? Because I use GNOME, and 4 years ago when the project started, we had good GNOME/python integration (including GLADE support) from the pygtk project. Four years later, would I have made a different choice? No, I would not. In fact, I believe more firmly than ever that GNOME was the right choice based of their focus on simplicity and usability. Do I view it as important to support different toolkits? No, I do not. Supporting different toolkits does not really offer any additional benefit to the end user. I want to use the time I have to dedicate to the project to increasing functionality for the end user, not reimplementing things that have already been implemented and will vastly increase the amount of support the project takes. So, if I have a couple of hours to spend, I think the project will get more benefit from a new or enhanced report than from a different set of toolkit widgets. The report adds new functionality, the additional toolkit does not add new functionality. Right now, I am running a GNOME desktop under Ubuntu. If you look at my toolbar, you will see Firefox (XUL toolkit), Evolution (GNOME/GTK), Rhythmbox (GNOME/GTK), K3B (KDE/QT) and GNU EMACS (Xaw3d). It does not offend me that K3B does not have a GNOME port. The fact that it is a KDE application does not prevent me from using it. I see it as simply the best CD application available. I use GNU EMACS as my editor. It uses the primative Xaw3d toolkit. It doesn't matter. It is the editor that suites my needs (and has for 20 years). I would rather that these teams keep their focus and continue work on enhancing their functionality instead of porting to various different toolkits. Sometimes the comment comes up, "But if you supported XXX toolkit, you could run it under the YYY operating system." And as harsh as it sounds, my honest answer is, "I really don't care." I have no interest in supporting Windows, and I am not capable of supporting the Mac (Apple hasn't given me a free mini-Mac, and I'm not holding my breath :-) The goal of the GRAMPS project has been to supply a solid genealogy project for the un*xish operating systems using GNOME. Windows and OS X don't fit in with these goals. That being said, I have no objection to someone porting GRAMPS to other platforms. The FINK project has ported to Mac OS X, and a few people have ported to Windows using Cygwin. I think these efforts are great, and I appreciate the efforts of these people. However, I am not capable of supporting these efforts (I don't have a Mac, and will not run Windows). And while we won't do anything to hinder these ports, we aren't going to change the direction of the project to support these ports. Alex did a pretty good job of describing how we accept contributions and patches (which we encourage and appreciate greatly). However, we've had to face the reality of Open Source development - developers will come and go. Since Alex and I are in it for the long term, when a developer goes, it falls on us to support what they have done. Usually this is not a problem, since contributions usually take the form of interface enhancements, bug fixes, additional reports and additional tools. Since these move the project forward and benefit the end user, we are willing to put in the additional effort. Alex proved himself over time. He started by providing the Russian translation. He then rewrote the User's Manual. He started submitting patches, and gained CVS access. His patches and contributions became very significant, and he started helping with the release process and helping with bug reports and solving user's problems. He proved he's in it for the long haul and became invaluable to the project. That is why I decided to share the project manager role with him. This has proven to be the smartest decision I made since starting the project. Occasionally, someone wants us to change our direction. These have included requests to rewrite in C++ (because python isn't a real language), rewrite in php and become a web application, rewrite using KDE (because everyone knows that GNOME is dying), rewrite using wxPython (because everyone knows that GNOME and KDE are dying), rewrite for Windows (because everyone knows that Linux is dying) and rewrite as a mySQL application. And our usual answer is something to the effect of, "We're sorry, but that does not align with goals of the project. If you would like to fork the project, we will try to assist you as best we can, so long as it doesn't interfere with our goals". This is the approach with took with gramps-tk. We made several changes to our code to support this effort, removing gtk and gnome dependencies where they weren't needed to make the gramps-tk effort easier. And we honestly hope for the best for the gramps-tk project, and we are open to a remerge sometime in the future. However, experience has taught us that we need to keep our focus. We don't want to risk having to support a half finished port to a different toolkit because a developer loses interest and moves on - once a feature is in a program, it is nearly impossible to remove, leaving the current development team to support something it feels does not match the project goals. Now, sometimes we get a request for a major architectural change that we will accept. A good example is the new database backend for the upcoming GRAMPS 2.0. The request came in to support a real database backend so we could support larger databases. We analyzed the request, and felt that it matched the goals of the project and would provide a significant step forward in the usability of the program. The result was a major redesign effort that will soon be released. So, would we accept a mySQL database backend? There is a good chance we would (depending on the implementation), as long did not impact Aunt Martha. We have even architected the backend to support this, since we can see that higher end databases could provide additional functionality such as versioning and multiuser support. However, don't expect Alex or me to jump on this. Besides the fact that neither of us are mySQL experts (or even novices), we feel our efforts are probably better suited on other efforts that would affect all (or at least the vast majority) of users. So, in summary, the project is going in a direction that seems to meet the needs of our users. If we changed directions, we might or might not be able to reach a larger audience, but numbers are not our goal. We fully support others submitting patches and other contributions, but they will be weighed on how they match the goals of the project (and most of the patches we've received to date do match the goals). If someone wants us take the project in a different direction, we may or may not be receptive depending if the direction matches our goals. However, we will support your efforts if you decide to fork the project. Who knows, maybe a remerge will occur in the future, or a forked project will make us irrelevent. And that is okay. Don |
From: Jason S. <wha...@co...> - 2005-02-28 22:48:18
|
On Monday 28 February 2005 10:30, Don Allingham wrote: > I guess it is time for me to chime in. But first, I want to correct a > slight misstatement that Alex made above. If you look at the GRAMPS > project page at SourceForge, you will notice that there are two project > managers for GRAMPS - me and Alex. Alex tends to want to defer to me for > final declarations, but I see Alex as having just as much authority over > the project as I do. Fortunately, we usually tend to agree on issues - > with the exception that Alex tends to pull his Monty Python quotes from > the "Flying Circus" TV show, while I tend to pull mine from the Monty > Python movies :-) So that's how you do it! I will have to watch both now! *smirk* > When I started this project almost 4 years ago, the goal was to fill a > void for Linux users - an easy to use, open and standards compliant > personal genealogy software package that would be usable by the power > user and by Aunt Martha, who is still trying to figure out how to use a > mouse. I have to agree with this statement, since my wife isn't all that much of a power user under Linux. I've been the one that's been dinking with things around here in Linux, and I can say that Don and Alex have met this goal rather admirably. > So, if I have a couple of hours to spend, I think the project will get > more benefit from a new or enhanced report than from a different set of > toolkit widgets. The report adds new functionality, the additional > toolkit does not add new functionality. I would have to be the third person to agree with this statement. Reinventing the wheel to make someone else happy isn't the primary goal of the project. Providing functionality and ease of use is the top goal, even for us people who only poke around for bugs in the program. [snip] > Sometimes the comment comes up, "But if you supported XXX toolkit, you > could run it under the YYY operating system." And as harsh as it sounds, > my honest answer is, "I really don't care." I have no interest in > supporting Windows, and I am not capable of supporting the Mac (Apple > hasn't given me a free mini-Mac, and I'm not holding my breath :-) The > goal of the GRAMPS project has been to supply a solid genealogy project > for the un*xish operating systems using GNOME. Windows and OS X don't > fit in with these goals. I would agree with Don's assessment. I could help with a port to KDE/Qt, but why? I would not want to assist in maintaining that fork, since there's really no need to change anything. And I also agree that providing additional branches for different toolkits is going to make the whole thing much worse in the end. I can sympathize with Don and Alex in this view. Since the whole Gramps project is based on Gnome and it's tools, leaving it the way it is, is the best option. Porting rarely does any more good than what people think it will do. I mean, you can still run Gramps under KDE. In the end, Linux will still run it, and getting things aligned with the end user is still happening. Porting it will do what? It will make it more confusing for the end user. > That being said, I have no objection to someone porting GRAMPS to other > platforms. The FINK project has ported to Mac OS X, and a few people > have ported to Windows using Cygwin. I think these efforts are great, > and I appreciate the efforts of these people. However, I am not capable > of supporting these efforts (I don't have a Mac, and will not run > Windows). And while we won't do anything to hinder these ports, we > aren't going to change the direction of the project to support these ports. *nods at Don* I agree with your points. I would like to see Gramps running on Windows, but I also have to admit that running it under Linux will be vastly better, since that's what it's designed to do. Cygwin comes close. but the end user will not want to go through and compile code, and set up Cygwin just to run Gramps. For Windows, there are a myriad of genealogical programs. The end user has the options open to them, let them run with it. [snip] > Alex proved himself over time. He started by providing the Russian > translation. He then rewrote the User's Manual. He started submitting > patches, and gained CVS access. His patches and contributions became > very significant, and he started helping with the release process and > helping with bug reports and solving user's problems. He proved he's in > it for the long haul and became invaluable to the project. That is why I > decided to share the project manager role with him. This has proven to > be the smartest decision I made since starting the project. And we thank you for it, Don. You and Alex are the best developers that I've ever worked with. [snip] > Now, sometimes we get a request for a major architectural change that we > will accept. A good example is the new database backend for the upcoming > GRAMPS 2.0. The request came in to support a real database backend so we > could support larger databases. We analyzed the request, and felt that > it matched the goals of the project and would provide a significant step > forward in the usability of the program. The result was a major redesign > effort that will soon be released. I think I and few others are the ones that impacted this decision. Having an 850,000 person database tends to be deadly to the XML architecture that we were with. I've been the main person to test the integrity of the system with my Gedcom file importing. When I found that I couldn't import my file without extensive data loss, I came to Don and Alex and we all sought for solutions. We found that the XML interface was taking huge amounts of memory, and we looked for database backends that would handle the load. Don and Alex came through with the BSDDB backend, and ever since 1.1.3, I've been happy as a clam with the Gramps project, because I'm one step closer to killing Windows. I personally want to do away with it, but I need it for other applications. I've also come to the realization that both Windows and Linux are good, but in their own realms. I don't want this to become a huge flame war about Linux and Windows. so if you have other questions as to why I feel this way, email me. > So, would we accept a mySQL database backend? There is a good chance we > would (depending on the implementation), as long did not impact Aunt > Martha. We have even architected the backend to support this, since we > can see that higher end databases could provide additional functionality > such as versioning and multiuser support. We could accept mySQL because of this, but I agree with Don. If it negatively impacts the end user, why would we want to proceed with it? I have a friend that wondered about mySQL interaction, but he can see the impact that BSDDB has had on my database, and he has sided with me as well as the rest of the team. Not to say that this is not a possibility, but we need to remain focused on the tasks at hand. > So, in summary, the project is going in a direction that seems to meet > the needs of our users. If we changed directions, we might or might not > be able to reach a larger audience, but numbers are not our goal. We > fully support others submitting patches and other contributions, but > they will be weighed on how they match the goals of the project (and > most of the patches we've received to date do match the goals). If > someone wants us take the project in a different direction, we may or > may not be receptive depending if the direction matches our goals. > However, we will support your efforts if you decide to fork the project. > Who knows, maybe a remerge will occur in the future, or a forked project > will make us irrelevent. I agree with Don on this, numbers don't matter as long as the users are happy. Getting things appropriately nailed down and ready for the end user's use is what is paramount. After all, if there were no users, why would we even have a project with which to collaborate in the first place? We are here for the users, especially Aunt Martha, because of the fact that many people are just moving over to Linux and having something familiar to them, like a genealogical program is what matters to them. Making the transition to Linux is hard, don't get me wrong. But we are making it one step easier by not complicating the user's experience in their move. Like I said before, I'm just a bug finder. I'm not really a Python programmer, or anything, but I like to find bugs. Even if that's all I do on this project, I'm rather content. Everyone else that wants to port over to other toolkits and whatnot is free to do so. But also as an end user that's still a greenie to Linux in general, I can say that this program has helped my move over to Linux that much easier. Even if I have only contributed a little in the way of feedback (mostly from the end-user perspective). -Jason |
From: Eero T. <eer...@ne...> - 2005-02-28 18:58:47
|
Hi, > What has changed for the better in the 1.1 branch? From what I can tell, > it has the ability to edit certain objects in more detail (like names), IMHO one of the main user visible improvements in Gramps is that all reports remember all the options user selected in them earlier. I wonder why Alex didn't mention this although it's all his work. :-) > but that shouldn't be too difficult to backport... Reports API has changed very throughly (for the better). You can fairly easily port things from 1.0 to 2.0 (remove now redundant code and refactor rest), the other way round is more work. > What was the reason behind abandoning a nice XML format? I see that 1.1 > will still give me the option to save as GRAMPS XML, but the output is > not actually XML, but gzipped XML (which is much less diff-friendly). The > old option to not gzip the file is gone. :( > Is the 1.0 branch still in development? - Eero |
From: Luke-Jr <lu...@da...> - 2005-02-28 19:42:20
|
On Monday 28 February 2005 17:30, Don Allingham wrote: > Sometimes the comment comes up, "But if you supported XXX toolkit, you > could run it under the YYY operating system." And as harsh as it sounds, > my honest answer is, "I really don't care." I have no interest in > supporting Windows, and I am not capable of supporting the Mac (Apple > hasn't given me a free mini-Mac, and I'm not holding my breath :-) The > goal of the GRAMPS project has been to supply a solid genealogy project > for the un*xish operating systems using GNOME. Windows and OS X don't > fit in with these goals. X11 isn't necessary the only thing *nix OS use for a graphical interface. Mac OS X is only *nix OS that primarily does not use X11, and many various *nix systems run Qt/Embedded if they lack the space for a full X server. Framebuffer support could also broaden support, but I think that would be significantly more complex... > That being said, I have no objection to someone porting GRAMPS to other > platforms. The FINK project has ported to Mac OS X, and a few people > have ported to Windows using Cygwin. I think these efforts are great, > and I appreciate the efforts of these people. However, I am not capable > of supporting these efforts (I don't have a Mac, and will not run > Windows). And while we won't do anything to hinder these ports, we > aren't going to change the direction of the project to support these ports. Adding branches does not need to change the direction of a project. > Alex did a pretty good job of describing how we accept contributions and > patches (which we encourage and appreciate greatly). However, we've had > to face the reality of Open Source development - developers will come > and go. Since Alex and I are in it for the long term, when a developer > goes, it falls on us to support what they have done. Usually this is not > a problem, since contributions usually take the form of interface > enhancements, bug fixes, additional reports and additional tools. Since > these move the project forward and benefit the end user, we are willing > to put in the additional effort. If nobody cares to maintain the alternate toolkit support, then the toolkit need only be remove from the list of those supported, and eventually, removed from the tree if nobody else steps up to take over maintenance of it. I don't suggest that any project needs to keep all the features of its former releases if there is no interest in maintaining those features. > Occasionally, someone wants us to change our direction. These have > included requests to rewrite in C++ (because python isn't a real > language), There isn't some rule saying that a project can only have one official version. For example, back years ago I have a project called ODC. There was a Visual Basic version and a Java version, led by different people only really similar because of their design. > rewrite in php and become a web application, Now that would be an interesting extension... though I'm pretty sure it would work just fine using Python. > rewrite using KDE (because everyone knows that GNOME is dying), rewrite > using wxPython (because everyone knows that GNOME and KDE are dying), > rewrite for Windows (because everyone knows that Linux is dying) The problem with these is the approach as a rewrite/fork. Multiple toolkits can be supported with a lot of code in common. > and rewrite as a mySQL application. I'm sure you know better than I do how well MySQL support could be added without interfering with the rest of GRAMPS. The same applies for toolkits above. > And we honestly hope for the best for the gramps-tk project, and we are > open to a remerge sometime in the future. However, experience has taught > us that we need to keep our focus. We don't want to risk having to > support a half finished port to a different toolkit because a developer > loses interest and moves on - once a feature is in a program, it is > nearly impossible to remove, Not at all, especially with modulized components. Mozilla, for example, used to have Qt support. It was unmaintained for months (if not years) and nobody complained. I don't recall if someone took over Qt support and brought it up to date or if it was removed eventually... > leaving the current development team to support something it feels does not > match the project goals. > > So, in summary, the project is going in a direction that seems to meet > the needs of our users. If we changed directions, we might or might not > be able to reach a larger audience, but numbers are not our goal. We > fully support others submitting patches and other contributions, but > they will be weighed on how they match the goals of the project (and > most of the patches we've received to date do match the goals). If > someone wants us take the project in a different direction, we may or > may not be receptive depending if the direction matches our goals. > However, we will support your efforts if you decide to fork the project. > Who knows, maybe a remerge will occur in the future, or a forked project > will make us irrelevent. The problem with merging separate projects is that you lose the CVS history of one of them. If both 'projects' were instead branches in CVS (one being an unsupported branch, even), they can be easily merged any time. On Monday 28 February 2005 13:55, Alex Roitman wrote: > > Other toolkits would be useful for the new users who need it, which may > > be a large percentage of resulting total users. > [snip] > > The purpose of CVS is to manage changes to code. Even if the change was > > too large to make it into HEAD, it could still be a branch without > > interfering with the rest of the project. > [snip] > > This is a looping effect. If the existing users needed such features, > > they would not qualify as users in the first place. Once such features > > are added, however, the user base increases to include those who find it > > useful. > > You may be right in this. But the project has started as a personal > program. We have interests in working on a personal program. We have users > who use a personal program on their personal computers. And many (most?) of the new users gained would also be using GRAMPS as a personal program on their PCs. > Why should we suffer changes in the code and make debugging and maintaining > it more difficult if it's not what we want to do? Different toolkit modules wouldn't need to make debugging/maintaining any more difficult. |
From: Luke-Jr <lu...@da...> - 2005-02-28 23:03:32
|
On Monday 28 February 2005 22:48, Jason Salaz wrote: > On Monday 28 February 2005 10:30, Don Allingham wrote: > > So, if I have a couple of hours to spend, I think the project will get > > more benefit from a new or enhanced report than from a different set of > > toolkit widgets. The report adds new functionality, the additional > > toolkit does not add new functionality. > > I would have to be the third person to agree with this statement. > Reinventing the wheel to make someone else happy isn't the primary goal of > the project. Providing functionality and ease of use is the top goal, even > for us people who only poke around for bugs in the program. This wouldn't *be* reinventing the wheel. It would be providing existing functionality to more users. > > Sometimes the comment comes up, "But if you supported XXX toolkit, you > > could run it under the YYY operating system." And as harsh as it sounds, > > my honest answer is, "I really don't care." I have no interest in > > supporting Windows, and I am not capable of supporting the Mac (Apple > > hasn't given me a free mini-Mac, and I'm not holding my breath :-) The > > goal of the GRAMPS project has been to supply a solid genealogy project > > for the un*xish operating systems using GNOME. Windows and OS X don't > > fit in with these goals. > > I would agree with Don's assessment. I could help with a port to KDE/Qt, > but why? I would not want to assist in maintaining that fork, since > there's really no need to change anything. And I also agree that providing > additional branches for different toolkits is going to make the whole thing > much worse in the end. How do you get the idea that branches will hurt anything? Branches are *designed* for things like this. > Porting rarely does any more good than what people think it will do. I > mean, you can still run Gramps under KDE. Not always. What if KDE isn't running under X11? > In the end, Linux will still run it, Linux doesn't 'run' GRAMPS at all, from what I can tell. Python runs GRAMPS, so long as GTK and parts of GNOME are present. > and getting things aligned with the end user is still happening. Only because the existing end user can already run it. However, *potential* end users cannot. > Porting it will do what? Allow GRAMPS to run on platforms without GTK/GNOME. There are many *nix systems (not to mention others like Windows) that do not support X11. > It will make it more confusing for the end user. How so? Default to GTK, and if PyGTK support isn't on the system, try the others. No user knowledge necessary. > We are here for the users, especially Aunt Martha, because of the fact that > many people are just moving over to Linux and having something familiar to > them, like a genealogical program is what matters to them. Making the > transition to Linux is hard, don't get me wrong. But we are making it one > step easier by not complicating the user's experience in their move. If the users need to change programs, it isn't helping the transition process. The existence of cross-OS programs allows users to change one program at a time, and while actually changing OS (dual-boot phase), run the same programs on both sharing the data. |
From: Alexandre P. <ale...@gm...> - 2005-03-01 10:59:51
|
On Mon, 28 Feb 2005 23:04:54 +0000, Luke-Jr <lu...@da... > wrote: > If the users need to change programs, it isn't helping the transition pro= cess. > The existence of cross-OS programs allows users to change one program at = a > time, and while actually changing OS (dual-boot phase), run the same prog= rams > on both sharing the data. If ever you need. I don't remember myself using Inkscape/GIMP much in Windows just because I don't need them at work, while I extensively use them at home. The only valid point of having dual boot is that people need Windows to run applications they cannot run in GNU/Linux. I'm not sure that you have decent statistics about target group of dual boot users. We all judge by our own experience, while "the milage varies". According to my experience people don't dual-reboot all the time. They just happily use VMware. I'm not talking about teenage hackers who have time and nerves to swit=D1=81h between OSes. I'm talking about people who are serious enough to know they can spare some time for family and friends. I don't know of any application except maybe LICQ which supported different toolkits and became well-known and widely used for just that fact. Yes, you can use either Qt or Gtk based build of OpenOffice.org , if you really need that fancy desktop consistent look of widgets, and it doesn't help by portability much (OOo for Mac OS X please? :)). That said, I don't really see any point in further discussing _possibility_ of toolkit abstraction. If you are really keen of it, "use the source", Luke, and make it _reality_ :) Alexandre |
From: Eero T. <eer...@ne...> - 2005-03-01 20:27:20
|
Hi, > > Sometimes the comment comes up, "But if you supported XXX toolkit, you > > could run it under the YYY operating system." And as harsh as it > > sounds, my honest answer is, "I really don't care." I have no interest > > in supporting Windows, and I am not capable of supporting the Mac > > (Apple hasn't given me a free mini-Mac, and I'm not holding my breath > > :-) The goal of the GRAMPS project has been to supply a solid genealogy > > project for the un*xish operating systems using GNOME. Windows and OS X > > don't fit in with these goals. > > X11 isn't necessary the only thing *nix OS use for a graphical interface. > Mac OS X is only *nix OS that primarily does not use X11. It is not Open Source. > and many various *nix systems run Qt/Embedded if they lack the space for > a full X server. Qt/Embedded is just a GUI toolkit, it's not a desktop environment. It lacks several of the features required by Gramps (for example a mime-registry for running automatically viewers for the reports which is pretty convenient). Qtopia again is not Open Source, unlike Gnome or KDE. > Framebuffer support could also broaden support, > but I think that would be significantly more complex... I know nobody who *uses* applications from the framebuffer, not even for running games since (1996?) we got better alternatives than SVGAlib. Some people use *console* applications, but nobody uses framebuffer applications. What would be the point? > > That being said, I have no objection to someone porting GRAMPS to other > > platforms. The FINK project has ported to Mac OS X, and a few people > > have ported to Windows using Cygwin. I think these efforts are great, > > and I appreciate the efforts of these people. However, I am not capable > > of supporting these efforts (I don't have a Mac, and will not run > > Windows). And while we won't do anything to hinder these ports, we > > aren't going to change the direction of the project to support these > > ports. > > Adding branches does not need to change the direction of a project. > > > Alex did a pretty good job of describing how we accept contributions > > and patches (which we encourage and appreciate greatly). However, we've > > had to face the reality of Open Source development - developers will > > come and go. Since Alex and I are in it for the long term, when a > > developer goes, it falls on us to support what they have done. Usually > > this is not a problem, since contributions usually take the form of > > interface enhancements, bug fixes, additional reports and additional > > tools. Since these move the project forward and benefit the end user, > > we are willing to put in the additional effort. > > If nobody cares to maintain the alternate toolkit support, then the > toolkit need only be remove from the list of those supported, and > eventually, removed from the tree if nobody else steps up to take over > maintenance of it. I don't suggest that any project needs to keep all the > features of its former releases if there is no interest in maintaining > those features. I think Don and Alex can re-consider this decision once you've provided the support for the other toolkits and demonstrated that it doesn't have large impact on maintaining rest of Gramps code. > > Occasionally, someone wants us to change our direction. These have > > included requests to rewrite in C++ (because python isn't a real > > language), > > There isn't some rule saying that a project can only have one official > version. For example, back years ago I have a project called ODC. There > was a Visual Basic version and a Java version, led by different people > only really similar because of their design. > > > rewrite in php and become a web application, > > Now that would be an interesting extension... though I'm pretty sure it > would work just fine using Python. There are already exising the www/php/mysql based genealogy programs. Www-application interfaces suck when compared to real applications that integrate to the desktop. However, they offer centralized / multiuser database access. Both have their own goals. Data with them can be exchanged through e.g. Gedcom file format. It would be nice if they would support all the data in Gramps exports thought (unique IDs in v2.0). [...] > > So, in summary, the project is going in a direction that seems to meet > > the needs of our users. If we changed directions, we might or might not > > be able to reach a larger audience, but numbers are not our goal. We > > fully support others submitting patches and other contributions, but > > they will be weighed on how they match the goals of the project (and > > most of the patches we've received to date do match the goals). If > > someone wants us take the project in a different direction, we may or > > may not be receptive depending if the direction matches our goals. > > However, we will support your efforts if you decide to fork the > > project. Who knows, maybe a remerge will occur in the future, or a > > forked project will make us irrelevent. > > The problem with merging separate projects is that you lose the CVS > history of one of them. If both 'projects' were instead branches in CVS > (one being an unsupported branch, even), they can be easily merged any > time. Hm. Are you really saying that we should change from CVS into using a distributed version control system so that everybody could maintain his/her own branch without disturbing the main project? AFAIK this works pretty well in the case of the Linux kernel project. However, changing version control system is a major undertaking... - Eero |