From: Benny M. <ben...@gm...> - 2012-01-26 08:05:21
|
Hi, I believe we should start the push for 3.4. Step 1: Brian, can you make branch 3.4, and a new trunk? Step 2: Doug, can you shift the plugin infrastructure to accomodate this Step 3: All: stabilization of the code, bug fixing. Suggestions: no new features anymore 12 feb (so only bug fix in 3.4 after that) string freeze: 26 feb If we can cleanup the roadmap of 3.4 then in March, we can aim for a beta release end of March. Looking at the roadmap, we should also do a 3.3.2 before that. Greetings, Benny |
From: Doug B. <dou...@gm...> - 2012-01-26 11:54:11
|
On 1/26/12, Benny Malengier <ben...@gm...> wrote: > Hi, > > I believe we should start the push for 3.4. > > Step 1: Brian, can you make branch 3.4, and a new trunk? > Step 2: Doug, can you shift the plugin infrastructure to accomodate this That should already be ready. > Step 3: All: stabilization of the code, bug fixing. I've got a few items in my queue that I will make sure get addressed by Feb 12. Sounds like a plan! -Doug > Suggestions: > no new features anymore 12 feb (so only bug fix in 3.4 after that) > string freeze: 26 feb > > If we can cleanup the roadmap of 3.4 then in March, we can aim for a > beta release end of March. > > Looking at the roadmap, we should also do a 3.3.2 before that. > > Greetings, > Benny > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Brian M. <br...@gr...> - 2012-01-26 13:21:57
|
> I believe we should start the push for 3.4. > > Step 1: Brian, can you make branch 3.4, and a new trunk? I can do that any time. But typically, we don't create the maintenance branch (3.4) until the code is "feature complete" in trunk. That way there are only stability changes and bug fixed going in to the maintenance branch. So if we expect to be feature complete by Feb 12, I think that would be the day to make the 3.4 branch. I will wait until the 12th unless there is a good reason to branch sooner. We don't make a new trunk. Trunk is always trunk. ~Brian |
From: Tim L. <guy...@gm...> - 2012-04-06 10:14:47
|
Brian Matherly wrote > > On 1/26/12, Benny Malengier <[hidden email]> wrote: >> I believe we should start the push for 3.4. > >> >> Step 1: Brian, can you make branch 3.4, <snip> > > I can do that any time. But typically, we don't create the maintenance > branch (3.4) until the code is "feature complete" in trunk. That way there > are only stability changes and bug fixed going in to the maintenance > branch. So if we expect to be feature complete by Feb 12, I think that > would be the day to make the 3.4 branch. I will wait until the 12th unless > there is a good reason to branch sooner. > >> Suggestions: >> no new features anymore 12 feb (so only bug fix in 3.4 after that) >> string freeze: 26 feb >> >> If we can cleanup the roadmap of 3.4 then in March, we can aim for a >> beta release end of March. >> >> Looking at the roadmap, we should also do a 3.3.2 before that. > What is the current state? Jérôme has done a fantastic job on bug triage (many thanks to him), but it has meant that quite a few things that are really either feature requests or annoyances that have existed for a long time have crept into the roadmap (except [1]) since your messages in January 2012. Given that there has been a string freeze since 26 Feb, no new features or major fixes have been introduced since then, so is it now time to progress the release? Is there any appetite for doing 3.3.2? Given apparent shortage of resources, I would be inclined not to proceed with that. Tim. [1] 5656 and 5667 are genuinely new bugs on the new features, I have fixed the first and will do the second soon. -- View this message in context: http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4537071.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Benny M. <ben...@gm...> - 2012-04-06 11:57:45
|
2012/4/6 Tim Lyons <guy...@gm...> > > Brian Matherly wrote > > > > On 1/26/12, Benny Malengier <[hidden email]> wrote: > >> I believe we should start the push for 3.4. > > > >> > >> Step 1: Brian, can you make branch 3.4, <snip> > > > > I can do that any time. But typically, we don't create the maintenance > > branch (3.4) until the code is "feature complete" in trunk. That way > there > > are only stability changes and bug fixed going in to the maintenance > > branch. So if we expect to be feature complete by Feb 12, I think that > > would be the day to make the 3.4 branch. I will wait until the 12th > unless > > there is a good reason to branch sooner. > > > >> Suggestions: > >> no new features anymore 12 feb (so only bug fix in 3.4 after that) > >> string freeze: 26 feb > >> > >> If we can cleanup the roadmap of 3.4 then in March, we can aim for a > >> beta release end of March. > >> > >> Looking at the roadmap, we should also do a 3.3.2 before that. > > > > What is the current state? > > Jérôme has done a fantastic job on bug triage (many thanks to him), but it > has meant that quite a few things that are really either feature requests > or > annoyances that have existed for a long time have crept into the roadmap > (except [1]) since your messages in January 2012. > > Given that there has been a string freeze since 26 Feb, no new features or > major fixes have been introduced since then, so is it now time to progress > the release? > > Is there any appetite for doing 3.3.2? Given apparent shortage of > resources, > I would be inclined not to proceed with that. > I would prefer if both are done. We just need someone to pull this, so we can ask Stephane to release. I have an important solicitation coming up, which is why I missed the end of March to finish up. As the major change is your citation change, perhaps you can finilize 3.4? So finish roadmap (by eg moving to 3.4.1), some final testing, actually installing gramps with make install, and testing the installed version. If this is ok, then you pass the baton to Stephane to decide on a time of release, which should be when you are actually available to help the days after release, should a follow up release be needed shortly after due to an unforeseen problem. Benny > > Tim. > > > [1] 5656 and 5667 are genuinely new bugs on the new features, I have fixed > the first and will do the second soon. > > -- > View this message in context: > http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4537071.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jérôme <rom...@ya...> - 2012-04-06 18:17:27
|
I do not think that Gramps 3.3.1 should be the last release for 3.3.x branch! There is already some duplicate bug-reports about 3.3.1, and fixes or better descriptions on 3.3.2. Remember that some linux distributions/packagers do not provide new major releases. So, we could still have bug-reports for 3.3.x on next months, even after 3.4.x release... If this could help, I should be able to make a '3.3.2' release/archive[1][3]. Maybe, just a problem for myself to properly set the name and to generate well written english textual informations (change log, etc ...) I can generate the archive, which might wait for uploading. Stephane could check it before upload on sourceforge hosting. Otherwise, there is also the fix for last automake versions on 3.3.2[4]. Packagers might test, improve packaging before next major release. This could avoid some bad surprises with 3.4.x. Finally, what should be done with 3.3.3[5]! [1] http://www.gramps-project.org/wiki/index.php?title=What_to_do_for_a_release [2] http://www.gramps-project.org/wiki/index.php?title=What_to_do_for_a_release#Release_name [3] http://www.gramps-project.org/bugs/roadmap_page.php?version_id=28 [4] http://www.gramps-project.org/bugs/changelog_page.php?version_id=28 [5] http://www.gramps-project.org/bugs/roadmap_page.php?version_id=29 Benny Malengier a écrit : > > > 2012/4/6 Tim Lyons <guy...@gm... <mailto:guy...@gm...>> > > > Brian Matherly wrote > > > > On 1/26/12, Benny Malengier <[hidden email]> wrote: > >> I believe we should start the push for 3.4. > > > >> > >> Step 1: Brian, can you make branch 3.4, <snip> > > > > I can do that any time. But typically, we don't create the > maintenance > > branch (3.4) until the code is "feature complete" in trunk. That > way there > > are only stability changes and bug fixed going in to the maintenance > > branch. So if we expect to be feature complete by Feb 12, I think > that > > would be the day to make the 3.4 branch. I will wait until the > 12th unless > > there is a good reason to branch sooner. > > > >> Suggestions: > >> no new features anymore 12 feb (so only bug fix in 3.4 after that) > >> string freeze: 26 feb > >> > >> If we can cleanup the roadmap of 3.4 then in March, we can aim for a > >> beta release end of March. > >> > >> Looking at the roadmap, we should also do a 3.3.2 before that. > > > > What is the current state? > > Jérôme has done a fantastic job on bug triage (many thanks to him), > but it > has meant that quite a few things that are really either feature > requests or > annoyances that have existed for a long time have crept into the roadmap > (except [1]) since your messages in January 2012. > > Given that there has been a string freeze since 26 Feb, no new > features or > major fixes have been introduced since then, so is it now time to > progress > the release? > > Is there any appetite for doing 3.3.2? Given apparent shortage of > resources, > I would be inclined not to proceed with that. > > > I would prefer if both are done. > > We just need someone to pull this, so we can ask Stephane to release. > I have an important solicitation coming up, which is why I missed the > end of March to finish up. > > As the major change is your citation change, perhaps you can finilize > 3.4? So finish roadmap (by eg moving to 3.4.1), some final testing, > actually installing gramps with make install, and testing the installed > version. > > If this is ok, then you pass the baton to Stephane to decide on a time > of release, which should be when you are actually available to help the > days after release, should a follow up release be needed shortly after > due to an unforeseen problem. > > Benny > > > > Tim. > > > [1] 5656 and 5667 are genuinely new bugs on the new features, I have > fixed > the first and will do the second soon. > > -- > View this message in context: > http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4537071.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Tim L. <guy...@gm...> - 2012-04-28 20:37:34
|
Benny Malengier wrote > > 2012/4/6 Tim Lyons <guy.linton@> >> Is there any appetite for doing 3.3.2? Given apparent shortage of >> resources, >> I would be inclined not to proceed with that. >> > > I would prefer if both are done. > > We just need someone to pull this, so we can ask Stephane to release. > I have an important solicitation coming up, which is why I missed the end > of March to finish up. > > As the major change is your citation change, perhaps you can finilize 3.4? > So finish roadmap (by eg moving to 3.4.1), some final testing, actually > installing gramps with make install, and testing the installed version. > > If this is ok, then you pass the baton to Stephane to decide on a time of > release, which should be when you are actually available to help the days > after release, should a follow up release be needed shortly after due to > an > unforeseen problem. > The roadmap is now OK (0005702: "Fadder" in DeepConnectionsGramplet does not look like a bug) I have done the make install, but the translations are installed in /usr/local/lib/locale/<lg>/LC_MESSAGES/gramps.mo, and they don't seem to be found there. this page of the wiki: http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#Running_trunk_with_your_translation says the translations are looked for in /usr/local/share/locale. Which is right - am I doing something wrong - I am not very familiar with the translations? Stephane, how are you fixed for bringing out a new release shortly? Tim -- View this message in context: http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4595279.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Benny M. <ben...@gm...> - 2012-04-29 15:10:37
|
Great work. I don't know about the translations myself, hope somebody else has an idea. I have some time next weekend and the weekend after that. Benny 2012/4/28 Tim Lyons <guy...@gm...> > > Benny Malengier wrote > > > > 2012/4/6 Tim Lyons <guy.linton@> > >> Is there any appetite for doing 3.3.2? Given apparent shortage of > >> resources, > >> I would be inclined not to proceed with that. > >> > > > > I would prefer if both are done. > > > > We just need someone to pull this, so we can ask Stephane to release. > > I have an important solicitation coming up, which is why I missed the end > > of March to finish up. > > > > As the major change is your citation change, perhaps you can finilize > 3.4? > > So finish roadmap (by eg moving to 3.4.1), some final testing, actually > > installing gramps with make install, and testing the installed version. > > > > If this is ok, then you pass the baton to Stephane to decide on a time of > > release, which should be when you are actually available to help the days > > after release, should a follow up release be needed shortly after due to > > an > > unforeseen problem. > > > > The roadmap is now OK (0005702: "Fadder" in DeepConnectionsGramplet does > not > look like a bug) I have done the make install, but the translations are > installed in /usr/local/lib/locale/<lg>/LC_MESSAGES/gramps.mo, and they > don't seem to be found there. > > this page of the wiki: > > http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#Running_trunk_with_your_translation > says the translations are looked for in /usr/local/share/locale. > > Which is right - am I doing something wrong - I am not very familiar with > the translations? > > Stephane, how are you fixed for bringing out a new release shortly? > > Tim > > -- > View this message in context: > http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4595279.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > 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: Jérôme <rom...@ya...> - 2012-05-04 18:46:15
|
DeepConnectionsGramplet is an addon. Gramps is looking at multiple locations/domains for addons. Yes, there is still some minor translation issues (PlaceCompletion or domain with strings using markup into a .glade file ? , hardcoded labels/returns). And I wanted to try to generate an alternative to current 'make.py' by using 'optparse' http://docs.python.org/library/optparse.html or 'argparse' http://docs.python.org/library/argparse.html#module-argparse Anyway, this is not specific to 3.4! Tim Lyons a écrit : > Benny Malengier wrote >> 2012/4/6 Tim Lyons <guy.linton@> >>> Is there any appetite for doing 3.3.2? Given apparent shortage of >>> resources, >>> I would be inclined not to proceed with that. >>> >> I would prefer if both are done. >> >> We just need someone to pull this, so we can ask Stephane to release. >> I have an important solicitation coming up, which is why I missed the end >> of March to finish up. >> >> As the major change is your citation change, perhaps you can finilize 3.4? >> So finish roadmap (by eg moving to 3.4.1), some final testing, actually >> installing gramps with make install, and testing the installed version. >> >> If this is ok, then you pass the baton to Stephane to decide on a time of >> release, which should be when you are actually available to help the days >> after release, should a follow up release be needed shortly after due to >> an >> unforeseen problem. >> > > The roadmap is now OK (0005702: "Fadder" in does not > look like a bug) I have done the make install, but the translations are > installed in /usr/local/lib/locale/<lg>/LC_MESSAGES/gramps.mo, and they > don't seem to be found there. > > this page of the wiki: > http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#Running_trunk_with_your_translation > says the translations are looked for in /usr/local/share/locale. > > Which is right - am I doing something wrong - I am not very familiar with > the translations? > > Stephane, how are you fixed for bringing out a new release shortly? > > Tim > > -- > View this message in context: http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4595279.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > 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: Tim L. <guy...@gm...> - 2012-05-04 21:46:02
|
On 4 May 2012, at 19:46, Jérôme wrote: > DeepConnectionsGramplet is an addon. Since DeepConnections gramplet is an addon, it has no impact on the timing of the 3.4 release (nor on the completeness of the roadmap). > Gramps is looking at multiple locations/domains for addons. I have updated the addons page here: http://www.gramps-project.org/wiki/index.php?title=3.4_Addons to describe how gramps 3.4 looks for addons. It no longer looks in two places. The addons are installed through the Preferences dialogue (except for some which are installed manually). > > Yes, there is still some minor translation issues (PlaceCompletion > or domain with strings using markup into a .glade file ? , hardcoded > labels/returns). The problem I was having with translations is described below. For me 'make install' is installing the translation files in /usr/local/lib/ locale/<lg>/LC_MESSAGES/gramps.mo, but Gramps is not looking there for the files. Maybe it is looking in /usr/local/share/locale, which is where the wiki says the files are. Am I doing something wrong (because I do not usually use the translations)? If there is a real problem here, then it needs to be resolved before the release. regards, Tim. > > And I wanted to try to generate an alternative to current 'make.py' > by using > 'optparse' > http://docs.python.org/library/optparse.html > or 'argparse' > http://docs.python.org/library/argparse.html#module-argparse > > Anyway, this is not specific to 3.4! Yes, let's ignore alternatives to make, because they are not relevant to the 3.4.0 release. (Rob is working on this under GEPS026 in the GEPS026 branch) > > Tim Lyons a écrit : >> Benny Malengier wrote >>> 2012/4/6 Tim Lyons <guy.linton@> >>>> Is there any appetite for doing 3.3.2? Given apparent shortage of >>>> resources, >>>> I would be inclined not to proceed with that. >>>> >>> I would prefer if both are done. >>> >>> We just need someone to pull this, so we can ask Stephane to >>> release. >>> I have an important solicitation coming up, which is why I missed >>> the end >>> of March to finish up. >>> >>> As the major change is your citation change, perhaps you can >>> finilize 3.4? >>> So finish roadmap (by eg moving to 3.4.1), some final testing, >>> actually >>> installing gramps with make install, and testing the installed >>> version. >>> >>> If this is ok, then you pass the baton to Stephane to decide on a >>> time of >>> release, which should be when you are actually available to help >>> the days >>> after release, should a follow up release be needed shortly after >>> due to >>> an >>> unforeseen problem. >>> >> The roadmap is now OK (0005702: "Fadder" in does not >> look like a bug) I have done the make install, but the translations >> are >> installed in /usr/local/lib/locale/<lg>/LC_MESSAGES/gramps.mo, and >> they >> don't seem to be found there. >> this page of the wiki: >> http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#Running_trunk_with_your_translation >> says the translations are looked for in /usr/local/share/locale. >> Which is right - am I doing something wrong - I am not very >> familiar with >> the translations? >> Stephane, how are you fixed for bringing out a new release shortly? >> Tim >> -- >> View this message in context: http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4595279.html >> Sent from the GRAMPS - Dev mailing list archive at Nabble.com. >> ------------------------------------------------------------------------------ >> 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: Jérôme <rom...@ya...> - 2012-05-05 08:01:15
|
Tim, No problem, but only few like bug #5702 , which is a 'addon' issue. There is a custom use of gettext domain under some locales with available translations for addons, see TransUtils module: def get_addon_translator(filename=None, domain="addon", languages=None): """ Get a translator for an addon. filename - filename of a file in directory with full path, or None to get from running code domain - the name of the .mo file under the LANG/LC_MESSAGES dir languages - a list of languages to force returns - a gettext.translation object Example: _ = get_addon_translator(languages=["fr_BE.utf8"]).gettext The return object has the following properties and methods: .gettext .info .lgettext .lngettext .ngettext .output_charset .plural .set_output_charset .ugettext .ungettext Assumes path/filename path/locale/LANG/LC_MESSAGES/addon.mo The 'make.py' is a python script used for handling addons (packaging, listing files, translations, init, etc ...). I just thought on alternative script: nothing related to setup alternative (Makefile) for Gramps itself! My guess was for few minor issues remaining on Addon environment (not only for 3.4). Is markup for Gtkbuilder domain (.glade) properly set for addons? Ot is there any encoding issue related to markup and .glade file? ex: PlaceCompletion addon 'make.py' is a CLI handler but I suppose designed for linux (shell, paths to programs used by script). It is more global, something like described into article "The benefits of open source" [1] --George Wright March 25, 2012 > "Systems are more than the sum of their component parts, if using a free library gets you the functionality that you need and as long as you comply with the licence, it makes good sense. Why reinvent the wheel and forgo what is sometimes years of community development and testing? > > This is not a free software free pass, every business should evaluate the pros and cons of each library or subsystem in light of their needs but to exclude potential solutions because of the free software/open sources stigma is blindness. There are legal implications if you decide to extend these libraries, but it is nowhere near as problematic as often made out." Current addons handling for Gramps sounds like having servers with a centralized translation handler/platform, like pootle[2], transifex[3], launchpad, etc ... associated with a repository (like mobile business/market)! Here, Doug has generated something close to an addon SDK, making handling easier for people familiar with free library. These free ressources/logic_ways used by 'make.py' rather mean 'accessible' and 'fast' handling with few efforts (if you are familiar with linux usage...). Translators contributions is growing with gramps project. eg, *.po files is like main Gramps' API (gen.lib): flexible and independant data/libs! The gramps' ecosystem is powerful but *if* we can spend less time on maintenance this may be also greater, even it is not perfect (ex: cannot use all features provided by/via 'make.py', under Windows platform). It is behind a request for more platforms support, a specific SDK for addons, to still have something fast and flexible, to provide documentation for next developement and needs. I do not like the logic which often forget maintenance (ex: market activity and minor update/developement wanted by the user: iOS, Androïd, Windows, Ubuntu ...) As said before, it was a good surprise to see some alternate release like done by community/user. ex: gramps build service on OpenSuse[4] It is just how I see addons handling! [1] http://www.smh.com.au/technology/the-benefits-of-open-source-20120324-1vqv7.html [2] http://translate.sourceforge.net/wiki/pootle [3] https://www.transifex.net/ [4] https://build.opensuse.org/package/files?package=gramps3&project=home%3Ak-hb regards, Jérôme Tim Lyons a écrit : > > On 4 May 2012, at 19:46, Jérôme wrote: > >> DeepConnectionsGramplet is an addon. > > Since DeepConnections gramplet is an addon, it has no impact on the > timing of the 3.4 release (nor on the completeness of the roadmap). > >> Gramps is looking at multiple locations/domains for addons. > > I have updated the addons page here: > http://www.gramps-project.org/wiki/index.php?title=3.4_Addons > to describe how gramps 3.4 looks for addons. It no longer looks in two > places. The addons are installed through the Preferences dialogue > (except for some which are installed manually). > >> >> Yes, there is still some minor translation issues (PlaceCompletion or >> domain with strings using markup into a .glade file ? , hardcoded >> labels/returns). > > The problem I was having with translations is described below. For me > 'make install' is installing the translation files in > /usr/local/lib/locale/<lg>/LC_MESSAGES/gramps.mo, but Gramps is not > looking there for the files. Maybe it is looking in > /usr/local/share/locale, which is where the wiki says the files are. > > Am I doing something wrong (because I do not usually use the > translations)? If there is a real problem here, then it needs to be > resolved before the release. > > regards, > Tim. > >> >> And I wanted to try to generate an alternative to current 'make.py' by >> using >> 'optparse' >> http://docs.python.org/library/optparse.html >> or 'argparse' >> http://docs.python.org/library/argparse.html#module-argparse >> >> Anyway, this is not specific to 3.4! > > Yes, let's ignore alternatives to make, because they are not relevant to > the 3.4.0 release. (Rob is working on this under GEPS026 in the GEPS026 > branch) > > > ------------------------------------------------------------------------------ > > 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: Doug B. <dou...@gm...> - 2012-05-05 11:59:57
|
(None of this is necessary for Gramps 3.4, but for new features for a future build system for Addons. Although lxml in 3.4 requires special build handling; see below if interested.) Jérôme, I'm sure that there could be better ways of handling Addons rather than using make.py. Background: Currently, make.py does a few things: it does some clever translation merging to minimize the work for translators (eg, it looks in other addons and gramps for any existing translations), builds the tgz files for download, and builds the listing files in each language. But, make.py doesn't have to do everything for an addon: you could have additional tools that build the things that make.py needs. For example, your latest commit says that "lxml addon needs some non-python and non-xml files: css, xsl, dtd, rng; need to find a way via make.py". But as long as you create (and add to svn) the necessary files in po and locale, you can do that in contrib/lxml through whatever mechanism you want (Makefile, setup.py, etc). Also note that you can include files in the tgz file by listing them when you build the addon. But there are some limitations: 1) Can't build the addons on a system that doesn't have the standard Linux tools (eg, Windows) 2) When you "build all" (or "build AddonName") it doesn't know any specifics (eg, such as that outlined above) I'm not too concerned about (1) (but others are free to come up with something better). (2) could be fixed by looking for, and calling, a default addon-specific build command (for example, looking for a "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). Currently when you "build all" or "build lxml" it will not build all that needs building, nor include all of the relevant files (right?). Does this capture what is wrong with the current system? Anything else? -Doug On Sat, May 5, 2012 at 4:01 AM, Jérôme <rom...@ya...> wrote: > Tim, > > > No problem, but only few like bug #5702 , which is a 'addon' issue. > > There is a custom use of gettext domain under some locales with > available translations for addons, see TransUtils module: > > > def get_addon_translator(filename=None, domain="addon", languages=None): > """ > Get a translator for an addon. > > filename - filename of a file in directory with full path, or > None to get from running code > domain - the name of the .mo file under the LANG/LC_MESSAGES dir > languages - a list of languages to force > returns - a gettext.translation object > > Example: > _ = get_addon_translator(languages=["fr_BE.utf8"]).gettext > > The return object has the following properties and methods: > .gettext > .info > .lgettext > .lngettext > .ngettext > .output_charset > .plural > .set_output_charset > .ugettext > .ungettext > > Assumes path/filename > path/locale/LANG/LC_MESSAGES/addon.mo > > > The 'make.py' is a python script used for handling addons (packaging, > listing files, translations, init, etc ...). I just thought on > alternative script: nothing related to setup alternative (Makefile) for > Gramps itself! > > My guess was for few minor issues remaining on Addon environment (not > only for 3.4). > > Is markup for Gtkbuilder domain (.glade) properly set for addons? > Ot is there any encoding issue related to markup and .glade file? > ex: PlaceCompletion addon > > 'make.py' is a CLI handler but I suppose designed for linux (shell, > paths to programs used by script). > > It is more global, something like described into article "The benefits > of open source" [1] --George Wright March 25, 2012 > >> "Systems are more than the sum of their component parts, if using a free library gets you the functionality that you need and as long as you comply with the licence, it makes good sense. Why reinvent the wheel and forgo what is sometimes years of community development and testing? >> >> This is not a free software free pass, every business should evaluate the pros and cons of each library or subsystem in light of their needs but to exclude potential solutions because of the free software/open sources stigma is blindness. There are legal implications if you decide to extend these libraries, but it is nowhere near as problematic as often made out." > > Current addons handling for Gramps sounds like having servers with a > centralized translation handler/platform, like pootle[2], transifex[3], > launchpad, etc ... associated with a repository (like mobile > business/market)! > > Here, Doug has generated something close to an addon SDK, making > handling easier for people familiar with free library. > These free ressources/logic_ways used by 'make.py' rather mean > 'accessible' and 'fast' handling with few efforts (if you are familiar > with linux usage...). > > Translators contributions is growing with gramps project. > eg, *.po files is like main Gramps' API (gen.lib): flexible and > independant data/libs! > > The gramps' ecosystem is powerful but *if* we can spend less time on > maintenance this may be also greater, even it is not perfect (ex: cannot > use all features provided by/via 'make.py', under Windows platform). > > It is behind a request for more platforms support, a specific SDK for > addons, to still have something fast and flexible, to provide > documentation for next developement and needs. > > I do not like the logic which often forget maintenance > (ex: market activity and minor update/developement wanted by the user: > iOS, Androïd, Windows, Ubuntu ...) > > As said before, it was a good surprise to see some alternate release > like done by community/user. ex: gramps build service on OpenSuse[4] > > > It is just how I see addons handling! > > > [1] > http://www.smh.com.au/technology/the-benefits-of-open-source-20120324-1vqv7.html > [2] http://translate.sourceforge.net/wiki/pootle > [3] https://www.transifex.net/ > [4] > https://build.opensuse.org/package/files?package=gramps3&project=home%3Ak-hb > > > regards, > Jérôme > > > Tim Lyons a écrit : >> >> On 4 May 2012, at 19:46, Jérôme wrote: >> >>> DeepConnectionsGramplet is an addon. >> >> Since DeepConnections gramplet is an addon, it has no impact on the >> timing of the 3.4 release (nor on the completeness of the roadmap). >> >>> Gramps is looking at multiple locations/domains for addons. >> >> I have updated the addons page here: >> http://www.gramps-project.org/wiki/index.php?title=3.4_Addons >> to describe how gramps 3.4 looks for addons. It no longer looks in two >> places. The addons are installed through the Preferences dialogue >> (except for some which are installed manually). >> >>> >>> Yes, there is still some minor translation issues (PlaceCompletion or >>> domain with strings using markup into a .glade file ? , hardcoded >>> labels/returns). >> >> The problem I was having with translations is described below. For me >> 'make install' is installing the translation files in >> /usr/local/lib/locale/<lg>/LC_MESSAGES/gramps.mo, but Gramps is not >> looking there for the files. Maybe it is looking in >> /usr/local/share/locale, which is where the wiki says the files are. >> >> Am I doing something wrong (because I do not usually use the >> translations)? If there is a real problem here, then it needs to be >> resolved before the release. >> >> regards, >> Tim. >> >>> >>> And I wanted to try to generate an alternative to current 'make.py' by >>> using >>> 'optparse' >>> http://docs.python.org/library/optparse.html >>> or 'argparse' >>> http://docs.python.org/library/argparse.html#module-argparse >>> >>> Anyway, this is not specific to 3.4! >> >> Yes, let's ignore alternatives to make, because they are not relevant to >> the 3.4.0 release. (Rob is working on this under GEPS026 in the GEPS026 >> branch) >> >> >> ------------------------------------------------------------------------------ >> >> 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 >> >> >> > > > ------------------------------------------------------------------------------ > 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: Jérôme <rom...@ya...> - 2012-05-05 18:15:31
|
Doug, > Does this capture what is wrong with the current system? Yes! I started to look at a possible exception on 'make.py', but you are right I should rather make a custom builder for lxml addon, exception might be for the 'build all' argument (make.py) when matching 'lxml' addon! I should be able to do that. It could be close to what I already did for 'po/update_po.py' on trunk! > Anything else? No! > lxml in 3.4 requires special build handling Yes, this gramplet is already ignored by listing files (feature added by you on 3.4), but it seems that it is also no more possible to install a downloaded addon (tgz files) via Gramps (plugins manager)! It should be minor because, even stable, this gramplet is for testing, having a sample of Gramps XML handling with lxml lib, an experimental Gramps XML validator, a possible quick XML dump, and also a quick way for transforming our data without advanced coding. I do not think this addon is for an every day use. It will be still experimental. So, the download is possible, but as you write, it requires something special for building because it also needs specific files. PS1: about the lxml gramplet itself, there one/two limitations: 1. cannot parse a Gramps XML file more that one time during the session (gramplet/gramps) 2. buffer/cache limitations; I guess like most mobile applications or local scripts: slow down when I display more than 2/3Mo of XML data (raw - plain text). PS2: the Gramps XML validation/parsing via lxml is very sensible (related to C language?). ie, pass it all or a nothing Jérôme Doug Blank a écrit : > (None of this is necessary for Gramps 3.4, but for new features for a > future build system for Addons. Although lxml in 3.4 requires special > build handling; see below if interested.) > > Jérôme, > > I'm sure that there could be better ways of handling Addons rather > than using make.py. Background: Currently, make.py does a few things: > it does some clever translation merging to minimize the work for > translators (eg, it looks in other addons and gramps for any existing > translations), builds the tgz files for download, and builds the > listing files in each language. > > But, make.py doesn't have to do everything for an addon: you could > have additional tools that build the things that make.py needs. > > For example, your latest commit says that "lxml addon needs some > non-python and non-xml files: css, xsl, dtd, rng; need to find a way > via make.py". But as long as you create (and add to svn) the necessary > files in po and locale, you can do that in contrib/lxml through > whatever mechanism you want (Makefile, setup.py, etc). > > Also note that you can include files in the tgz file by listing them > when you build the addon. But there are some limitations: > > 1) Can't build the addons on a system that doesn't have the standard > Linux tools (eg, Windows) > 2) When you "build all" (or "build AddonName") it doesn't know any > specifics (eg, such as that outlined above) > > I'm not too concerned about (1) (but others are free to come up with > something better). (2) could be fixed by looking for, and calling, a > default addon-specific build command (for example, looking for a > "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). > Currently when you "build all" or "build lxml" it will not build all > that needs building, nor include all of the relevant files (right?). > > Does this capture what is wrong with the current system? Anything else? > > -Doug > > On Sat, May 5, 2012 at 4:01 AM, Jérôme <rom...@ya...> wrote: >> Tim, >> >> >> No problem, but only few like bug #5702 , which is a 'addon' issue. >> >> There is a custom use of gettext domain under some locales with >> available translations for addons, see TransUtils module: >> >> >> def get_addon_translator(filename=None, domain="addon", languages=None): >> """ >> Get a translator for an addon. >> >> filename - filename of a file in directory with full path, or >> None to get from running code >> domain - the name of the .mo file under the LANG/LC_MESSAGES dir >> languages - a list of languages to force >> returns - a gettext.translation object >> >> Example: >> _ = get_addon_translator(languages=["fr_BE.utf8"]).gettext >> >> The return object has the following properties and methods: >> .gettext >> .info >> .lgettext >> .lngettext >> .ngettext >> .output_charset >> .plural >> .set_output_charset >> .ugettext >> .ungettext >> >> Assumes path/filename >> path/locale/LANG/LC_MESSAGES/addon.mo >> >> >> The 'make.py' is a python script used for handling addons (packaging, >> listing files, translations, init, etc ...). I just thought on >> alternative script: nothing related to setup alternative (Makefile) for >> Gramps itself! >> >> My guess was for few minor issues remaining on Addon environment (not >> only for 3.4). >> >> Is markup for Gtkbuilder domain (.glade) properly set for addons? >> Ot is there any encoding issue related to markup and .glade file? >> ex: PlaceCompletion addon >> >> 'make.py' is a CLI handler but I suppose designed for linux (shell, >> paths to programs used by script). >> >> It is more global, something like described into article "The benefits >> of open source" [1] --George Wright March 25, 2012 >> >>> "Systems are more than the sum of their component parts, if using a free library gets you the functionality that you need and as long as you comply with the licence, it makes good sense. Why reinvent the wheel and forgo what is sometimes years of community development and testing? >>> >>> This is not a free software free pass, every business should evaluate the pros and cons of each library or subsystem in light of their needs but to exclude potential solutions because of the free software/open sources stigma is blindness. There are legal implications if you decide to extend these libraries, but it is nowhere near as problematic as often made out." >> Current addons handling for Gramps sounds like having servers with a >> centralized translation handler/platform, like pootle[2], transifex[3], >> launchpad, etc ... associated with a repository (like mobile >> business/market)! >> >> Here, Doug has generated something close to an addon SDK, making >> handling easier for people familiar with free library. >> These free ressources/logic_ways used by 'make.py' rather mean >> 'accessible' and 'fast' handling with few efforts (if you are familiar >> with linux usage...). >> >> Translators contributions is growing with gramps project. >> eg, *.po files is like main Gramps' API (gen.lib): flexible and >> independant data/libs! >> >> The gramps' ecosystem is powerful but *if* we can spend less time on >> maintenance this may be also greater, even it is not perfect (ex: cannot >> use all features provided by/via 'make.py', under Windows platform). >> >> It is behind a request for more platforms support, a specific SDK for >> addons, to still have something fast and flexible, to provide >> documentation for next developement and needs. >> >> I do not like the logic which often forget maintenance >> (ex: market activity and minor update/developement wanted by the user: >> iOS, Androïd, Windows, Ubuntu ...) >> >> As said before, it was a good surprise to see some alternate release >> like done by community/user. ex: gramps build service on OpenSuse[4] >> >> >> It is just how I see addons handling! >> >> >> [1] >> http://www.smh.com.au/technology/the-benefits-of-open-source-20120324-1vqv7.html >> [2] http://translate.sourceforge.net/wiki/pootle >> [3] https://www.transifex.net/ >> [4] >> https://build.opensuse.org/package/files?package=gramps3&project=home%3Ak-hb >> >> >> regards, >> Jérôme >> >> >> Tim Lyons a écrit : >>> On 4 May 2012, at 19:46, Jérôme wrote: >>> >>>> DeepConnectionsGramplet is an addon. >>> Since DeepConnections gramplet is an addon, it has no impact on the >>> timing of the 3.4 release (nor on the completeness of the roadmap). >>> >>>> Gramps is looking at multiple locations/domains for addons. >>> I have updated the addons page here: >>> http://www.gramps-project.org/wiki/index.php?title=3.4_Addons >>> to describe how gramps 3.4 looks for addons. It no longer looks in two >>> places. The addons are installed through the Preferences dialogue >>> (except for some which are installed manually). >>> >>>> Yes, there is still some minor translation issues (PlaceCompletion or >>>> domain with strings using markup into a .glade file ? , hardcoded >>>> labels/returns). >>> The problem I was having with translations is described below. For me >>> 'make install' is installing the translation files in >>> /usr/local/lib/locale/<lg>/LC_MESSAGES/gramps.mo, but Gramps is not >>> looking there for the files. Maybe it is looking in >>> /usr/local/share/locale, which is where the wiki says the files are. >>> >>> Am I doing something wrong (because I do not usually use the >>> translations)? If there is a real problem here, then it needs to be >>> resolved before the release. >>> >>> regards, >>> Tim. >>> >>>> And I wanted to try to generate an alternative to current 'make.py' by >>>> using >>>> 'optparse' >>>> http://docs.python.org/library/optparse.html >>>> or 'argparse' >>>> http://docs.python.org/library/argparse.html#module-argparse >>>> >>>> Anyway, this is not specific to 3.4! >>> Yes, let's ignore alternatives to make, because they are not relevant to >>> the 3.4.0 release. (Rob is working on this under GEPS026 in the GEPS026 >>> branch) >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> 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 >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> 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: Jérôme <rom...@ya...> - 2012-05-09 17:10:41
|
Doug, > your latest commit says that "lxml addon needs some > non-python and non-xml files: css, xsl, dtd, rng; need to find a way > via make.py". But as long as you create (and add to svn) the necessary > files in po and locale, you can do that in contrib/lxml through > whatever mechanism you want (Makefile, setup.py, etc). > .. > 2) When you "build all" (or "build AddonName") it doesn't know any > specifics (eg, such as that outlined above) > .. > (2) could be fixed by looking for, and calling, a > default addon-specific build command (for example, looking for a > "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). > Currently when you "build all" or "build lxml" it will not build all > that needs building, nor include all of the relevant files (right?). 'lxml' gramplet is ignored by listing. So, I only made a minor change on rev1262 [1]: 1. 'python make.py build all' command: To continue when addon is matching 'lxml'! Compilation for translations on lxml addon is not a problem. 2. I have generated a custom 'lxml/setup.py' (just 'setup' as name, not related to distutils or others builders!) for 'lxml' addon. I tried to keep 'make.py' logic, some refactoring (only one addon!) and I let the kwargs stuff alone (too complicated for me). True, I suppose it is also possible to call "python lxml/setup.py -b" instead of ignoring this addon into 'python make.py build lxml' /or build all/ commands. As this addon is ignored by listing files, we do not really need to build lxml! I thought on one improvement for this addon: to parse XPaths_xx.txt files, line per line, for having a simple query variable (walk into Gramps XML). But there is so many XPath parsers with specific issues (also for lxml related libs and memory cache), that this does not make sense! ie. fixed with a custom builder for lxml gramplet and do not need to often re-build this package or to build it with others addons. This should be OK on next time one will call building process via make.py. Note, I also tested an alternative to 'intltool-extract' for 'census.xml'! from xml.etree import ElementTree tree = ElementTree.parse('census.xml') root = tree.getroot() python_v = sys.version_info #if python_v[1] != 6: # python 2.7 # iter() is the new name for getiterator; # in ET 1.3, it is implemented as a generator method, # but is otherwise identical catalog = open('xml.h', 'w') for key in root.getiterator('_attribute'): catalog.write('char *s = N_("%s");\n' % key.text) catalog.close() .. if os.path.isfile('census.xml'): os.system('''%(xgettext)s --keyword=N_ --add-comments -j''' ''' --from-code=UTF-8 -o "po/template.pot" xml.h''' % {'xgettext': xgettextCmd} ) It is simple and does not need 'intltool' (make.py). [1] http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?revision=1262&view=revision Thanks! Jérôme Jérôme a écrit : > Doug, > >> Does this capture what is wrong with the current system? > > Yes! > I started to look at a possible exception on 'make.py', but you are > right I should rather make a custom builder for lxml addon, exception > might be for the 'build all' argument (make.py) when matching 'lxml' addon! > > I should be able to do that. > It could be close to what I already did for 'po/update_po.py' on trunk! > >> Anything else? > > No! > >> lxml in 3.4 requires special build handling > > Yes, this gramplet is already ignored by listing files (feature added by > you on 3.4), but it seems that it is also no more possible to install a > downloaded addon (tgz files) via Gramps (plugins manager)! > > It should be minor because, even stable, this gramplet is for testing, > having a sample of Gramps XML handling with lxml lib, an experimental > Gramps XML validator, a possible quick XML dump, and also a quick way > for transforming our data without advanced coding. I do not think this > addon is for an every day use. It will be still experimental. > > So, the download is possible, but as you write, it requires something > special for building because it also needs specific files. > > PS1: about the lxml gramplet itself, there one/two limitations: > 1. cannot parse a Gramps XML file more that one time during the session > (gramplet/gramps) > 2. buffer/cache limitations; I guess like most mobile applications or > local scripts: slow down when I display more than 2/3Mo of XML data (raw > - plain text). > > PS2: the Gramps XML validation/parsing via lxml is very sensible > (related to C language?). ie, pass it all or a nothing > > > Jérôme > > > Doug Blank a écrit : >> (None of this is necessary for Gramps 3.4, but for new features for a >> future build system for Addons. Although lxml in 3.4 requires special >> build handling; see below if interested.) >> >> Jérôme, >> >> I'm sure that there could be better ways of handling Addons rather >> than using make.py. Background: Currently, make.py does a few things: >> it does some clever translation merging to minimize the work for >> translators (eg, it looks in other addons and gramps for any existing >> translations), builds the tgz files for download, and builds the >> listing files in each language. >> >> But, make.py doesn't have to do everything for an addon: you could >> have additional tools that build the things that make.py needs. >> >> For example, your latest commit says that "lxml addon needs some >> non-python and non-xml files: css, xsl, dtd, rng; need to find a way >> via make.py". But as long as you create (and add to svn) the necessary >> files in po and locale, you can do that in contrib/lxml through >> whatever mechanism you want (Makefile, setup.py, etc). >> >> Also note that you can include files in the tgz file by listing them >> when you build the addon. But there are some limitations: >> >> 1) Can't build the addons on a system that doesn't have the standard >> Linux tools (eg, Windows) >> 2) When you "build all" (or "build AddonName") it doesn't know any >> specifics (eg, such as that outlined above) >> >> I'm not too concerned about (1) (but others are free to come up with >> something better). (2) could be fixed by looking for, and calling, a >> default addon-specific build command (for example, looking for a >> "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). >> Currently when you "build all" or "build lxml" it will not build all >> that needs building, nor include all of the relevant files (right?). >> >> Does this capture what is wrong with the current system? Anything else? >> >> -Doug >> >> ------------------------------------------------------------------------------ _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > |
From: Doug B. <dou...@gm...> - 2012-05-09 17:41:10
|
On Wed, May 9, 2012 at 1:10 PM, Jérôme <rom...@ya...> wrote: > Doug, > >> your latest commit says that "lxml addon needs some >> non-python and non-xml files: css, xsl, dtd, rng; need to find a way >> via make.py". But as long as you create (and add to svn) the necessary >> files in po and locale, you can do that in contrib/lxml through >> whatever mechanism you want (Makefile, setup.py, etc). >> .. >> >> 2) When you "build all" (or "build AddonName") it doesn't know any >> specifics (eg, such as that outlined above) >> .. >> >> (2) could be fixed by looking for, and calling, a >> default addon-specific build command (for example, looking for a >> "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). >> Currently when you "build all" or "build lxml" it will not build all >> that needs building, nor include all of the relevant files (right?). > > > 'lxml' gramplet is ignored by listing. > > So, I only made a minor change on rev1262 [1]: > > 1. 'python make.py build all' command: > To continue when addon is matching 'lxml'! > Compilation for translations on lxml addon is not a problem. > > 2. I have generated a custom 'lxml/setup.py' (just 'setup' as name, not > related to distutils or others builders!) for 'lxml' addon. I tried to keep > 'make.py' logic, some refactoring (only one addon!) and I let the kwargs > stuff alone (too complicated for me). > > True, I suppose it is also possible to call "python lxml/setup.py -b" > instead of ignoring this addon into 'python make.py build lxml' /or build > all/ commands. Ok, but let's not leave it like this... this is a hack that we should fix with a solution that will work for future variations. Can you change it so that: if there is a */setup.py file (like you have) then we call it (we can just os.system("cd Addon; python setup.py") to keep it simple. Your setup.py can check timestamps to see if there is anything to do, like Makefile). Otherwise, we do what we would do normally. That is one sophisticated setup.py file! Glad you got it to work. -Doug > As this addon is ignored by listing files, we do not really need to build > lxml! I thought on one improvement for this addon: to parse XPaths_xx.txt > files, line per line, for having a simple query variable (walk into Gramps > XML). But there is so many XPath parsers with specific issues (also for lxml > related libs and memory cache), that this does not make sense! > > ie. fixed with a custom builder for lxml gramplet and do not need to often > re-build this package or to build it with others addons. > This should be OK on next time one will call building process via make.py. > > > Note, I also tested an alternative to 'intltool-extract' for 'census.xml'! > > from xml.etree import ElementTree > > tree = ElementTree.parse('census.xml') > root = tree.getroot() > > python_v = sys.version_info > > #if python_v[1] != 6: > > # python 2.7 > # iter() is the new name for getiterator; > # in ET 1.3, it is implemented as a generator method, > # but is otherwise identical > > catalog = open('xml.h', 'w') > > for key in root.getiterator('_attribute'): > catalog.write('char *s = N_("%s");\n' % key.text) > > catalog.close() > > .. > > if os.path.isfile('census.xml'): > os.system('''%(xgettext)s --keyword=N_ --add-comments -j''' > ''' --from-code=UTF-8 -o "po/template.pot" xml.h''' > % {'xgettext': xgettextCmd} > ) > > It is simple and does not need 'intltool' (make.py). > > > > [1] > http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?revision=1262&view=revision > > > Thanks! > Jérôme > > > > Jérôme a écrit : >> >> Doug, >> >>> Does this capture what is wrong with the current system? >> >> >> Yes! >> I started to look at a possible exception on 'make.py', but you are right >> I should rather make a custom builder for lxml addon, exception might be for >> the 'build all' argument (make.py) when matching 'lxml' addon! >> >> I should be able to do that. >> It could be close to what I already did for 'po/update_po.py' on trunk! >> >>> Anything else? >> >> >> No! >> >>> lxml in 3.4 requires special build handling >> >> >> Yes, this gramplet is already ignored by listing files (feature added by >> you on 3.4), but it seems that it is also no more possible to install a >> downloaded addon (tgz files) via Gramps (plugins manager)! >> >> It should be minor because, even stable, this gramplet is for testing, >> having a sample of Gramps XML handling with lxml lib, an experimental Gramps >> XML validator, a possible quick XML dump, and also a quick way for >> transforming our data without advanced coding. I do not think this addon is >> for an every day use. It will be still experimental. >> >> So, the download is possible, but as you write, it requires something >> special for building because it also needs specific files. >> >> PS1: about the lxml gramplet itself, there one/two limitations: >> 1. cannot parse a Gramps XML file more that one time during the session >> (gramplet/gramps) >> 2. buffer/cache limitations; I guess like most mobile applications or >> local scripts: slow down when I display more than 2/3Mo of XML data (raw - >> plain text). >> >> PS2: the Gramps XML validation/parsing via lxml is very sensible (related >> to C language?). ie, pass it all or a nothing >> >> >> Jérôme >> >> >> Doug Blank a écrit : >>> >>> (None of this is necessary for Gramps 3.4, but for new features for a >>> future build system for Addons. Although lxml in 3.4 requires special >>> build handling; see below if interested.) >>> >>> Jérôme, >>> >>> I'm sure that there could be better ways of handling Addons rather >>> than using make.py. Background: Currently, make.py does a few things: >>> it does some clever translation merging to minimize the work for >>> translators (eg, it looks in other addons and gramps for any existing >>> translations), builds the tgz files for download, and builds the >>> listing files in each language. >>> >>> But, make.py doesn't have to do everything for an addon: you could >>> have additional tools that build the things that make.py needs. >>> >>> For example, your latest commit says that "lxml addon needs some >>> non-python and non-xml files: css, xsl, dtd, rng; need to find a way >>> via make.py". But as long as you create (and add to svn) the necessary >>> files in po and locale, you can do that in contrib/lxml through >>> whatever mechanism you want (Makefile, setup.py, etc). >>> >>> Also note that you can include files in the tgz file by listing them >>> when you build the addon. But there are some limitations: >>> >>> 1) Can't build the addons on a system that doesn't have the standard >>> Linux tools (eg, Windows) >>> 2) When you "build all" (or "build AddonName") it doesn't know any >>> specifics (eg, such as that outlined above) >>> >>> I'm not too concerned about (1) (but others are free to come up with >>> something better). (2) could be fixed by looking for, and calling, a >>> default addon-specific build command (for example, looking for a >>> "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). >>> Currently when you "build all" or "build lxml" it will not build all >>> that needs building, nor include all of the relevant files (right?). >>> >>> Does this capture what is wrong with the current system? Anything else? >>> >>> -Doug >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> > |
From: Jérôme <rom...@ya...> - 2012-05-10 10:28:22
|
Doug, > Ok, but let's not leave it like this... this is a hack that we should > fix with a solution that will work for future variations. It should be nicer/proper after rev1273[1]. Thank you! > That is one sophisticated setup.py file! Glad you got it to work. It is a part of 'make.py' derived from my first experimentations on 'po/update_po.py' (trunk)[2], which has been inherited from and is related to 'po/check_po'[3]! Powered by python, gettext and Gnu tools. :) I am not certain to provide paths for windows platform is very useful, it is just more accessible than 'make.py'! Some few minor issues are remaining (ie. do not need to call 'mkdir -p locale' every time!). Anyway, it also adds a new feature against current make.py: the quicker ability to update/create all locales according existing translations (gramps program) with one argument (it is also for only one addon = more easy!)... [1] http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?revision=1273&view=revision [2] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/update_po.py [3] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/check_po Jérôme Doug Blank a écrit : > On Wed, May 9, 2012 at 1:10 PM, Jérôme <rom...@ya...> wrote: >> Doug, >> >>> your latest commit says that "lxml addon needs some >>> non-python and non-xml files: css, xsl, dtd, rng; need to find a way >>> via make.py". But as long as you create (and add to svn) the necessary >>> files in po and locale, you can do that in contrib/lxml through >>> whatever mechanism you want (Makefile, setup.py, etc). >>> .. >>> >>> 2) When you "build all" (or "build AddonName") it doesn't know any >>> specifics (eg, such as that outlined above) >>> .. >>> >>> (2) could be fixed by looking for, and calling, a >>> default addon-specific build command (for example, looking for a >>> "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). >>> Currently when you "build all" or "build lxml" it will not build all >>> that needs building, nor include all of the relevant files (right?). >> >> 'lxml' gramplet is ignored by listing. >> >> So, I only made a minor change on rev1262 [1]: >> >> 1. 'python make.py build all' command: >> To continue when addon is matching 'lxml'! >> Compilation for translations on lxml addon is not a problem. >> >> 2. I have generated a custom 'lxml/setup.py' (just 'setup' as name, not >> related to distutils or others builders!) for 'lxml' addon. I tried to keep >> 'make.py' logic, some refactoring (only one addon!) and I let the kwargs >> stuff alone (too complicated for me). >> >> True, I suppose it is also possible to call "python lxml/setup.py -b" >> instead of ignoring this addon into 'python make.py build lxml' /or build >> all/ commands. > > Ok, but let's not leave it like this... this is a hack that we should > fix with a solution that will work for future variations. > > Can you change it so that: > > if there is a */setup.py file (like you have) then we call it (we can > just os.system("cd Addon; python setup.py") to keep it simple. Your > setup.py can check timestamps to see if there is anything to do, like > Makefile). Otherwise, we do what we would do normally. > > That is one sophisticated setup.py file! Glad you got it to work. > > -Doug > >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>> > |
From: Doug B. <dou...@gm...> - 2012-05-10 14:28:22
|
On Thu, May 10, 2012 at 6:28 AM, Jérôme <rom...@ya...> wrote: > Doug, > > >> Ok, but let's not leave it like this... this is a hack that we should >> fix with a solution that will work for future variations. > > > It should be nicer/proper after rev1273[1]. Yes, that is better! But we should not check the addon name, but to see if there is a "setup.py" in the addon directory. I can help this weekend if you get stuck on that... it should be easy, something like: if os.path.exists("%s/setup.py" % path_to_addon): ... system("cd ...") (there is a isfile() somewhere which is better for this use) This would be instead of checking for "lxml" specifically. Then, anyone can put additional build code in setup.py. Thanks! -Doug > Thank you! > > >> That is one sophisticated setup.py file! Glad you got it to work. > > > It is a part of 'make.py' derived from my first experimentations on > 'po/update_po.py' (trunk)[2], which has been inherited from and is related > to 'po/check_po'[3]! > Powered by python, gettext and Gnu tools. :) > > I am not certain to provide paths for windows platform is very useful, it is > just more accessible than 'make.py'! > > Some few minor issues are remaining (ie. do not need to call 'mkdir -p > locale' every time!). > > Anyway, it also adds a new feature against current make.py: the quicker > ability to update/create all locales according existing translations (gramps > program) with one argument (it is also for only one addon = more easy!)... > > > [1] > http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?revision=1273&view=revision > [2] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/update_po.py > [3] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/check_po > > > > Jérôme > > > Doug Blank a écrit : >> >> On Wed, May 9, 2012 at 1:10 PM, Jérôme <rom...@ya...> wrote: >> >>> Doug, >>> >>>> your latest commit says that "lxml addon needs some >>>> non-python and non-xml files: css, xsl, dtd, rng; need to find a way >>>> via make.py". But as long as you create (and add to svn) the necessary >>>> files in po and locale, you can do that in contrib/lxml through >>>> whatever mechanism you want (Makefile, setup.py, etc). >>>> .. >>>> >>>> 2) When you "build all" (or "build AddonName") it doesn't know any >>>> specifics (eg, such as that outlined above) >>>> .. >>>> >>>> (2) could be fixed by looking for, and calling, a >>>> default addon-specific build command (for example, looking for a >>>> "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). >>>> Currently when you "build all" or "build lxml" it will not build all >>>> that needs building, nor include all of the relevant files (right?). >>> >>> >>> 'lxml' gramplet is ignored by listing. >>> >>> So, I only made a minor change on rev1262 [1]: >>> >>> 1. 'python make.py build all' command: >>> To continue when addon is matching 'lxml'! >>> Compilation for translations on lxml addon is not a problem. >>> >>> 2. I have generated a custom 'lxml/setup.py' (just 'setup' as name, not >>> related to distutils or others builders!) for 'lxml' addon. I tried to >>> keep >>> 'make.py' logic, some refactoring (only one addon!) and I let the kwargs >>> stuff alone (too complicated for me). >>> >>> True, I suppose it is also possible to call "python lxml/setup.py -b" >>> instead of ignoring this addon into 'python make.py build lxml' /or build >>> all/ commands. >> >> >> Ok, but let's not leave it like this... this is a hack that we should >> fix with a solution that will work for future variations. >> >> Can you change it so that: >> >> if there is a */setup.py file (like you have) then we call it (we can >> just os.system("cd Addon; python setup.py") to keep it simple. Your >> setup.py can check timestamps to see if there is anything to do, like >> Makefile). Otherwise, we do what we would do normally. >> >> That is one sophisticated setup.py file! Glad you got it to work. >> >> -Doug >> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> >>>>> Gramps-devel mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>> >>>> >> > |
From: Jérôme <rom...@ya...> - 2012-05-11 05:25:57
|
OK, something like: - if addon == 'lxml': - system('''cd lxml; python setup.py --build''') + if os.path.isfile('*/setup.py'): + system('''cd %(addon)s; python setup.py --build''') Note, 'setup.py' file might be used for addons with additional files? ie. not 'pure' python, addons with .glade, .css, .xml, etc ... files eg, "Census", "ChangeGivenNames", "PlaceCompletion", "lxml". This will avoid to check translation strings on .xml and .glade files (and will avoid to print warnings) when there is none of them for this addon. On previous gramps' releases, we always merged some strings back during build time (holidays, tips, etc ...)! I suppose it was related to the given sample (Gtk/Gnome), used as model? When Josip has generated bundle packages for gramps, he pointed out that run time also translates these strings once these translations exist on catalog! ie. do not need to generate copies of xml files during build time (except for desktop/menu/mime keys). Here for addons, as we also just need to extract strings from files (.xml, .glade), we can try our own cooking with SAX or ElementTree? //I got stuck with the new name for getiterator() on E.T 1.3 (python 2.7), else I found logical to also use python for extracting these strings// There was an other thread/post on mailing list (~ 1 month ago) about the use of intltool as dependency and related (perl). This might also help to track down the missing/wrong gettext return on some .glade files (addon domain). Jérôme Doug Blank a écrit : > On Thu, May 10, 2012 at 6:28 AM, Jérôme <rom...@ya...> wrote: >> Doug, >> >> >>> Ok, but let's not leave it like this... this is a hack that we should >>> fix with a solution that will work for future variations. >> >> It should be nicer/proper after rev1273[1]. > > Yes, that is better! But we should not check the addon name, but to > see if there is a "setup.py" in the addon directory. I can help this > weekend if you get stuck on that... it should be easy, something like: > > if os.path.exists("%s/setup.py" % path_to_addon): > ... system("cd ...") > > (there is a isfile() somewhere which is better for this use) > > This would be instead of checking for "lxml" specifically. Then, > anyone can put additional build code in setup.py. > > Thanks! > > -Doug > >> Thank you! >> >> >>> That is one sophisticated setup.py file! Glad you got it to work. >> >> It is a part of 'make.py' derived from my first experimentations on >> 'po/update_po.py' (trunk)[2], which has been inherited from and is related >> to 'po/check_po'[3]! >> Powered by python, gettext and Gnu tools. :) >> >> I am not certain to provide paths for windows platform is very useful, it is >> just more accessible than 'make.py'! >> >> Some few minor issues are remaining (ie. do not need to call 'mkdir -p >> locale' every time!). >> >> Anyway, it also adds a new feature against current make.py: the quicker >> ability to update/create all locales according existing translations (gramps >> program) with one argument (it is also for only one addon = more easy!)... >> >> >> [1] >> http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?revision=1273&view=revision >> [2] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/update_po.py >> [3] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/check_po >> >> >> >> Jérôme >> >> >> Doug Blank a écrit : >>> On Wed, May 9, 2012 at 1:10 PM, Jérôme <rom...@ya...> wrote: >>> >>>> Doug, >>>> >>>>> your latest commit says that "lxml addon needs some >>>>> non-python and non-xml files: css, xsl, dtd, rng; need to find a way >>>>> via make.py". But as long as you create (and add to svn) the necessary >>>>> files in po and locale, you can do that in contrib/lxml through >>>>> whatever mechanism you want (Makefile, setup.py, etc). >>>>> .. >>>>> >>>>> 2) When you "build all" (or "build AddonName") it doesn't know any >>>>> specifics (eg, such as that outlined above) >>>>> .. >>>>> >>>>> (2) could be fixed by looking for, and calling, a >>>>> default addon-specific build command (for example, looking for a >>>>> "AddonName/Makefile" or "AddonName/setup.py" or "AddonName/Manifest"). >>>>> Currently when you "build all" or "build lxml" it will not build all >>>>> that needs building, nor include all of the relevant files (right?). >>>> >>>> 'lxml' gramplet is ignored by listing. >>>> >>>> So, I only made a minor change on rev1262 [1]: >>>> >>>> 1. 'python make.py build all' command: >>>> To continue when addon is matching 'lxml'! >>>> Compilation for translations on lxml addon is not a problem. >>>> >>>> 2. I have generated a custom 'lxml/setup.py' (just 'setup' as name, not >>>> related to distutils or others builders!) for 'lxml' addon. I tried to >>>> keep >>>> 'make.py' logic, some refactoring (only one addon!) and I let the kwargs >>>> stuff alone (too complicated for me). >>>> >>>> True, I suppose it is also possible to call "python lxml/setup.py -b" >>>> instead of ignoring this addon into 'python make.py build lxml' /or build >>>> all/ commands. >>> >>> Ok, but let's not leave it like this... this is a hack that we should >>> fix with a solution that will work for future variations. >>> >>> Can you change it so that: >>> >>> if there is a */setup.py file (like you have) then we call it (we can >>> just os.system("cd Addon; python setup.py") to keep it simple. Your >>> setup.py can check timestamps to see if there is anything to do, like >>> Makefile). Otherwise, we do what we would do normally. >>> >>> That is one sophisticated setup.py file! Glad you got it to work. >>> >>> -Doug >>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> >>>>>> Gramps-devel mailing list >>>>>> Gra...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>> > |
From: Jérôme <rom...@ya...> - 2012-05-11 15:23:03
|
Doug, It should be OK for others '*/setup.py' files in the future (if need)[1] after rev1275/6 [2]! I also cleaned a little bit 'lxml/setup.py' because it seems that I am no more allowed to re-use 'fuzzy matching' on strings! I thought we can set an option/flag somewhere, but it seems to be a default option on some specific cases, which I did not used/called on current sequence! Anyway, it is a cosmetic option. Most important is the fix for gramps 3.4 environment. Patched version[1] generates the expected result, but I do not know if there is a coding convention on this piece of code. So, I tried to keep the same logic as global file (make.py). [1] http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/trunk/contrib/make.py?view=patch&r1=1275&r2=1274&pathrev=1275 [2] http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?revision=1275&view=revision Jérôme a écrit : > OK, something like: > > - if addon == 'lxml': > - system('''cd lxml; python setup.py --build''') > + if os.path.isfile('*/setup.py'): > + system('''cd %(addon)s; python setup.py --build''') > > Note, 'setup.py' file might be used for addons with additional files? > ie. not 'pure' python, addons with .glade, .css, .xml, etc ... files > eg, "Census", "ChangeGivenNames", "PlaceCompletion", "lxml". > > This will avoid to check translation strings on .xml and .glade files > (and will avoid to print warnings) when there is none of them for this > addon. > > On previous gramps' releases, we always merged some strings back during > build time (holidays, tips, etc ...)! I suppose it was related to the > given sample (Gtk/Gnome), used as model? When Josip has generated bundle > packages for gramps, he pointed out that run time also translates these > strings once these translations exist on catalog! ie. do not need to > generate copies of xml files during build time (except for > desktop/menu/mime keys). > > Here for addons, as we also just need to extract strings from files > (.xml, .glade), we can try our own cooking with SAX or ElementTree? > //I got stuck with the new name for getiterator() on E.T 1.3 (python > 2.7), else I found logical to also use python for extracting these strings// > > There was an other thread/post on mailing list (~ 1 month ago) about the > use of intltool as dependency and related (perl). > > This might also help to track down the missing/wrong gettext return on > some .glade files (addon domain). > > > Jérôme > > > Doug Blank a écrit : >> On Thu, May 10, 2012 at 6:28 AM, Jérôme <rom...@ya...> wrote: >>> Doug, >>> >>> >>>> Ok, but let's not leave it like this... this is a hack that we should >>>> fix with a solution that will work for future variations. >>> It should be nicer/proper after rev1273[1]. >> Yes, that is better! But we should not check the addon name, but to >> see if there is a "setup.py" in the addon directory. I can help this >> weekend if you get stuck on that... it should be easy, something like: >> >> if os.path.exists("%s/setup.py" % path_to_addon): >> ... system("cd ...") >> >> (there is a isfile() somewhere which is better for this use) >> >> This would be instead of checking for "lxml" specifically. Then, >> anyone can put additional build code in setup.py. >> >> Thanks! >> >> -Doug > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Doug B. <dou...@gm...> - 2012-05-11 17:22:01
|
Jérôme, The changes to make.py look good; thank you for that! I think those addons that have missing translations will need to have some processing applied to their glade files. But maybe you (or Perter) understand the issue better. -Doug On Fri, May 11, 2012 at 11:22 AM, Jérôme <rom...@ya...> wrote: > Doug, > > > It should be OK for others '*/setup.py' files in the future (if need)[1] > after rev1275/6 [2]! > > I also cleaned a little bit 'lxml/setup.py' because it seems that I am no > more allowed to re-use 'fuzzy matching' on strings! > I thought we can set an option/flag somewhere, but it seems to be a default > option on some specific cases, which I did not used/called on current > sequence! > > Anyway, it is a cosmetic option. > Most important is the fix for gramps 3.4 environment. > > Patched version[1] generates the expected result, but I do not know if there > is a coding convention on this piece of code. So, I tried to keep the same > logic as global file (make.py). > > > [1] > http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/trunk/contrib/make.py?view=patch&r1=1275&r2=1274&pathrev=1275 > [2] > http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?revision=1275&view=revision > > Jérôme a écrit : >> >> OK, something like: >> >> - if addon == 'lxml': >> - system('''cd lxml; python setup.py --build''') >> + if os.path.isfile('*/setup.py'): >> + system('''cd %(addon)s; python setup.py --build''') >> >> Note, 'setup.py' file might be used for addons with additional files? >> ie. not 'pure' python, addons with .glade, .css, .xml, etc ... files >> eg, "Census", "ChangeGivenNames", "PlaceCompletion", "lxml". >> >> This will avoid to check translation strings on .xml and .glade files (and >> will avoid to print warnings) when there is none of them for this addon. >> >> On previous gramps' releases, we always merged some strings back during >> build time (holidays, tips, etc ...)! I suppose it was related to the given >> sample (Gtk/Gnome), used as model? When Josip has generated bundle packages >> for gramps, he pointed out that run time also translates these strings once >> these translations exist on catalog! ie. do not need to generate copies of >> xml files during build time (except for desktop/menu/mime keys). >> >> Here for addons, as we also just need to extract strings from files (.xml, >> .glade), we can try our own cooking with SAX or ElementTree? >> //I got stuck with the new name for getiterator() on E.T 1.3 (python 2.7), >> else I found logical to also use python for extracting these strings// >> >> There was an other thread/post on mailing list (~ 1 month ago) about the >> use of intltool as dependency and related (perl). >> >> This might also help to track down the missing/wrong gettext return on >> some .glade files (addon domain). >> >> >> Jérôme >> >> >> Doug Blank a écrit : >>> >>> On Thu, May 10, 2012 at 6:28 AM, Jérôme <rom...@ya...> wrote: >>>> >>>> Doug, >>>> >>>> >>>>> Ok, but let's not leave it like this... this is a hack that we should >>>>> fix with a solution that will work for future variations. >>>> >>>> It should be nicer/proper after rev1273[1]. >>> >>> Yes, that is better! But we should not check the addon name, but to >>> see if there is a "setup.py" in the addon directory. I can help this >>> weekend if you get stuck on that... it should be easy, something like: >>> >>> if os.path.exists("%s/setup.py" % path_to_addon): >>> ... system("cd ...") >>> >>> (there is a isfile() somewhere which is better for this use) >>> >>> This would be instead of checking for "lxml" specifically. Then, >>> anyone can put additional build code in setup.py. >>> >>> Thanks! >>> >>> -Doug >> >> _______________________________________________ >> >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Jérôme <rom...@ya...> - 2012-05-12 07:26:09
|
Doug, About glade files, I get stuck with PlaceCompletion since a while! The extract strings process seems OK and the translation seems also OK. My guess gone to a wrong path for gtk.glade.bindtextdomain() because there was already some issues like this one since GtkBuilder migration. But it seems correct on TransUtils because I can display translated strings on ChangeGivenNames (other addon), which also uses a glade file! I suppose there is an incomplete migration (glade to GtkBuilder) on PlaceCompletion addon? I also remember Gerald's post[1] about a specific behavior (naming/case) with glade class! Into 'PlaceCompletion.py': base = os.path.dirname(__file__) glade_file = base + os.sep + "placecompletion.glade" self.glade = Glade(glade_file) window = self.glade.get_object("top") self.tree = self.glade.get_object("tree1") I wonder if we need "base + os.sep" ! And if this is properly using the glade() class? => "The constructor does a two-pass lookup for the glade file: First it tries the directory specified with the dirname argument, or the same directory as the calling module if dirname is not specified. If the glade file is not found there, the directory specified by const.GLADEDIR is used. Note that, if we adopt a strict naming convention for glade files such that the filename of the glade file is the same as that for the module, all that is needed is: xml = Glade()" -- Gerald B. Maybe a relative path will be better for Gtk/glade domaine (or something like that)? And maybe code modification into 'PlaceCompletion.py'! The .py / .glade connection/signal is not very clear for me! I was already blocked when I tried to generate collections indexes[2]. Agreed, to generate .glade files makes life easier for maintenance and this quickly generates a GUI without advanced knowledges, but all these signals/connections stuff are very sensitive and most Gtk warnings messages are very cryptic. Now, I do not know what should be the direction ? Should I try to use a new method for handling .glade into PlaceCompletion? If so, I am not certain to fully understand all levels and signals issues about python and glade files, but I could try to do this, more with feeling than technical design, because the current description[1] generates more questions that it gives answers! [1] http://sourceforge.net/mailarchive/message.php?msg_id=22349222 [2] http://www.gramps-project.org/bugs/view.php?id=5552 Jérôme Doug Blank a écrit : > Jérôme, > > The changes to make.py look good; thank you for that! > > I think those addons that have missing translations will need to have > some processing applied to their glade files. But maybe you (or > Perter) understand the issue better. > > -Doug > > On Fri, May 11, 2012 at 11:22 AM, Jérôme <rom...@ya...> wrote: >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > |
From: Jérôme <rom...@ya...> - 2012-05-12 17:20:13
|
>> I think those addons that have missing translations will need to have >> some processing applied to their glade files. > But it seems correct on TransUtils because I can display translated > strings on ChangeGivenNames (other addon), which also uses a glade file! Oh, 'changenames.glade' was a simple copy of the file used by 'gramps' domain ! It displays translation strings from 'gramps' domain for glade addon file. You are right, gtk/glade 'addon' domain seems to be ignored by Addons. Something seems missing/wrong on 'TransUtils.py' or 'glade.py' for addons (glade files)! Jérôme Jérôme a écrit : > Doug, > > > About glade files, I get stuck with PlaceCompletion since a while! > The extract strings process seems OK and the translation seems also OK. > > My guess gone to a wrong path for gtk.glade.bindtextdomain() because > there was already some issues like this one since GtkBuilder migration. > But it seems correct on TransUtils because I can display translated > strings on ChangeGivenNames (other addon), which also uses a glade file! > > I suppose there is an incomplete migration (glade to GtkBuilder) on > PlaceCompletion addon? I also remember Gerald's post[1] about a specific > behavior (naming/case) with glade class! > > Into 'PlaceCompletion.py': > > base = os.path.dirname(__file__) > glade_file = base + os.sep + "placecompletion.glade" > > self.glade = Glade(glade_file) > > window = self.glade.get_object("top") > > self.tree = self.glade.get_object("tree1") > > I wonder if we need "base + os.sep" ! > And if this is properly using the glade() class? > > => "The constructor does a two-pass lookup for the glade file: First it > tries the directory specified with the dirname argument, or the same > directory as the calling module if dirname is not specified. If the > glade file is not found there, the directory specified by > const.GLADEDIR is used. > > Note that, if we adopt a strict naming convention for glade files such > that the filename of the glade file is the same as that for the > module, all that is needed is: > > xml = Glade()" > > -- Gerald B. > > Maybe a relative path will be better for Gtk/glade domaine (or something > like that)? And maybe code modification into 'PlaceCompletion.py'! > > The .py / .glade connection/signal is not very clear for me! > I was already blocked when I tried to generate collections indexes[2]. > > Agreed, to generate .glade files makes life easier for maintenance and > this quickly generates a GUI without advanced knowledges, but all these > signals/connections stuff are very sensitive and most Gtk warnings > messages are very cryptic. > > Now, I do not know what should be the direction ? > Should I try to use a new method for handling .glade into > PlaceCompletion? If so, I am not certain to fully understand all levels > and signals issues about python and glade files, but I could try to do > this, more with feeling than technical design, because the current > description[1] generates more questions that it gives answers! > > > [1] http://sourceforge.net/mailarchive/message.php?msg_id=22349222 > [2] http://www.gramps-project.org/bugs/view.php?id=5552 > > > Jérôme > > > Doug Blank a écrit : >> Jérôme, >> >> The changes to make.py look good; thank you for that! >> >> I think those addons that have missing translations will need to have >> some processing applied to their glade files. But maybe you (or >> Perter) understand the issue better. >> >> -Doug >> >> On Fri, May 11, 2012 at 11:22 AM, Jérôme <rom...@ya...> wrote: >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> > > |
From: Harald R. <ros...@im...> - 2012-01-26 14:59:17
|
What is the last time to upload a new LaTeXDoc.py-version? (self-adapting table building mechanism, displaying pictures) I am nearly ready. Only the new feature: table of multirow-columns in version 18769 has to be respected. (see bug tracker #5434) Harald Am 26.01.2012 14:21, schrieb Brian Matherly: >> I believe we should start the push for 3.4. >> Step 1: Brian, can you make branch 3.4, and a new trunk? > I can do that any time. But typically, we don't create the maintenance branch (3.4) until the code is "feature complete" in trunk. That way there are only stability changes and bug fixed going in to the maintenance branch. So if we expect to be feature complete by Feb 12, I think that would be the day to make the 3.4 branch. I will wait until the 12th unless there is a good reason to branch sooner. > > We don't make a new trunk. Trunk is always trunk. > > ~Brian > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2012-01-26 15:40:07
|
2012/1/26 Harald Rosemann <ros...@im...>: > > What is the last time to upload a new LaTeXDoc.py-version? > (self-adapting table building mechanism, displaying pictures) > I am nearly ready. Before 12 feb. As Brian notes, we create branch 34 then. Benny > > Only the new feature: table of multirow-columns > in version 18769 has to be respected. > (see bug tracker #5434) > > Harald > > > > Am 26.01.2012 14:21, schrieb Brian Matherly: >>> I believe we should start the push for 3.4. >>> Step 1: Brian, can you make branch 3.4, and a new trunk? >> I can do that any time. But typically, we don't create the maintenance branch (3.4) until the code is "feature complete" in trunk. That way there are only stability changes and bug fixed going in to the maintenance branch. So if we expect to be feature complete by Feb 12, I think that would be the day to make the 3.4 branch. I will wait until the 12th unless there is a good reason to branch sooner. >> >> We don't make a new trunk. Trunk is always trunk. >> >> ~Brian >> >> >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Tim L. <guy...@gm...> - 2012-01-26 15:01:20
|
DS Blank wrote > > On 1/26/12, Benny Malengier <benny.malengier@> wrote: >> Hi, >> >> I believe we should start the push for 3.4. >> >> Step 1: Brian, can you make branch 3.4, and a new trunk? >> Step 2: Doug, can you shift the plugin infrastructure to accomodate this > > That should already be ready. > I agree with the logic of not creating a gramps34 branch till later, but I am confused about what is supposed to happen with the add-ons. Where should development of the 3.4 add-ons take place? Should it be in https://gramps-addons.svn.sourceforge.net/svnroot/gramps-addons/trunk or https://gramps-addons.svn.sourceforge.net/svnroot/gramps-addons/branches/gramps34 Should test versions of gramps be altered to look in either one or the other for their add-ons? When I try to refresh the add-on list in trunk gramps, it returns nothing. Should a 3.4 add-ons wiki page be created? I am concerned because there may be some add-ons tha need to be updated. -- View this message in context: http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4330559.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |