From: Benny M. <ben...@gm...> - 2012-07-10 12:56:15
|
All, The GTK3 branch is progressing nice. I finished today persontreeview, editnote. That means that at the moment editperson, editevent, editnote, listviews, and person treeview is working again in the GTK3 branch. Various other things also work, like quickviews, most gramplets, ... Much work remains. I will not have time to continue until 23 July. Instead of continuing then, I will merge further trunk changes in the branch and reintegrate the branch in trunk. That is, I consider proven that GTK3 can be made to work, so everybody will be forced to fix further issues in their code with GTK3 in trunk. I do this because every code path must be retested. Yes, this is annoying, but necessary if we want a Gramps 4.0 version at the start of 2013 that is sufficiently stable. The main issue outside the gui code I encountered; is that since GTK3, unicode() and str(), no longer work on non ascii chars!! So it is needed to pass the encoding, I now pass 'utf-8' by default. This is not ideal. Best would be if we support python 3 and python 2.7 at the same time, and do the encoding cleanly. I would have to read up on how this is best done. Anyway, I assume this will be mostly a headache on windows. Known problems: http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems Feel free to already help out in this GEP branch before 23 July. I needed 4+ hours to merge trunk changes in this branch a week ago, so please don't do changes in trunk that will make my work again that complicated. Greetings, Benny |
From: Benny M. <ben...@gm...> - 2012-07-10 13:03:33
|
Jerome, Concerning the problem with unicode, you should try with french and test if it crashes. If so, I would suggest that src/gen/ggettext.py does not convert to unicode, but instead just passes the string. My guess would be the string is utf-8 anyway. If gettext can pass something else, we would need to query the codeset, and decode to unicode, then encode to utf-8 That is, GTK3 crashes if you pass a unicode object, it does not do the automatic conversion to utf-8 pygtk did. Benny 2012/7/10 Benny Malengier <ben...@gm...> > All, > > The GTK3 branch is progressing nice. I finished today persontreeview, > editnote. > That means that at the moment editperson, editevent, editnote, listviews, > and person treeview is working again in the GTK3 branch. Various other > things also work, like quickviews, most gramplets, ... > > Much work remains. I will not have time to continue until 23 July. > Instead of continuing then, I will merge further trunk changes in the > branch and reintegrate the branch in trunk. > > That is, I consider proven that GTK3 can be made to work, so everybody > will be forced to fix further issues in their code with GTK3 in trunk. I > do this because every code path must be retested. Yes, this is annoying, > but necessary if we want a Gramps 4.0 version at the start of 2013 that is > sufficiently stable. > > The main issue outside the gui code I encountered; is that since GTK3, > unicode() and str(), no longer work on non ascii chars!! So it is needed to > pass the encoding, I now pass 'utf-8' by default. This is not ideal. Best > would be if we support python 3 and python 2.7 at the same time, and do the > encoding cleanly. I would have to read up on how this is best done. Anyway, > I assume this will be mostly a headache on windows. > > Known problems: > http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems > > Feel free to already help out in this GEP branch before 23 July. I needed > 4+ hours to merge trunk changes in this branch a week ago, so please don't > do changes in trunk that will make my work again that complicated. > > Greetings, > Benny > |
From: John R. <jr...@ce...> - 2012-07-10 16:18:56
|
On Jul 10, 2012, at 1:56 PM, Benny Malengier wrote: > All, > > The GTK3 branch is progressing nice. I finished today persontreeview, editnote. > That means that at the moment editperson, editevent, editnote, listviews, and person treeview is working again in the GTK3 branch. Various other things also work, like quickviews, most gramplets, ... > > Much work remains. I will not have time to continue until 23 July. > Instead of continuing then, I will merge further trunk changes in the branch and reintegrate the branch in trunk. > > That is, I consider proven that GTK3 can be made to work, so everybody will be forced to fix further issues in their code with GTK3 in trunk. I do this because every code path must be retested. Yes, this is annoying, but necessary if we want a Gramps 4.0 version at the start of 2013 that is sufficiently stable. > > The main issue outside the gui code I encountered; is that since GTK3, unicode() and str(), no longer work on non ascii chars!! So it is needed to pass the encoding, I now pass 'utf-8' by default. This is not ideal. Best would be if we support python 3 and python 2.7 at the same time, and do the encoding cleanly. I would have to read up on how this is best done. Anyway, I assume this will be mostly a headache on windows. > > Known problems: http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems > > Feel free to already help out in this GEP branch before 23 July. I needed 4+ hours to merge trunk changes in this branch a week ago, so please don't do changes in trunk that will make my work again that complicated. > There turn out to be some issues with Gtk3 itself with quartz. I've figured out at least part of it and will be committing the changes over the next week (that's to Gtk, not Gramps). There's also a small change in the way that one detects the backend with pygi, it's a one-line change that I'll get checked in to Gramps by this weekend. If all goes well I'll have gep-029 running on quartz before the 23rd. Regards, John Ralls |
From: Jérôme <rom...@ya...> - 2012-07-11 06:20:46
|
Benny, I need to upgrade one on my OS (still using GTK2...) or to try something like Ubuntu 12.04 LTS under an old PC, then to install last "dev" libs with fixes for this branch. I should be able to find some days on next weeks for that. Not certain, but it seems that some 'old' Windows OS are using own cooking (encoding, sorting[1]). So, maybe OS support on next major release will be more experimental for some Windows versions. [1]http://www.gramps-project.org/bugs/view.php?id=5752#c24187 Thanks! Jérôme Benny Malengier a écrit : > Jerome, > > Concerning the problem with unicode, you should try with french and test > if it crashes. If so, I would suggest that src/gen/ggettext.py does not > convert to unicode, but instead just passes the string. My guess would > be the string is utf-8 anyway. If gettext can pass something else, we > would need to query the codeset, and decode to unicode, then encode to utf-8 > That is, GTK3 crashes if you pass a unicode object, it does not do the > automatic conversion to utf-8 pygtk did. > > Benny > > 2012/7/10 Benny Malengier <ben...@gm... > <mailto:ben...@gm...>> > > All, > > The GTK3 branch is progressing nice. I finished today > persontreeview, editnote. > That means that at the moment editperson, editevent, editnote, > listviews, and person treeview is working again in the GTK3 branch. > Various other things also work, like quickviews, most gramplets, ... > > Much work remains. I will not have time to continue until 23 July. > Instead of continuing then, I will merge further trunk changes in > the branch and reintegrate the branch in trunk. > > That is, I consider proven that GTK3 can be made to work, so > everybody will be forced to fix further issues in their code with > GTK3 in trunk. I do this because every code path must be retested. > Yes, this is annoying, but necessary if we want a Gramps 4.0 version > at the start of 2013 that is sufficiently stable. > > The main issue outside the gui code I encountered; is that since > GTK3, unicode() and str(), no longer work on non ascii chars!! So it > is needed to pass the encoding, I now pass 'utf-8' by default. This > is not ideal. Best would be if we support python 3 and python 2.7 at > the same time, and do the encoding cleanly. I would have to read up > on how this is best done. Anyway, I assume this will be mostly a > headache on windows. > > Known problems: > http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems > > Feel free to already help out in this GEP branch before 23 July. I > needed 4+ hours to merge trunk changes in this branch a week ago, so > please don't do changes in trunk that will make my work again that > complicated. > > Greetings, > Benny > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Paul F. <pf....@gm...> - 2012-07-11 14:41:28
|
In the README it says "pygobject 3.3.2 or greater" so I would suggest that requirement be coded into src/gramps.py, the same as "MIN_PYTHON_VERSION = (2, 7, 0, '', 0)" is already checked for, up at the top. By the way, the last time I checked the latest RPM available for F17 was pygobject3-3.2.2-1.fc17.i686.rpm so while the Ubuntu users won't be troubled when the GEPS029 changes are merged back into trunk, there may be others of us who won't be able to use trunk very easily, after that. I will admit I see a pygobject3-3.3.3.1-2.fc18.i686.rpm out there, so it's coming, for us Fedora users -- in November. The thought occurs to me that it might be a good idea to consider giving the 3.4.x branch a longer life than usual, perhaps even an extra year, to allow users to keep using gramps without forcing them to upgrade their system. |
From: Benny M. <ben...@gm...> - 2012-07-11 19:18:27
|
2012/7/11 Paul Franklin <pf....@gm...> > In the README it says "pygobject 3.3.2 or greater" so I > would suggest that requirement be coded into src/gramps.py, > the same as "MIN_PYTHON_VERSION = (2, 7, 0, '', 0)" is > already checked for, up at the top. > It is, but in the gep branch off course, not in trunk yet. > > By the way, the last time I checked the latest RPM available > for F17 was pygobject3-3.2.2-1.fc17.i686.rpm so while the > Ubuntu users won't be troubled when the GEPS029 changes are > merged back into trunk, there may be others of us who won't > be able to use trunk very easily, after that. > Also in ubuntu it is not easy (compile of gi and setting pythonpath), but we must push ahead with this now, so that we can figure out what causes problems and push like that to upstream distro's and quartz the fixes needed, so that the autumn releases, and certainly the spring releases, can work without problems. Older distro's will remain on 3.4.x series, which is not a problem as we support that for another year. > > I will admit I see a pygobject3-3.3.3.1-2.fc18.i686.rpm out > there, so it's coming, for us Fedora users -- in November. > Yes, and we would want other fixes in there too, eg I found https://bugzilla.gnome.org/show_bug.cgi?id=679654, so let's hope a fix for that is also in November. > > The thought occurs to me that it might be a good idea to > consider giving the 3.4.x branch a longer life than usual, > perhaps even an extra year, to allow users to keep using > gramps without forcing them to upgrade their system. > It seems likely that we will do bug fixes in 3.4 longer than otherwise. However, new features should, as always, go to trunk, and next version. Note that 3.3 is the version of ubuntu LTS, but asking users to install 3.4 there is not a problem. Benny > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Paul F. <pf....@gm...> - 2012-07-11 21:13:37
|
On 7/11/12, Benny Malengier <ben...@gm...> wrote: > 2012/7/11 Paul Franklin <pf....@gm...> > >> In the README it says "pygobject 3.3.2 or greater" so I >> would suggest that requirement be coded into src/gramps.py, >> the same as "MIN_PYTHON_VERSION = (2, 7, 0, '', 0)" is >> already checked for, up at the top. >> > > It is, but in the gep branch off course, not in trunk yet. I had looked in your branch. It's not in src/gramps.py there. But when I looked deeper I found it in src/gui/grampsgui.py so I suppose that makes more sense. Thanks. |
From: John R. <jr...@ce...> - 2012-07-20 02:43:33
|
On Jul 10, 2012, at 9:18 AM, John Ralls wrote: > > On Jul 10, 2012, at 1:56 PM, Benny Malengier wrote: > >> All, >> >> The GTK3 branch is progressing nice. I finished today persontreeview, editnote. >> That means that at the moment editperson, editevent, editnote, listviews, and person treeview is working again in the GTK3 branch. Various other things also work, like quickviews, most gramplets, ... >> >> Much work remains. I will not have time to continue until 23 July. >> Instead of continuing then, I will merge further trunk changes in the branch and reintegrate the branch in trunk. >> >> That is, I consider proven that GTK3 can be made to work, so everybody will be forced to fix further issues in their code with GTK3 in trunk. I do this because every code path must be retested. Yes, this is annoying, but necessary if we want a Gramps 4.0 version at the start of 2013 that is sufficiently stable. >> >> The main issue outside the gui code I encountered; is that since GTK3, unicode() and str(), no longer work on non ascii chars!! So it is needed to pass the encoding, I now pass 'utf-8' by default. This is not ideal. Best would be if we support python 3 and python 2.7 at the same time, and do the encoding cleanly. I would have to read up on how this is best done. Anyway, I assume this will be mostly a headache on windows. >> >> Known problems: http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems >> >> Feel free to already help out in this GEP branch before 23 July. I needed 4+ hours to merge trunk changes in this branch a week ago, so please don't do changes in trunk that will make my work again that complicated. >> > > There turn out to be some issues with Gtk3 itself with quartz. I've figured out at least part of it and will be committing the changes over the next week (that's to Gtk, not Gramps). There's also a small change in the way that one detects the backend with pygi, it's a one-line change that I'll get checked in to Gramps by this weekend. If all goes well I'll have gep-029 running on quartz before the 23rd. Using for a temporary workaround for Bug 675332 [1], I've now got gramps working more-or-less on Quartz. There are still some things that don't work right, but it's good enough for you to merge it into trunk. That said, Gtk3 itself now has built-in menu integration, but it requires converting Gramps to use GApplication. I think that this will have other benefits, but I do want to get agreement before I start in on it because it affects all platforms, not just Mac. Regards, John Ralls [1] https://bugzilla.gnome.org/show_bug.cgi?id=675332 |
From: Jérôme <rom...@ya...> - 2012-07-20 05:46:36
|
Note, I get some problems (edition, non-ASCII characters, size of some dialogs, etc ...) by trying GEPS 029 ! http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_029:_GTK3-GObject_introspection_Conversion Le 20/07/2012 04:43, John Ralls a écrit : > > On Jul 10, 2012, at 9:18 AM, John Ralls wrote: > >> >> On Jul 10, 2012, at 1:56 PM, Benny Malengier wrote: >> >>> All, >>> >>> The GTK3 branch is progressing nice. I finished today persontreeview, editnote. >>> That means that at the moment editperson, editevent, editnote, listviews, and person treeview is working again in the GTK3 branch. Various other things also work, like quickviews, most gramplets, ... >>> >>> Much work remains. I will not have time to continue until 23 July. >>> Instead of continuing then, I will merge further trunk changes in the branch and reintegrate the branch in trunk. >>> >>> That is, I consider proven that GTK3 can be made to work, so everybody will be forced to fix further issues in their code with GTK3 in trunk. I do this because every code path must be retested. Yes, this is annoying, but necessary if we want a Gramps 4.0 version at the start of 2013 that is sufficiently stable. >>> >>> The main issue outside the gui code I encountered; is that since GTK3, unicode() and str(), no longer work on non ascii chars!! So it is needed to pass the encoding, I now pass 'utf-8' by default. This is not ideal. Best would be if we support python 3 and python 2.7 at the same time, and do the encoding cleanly. I would have to read up on how this is best done. Anyway, I assume this will be mostly a headache on windows. >>> >>> Known problems: http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems >>> >>> Feel free to already help out in this GEP branch before 23 July. I needed 4+ hours to merge trunk changes in this branch a week ago, so please don't do changes in trunk that will make my work again that complicated. >>> >> >> There turn out to be some issues with Gtk3 itself with quartz. I've figured out at least part of it and will be committing the changes over the next week (that's to Gtk, not Gramps). There's also a small change in the way that one detects the backend with pygi, it's a one-line change that I'll get checked in to Gramps by this weekend. If all goes well I'll have gep-029 running on quartz before the 23rd. > > Using for a temporary workaround for Bug 675332 [1], I've now got gramps working more-or-less on Quartz. There are still some things that don't work right, but it's good enough for you to merge it into trunk. > > That said, Gtk3 itself now has built-in menu integration, but it requires converting Gramps to use GApplication. I think that this will have other benefits, but I do want to get agreement before I start in on it because it affects all platforms, not just Mac. > > Regards, > John Ralls > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=675332 > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2012-07-22 21:46:55
|
2012/7/20 John Ralls <jr...@ce...> > > On Jul 10, 2012, at 9:18 AM, John Ralls wrote: > > > > > On Jul 10, 2012, at 1:56 PM, Benny Malengier wrote: > > > >> All, > >> > >> The GTK3 branch is progressing nice. I finished today persontreeview, > editnote. > >> That means that at the moment editperson, editevent, editnote, > listviews, and person treeview is working again in the GTK3 branch. Various > other things also work, like quickviews, most gramplets, ... > >> > >> Much work remains. I will not have time to continue until 23 July. > >> Instead of continuing then, I will merge further trunk changes in the > branch and reintegrate the branch in trunk. > >> > >> That is, I consider proven that GTK3 can be made to work, so everybody > will be forced to fix further issues in their code with GTK3 in trunk. I do > this because every code path must be retested. Yes, this is annoying, but > necessary if we want a Gramps 4.0 version at the start of 2013 that is > sufficiently stable. > >> > >> The main issue outside the gui code I encountered; is that since GTK3, > unicode() and str(), no longer work on non ascii chars!! So it is needed to > pass the encoding, I now pass 'utf-8' by default. This is not ideal. Best > would be if we support python 3 and python 2.7 at the same time, and do the > encoding cleanly. I would have to read up on how this is best done. Anyway, > I assume this will be mostly a headache on windows. > >> > >> Known problems: > http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems > >> > >> Feel free to already help out in this GEP branch before 23 July. I > needed 4+ hours to merge trunk changes in this branch a week ago, so please > don't do changes in trunk that will make my work again that complicated. > >> > > > > There turn out to be some issues with Gtk3 itself with quartz. I've > figured out at least part of it and will be committing the changes over the > next week (that's to Gtk, not Gramps). There's also a small change in the > way that one detects the backend with pygi, it's a one-line change that > I'll get checked in to Gramps by this weekend. If all goes well I'll have > gep-029 running on quartz before the 23rd. > > Using for a temporary workaround for Bug 675332 [1], I've now got gramps > working more-or-less on Quartz. There are still some things that don't work > right, but it's good enough for you to merge it into trunk. > > That said, Gtk3 itself now has built-in menu integration, but it requires > converting Gramps to use GApplication. I think that this will have other > benefits, but I do want to get agreement before I start in on it because it > affects all platforms, not just Mac. > > I have been looking at http://developer.gnome.org/gtk3/3.3/GtkApplication.html Seems good to me. I do like the fact we can run multiple Gramps instances (looking at different trees), not sure what "application uniqueness" means, hopefully that is then still possible. If you want to do this, best to start hacking after reintegration in trunk. It could be a big patch though, needing a branch. Benny > Regards, > John Ralls > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=675332 > > |
From: John R. <jr...@ce...> - 2012-07-23 14:36:34
|
On Jul 22, 2012, at 2:46 PM, Benny Malengier wrote: > > > 2012/7/20 John Ralls <jr...@ce...> > > On Jul 10, 2012, at 9:18 AM, John Ralls wrote: > > > > > On Jul 10, 2012, at 1:56 PM, Benny Malengier wrote: > > > >> All, > >> > >> The GTK3 branch is progressing nice. I finished today persontreeview, editnote. > >> That means that at the moment editperson, editevent, editnote, listviews, and person treeview is working again in the GTK3 branch. Various other things also work, like quickviews, most gramplets, ... > >> > >> Much work remains. I will not have time to continue until 23 July. > >> Instead of continuing then, I will merge further trunk changes in the branch and reintegrate the branch in trunk. > >> > >> That is, I consider proven that GTK3 can be made to work, so everybody will be forced to fix further issues in their code with GTK3 in trunk. I do this because every code path must be retested. Yes, this is annoying, but necessary if we want a Gramps 4.0 version at the start of 2013 that is sufficiently stable. > >> > >> The main issue outside the gui code I encountered; is that since GTK3, unicode() and str(), no longer work on non ascii chars!! So it is needed to pass the encoding, I now pass 'utf-8' by default. This is not ideal. Best would be if we support python 3 and python 2.7 at the same time, and do the encoding cleanly. I would have to read up on how this is best done. Anyway, I assume this will be mostly a headache on windows. > >> > >> Known problems: http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems > >> > >> Feel free to already help out in this GEP branch before 23 July. I needed 4+ hours to merge trunk changes in this branch a week ago, so please don't do changes in trunk that will make my work again that complicated. > >> > > > > There turn out to be some issues with Gtk3 itself with quartz. I've figured out at least part of it and will be committing the changes over the next week (that's to Gtk, not Gramps). There's also a small change in the way that one detects the backend with pygi, it's a one-line change that I'll get checked in to Gramps by this weekend. If all goes well I'll have gep-029 running on quartz before the 23rd. > > Using for a temporary workaround for Bug 675332 [1], I've now got gramps working more-or-less on Quartz. There are still some things that don't work right, but it's good enough for you to merge it into trunk. > > That said, Gtk3 itself now has built-in menu integration, but it requires converting Gramps to use GApplication. I think that this will have other benefits, but I do want to get agreement before I start in on it because it affects all platforms, not just Mac. > > > I have been looking at http://developer.gnome.org/gtk3/3.3/GtkApplication.html > Seems good to me. I do like the fact we can run multiple Gramps instances (looking at different trees), not sure what "application uniqueness" means, hopefully that is then still possible. > Application uniqueness means only one instance of Gramps can be running at a time. It's optional (see G_APPLICATION_NON_UNIQUE in [1]). > If you want to do this, best to start hacking after reintegration in trunk. It could be a big patch though, needing a branch. Sounds wise. Yes, of course it will need to be on a feature branch. Since trunk is going to be a fast-moving target for a while after you merge back GEP 29, I'll make a git repo and branch there so that I can frequently merge with trunk. I'll publish on Github so that others can play along. First, though, there are plenty of issues with Gtk3 to clean up, and it's not at all clear to me that they're all necessarily Gramps problems. There's also OsmGpsMap which is still Gtk2, and apparently Stowers needs some help with that. Regards, John Ralls [1] http://developer.gnome.org/gio/stable/GApplication.html#GApplicationFlags |
From: Doug B. <dou...@gm...> - 2012-07-23 14:19:04
|
On Sun, Jul 22, 2012 at 5:46 PM, Benny Malengier <ben...@gm...> wrote: > > > 2012/7/20 John Ralls <jr...@ce...> >> >> >> On Jul 10, 2012, at 9:18 AM, John Ralls wrote: >> >> > >> > On Jul 10, 2012, at 1:56 PM, Benny Malengier wrote: >> > >> >> All, >> >> >> >> The GTK3 branch is progressing nice. I finished today persontreeview, >> >> editnote. >> >> That means that at the moment editperson, editevent, editnote, >> >> listviews, and person treeview is working again in the GTK3 branch. Various >> >> other things also work, like quickviews, most gramplets, ... >> >> >> >> Much work remains. I will not have time to continue until 23 July. >> >> Instead of continuing then, I will merge further trunk changes in the >> >> branch and reintegrate the branch in trunk. >> >> >> >> That is, I consider proven that GTK3 can be made to work, so everybody >> >> will be forced to fix further issues in their code with GTK3 in trunk. I do >> >> this because every code path must be retested. Yes, this is annoying, but >> >> necessary if we want a Gramps 4.0 version at the start of 2013 that is >> >> sufficiently stable. >> >> >> >> The main issue outside the gui code I encountered; is that since GTK3, >> >> unicode() and str(), no longer work on non ascii chars!! So it is needed to >> >> pass the encoding, I now pass 'utf-8' by default. This is not ideal. Best >> >> would be if we support python 3 and python 2.7 at the same time, and do the >> >> encoding cleanly. I would have to read up on how this is best done. Anyway, >> >> I assume this will be mostly a headache on windows. >> >> >> >> Known problems: >> >> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Problems >> >> >> >> Feel free to already help out in this GEP branch before 23 July. I >> >> needed 4+ hours to merge trunk changes in this branch a week ago, so please >> >> don't do changes in trunk that will make my work again that complicated. >> >> >> > >> > There turn out to be some issues with Gtk3 itself with quartz. I've >> > figured out at least part of it and will be committing the changes over the >> > next week (that's to Gtk, not Gramps). There's also a small change in the >> > way that one detects the backend with pygi, it's a one-line change that I'll >> > get checked in to Gramps by this weekend. If all goes well I'll have gep-029 >> > running on quartz before the 23rd. >> >> Using for a temporary workaround for Bug 675332 [1], I've now got gramps >> working more-or-less on Quartz. There are still some things that don't work >> right, but it's good enough for you to merge it into trunk. >> >> That said, Gtk3 itself now has built-in menu integration, but it requires >> converting Gramps to use GApplication. I think that this will have other >> benefits, but I do want to get agreement before I start in on it because it >> affects all platforms, not just Mac. >> > > I have been looking at > http://developer.gnome.org/gtk3/3.3/GtkApplication.html > Seems good to me. I do like the fact we can run multiple Gramps instances > (looking at different trees), not sure what "application uniqueness" means, > hopefully that is then still possible. Application uniqueness might mean that it uses an already running version of the app, if you try to open another file associated with it. I tried to do this cross-platform recently on another project, and it was a real pain (looking through processes, message passing, etc.) It would be nice to have a global app which could have multiple trees opened at the same time. For example, some of the diff-patch-merge tools I'm working on could benefit from such a use. Moving people between trees would be very useful. -Doug > If you want to do this, best to start hacking after reintegration in trunk. > It could be a big patch though, needing a branch. > > Benny > >> >> Regards, >> John Ralls >> >> [1] https://bugzilla.gnome.org/show_bug.cgi?id=675332 >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: John R. <jr...@ce...> - 2012-07-23 14:51:59
|
On Jul 23, 2012, at 7:18 AM, Doug Blank wrote: > On Sun, Jul 22, 2012 at 5:46 PM, Benny Malengier > <ben...@gm...> wrote: >> >> >> I have been looking at >> http://developer.gnome.org/gtk3/3.3/GtkApplication.html >> Seems good to me. I do like the fact we can run multiple Gramps instances >> (looking at different trees), not sure what "application uniqueness" means, >> hopefully that is then still possible. > > Application uniqueness might mean that it uses an already running > version of the app, if you try to open another file associated with > it. > > I tried to do this cross-platform recently on another project, and it > was a real pain (looking through processes, message passing, etc.) > > It would be nice to have a global app which could have multiple trees > opened at the same time. For example, some of the diff-patch-merge > tools I'm working on could benefit from such a use. Moving people > between trees would be very useful. Yup, that's what application uniqueness means. As I noted in my reply to Benny, it's optional. Allowing multiple documents usually requires a couple of extra layers of abstraction so that the application can keep track of which one it's talking to. I'm not familiar enough with Gramps's backend to know how hard that would be, but I'll observe that unlike some toolkits, Gtk/Glib/Gio doesn't offer a library for handling the details. Regards, John Ralls |
From: Doug B. <dou...@gm...> - 2012-07-23 15:26:16
|
On Mon, Jul 23, 2012 at 10:51 AM, John Ralls <jr...@ce...> wrote: > > On Jul 23, 2012, at 7:18 AM, Doug Blank wrote: > >> On Sun, Jul 22, 2012 at 5:46 PM, Benny Malengier >> <ben...@gm...> wrote: >>> >>> >>> I have been looking at >>> http://developer.gnome.org/gtk3/3.3/GtkApplication.html >>> Seems good to me. I do like the fact we can run multiple Gramps instances >>> (looking at different trees), not sure what "application uniqueness" means, >>> hopefully that is then still possible. >> >> Application uniqueness might mean that it uses an already running >> version of the app, if you try to open another file associated with >> it. >> >> I tried to do this cross-platform recently on another project, and it >> was a real pain (looking through processes, message passing, etc.) >> >> It would be nice to have a global app which could have multiple trees >> opened at the same time. For example, some of the diff-patch-merge >> tools I'm working on could benefit from such a use. Moving people >> between trees would be very useful. > > Yup, that's what application uniqueness means. As I noted in my reply to Benny, it's optional. > > Allowing multiple documents usually requires a couple of extra layers of abstraction so that the application can keep track of which one it's talking to. I'm not familiar enough with Gramps's backend to know how hard that would be, but I'll observe that unlike some toolkits, Gtk/Glib/Gio doesn't offer a library for handling the details. > I don't think it would be too difficult. Off the top of my head, we'd probably only have to add a database-id to the signaling mechanism. For example, currently if you change the current active person, then that is a signal that is sent, and caught. We'd probably need to add the specific database-id to that. Everything below that passes the database (or dbstate) around, so it should be easy. BTW, I added some cross-database support in the Clipboard and Clipboard Gramplet not too long ago which allows one to copy objects to it and change databases without losing the data. It just uses the database ID, now accessible through db.get_dbid(). -Doug > Regards, > John Ralls > |
From: Benny M. <ben...@gm...> - 2012-07-23 21:05:09
|
Ok, Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. So crashes abound now. most fixes are simple, look at the changelog done for equal code, and change likewise: http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 All glade files not touched yet should be opened in current glade for GTK3 and resaved, then fixed for layout problems. Seen changes in glade files fixed already by me in case of issues. For documentation links, and how to install the new requirements, see the GEP: http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion Fixing the crashes in a part will make you acquinted with the new way of working. I'll fix futher things the coming days. Main issue will probably be geography view which is now disabled. If needed we will have to help out in porting the dependency. On the plus side, the developer will know the code will be used immediately, helping to find bugs. Benny |
From: Doug B. <dou...@gm...> - 2012-07-24 01:39:29
|
On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier <ben...@gm...> wrote: > Ok, > > Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. > > So crashes abound now. most fixes are simple, look at the changelog done for > equal code, and change likewise: > > http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 > > All glade files not touched yet should be opened in current glade for GTK3 > and resaved, then fixed for layout problems. Seen changes in glade files > fixed already by me in case of issues. > > For documentation links, and how to install the new requirements, see the > GEP: > http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion > > Fixing the crashes in a part will make you acquinted with the new way of > working. > > I'll fix futher things the coming days. > > Main issue will probably be geography view which is now disabled. If needed > we will have to help out in porting the dependency. On the plus side, the > developer will know the code will be used immediately, helping to find bugs. > > Benny Great to see this happening! BTW, I did have a strange hard-crash on Python 2.7.2 without the proper pygobject. (I'll no doubt be helping with this port, but I'm still working hard to get Gramps-Connect to a near-finished state. So, initially I'm just making sure that the CLI use of Gramps works ok even without the proper pygobject, as it should.) I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash without the ability to try/except when you try to import webkit from a Gramps plugin. However, if you "import gtk" early on, then later "import webkit" it won't crash. Just thought I'd mention this in case anyone is having trouble getting started on the new Gramps... shall we call this Gramps 4.0? -Doug > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: John R. <jr...@ce...> - 2012-07-24 03:12:04
|
On Jul 23, 2012, at 6:39 PM, Doug Blank wrote: > On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier > <ben...@gm...> wrote: >> Ok, >> >> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. >> >> So crashes abound now. most fixes are simple, look at the changelog done for >> equal code, and change likewise: >> >> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 >> >> All glade files not touched yet should be opened in current glade for GTK3 >> and resaved, then fixed for layout problems. Seen changes in glade files >> fixed already by me in case of issues. >> >> For documentation links, and how to install the new requirements, see the >> GEP: >> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion >> >> Fixing the crashes in a part will make you acquinted with the new way of >> working. >> >> I'll fix futher things the coming days. >> >> Main issue will probably be geography view which is now disabled. If needed >> we will have to help out in porting the dependency. On the plus side, the >> developer will know the code will be used immediately, helping to find bugs. >> >> Benny > > Great to see this happening! > > BTW, I did have a strange hard-crash on Python 2.7.2 without the > proper pygobject. (I'll no doubt be helping with this port, but I'm > still working hard to get Gramps-Connect to a near-finished state. So, > initially I'm just making sure that the CLI use of Gramps works ok > even without the proper pygobject, as it should.) > > I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash > without the ability to try/except when you try to import webkit from a > Gramps plugin. However, if you "import gtk" early on, then later > "import webkit" it won't crash. Just thought I'd mention this in case > anyone is having trouble getting started on the new Gramps... That's an interesting crash. Did you look at the C backtrace? > shall we call this Gramps 4.0? I think we'll need to have a bunch of testing releases, so we should probably call it 3.90.x for a while. Regards, John Ralls |
From: Doug B. <dou...@gm...> - 2012-07-24 03:34:38
|
On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jr...@ce...> wrote: > > On Jul 23, 2012, at 6:39 PM, Doug Blank wrote: > >> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier >> <ben...@gm...> wrote: >>> Ok, >>> >>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. >>> >>> So crashes abound now. most fixes are simple, look at the changelog done for >>> equal code, and change likewise: >>> >>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 >>> >>> All glade files not touched yet should be opened in current glade for GTK3 >>> and resaved, then fixed for layout problems. Seen changes in glade files >>> fixed already by me in case of issues. >>> >>> For documentation links, and how to install the new requirements, see the >>> GEP: >>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion >>> >>> Fixing the crashes in a part will make you acquinted with the new way of >>> working. >>> >>> I'll fix futher things the coming days. >>> >>> Main issue will probably be geography view which is now disabled. If needed >>> we will have to help out in porting the dependency. On the plus side, the >>> developer will know the code will be used immediately, helping to find bugs. >>> >>> Benny >> >> Great to see this happening! >> >> BTW, I did have a strange hard-crash on Python 2.7.2 without the >> proper pygobject. (I'll no doubt be helping with this port, but I'm >> still working hard to get Gramps-Connect to a near-finished state. So, >> initially I'm just making sure that the CLI use of Gramps works ok >> even without the proper pygobject, as it should.) >> >> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash >> without the ability to try/except when you try to import webkit from a >> Gramps plugin. However, if you "import gtk" early on, then later >> "import webkit" it won't crash. Just thought I'd mention this in case >> anyone is having trouble getting started on the new Gramps... > > That's an interesting crash. Did you look at the C backtrace? > >> shall we call this Gramps 4.0? > > I think we'll need to have a bunch of testing releases, so we should probably call it 3.90.x for a while. I guess with Gramps the x.9 status is implied. For example, trunk has been called "3.3" and "3.4" at various times (and is "3.5" currently) so that the addon version numbers will match. (The addons need to match at least major version number with Gramps.) SVN versions get appended onto the displayed version number (after updating const.py with ./autogen.sh), so we always can tell one is running trunk. Since we don't have an official release until it is really ready (and usually follow that up with a few point releases) the name is really just a place holder. But I thought it might be nice to move it from "3.5" to "4.0" to indicate that trunk is now on a backwards-incompatible path, and give a clear point for people's reference. -Doug > Regards, > John Ralls > |
From: John R. <jr...@ce...> - 2012-07-24 04:33:35
|
On Jul 23, 2012, at 8:34 PM, Doug Blank wrote: > On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jr...@ce...> wrote: >> >> On Jul 23, 2012, at 6:39 PM, Doug Blank wrote: >> >>> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier >>> <ben...@gm...> wrote: >>>> Ok, >>>> >>>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. >>>> >>>> So crashes abound now. most fixes are simple, look at the changelog done for >>>> equal code, and change likewise: >>>> >>>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 >>>> >>>> All glade files not touched yet should be opened in current glade for GTK3 >>>> and resaved, then fixed for layout problems. Seen changes in glade files >>>> fixed already by me in case of issues. >>>> >>>> For documentation links, and how to install the new requirements, see the >>>> GEP: >>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion >>>> >>>> Fixing the crashes in a part will make you acquinted with the new way of >>>> working. >>>> >>>> I'll fix futher things the coming days. >>>> >>>> Main issue will probably be geography view which is now disabled. If needed >>>> we will have to help out in porting the dependency. On the plus side, the >>>> developer will know the code will be used immediately, helping to find bugs. >>>> >>>> Benny >>> >>> Great to see this happening! >>> >>> BTW, I did have a strange hard-crash on Python 2.7.2 without the >>> proper pygobject. (I'll no doubt be helping with this port, but I'm >>> still working hard to get Gramps-Connect to a near-finished state. So, >>> initially I'm just making sure that the CLI use of Gramps works ok >>> even without the proper pygobject, as it should.) >>> >>> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash >>> without the ability to try/except when you try to import webkit from a >>> Gramps plugin. However, if you "import gtk" early on, then later >>> "import webkit" it won't crash. Just thought I'd mention this in case >>> anyone is having trouble getting started on the new Gramps... >> >> That's an interesting crash. Did you look at the C backtrace? >> >>> shall we call this Gramps 4.0? >> >> I think we'll need to have a bunch of testing releases, so we should probably call it 3.90.x for a while. > > I guess with Gramps the x.9 status is implied. For example, trunk has > been called "3.3" and "3.4" at various times (and is "3.5" currently) > so that the addon version numbers will match. (The addons need to > match at least major version number with Gramps.) SVN versions get > appended onto the displayed version number (after updating const.py > with ./autogen.sh), so we always can tell one is running trunk. > > Since we don't have an official release until it is really ready (and > usually follow that up with a few point releases) the name is really > just a place holder. But I thought it might be nice to move it from > "3.5" to "4.0" to indicate that trunk is now on a > backwards-incompatible path, and give a clear point for people's > reference. OK. I'd forgotten about the plugin requirement, so my suggestion followed the Gnome practice. But it's definitely time for a new major number. Thanks to BDB being a bit of a moving target, I think everyone's used to backwards-incompatiblity. :-\. Regards, John Ralls |
From: Doug B. <dou...@gm...> - 2012-07-24 03:37:49
|
On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jr...@ce...> wrote: > > On Jul 23, 2012, at 6:39 PM, Doug Blank wrote: > >> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier >> <ben...@gm...> wrote: >>> Ok, >>> >>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. >>> >>> So crashes abound now. most fixes are simple, look at the changelog done for >>> equal code, and change likewise: >>> >>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 >>> >>> All glade files not touched yet should be opened in current glade for GTK3 >>> and resaved, then fixed for layout problems. Seen changes in glade files >>> fixed already by me in case of issues. >>> >>> For documentation links, and how to install the new requirements, see the >>> GEP: >>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion >>> >>> Fixing the crashes in a part will make you acquinted with the new way of >>> working. >>> >>> I'll fix futher things the coming days. >>> >>> Main issue will probably be geography view which is now disabled. If needed >>> we will have to help out in porting the dependency. On the plus side, the >>> developer will know the code will be used immediately, helping to find bugs. >>> >>> Benny >> >> Great to see this happening! >> >> BTW, I did have a strange hard-crash on Python 2.7.2 without the >> proper pygobject. (I'll no doubt be helping with this port, but I'm >> still working hard to get Gramps-Connect to a near-finished state. So, >> initially I'm just making sure that the CLI use of Gramps works ok >> even without the proper pygobject, as it should.) >> >> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash >> without the ability to try/except when you try to import webkit from a >> Gramps plugin. However, if you "import gtk" early on, then later >> "import webkit" it won't crash. Just thought I'd mention this in case >> anyone is having trouble getting started on the new Gramps... > > That's an interesting crash. Did you look at the C backtrace? How do you get a C backtrace? I was only able to narrow down the problem by using strace, and entering commands one at a time in an interactive Python shell. -Doug >> shall we call this Gramps 4.0? > > I think we'll need to have a bunch of testing releases, so we should probably call it 3.90.x for a while. > > Regards, > John Ralls > |
From: John R. <jr...@ce...> - 2012-07-24 04:22:29
|
On Jul 23, 2012, at 8:37 PM, Doug Blank wrote: > On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jr...@ce...> wrote: >> >> On Jul 23, 2012, at 6:39 PM, Doug Blank wrote: >> >>> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier >>> <ben...@gm...> wrote: >>>> Ok, >>>> >>>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. >>>> >>>> So crashes abound now. most fixes are simple, look at the changelog done for >>>> equal code, and change likewise: >>>> >>>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 >>>> >>>> All glade files not touched yet should be opened in current glade for GTK3 >>>> and resaved, then fixed for layout problems. Seen changes in glade files >>>> fixed already by me in case of issues. >>>> >>>> For documentation links, and how to install the new requirements, see the >>>> GEP: >>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion >>>> >>>> Fixing the crashes in a part will make you acquinted with the new way of >>>> working. >>>> >>>> I'll fix futher things the coming days. >>>> >>>> Main issue will probably be geography view which is now disabled. If needed >>>> we will have to help out in porting the dependency. On the plus side, the >>>> developer will know the code will be used immediately, helping to find bugs. >>>> >>>> Benny >>> >>> Great to see this happening! >>> >>> BTW, I did have a strange hard-crash on Python 2.7.2 without the >>> proper pygobject. (I'll no doubt be helping with this port, but I'm >>> still working hard to get Gramps-Connect to a near-finished state. So, >>> initially I'm just making sure that the CLI use of Gramps works ok >>> even without the proper pygobject, as it should.) >>> >>> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash >>> without the ability to try/except when you try to import webkit from a >>> Gramps plugin. However, if you "import gtk" early on, then later >>> "import webkit" it won't crash. Just thought I'd mention this in case >>> anyone is having trouble getting started on the new Gramps... >> >> That's an interesting crash. Did you look at the C backtrace? > > How do you get a C backtrace? > > I was only able to narrow down the problem by using strace, and > entering commands one at a time in an interactive Python shell. The easy way is to use a Mac, which always writes a backtrace in its crash reports. ;-) Otherwise: $ > gdb python (gdb) set env GRAMPSHOME /path/to/gramps/src (gdb) set env PYTHONPATH $PYTHONPATH:$GRAMPSHOME (gdb) r $GRAMPSHOME/gramps.py ...after the crash... (gdb) bt This works best if you have the debug symbols installed for everything relevant, or are running from a self-built tree. Frankly, given the current state of pygi, I really recommend running the current git master for GLib, Gtk, GObject-Introspection, and PyGobject -- built with debug, of course. Jhbuild makes that reasonably painless. Regards, John Ralls |
From: Benny M. <ben...@gm...> - 2012-07-24 07:40:28
|
2012/7/24 John Ralls <jr...@ce...> > Frankly, > given the current state of pygi, I really recommend running the current > git master for GLib, Gtk, GObject-Introspection, and > PyGobject -- built with debug, of course. Jhbuild makes that reasonably > painless. > > I tried jhbuild some months ago, but after two days of compiling, I gave up, and just got the git tree of gobject. There really should be better documentation for jhbuild, like, if you only need gobject and gtk for gramps, how do you set up jhbuild up to the point you have gramps working with the new libs Benny > Regards, > John Ralls > > |
From: Benny M. <ben...@gm...> - 2012-07-24 06:54:56
|
2012/7/24 Doug Blank <dou...@gm...> > On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jr...@ce...> wrote: > > > > On Jul 23, 2012, at 6:39 PM, Doug Blank wrote: > > > >> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier > >> <ben...@gm...> wrote: > >>> Ok, > >>> > >>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. > >>> > >>> So crashes abound now. most fixes are simple, look at the changelog > done for > >>> equal code, and change likewise: > >>> > >>> > http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 > >>> > >>> All glade files not touched yet should be opened in current glade for > GTK3 > >>> and resaved, then fixed for layout problems. Seen changes in glade > files > >>> fixed already by me in case of issues. > >>> > >>> For documentation links, and how to install the new requirements, see > the > >>> GEP: > >>> > http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion > >>> > >>> Fixing the crashes in a part will make you acquinted with the new way > of > >>> working. > >>> > >>> I'll fix futher things the coming days. > >>> > >>> Main issue will probably be geography view which is now disabled. If > needed > >>> we will have to help out in porting the dependency. On the plus side, > the > >>> developer will know the code will be used immediately, helping to find > bugs. > >>> > >>> Benny > >> > >> Great to see this happening! > >> > >> BTW, I did have a strange hard-crash on Python 2.7.2 without the > >> proper pygobject. (I'll no doubt be helping with this port, but I'm > >> still working hard to get Gramps-Connect to a near-finished state. So, > >> initially I'm just making sure that the CLI use of Gramps works ok > >> even without the proper pygobject, as it should.) > >> > >> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash > >> without the ability to try/except when you try to import webkit from a > >> Gramps plugin. However, if you "import gtk" early on, then later > >> "import webkit" it won't crash. Just thought I'd mention this in case > >> anyone is having trouble getting started on the new Gramps... > > > > That's an interesting crash. Did you look at the C backtrace? > > > >> shall we call this Gramps 4.0? > > > > I think we'll need to have a bunch of testing releases, so we should > probably call it 3.90.x for a while. > > I guess with Gramps the x.9 status is implied. For example, trunk has > been called "3.3" and "3.4" at various times (and is "3.5" currently) > so that the addon version numbers will match. (The addons need to > match at least major version number with Gramps.) SVN versions get > appended onto the displayed version number (after updating const.py > with ./autogen.sh), so we always can tell one is running trunk. > > Since we don't have an official release until it is really ready (and > usually follow that up with a few point releases) the name is really > just a place holder. But I thought it might be nice to move it from > "3.5" to "4.0" to indicate that trunk is now on a > backwards-incompatible path, and give a clear point for people's > reference. > Yes, this should be version 4.0 later. Can you do the changes? As you know gramps-addons better, you should have a good view on what to change. It is a pity we can't do the 3.99 thing, but a release called 4.0-0.alpha is not a big issue if communication is done correctly. About webkit, we are not to do import gtk anywhere in the code! In the docs I read they claim this leads to issues. As geography is not ready, I also did not test htmlview. As to allowing lower gi version number for CLI, that is not a problem. B. > -Doug > > > Regards, > > John Ralls > > > |
From: Doug B. <dou...@gm...> - 2012-07-24 07:29:43
|
On Tue, Jul 24, 2012 at 2:54 AM, Benny Malengier <ben...@gm...> wrote: > > > 2012/7/24 Doug Blank <dou...@gm...> >> >> On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jr...@ce...> wrote: >> > >> > On Jul 23, 2012, at 6:39 PM, Doug Blank wrote: >> > >> >> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier >> >> <ben...@gm...> wrote: >> >>> Ok, >> >>> >> >>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. >> >>> >> >>> So crashes abound now. most fixes are simple, look at the changelog >> >>> done for >> >>> equal code, and change likewise: >> >>> >> >>> >> >>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 >> >>> >> >>> All glade files not touched yet should be opened in current glade for >> >>> GTK3 >> >>> and resaved, then fixed for layout problems. Seen changes in glade >> >>> files >> >>> fixed already by me in case of issues. >> >>> >> >>> For documentation links, and how to install the new requirements, see >> >>> the >> >>> GEP: >> >>> >> >>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion >> >>> >> >>> Fixing the crashes in a part will make you acquinted with the new way >> >>> of >> >>> working. >> >>> >> >>> I'll fix futher things the coming days. >> >>> >> >>> Main issue will probably be geography view which is now disabled. If >> >>> needed >> >>> we will have to help out in porting the dependency. On the plus side, >> >>> the >> >>> developer will know the code will be used immediately, helping to find >> >>> bugs. >> >>> >> >>> Benny >> >> >> >> Great to see this happening! >> >> >> >> BTW, I did have a strange hard-crash on Python 2.7.2 without the >> >> proper pygobject. (I'll no doubt be helping with this port, but I'm >> >> still working hard to get Gramps-Connect to a near-finished state. So, >> >> initially I'm just making sure that the CLI use of Gramps works ok >> >> even without the proper pygobject, as it should.) >> >> >> >> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash >> >> without the ability to try/except when you try to import webkit from a >> >> Gramps plugin. However, if you "import gtk" early on, then later >> >> "import webkit" it won't crash. Just thought I'd mention this in case >> >> anyone is having trouble getting started on the new Gramps... >> > >> > That's an interesting crash. Did you look at the C backtrace? >> > >> >> shall we call this Gramps 4.0? >> > >> > I think we'll need to have a bunch of testing releases, so we should >> > probably call it 3.90.x for a while. >> >> I guess with Gramps the x.9 status is implied. For example, trunk has >> been called "3.3" and "3.4" at various times (and is "3.5" currently) >> so that the addon version numbers will match. (The addons need to >> match at least major version number with Gramps.) SVN versions get >> appended onto the displayed version number (after updating const.py >> with ./autogen.sh), so we always can tell one is running trunk. >> >> Since we don't have an official release until it is really ready (and >> usually follow that up with a few point releases) the name is really >> just a place holder. But I thought it might be nice to move it from >> "3.5" to "4.0" to indicate that trunk is now on a >> backwards-incompatible path, and give a clear point for people's >> reference. > > > Yes, this should be version 4.0 later. > Can you do the changes? As you know gramps-addons better, you should have a > good view on what to change. Done. There appears to be an error in ./autogen.sh so make sure you at least: cp src/gen/const.py.in src/gen/const.py > It is a pity we can't do the 3.99 thing, but a release called 4.0-0.alpha is > not a big issue if communication is done correctly. > > About webkit, we are not to do import gtk anywhere in the code! In the docs > I read they claim this leads to issues. As geography is not ready, I also > did not test htmlview. Yes, I just meant this as a workaround. But I think I found the root of the problem and made more notes at: http://gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion > As to allowing lower gi version number for CLI, that is not a problem. As we approach the next release, it looks like it will be entirely possible to have a core gramps package without GUI code, for use in Gramps-Connect, etc. However, by moving all of the graphics subsystems (including PDF creation) to pygobject and friends, that substantially raises the bar for what is needed in a server-based install. For example, I can run gramps-connect with Gramps 4.0 on Python 2.6, Django 1.2 on an old Fedora 13 machine (in fact it is running on http://gramps-connect.org right now). But, I had to use src/plugins/lib/libcairodoc.py and src/plugins/docgen/pdfdoc.py from Gramps 3.5 to allow PDF creation from the webserver. I wonder how we can have both the newer versions, and the older versions? Maybe we could add something else to the gpr file, so that one would load in gramps-gtk, and the other in gramps-connect? -Doug > B. > >> >> -Doug >> >> > Regards, >> > John Ralls >> > > > |
From: John R. <jr...@ce...> - 2012-07-24 14:41:58
|
On Jul 24, 2012, at 12:29 AM, Doug Blank wrote: > On Tue, Jul 24, 2012 at 2:54 AM, Benny Malengier > <ben...@gm...> wrote: >> >> >> 2012/7/24 Doug Blank <dou...@gm...> >>> >>> On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jr...@ce...> wrote: >>>> >>>> On Jul 23, 2012, at 6:39 PM, Doug Blank wrote: >>>> >>>>> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier >>>>> <ben...@gm...> wrote: >>>>>> Ok, >>>>>> >>>>>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk. >>>>>> >>>>>> So crashes abound now. most fixes are simple, look at the changelog >>>>>> done for >>>>>> equal code, and change likewise: >>>>>> >>>>>> >>>>>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057 >>>>>> >>>>>> All glade files not touched yet should be opened in current glade for >>>>>> GTK3 >>>>>> and resaved, then fixed for layout problems. Seen changes in glade >>>>>> files >>>>>> fixed already by me in case of issues. >>>>>> >>>>>> For documentation links, and how to install the new requirements, see >>>>>> the >>>>>> GEP: >>>>>> >>>>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion >>>>>> >>>>>> Fixing the crashes in a part will make you acquinted with the new way >>>>>> of >>>>>> working. >>>>>> >>>>>> I'll fix futher things the coming days. >>>>>> >>>>>> Main issue will probably be geography view which is now disabled. If >>>>>> needed >>>>>> we will have to help out in porting the dependency. On the plus side, >>>>>> the >>>>>> developer will know the code will be used immediately, helping to find >>>>>> bugs. >>>>>> >>>>>> Benny >>>>> >>>>> Great to see this happening! >>>>> >>>>> BTW, I did have a strange hard-crash on Python 2.7.2 without the >>>>> proper pygobject. (I'll no doubt be helping with this port, but I'm >>>>> still working hard to get Gramps-Connect to a near-finished state. So, >>>>> initially I'm just making sure that the CLI use of Gramps works ok >>>>> even without the proper pygobject, as it should.) >>>>> >>>>> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash >>>>> without the ability to try/except when you try to import webkit from a >>>>> Gramps plugin. However, if you "import gtk" early on, then later >>>>> "import webkit" it won't crash. Just thought I'd mention this in case >>>>> anyone is having trouble getting started on the new Gramps... >>>> >>>> That's an interesting crash. Did you look at the C backtrace? >>>> >>>>> shall we call this Gramps 4.0? >>>> >>>> I think we'll need to have a bunch of testing releases, so we should >>>> probably call it 3.90.x for a while. >>> >>> I guess with Gramps the x.9 status is implied. For example, trunk has >>> been called "3.3" and "3.4" at various times (and is "3.5" currently) >>> so that the addon version numbers will match. (The addons need to >>> match at least major version number with Gramps.) SVN versions get >>> appended onto the displayed version number (after updating const.py >>> with ./autogen.sh), so we always can tell one is running trunk. >>> >>> Since we don't have an official release until it is really ready (and >>> usually follow that up with a few point releases) the name is really >>> just a place holder. But I thought it might be nice to move it from >>> "3.5" to "4.0" to indicate that trunk is now on a >>> backwards-incompatible path, and give a clear point for people's >>> reference. >> >> >> Yes, this should be version 4.0 later. >> Can you do the changes? As you know gramps-addons better, you should have a >> good view on what to change. > > Done. There appears to be an error in ./autogen.sh so make sure you at least: > > cp src/gen/const.py.in src/gen/const.py > >> It is a pity we can't do the 3.99 thing, but a release called 4.0-0.alpha is >> not a big issue if communication is done correctly. >> >> About webkit, we are not to do import gtk anywhere in the code! In the docs >> I read they claim this leads to issues. As geography is not ready, I also >> did not test htmlview. > > Yes, I just meant this as a workaround. But I think I found the root > of the problem and made more notes at: > http://gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion I don't see anything about webkit there. Was getting rid of the old gobject the solution? Speaking of the Wiki page, should we open bugs to track the listed problems? > >> As to allowing lower gi version number for CLI, that is not a problem. > > As we approach the next release, it looks like it will be entirely > possible to have a core gramps package without GUI code, for use in > Gramps-Connect, etc. However, by moving all of the graphics subsystems > (including PDF creation) to pygobject and friends, that substantially > raises the bar for what is needed in a server-based install. For > example, I can run gramps-connect with Gramps 4.0 on Python 2.6, > Django 1.2 on an old Fedora 13 machine (in fact it is running on > http://gramps-connect.org right now). But, I had to use > src/plugins/lib/libcairodoc.py and src/plugins/docgen/pdfdoc.py from > Gramps 3.5 to allow PDF creation from the webserver. > > I wonder how we can have both the newer versions, and the older > versions? Maybe we could add something else to the gpr file, so that > one would load in gramps-gtk, and the other in gramps-connect? Rename the pygtk versions and bring them back into trunk, then selectively import? It occurs to me that we're being a bit aggressive in migrating to pygi: Thanks to Bug 679654 [1] (and maybe others), Gramps won't actually run on any current released Gtk. That means that even after the next release cycle it's only going to work on bleeding-edge distros like Ubuntu and Debian Unstable. That's going to freeze out a lot of users. Regards, John Ralls [1] https://bugzilla.gnome.org/show_bug.cgi?id=679654 |