You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(35) |
Jun
(11) |
Jul
(41) |
Aug
(96) |
Sep
(29) |
Oct
(44) |
Nov
(70) |
Dec
(61) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(126) |
Feb
(31) |
Mar
(64) |
Apr
(84) |
May
(57) |
Jun
(56) |
Jul
(20) |
Aug
(23) |
Sep
(31) |
Oct
(19) |
Nov
(60) |
Dec
(34) |
2003 |
Jan
(30) |
Feb
(61) |
Mar
(32) |
Apr
(30) |
May
(78) |
Jun
(55) |
Jul
(111) |
Aug
(108) |
Sep
(104) |
Oct
(98) |
Nov
(92) |
Dec
(73) |
2004 |
Jan
(71) |
Feb
(70) |
Mar
(68) |
Apr
(40) |
May
(118) |
Jun
(51) |
Jul
(71) |
Aug
(251) |
Sep
(77) |
Oct
(155) |
Nov
(74) |
Dec
(57) |
2005 |
Jan
(183) |
Feb
(94) |
Mar
(170) |
Apr
(242) |
May
(233) |
Jun
(42) |
Jul
(69) |
Aug
(70) |
Sep
(99) |
Oct
(60) |
Nov
(65) |
Dec
(210) |
2006 |
Jan
(169) |
Feb
(99) |
Mar
(31) |
Apr
(179) |
May
(142) |
Jun
(72) |
Jul
(131) |
Aug
(98) |
Sep
(110) |
Oct
(189) |
Nov
(262) |
Dec
(207) |
2007 |
Jan
(376) |
Feb
(255) |
Mar
(168) |
Apr
(174) |
May
(167) |
Jun
(192) |
Jul
(197) |
Aug
(171) |
Sep
(307) |
Oct
(572) |
Nov
(454) |
Dec
(471) |
2008 |
Jan
(707) |
Feb
(365) |
Mar
(464) |
Apr
(410) |
May
(251) |
Jun
(142) |
Jul
(112) |
Aug
(143) |
Sep
(94) |
Oct
(280) |
Nov
(337) |
Dec
(232) |
2009 |
Jan
(508) |
Feb
(491) |
Mar
(363) |
Apr
(280) |
May
(186) |
Jun
(250) |
Jul
(231) |
Aug
(487) |
Sep
(189) |
Oct
(344) |
Nov
(456) |
Dec
(439) |
2010 |
Jan
(514) |
Feb
(725) |
Mar
(591) |
Apr
(256) |
May
(209) |
Jun
(75) |
Jul
(118) |
Aug
(248) |
Sep
(230) |
Oct
(393) |
Nov
(368) |
Dec
(276) |
2011 |
Jan
(457) |
Feb
(308) |
Mar
(358) |
Apr
(277) |
May
(333) |
Jun
(320) |
Jul
(198) |
Aug
(186) |
Sep
(87) |
Oct
(238) |
Nov
(123) |
Dec
(129) |
2012 |
Jan
(127) |
Feb
(182) |
Mar
(208) |
Apr
(134) |
May
(230) |
Jun
(138) |
Jul
(126) |
Aug
(176) |
Sep
(231) |
Oct
(235) |
Nov
(164) |
Dec
(219) |
2013 |
Jan
(316) |
Feb
(371) |
Mar
(393) |
Apr
(165) |
May
(321) |
Jun
(301) |
Jul
(124) |
Aug
(183) |
Sep
(191) |
Oct
(285) |
Nov
(172) |
Dec
(196) |
2014 |
Jan
(392) |
Feb
(284) |
Mar
(134) |
Apr
(206) |
May
(123) |
Jun
(115) |
Jul
(41) |
Aug
(157) |
Sep
(122) |
Oct
(124) |
Nov
(63) |
Dec
(56) |
2015 |
Jan
(249) |
Feb
(335) |
Mar
(277) |
Apr
(98) |
May
(274) |
Jun
(214) |
Jul
(142) |
Aug
(240) |
Sep
(57) |
Oct
(77) |
Nov
(18) |
Dec
(171) |
2016 |
Jan
(217) |
Feb
(167) |
Mar
(62) |
Apr
(180) |
May
(270) |
Jun
(86) |
Jul
(112) |
Aug
(50) |
Sep
(57) |
Oct
(91) |
Nov
(62) |
Dec
(101) |
2017 |
Jan
(116) |
Feb
(115) |
Mar
(85) |
Apr
(35) |
May
(54) |
Jun
(123) |
Jul
(65) |
Aug
(35) |
Sep
(103) |
Oct
(28) |
Nov
(21) |
Dec
(7) |
2018 |
Jan
(27) |
Feb
(64) |
Mar
(42) |
Apr
(72) |
May
(49) |
Jun
(24) |
Jul
(18) |
Aug
(4) |
Sep
(9) |
Oct
(39) |
Nov
(11) |
Dec
(45) |
2019 |
Jan
(35) |
Feb
(24) |
Mar
(28) |
Apr
(38) |
May
(16) |
Jun
(41) |
Jul
|
Aug
(49) |
Sep
(41) |
Oct
(22) |
Nov
(15) |
Dec
(32) |
2020 |
Jan
(61) |
Feb
(3) |
Mar
(31) |
Apr
(29) |
May
(38) |
Jun
(16) |
Jul
(26) |
Aug
(87) |
Sep
(12) |
Oct
(4) |
Nov
(14) |
Dec
(5) |
2021 |
Jan
(3) |
Feb
(4) |
Mar
(26) |
Apr
(2) |
May
(55) |
Jun
(64) |
Jul
(96) |
Aug
(71) |
Sep
(1) |
Oct
(2) |
Nov
(17) |
Dec
(5) |
2022 |
Jan
(23) |
Feb
(22) |
Mar
(9) |
Apr
(7) |
May
(8) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
(14) |
Oct
(10) |
Nov
(1) |
Dec
(10) |
2023 |
Jan
(3) |
Feb
|
Mar
|
Apr
(34) |
May
(14) |
Jun
(25) |
Jul
(10) |
Aug
(13) |
Sep
|
Oct
|
Nov
(2) |
Dec
(7) |
2024 |
Jan
(1) |
Feb
(23) |
Mar
(33) |
Apr
(19) |
May
(5) |
Jun
(46) |
Jul
(2) |
Aug
(7) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
From: Fabio R. <fre...@gm...> - 2024-06-17 16:24:29
|
Thanks for your answer Sveinn. You are right, I confused PoEditor with PoEdit because I worked with both of them many years ago and I didn't remember the name of the program... I still am not able to understand where should I copy my personal it.mo file to let Gramps work with it. Thanks again in advance. Fabio Il giorno lun 17 giu 2024 alle ore 14:03 Sveinn í Felli <sv...@fe...> ha scritto: > Þann 17.6.2024 10:54, skrifaði Fabio Restante: > > Hi all, > > I'm disturbing you because I need a little help with my "problem". > > I actually don't like the italian translation used in the book, > especially > > for the words related to the main facts of the persons in the tree. For > > example, it's used a verbal tense that we normally use for people lived > > more than 100 years ago, and in the book this tense is used also for > kids... > > > > Maybe I'm the only italian user with this problem, so I don't want to > > change the official translation actually used by Gramps. I'm used to work > > with the .po files, so I also downloaded the poEditor program to modify > my > > own it.po file according to my "feelings": is there any way to use Gramps > > with my "private" translation instead of the official it.po file? How > could > > I transform this it.po file in the files needed by Gramps? > > > > I'm a Windows user, so please don't send me solutions working only in > Linux. > > > > Many thanks in advance for your help > > > > Fabio > > > > A bit confusing; poEditor is an online platform for translations, while > PoEdit is a program to translate PO-files. If you downloaded the latter, > you should be able to save/compile your file directly as a MO-file: > > [File] -> [Compile as MO...] > > Anyway, if you have set up the gettext-package, you can open a > terminal/command-line window in the folder with your PO-file, and issue > the command: > > msgfmt -i it.po -vc -o it.mo > > -v means 'verbose' and -c means 'check' so that all validity checks are > executed and you get verbose (more detailed) information. The -i (input) > and -o (output) are optional I think. > > Best regards and good luck, > Sveinn í Felli > -- E' bello che dove finiscono le mie dita debba in qualche modo incominciare una chitarra Fabrizio de Andre' - "Amico fragile" -------------- next part -------------- An HTML attachment was scrubbed... |
From: Fabio R. <fre...@gm...> - 2024-06-17 16:20:27
|
Thanks Luigi, it's true, the tense was changed but there are still a lot of things that I use in a different way. I.e.: "circa il" instead of "circa nel", "dopo del" instead of "dopo il", "in quel di" instead of the simplest "a", and so on. As I wrote before, I don't want you change the official italian translation just because I feel better with my version: I prefer to use a "private" translation leaving your good work without changes. Fabio Il giorno lun 17 giu 2024 alle ore 13:02 Luigi Toscano < lui...@ti...> ha scritto: > Fabio Restante ha scritto: > > Hi all, > > I'm disturbing you because I need a little help with my "problem". > > I actually don't like the italian translation used in the book, > especially > > for the words related to the main facts of the persons in the tree. For > > example, it's used a verbal tense that we normally use for people lived > > more than 100 years ago, and in the book this tense is used also for > kids... > > > > Maybe I'm the only italian user with this problem, so I don't want to > > change the official translation actually used by Gramps. I'm used to work > > with the .po files, so I also downloaded the poEditor program to modify > my > > own it.po file according to my "feelings": is there any way to use Gramps > > with my "private" translation instead of the official it.po file? How > could > > I transform this it.po file in the files needed by Gramps? > > > > I'm a Windows user, so please don't send me solutions working only in > Linux. > > I can't answer the main question because I don't know if there are > non-command > line tools for Windows which can to convert po files to mo files (the ones > used at runtime), but for the original question have you checked gramps > 5.2? > The verbal tense was changed to a narrative present. > > -- > Luigi > > -- E' bello che dove finiscono le mie dita debba in qualche modo incominciare una chitarra Fabrizio de Andre' - "Amico fragile" -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2024-06-17 15:53:25
|
On 17/06/2024 13:03, Sveinn í Felli wrote: > while PoEdit is a program to translate PO-files Yes. Poedit looks like a good solution for Windows users. https://poedit.net It can compile a "po" file into a "mo" file. Hopefully you can agree a solution with Luigi so that you can contribute to the main Italian translation. Nick. |
From: Sebastian C. <sa...@gm...> - 2024-06-17 15:40:12
|
Likewise, I haven't been involved in Gramps at all until this point (I played around privately) and I don't think I've ever sent a message to this list, but I'd be willing to help with getting things going. Perhaps I could team up with someone who's a known quantity (so you don't have to give me write access to the repo off the bat)? Sebastian On Mon, Jun 17, 2024, 08:33 Al Stone <ah...@ah...> wrote: > On 01 Jun 2024 22:23, Emyoulation--- via Gramps-devel wrote: > > Are there any well-versed GitHub users who would be willing to volunteer > to help get the Pull Requests in the Addons-source flowing again? > > There are 41 open Pull Requests in the repository, going all the way > back to 2018. There are 8 marked as "Work In Progress" but at a superficial > scan, 33 look like they could be pushed through. > > > > I tried to help a non-GitHub user (George Baynes) put through a useful > Note Report addon but made a mess of the GitHub side of it. -- Its > registration was upgraded to be work with 5.0, 5.1 and 5.2 and to pass the > Black format validation. (dunno about lint.) But I put the commit in the > wrong place and I don't understand which Branches need to have the source. > > And even after Pull Requests begin flowing, we need volunteers to help > get the other 'stuck' addons posted. (Those of us without the GitHub skills > can search for those.) The volunteers could also use the make.py for the > various release versions to generate the downloads and addon-en.txt/json > listings files that actually make add-ons accessible by average users. > > > > > > https://github.com/gramps-project/addons-source/pulls > > So, I'm pretty sure I have the git skills (long-time Linux developer) > and I'm familiar with github. I'm very new to gramps code, however, > so vetting the correctness of the pull requests is a problem, and I > have not yet set up a good testing environment for it (I literally > just pulled up the wiki page for developers :-). > > Have automated tests been set up on github? Or can someone reliable > at least indicate which PRs should/should not be accepted? I use > gramps quite a bit, so I don't mind helping but I'm just not familiar > with the code base or accepted development norms yet. > > -- > Ciao, > al > ---------------------------------------------------------------------- > Al Stone > E-mail: ah...@ah... > ---------------------------------------------------------------------- > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -------------- next part -------------- An HTML attachment was scrubbed... |
From: Al S. <ah...@ah...> - 2024-06-17 15:32:56
|
On 01 Jun 2024 22:23, Emyoulation--- via Gramps-devel wrote: > Are there any well-versed GitHub users who would be willing to volunteer to help get the Pull Requests in the Addons-source flowing again? > There are 41 open Pull Requests in the repository, going all the way back to 2018. There are 8 marked as "Work In Progress" but at a superficial scan, 33 look like they could be pushed through. > > I tried to help a non-GitHub user (George Baynes) put through a useful Note Report addon but made a mess of the GitHub side of it. -- Its registration was upgraded to be work with 5.0, 5.1 and 5.2 and to pass the Black format validation. (dunno about lint.) But I put the commit in the wrong place and I don't understand which Branches need to have the source. > And even after Pull Requests begin flowing, we need volunteers to help get the other 'stuck' addons posted. (Those of us without the GitHub skills can search for those.) The volunteers could also use the make.py for the various release versions to generate the downloads and addon-en.txt/json listings files that actually make add-ons accessible by average users. > > > https://github.com/gramps-project/addons-source/pulls So, I'm pretty sure I have the git skills (long-time Linux developer) and I'm familiar with github. I'm very new to gramps code, however, so vetting the correctness of the pull requests is a problem, and I have not yet set up a good testing environment for it (I literally just pulled up the wiki page for developers :-). Have automated tests been set up on github? Or can someone reliable at least indicate which PRs should/should not be accepted? I use gramps quite a bit, so I don't mind helping but I'm just not familiar with the code base or accepted development norms yet. -- Ciao, al ---------------------------------------------------------------------- Al Stone E-mail: ah...@ah... ---------------------------------------------------------------------- |
From: Sveinn í F. <sv...@fe...> - 2024-06-17 12:04:01
|
Þann 17.6.2024 10:54, skrifaði Fabio Restante: > Hi all, > I'm disturbing you because I need a little help with my "problem". > I actually don't like the italian translation used in the book, especially > for the words related to the main facts of the persons in the tree. For > example, it's used a verbal tense that we normally use for people lived > more than 100 years ago, and in the book this tense is used also for kids... > > Maybe I'm the only italian user with this problem, so I don't want to > change the official translation actually used by Gramps. I'm used to work > with the .po files, so I also downloaded the poEditor program to modify my > own it.po file according to my "feelings": is there any way to use Gramps > with my "private" translation instead of the official it.po file? How could > I transform this it.po file in the files needed by Gramps? > > I'm a Windows user, so please don't send me solutions working only in Linux. > > Many thanks in advance for your help > > Fabio > A bit confusing; poEditor is an online platform for translations, while PoEdit is a program to translate PO-files. If you downloaded the latter, you should be able to save/compile your file directly as a MO-file: [File] -> [Compile as MO...] Anyway, if you have set up the gettext-package, you can open a terminal/command-line window in the folder with your PO-file, and issue the command: msgfmt -i it.po -vc -o it.mo -v means 'verbose' and -c means 'check' so that all validity checks are executed and you get verbose (more detailed) information. The -i (input) and -o (output) are optional I think. Best regards and good luck, Sveinn í Felli |
From: Luigi T. <lui...@ti...> - 2024-06-17 11:17:00
|
Fabio Restante ha scritto: > Hi all, > I'm disturbing you because I need a little help with my "problem". > I actually don't like the italian translation used in the book, especially > for the words related to the main facts of the persons in the tree. For > example, it's used a verbal tense that we normally use for people lived > more than 100 years ago, and in the book this tense is used also for kids... > > Maybe I'm the only italian user with this problem, so I don't want to > change the official translation actually used by Gramps. I'm used to work > with the .po files, so I also downloaded the poEditor program to modify my > own it.po file according to my "feelings": is there any way to use Gramps > with my "private" translation instead of the official it.po file? How could > I transform this it.po file in the files needed by Gramps? > > I'm a Windows user, so please don't send me solutions working only in Linux. I can't answer the main question because I don't know if there are non-command line tools for Windows which can to convert po files to mo files (the ones used at runtime), but for the original question have you checked gramps 5.2? The verbal tense was changed to a narrative present. -- Luigi |
From: Fabio R. <fre...@gm...> - 2024-06-17 10:55:05
|
Hi all, I'm disturbing you because I need a little help with my "problem". I actually don't like the italian translation used in the book, especially for the words related to the main facts of the persons in the tree. For example, it's used a verbal tense that we normally use for people lived more than 100 years ago, and in the book this tense is used also for kids... Maybe I'm the only italian user with this problem, so I don't want to change the official translation actually used by Gramps. I'm used to work with the .po files, so I also downloaded the poEditor program to modify my own it.po file according to my "feelings": is there any way to use Gramps with my "private" translation instead of the official it.po file? How could I transform this it.po file in the files needed by Gramps? I'm a Windows user, so please don't send me solutions working only in Linux. Many thanks in advance for your help Fabio -- E' bello che dove finiscono le mie dita debba in qualche modo incominciare una chitarra Fabrizio de Andre' - "Amico fragile" -------------- next part -------------- An HTML attachment was scrubbed... |
From: John R. <jr...@ce...> - 2024-06-02 17:59:14
|
> On Jun 2, 2024, at 05:18, H Gohel via Gramps-devel <gra...@li...> wrote: > >> From: Emyoulation--- via Gramps-devel <gra...@li...> >> >> Are there any well-versed GitHub users who would be willing to volunteer to >> help get the Pull Requests in the Addons-source flowing again? > > It would help potential volunteers to understand what needs to be done. GitHub knowledge might not be the only thing needed. > > Similar to the addon developer's wiki, it would be very helpful to have a documentation of the steps to go from a PR being created to code review, PR approval, building, testing and publishing the addons. There's also the task of merging code back to master branch. See https://github.com/orgs/gramps-project/people for who potentially has authorization to push to Github: Just being on the list isn’t enough: Click on each member’s name and check the privilege level for each repo: It needs to be write, maintain, or admin to be able to merge a PR into that repo. Next see https://www.gramps-project.org/wiki/index.php/Developer_policies#Becoming_an_official_developer for how to get on that list. It’s definitely more than Github knowledge. Since there’s no CI on addons-source it’s always necessary to merge and test a PR locally. Having done that it makes more sense to just push the merge back to Github than to bother with Github’s built-in merge tools. Policies are in https://www.gramps-project.org/wiki/index.php/Committing_policies. It might be useful to add policies for addons-source that are actively maintained by someone who isn’t on the core team and what to do when a third-party add-on isn’t being maintained any more. For example, if someone other than the active maintainer submits a PR for an add-on should we require maintainer approval before we merge it? Regards, John Ralls -------------- next part -------------- An HTML attachment was scrubbed... |
From: H G. <hg...@ya...> - 2024-06-02 12:55:18
|
> From: Emyoulation--- via Gramps-devel <gra...@li...> > ... registration was upgraded to be work with 5.0, 5.1 and 5.2 ... Related to this - some of the PRs are targeted to Gramps 5.1. Given recent discussions on the forums about reasons to stay on 5.1, what is the thinking regarding the targeting of addons - 5.1 and 5.2, or 5.2 only? -- @codefarmer |
From: H G. <hg...@ya...> - 2024-06-02 12:19:11
|
> From: Emyoulation--- via Gramps-devel <gra...@li...> > > Are there any well-versed GitHub users who would be willing to volunteer to > help get the Pull Requests in the Addons-source flowing again? It would help potential volunteers to understand what needs to be done. GitHub knowledge might not be the only thing needed. Similar to the addon developer's wiki, it would be very helpful to have a documentation of the steps to go from a PR being created to code review, PR approval, building, testing and publishing the addons. There's also the task of merging code back to master branch. -- @codefarmer |
From: <Emy...@ya...> - 2024-06-01 22:23:38
|
Are there any well-versed GitHub users who would be willing to volunteer to help get the Pull Requests in the Addons-source flowing again? There are 41 open Pull Requests in the repository, going all the way back to 2018. There are 8 marked as "Work In Progress" but at a superficial scan, 33 look like they could be pushed through. I tried to help a non-GitHub user (George Baynes) put through a useful Note Report addon but made a mess of the GitHub side of it. -- Its registration was upgraded to be work with 5.0, 5.1 and 5.2 and to pass the Black format validation. (dunno about lint.) But I put the commit in the wrong place and I don't understand which Branches need to have the source. And even after Pull Requests begin flowing, we need volunteers to help get the other 'stuck' addons posted. (Those of us without the GitHub skills can search for those.) The volunteers could also use the make.py for the various release versions to generate the downloads and addon-en.txt/json listings files that actually make add-ons accessible by average users. https://github.com/gramps-project/addons-source/pulls -------------- next part -------------- An HTML attachment was scrubbed... |
From: David S. <st...@pr...> - 2024-05-08 14:55:49
|
Agreed, I'll be happy to update the guidelines in the Wiki as soon as the PR is merged. Best, David H Gohel <hg...@ya...> schrieb am Mittwoch, 8. Mai 2024 um 16:51: > On 5/7/2024 10:21 AM, David Straub wrote: > >>> @David, could you briefly describe the "new syntax" vs old syntax changes in the last two commits of your PR? >> >> Sure, this was suggested by @QuLogic in the PR review. The "new syntax" allows using the generic collection types like dict, list, tuple for type hints rather than having to import special ones from the typing module (Dict, List, Tuple). This is PEP 585, which was implemented in Python 3.9. > > That's very helpful. The kind of information we ought to include in developer guidelines so everyone uses a consistent typing style. > > -- > @codefarmer -------------- next part -------------- An HTML attachment was scrubbed... |
From: H G. <hg...@ya...> - 2024-05-08 14:52:04
|
On 5/7/2024 10:21 AM, David Straub wrote: >> @David, could you briefly describe the "new syntax" vs old syntax changes in the last two commits of your PR? > Sure, this was suggested by @QuLogic in the PR review. The "new syntax" allows using the generic collection types like dict, list, tuple for type hints rather than having to import special ones from the typing module (Dict, List, Tuple). This is PEP 585, which was implemented in Python 3.9. That's very helpful. The kind of information we ought to include in developer guidelines so everyone uses a consistent typing style. -- @codefarmer -------------- next part -------------- An HTML attachment was scrubbed... |
From: David S. <st...@pr...> - 2024-05-07 14:21:22
|
Hi, thanks! > @David, could you briefly describe the "new syntax" vs old syntax changes in the last two commits of your PR? Thanks, Sure, this was suggested by @QuLogic in the PR review. The "new syntax" allows using the generic collection types like dict, list, tuple for type hints rather than having to import special ones from the typing module (Dict, List, Tuple). This is PEP 585, which was implemented in Python 3.9. In addition there is PEP 604 allowing to write optional types as "X | None" rather than "Optional[X]" and implemented in Python 3.10. Both features can be used in older versions of Python (such as 3.8 still supported by Gramps) by adding "from __future__ import annotations". Arguably, the new syntax is more readable and we only have to remove the future statement once we remove support for Python 3.8/9, rather than having to change all the Dict, List, Tuple type hints to lower case and removing the import from typing. Cheers, David H Gohel via Gramps-devel <gra...@li...> schrieb am Dienstag, 7. Mai 2024 um 15:21: > > > > On 4/30/2024 11:00 AM, Nick Hall via Gramps-devel wrote: > > > Devs, > > > > What are you views on introducing type hints into the Gramps code? > > Based on cursory reading of PEP-484 and related docs, this seems like a good idea. If the decision is made to go ahead with it, I would recommend we update the dev wiki to encourage its usage with a couple of links on where to read up about it. I see David already has opened PR #1717 which enables mypy static type checking in CI which is awesome. > > https://github.com/gramps-project/gramps/pull/1717 > > @David, could you briefly describe the "new syntax" vs old syntax changes in the last two commits of your PR? Thanks, > > -- > > @codefarmer > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: H G. <hg...@ya...> - 2024-05-07 13:22:15
|
On 4/30/2024 11:00 AM, Nick Hall via Gramps-devel wrote: > Devs, > > What are you views on introducing type hints into the Gramps code? > Based on cursory reading of PEP-484 and related docs, this seems like a good idea. If the decision is made to go ahead with it, I would recommend we update the dev wiki to encourage its usage with a couple of links on where to read up about it. I see David already has opened PR #1717 which enables mypy static type checking in CI which is awesome. https://github.com/gramps-project/gramps/pull/1717 @David, could you briefly describe the "new syntax" vs old syntax changes in the last two commits of your PR? Thanks, -- @codefarmer |
From: john <jr...@ce...> - 2024-05-02 16:17:54
|
> On Apr 30, 2024, at 8:00 AM, Nick Hall via Gramps-devel <gra...@li...> wrote: > > Devs, > > What are you views on introducing type hints into the Gramps code? > > PEP 484 - Type Hints > https://peps.python.org/pep-0484/ > > These allow static type checking using tools such as mypy. > > See the mypy documentation: > https://mypy.readthedocs.io/en/stable/ > > From a technical standpoint this is a good idea since it improves code quality and helps detect latent bugs. > > The only downside that I can think of is that it is something extra for developers to learn and may be off putting to new contributors, especially those with little coding experience. > > David has already raised this topic on our Discourse forum. See: > https://gramps.discourse.group/t/making-mypy-happy/5342 > > I would be interested in your thoughts. Nick, I'm for it, particularly if you intend to add a static analysis workflow to CI. I don't think it should be much of a burden and it's anyway good practice for programmers to keep types and invariants in mind when writing and maintaining code. The annotations will also make the code easier to understand for newcomers to the code base and requiring them for new code will help less experienced programmers develop type awareness. Mind, that's coming from someone who does most of his work in C++ where type safety is a core principle. Regards, John Ralls |
From: David S. <st...@pr...> - 2024-04-30 15:49:51
|
Hi all, thanks Nick for kicking off this discussion! I would just like to add two comments from my side: - Adding passing mypy checks as a requirement for new contributions is very different from requiring type hinting - you can still accept contributions without any type hints, but mypy will still catch certain types of bugs. From the mypy docs: "Mypy is designed with gradual typing in mind. This means you can add type hints to your code base slowly and that you can always fall back to dynamic typing when static typing is not convenient." - Since (optionally) using type hints has become a standard in open source Python projects, not allowing it might also be putting off new contributors. Best regards, David Nick Hall via Gramps-devel <gra...@li...> schrieb am Dienstag, 30. April 2024 um 17:00: > > > Devs, > > What are you views on introducing type hints into the Gramps code? > > PEP 484 - Type Hints > https://peps.python.org/pep-0484/ > > These allow static type checking using tools such as mypy. > > See the mypy documentation: > https://mypy.readthedocs.io/en/stable/ > > From a technical standpoint this is a good idea since it improves code > quality and helps detect latent bugs. > > The only downside that I can think of is that it is something extra for > developers to learn and may be off putting to new contributors, > especially those with little coding experience. > > David has already raised this topic on our Discourse forum. See: > https://gramps.discourse.group/t/making-mypy-happy/5342 > > I would be interested in your thoughts. > > > Regards, > > > Nick. > > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Nick H. <ni...@gr...> - 2024-04-30 15:00:14
|
Devs, What are you views on introducing type hints into the Gramps code? PEP 484 - Type Hints https://peps.python.org/pep-0484/ These allow static type checking using tools such as mypy. See the mypy documentation: https://mypy.readthedocs.io/en/stable/ From a technical standpoint this is a good idea since it improves code quality and helps detect latent bugs. The only downside that I can think of is that it is something extra for developers to learn and may be off putting to new contributors, especially those with little coding experience. David has already raised this topic on our Discourse forum. See: https://gramps.discourse.group/t/making-mypy-happy/5342 I would be interested in your thoughts. Regards, Nick. |
From: Eloy G. <ea...@gm...> - 2024-04-17 16:28:08
|
Hi, First let me introduce my genealogy and programming background to give perspective to my thoughts on merging of database information. I'll start with my working career. I'm retired from 30 years of programming satellite testers using assembly, fortran, visual basic, pascal, python and shell scripting. Working also as the configuration manager for the software, I am very familiar with concept of merging in a source text team environment. Used a lot of diff type programs. Back in the old days ( 1970's ) I started doing genealogy research, inspired by my uncle, who started me into it. At that time I was doing every thing hard-copy. My research logs, and photo-copies from micro-fish readers of New Mexico Mission records ( same as now available from FamilySearch), census records etc., all cross linked by date, folder, page. Tedious process to keep up, but it worked after a fashion with memory to help. This helped me keep things straight until I found gramps and made that my repository for the fully authenticated info. This worked but lacked tools to implement the research process I was used to. Then I went off to other interests for a couple of decades. Along the line I took an interest in note taking apps. I kinda liked the hierarchical structure to relate notes. Then there were the mind-map oriented note apps. Finally I found Obsidian. If you are not familiar, it lets you create collections of notes from templates in markdown (.md text files), stored in a regular direcotory structure of your choosing (referred to as a vault), with meta-data and tags stored in the note that can be queried like a database to create lists and tables dynamically. The notes can be linked together easily in any kind of map that you like. I started out using it to keep a Journal (with the periodic notes abilities), but soon realized that with the many excellent plug-ins available, like templates, tasks, graph views, attachments, and metadata manipulation using javascript, output to pdf and html, presentation and input. I could implement my genealogy process. So I did. Then I realized that I would be nice to import the data from gramps and then be able to link it to the research data. Starting with the most excellent tool, SuperTool, from Isotammi, I was able to export mostly everything from gramps into csv files for different entities (people, families, places, events, citations and notes). Then using an awsome pluig-in in obsidian, "JSON/CSV Importer", I imported the data creating a note for each of the instances of the respective entities, putting all the data into the frontamatter meta-data for each note. All linked together and all stored in text files in regular directory structures. That is when my configuration management lens kicked in. Text files can be diffed and merged, as long as the filenames are consistent, using very mature developent tools across the two directories being diffed. I seems this would let researcher address the samantics of the data in context of genealogical validity when merging. Now if I want to collaborate, I would zip the vault directory, archive it and send it to my cousin and he opens it with obsidian goes off and does the research, altering her copy of the vault. When she is ready to merge her changes into mine, she zips of the vault dir(actually, all the research data is in a single directory of the vault), sends it to me, and I do a three-way merge, using the archive copy as the common ancestor, with a copy of my vault. The process should be fast enough that my cousin would not even need learn the how to merge. I would just send her a new copy of the master research directory. To make the cycle complete, it would be nice to be able to import ALL the data into gramps from a csv file created out of obsidian. I have managed to create csv files from obsidian from the entities front matter, now if gramps could only create a more compete database from that data, it would be nice to be able to use gramps' tools, reports and graphs. I realize this approach makes obsidian the master and just uses gramps as a utility. To me this is a better way to preserve the info. All the data is text and even if obidian goes away the data is readly accessible. The format is up and coming for documents and is widely supported. but the reverse could also be true by using obsidian as a merge tool by using Super Tool and JSON/CSV Importer to create a directory in obsidian of entities to merge the research data into, then re-import that into gramps. I've prototyped the process and it works well, but what is lacking is the capability to import all the data from a csv file into gramps in a entity object way as is done in the Isotammi Super Tool when exporting entity csv files. This would make constructing csv files for gramps from obsidian simple. I'm not offering solutions, just adding my use case to the perspective. I apologize for being long winded. Eloy Gonzales On Sat, Apr 13, 2024 at 3:25 AM Przemek Więch <pw...@gm...> wrote: > Hi, > > I was recently thinking about what family tree collaboration should look > like and I wrote a post about it: > https://pewu.github.io/Collaborating-on-building-family-trees/ > > I think Gramps would benefit from allowing more possibilities for easier > import of information from various sources. I know it's already possible to > import GEDCOM files and manually merge trees. Maybe we should design a > process where 2 people could work on separate family trees and also keep > common parts synchronized? > > This is somewhat parallel to the recent topic about "Allowing multi-user > access". I think another way to scale is by allowing to synchronize parts > of family trees between databases. > > Let me know what you think. > > Cheers, > Przemek > -------------- next part -------------- > An HTML attachment was scrubbed... > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -------------- next part -------------- An HTML attachment was scrubbed... |
From: Przemek W. <pw...@gm...> - 2024-04-15 17:55:14
|
Thanks for the comments. From the perspective of Gramps, it does make sense to first focus on the "common base" case first. We could make it very easy to merge 2 databases that are derived from a common base. I might try to document this process to see what it really takes to make the cousin-cousin collaboration work. Best, Przemek On Sat, Apr 13, 2024 at 11:22 PM Nick Hall via Gramps-devel < gra...@li...> wrote: > On 13/04/2024 21:37, David Straub wrote: > > A second step could be using UUIDs (but this will need to better > supported in Gramps first I guess) > > Adding the Gedcom identifier structure to primary objects was one of the > items that I suggested for the v5.3 roadmap. This includes REFN, UID > and EXID tags. > > > Nick. > > -------------- next part -------------- > An HTML attachment was scrubbed... > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2024-04-13 21:21:40
|
On 13/04/2024 21:37, David Straub wrote: > A second step could be using UUIDs (but this will need to better supported in Gramps first I guess) Adding the Gedcom identifier structure to primary objects was one of the items that I suggested for the v5.3 roadmap. This includes REFN, UID and EXID tags. Nick. -------------- next part -------------- An HTML attachment was scrubbed... |
From: David S. <st...@pr...> - 2024-04-13 20:37:32
|
Hi Przemek, an excellent and inspiring article and I totally agree on many of the issues you mention. Since this is the Gramps Development List, let me add a few thoughts from a Gramps (and especially Gramps Web) perspective: - From Gramps perspective, I would think about the Gramps data structure, not about Gedcoms - Matching records without common identifiers is very hard and error prone. Personally I think it's too ambitious for your use case of researching with your cousins. In my mind, a first step would be to assume that all trees are derived from a common base (sharing handles). A second step could be using UUIDs (but this will need to better supported in Gramps first I guess) - As Nick already mentioned, Gramps already has quite powerful tools for diff-ing two databases. This is leveraged by the Import Merge Tool as well as by the Gramps Web Sync Addon. In general, I think the most challenging part of realizing such an idea is defining a consistent set of rules for the automated merging. It's relatively straightforward for people (including/excluding based on lineage and then merging in case of differences), but for auxiliary objects like notes, sources, places, etc., I think it will be very difficult and probably it will be again be a case where different researchers will have quite different ideas about how it should be done. Best, David Nick Hall via Gramps-devel <gra...@li...> schrieb am Samstag, 13. April 2024 um 19:29: > > > On 13/04/2024 10:24, Przemek Więch wrote: > > > I was recently thinking about what family tree collaboration should look > > like and I wrote a post about it: > > https://pewu.github.io/Collaborating-on-building-family-trees/ > > > A well reasoned article. > > > I think Gramps would benefit from allowing more possibilities for easier > > import of information from various sources. I know it's already possible to > > import GEDCOM files and manually merge trees. Maybe we should design a > > process where 2 people could work on separate family trees and also keep > > common parts synchronized? > > I think that I would separate the import from the merge. Then you > reduce the problem to merging two Gramps databases. > > If you know the Gramps ID of a person common to the two databases, then > tree-walking would be worth trying as a way to match people. > > The Database Differences report already provides a way of comparing > objects between databases. Next, you would have to decide how automated > you wanted the merge to be. Perhaps you would want to click checkboxes > on the items in a differences report to merge? > > > Nick. > > -------------- next part -------------- > An HTML attachment was scrubbed... > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Nick H. <ni...@gr...> - 2024-04-13 17:29:20
|
On 13/04/2024 10:24, Przemek Więch wrote: > I was recently thinking about what family tree collaboration should look > like and I wrote a post about it: > https://pewu.github.io/Collaborating-on-building-family-trees/ A well reasoned article. > > I think Gramps would benefit from allowing more possibilities for easier > import of information from various sources. I know it's already possible to > import GEDCOM files and manually merge trees. Maybe we should design a > process where 2 people could work on separate family trees and also keep > common parts synchronized? > I think that I would separate the import from the merge. Then you reduce the problem to merging two Gramps databases. If you know the Gramps ID of a person common to the two databases, then tree-walking would be worth trying as a way to match people. The Database Differences report already provides a way of comparing objects between databases. Next, you would have to decide how automated you wanted the merge to be. Perhaps you would want to click checkboxes on the items in a differences report to merge? Nick. -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2024-04-13 16:37:40
|
Renée, Welcome to Gramps! I very much support your proposals. This is the best place to discuss them. Regarding the dynamic selection of "Section Role" specific to each row, the relationship to head of household field was originally recorded as a role in my first census prototype. I abandoned the idea because "Primary" and "Family" roles have a special meaning in the Gramps core code, and it was also difficult to come up with a list of relationships suitable for all the languages that we support. Now that the addon has expanded to cover forms in general, I can see that this would be useful. We can also revisit using roles in the census forms. It would be nice to be able to check a relationship against the tree for example. The preference menu allowing optional direct mapping of form fields from templates to Gedcom event or attribute objects is a commonly requested feature that I think will be very popular. As you point out, this must be customizable. Lack of flexibility was the stumbling block for the previous enhancement suggestion. The automatic update of the "date" field sounds like a bug. I'd expect it to populate as a default when creating a new form. If the user changes the date, then it shouldn't be automatically updated. A Template editor would really be a bonus. When you get to that stage, we should seriously consider integrating the forms into Gramps core. There is a user who is also interested in enhancements to the Forms addon. See: https://gramps.discourse.group/t/form-addon-development-questions/5242 Although I offered to help, it seems sensible to leave it to you. Regards, Nick. On 13/04/2024 03:14, Renee S wrote: > Hello, > I use Gramps for my family tree after migrating over from Legacy Family > Tree software. Thank you for the work you all do to keep the software going. > > I am not sure if this is the right location to post this, If the > information would be better posted somewhere else let me know and I will do > so. > > I am a self-taught python programmer and currently a college student > majoring in Machine Learning / Artificial Intelligence. I have some ideas > for updates to the Forms gramplet. Since I am doing a research fellowship > this summer instead of an internship I will have some extra time to work > with and would be interested in developing the features I have in mind. > > It is also worth noting that some of what I ampreference menu allowing optional direct mapping of form fields from > templates to gedcom event or attribute objects > proposing seems to have been > proposed before here: > https://www.gramps-project.org/wiki/index.php/GEPS_024:_Natural_transcription_of_Records > > Relevant Parts of My Background: > > - I have familiarized myself with the forms gramplet and produced/modified > a number of new forms myself which I use regularly throughout my tree. > > - Back in high school I made a tool that transformed Genscriber > transcriptions into GEDCOM files. Some of the updates I have in mind are > based on the features I built in this rather old project of mine (see: > https://github.com/rentheroot/Census2Ged/tree/master ) > > General Goals of Proposed Updates: > > - Greater customizability of the behavior of the Forms gramplet > > - Mapping of form fields in the Forms gramplet to events and attributes of > person records beyond just the "census" event > > - Template editing and creation from within the gramps interface (this > would probably actually be better organized as a separate addon that simply > extends the functionality of the Forms gramplet). > > Specific Features I Would Like to Develop: > > - Dynamic selection of "Section Role" specific to each row: > > Currently the form templates only allow for predefined roles to be assigned > to persons in a form through the use of the "role" tag in the "section" > field of the xml. This means that to allow, for instance, the roles of each > individual included in a census to be added as the actual role for the > census event the user must manually add new sections to the form templates > with duplicate form fields but different roles. The idea would be to allow > the user to select the role assigned to a person from a drop down selector > of roles used in their file. > > - A preference menu allowing optional direct mapping of form fields from > templates to gedcom event or attribute objects > > Documents often contain information that can be directly applied to event > definitions in Gedcom files, for instance 'Occupation'. To maintain high > levels of customizability and to prevent new users of the updated addon > from all of a sudden having their trees filled with new events the ideal > solution would be having form fields by default not map to any events. > However, incorporating a preference selector for the Forms gramplet could > provide users an option to map each form field in any of their templates to > any event tag they would like that field to map to. A refresh function > could then update all existing persons with attached forms to generate > events based on these fields. This feature appears to have been proposed in > the "Natural Transcription" GEP. > > - Option to disable the automatic update of the "date" field when editing > census forms. > > I personally like to use the enumeration date of the census as the date > attached to said census instead of the default date. However, currently to > change dates from default I have to go directly to the census event to > change the date, and the date is automatically updated back to default each > time the form is edited. > > - A Template editor within gramps > > This one is fairly self explanatory. It could be its own separate gramplet > or included as part of the Forms gramplet. It would allow Forms to be > created, edited, duplicated, and saved without the use of a text editor. > > Thank you for your consideration, > Renee Schmidt -------------- next part -------------- An HTML attachment was scrubbed... |