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
(5) |
Oct
|
Nov
|
Dec
|
From: Renee S <rj...@gm...> - 2024-04-13 02:14:51
|
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 am 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... |
From: <Emy...@ya...> - 2024-04-07 18:05:38
|
I completely agree that a breakdown of something as fundamental as the RelationshipCalculator justifies an immediate release... for users of the affected locality. But it should be made clear if that is the only critical issue. (The issue in Reports only seems like it affects trees with Family role events incorrectly assigned in Person Events. So data cleaning is the more appropriate action than updating.) Most English language users can wait for 5.2.3 Or did the RelCalc problem affect any of the other rtl languages? On Sun, Apr 7, 2024 at 9:08 AM, Nick Hall<ni...@gr...> wrote: On 06/04/2024 22:53, Emy...@ya... wrote: > What was the critical issue that motivated a maintenance release with > so little notice and so soon after 5.2.1? The Hebrew relationship calculator issue seemed important enough for a release. There were also a couple of other fixes and quite a few translation updates. > > > There are a couple other items that should have been considered. Like > inclusion of the deselected Isotammi project as a default and .gpr.py > files with the help_urls so the Addon Manager would be more navigable. > Please create a pull request for the inclusion of the Isotammi project in the default projects list. The last PR related to help_urls introduced quite a few new translatable strings, and was not suitable for a maintenance release. We can update the urls of third-party addons at any time though. Nick. -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2024-04-07 17:41:19
|
On 31/03/2024 21:26, David Straub wrote: > Concerning 2), I don't quite understand why users are interested in this > - for a publicly accessible file, the URL is a source citation, but the > file itself should still be downloaded and stored as a local media > object - unless the user relies on the file being at the same URL for > all times, which I don't think we can assume as genealogists. I got some feedback from Jan offlist. He is migrating from a Swedish program called MinSläkt in which a source can have an URL. He says "I could have saved each referred page as an image, but that would be an extra effort and would take up a lot of disk space both for gramps itself and for a generated web version." Taking a copy of the source citation is obviously a good idea, but it appears that some users don't want to do this. In some cases a user may still be interested in the original even if they have a local copy. There are also going to be cases where the original is something other than a source citation. Nick. -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2024-04-07 14:13:50
|
On 07/04/2024 14:03, Thierry Vignaud wrote: > > There are a couple other items that should have been considered. > Like inclusion of the deselected Isotammi project as a default and > .gpr.py files with the help_urls so the Addon Manager would be > more navigable. > > > It can still land in a later update Yes. I'm happy to release another version fairly soon. Nick. -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2024-04-07 14:08:30
|
On 06/04/2024 22:53, Emy...@ya... wrote: > What was the critical issue that motivated a maintenance release with > so little notice and so soon after 5.2.1? The Hebrew relationship calculator issue seemed important enough for a release. There were also a couple of other fixes and quite a few translation updates. > > > There are a couple other items that should have been considered. Like > inclusion of the deselected Isotammi project as a default and .gpr.py > files with the help_urls so the Addon Manager would be more navigable. > Please create a pull request for the inclusion of the Isotammi project in the default projects list. The last PR related to help_urls introduced quite a few new translatable strings, and was not suitable for a maintenance release. We can update the urls of third-party addons at any time though. Nick. |
From: Thierry V. <thi...@gm...> - 2024-04-07 13:03:49
|
Le sam. 6 avr. 2024, 23:54, Emyoulation--- via Gramps-devel < gra...@li...> a écrit : > Wait, what??? > > > What was the critical issue that motivated a maintenance release with so > little notice and so soon after 5.2.1? > > > There are a couple other items that should have been considered. Like > inclusion of the deselected Isotammi project as a default and .gpr.py files > with the help_urls so the Addon Manager would be more navigable. > It can still land in a later update -------------- next part -------------- An HTML attachment was scrubbed... |
From: <Emy...@ya...> - 2024-04-06 21:54:04
|
Wait, what??? What was the critical issue that motivated a maintenance release with so little notice and so soon after 5.2.1? There are a couple other items that should have been considered. Like inclusion of the deselected Isotammi project as a default and .gpr.py files with the help_urls so the Addon Manager would be more navigable. On Saturday, April 6, 2024 at 04:42:24 PM CDT, Nick Hall via Gramps-devel <gra...@li...> wrote: Version 5.2.2 - a new maintenance release, has been released 2024-04-06. Make sure to backup before you upgrade. See: https://www.gramps-project.org/wiki/index.php?title=How_to_make_a_backup Changes since v5.2.1: * Updated translations: cs, de, de_AT, es, fi, he, hr, nb, nl, pl, ru, sk, sv, tr. * Hebrew relationship calculator not loading. Fixes #13251. * Narweb: Person object has no get_father_handle. Fixes #13207. * Package Gramps 5.2.1 on macOS. * Restrict CI workflow to run on a single branch. * Don't show Navigation when we print a page. Fixes #13160. See the changelog for more details. https://gramps-project.org/bugs/changelog_page.php?version_id=114 You can obtain Gramps 5.2.2 from the GitHub release page. https://github.com/gramps-project/gramps/releases/tag/v5.2.2 _______________________________________________ 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-06 21:42:02
|
Version 5.2.2 - a new maintenance release, has been released 2024-04-06. Make sure to backup before you upgrade. See: https://www.gramps-project.org/wiki/index.php?title=How_to_make_a_backup Changes since v5.2.1: * Updated translations: cs, de, de_AT, es, fi, he, hr, nb, nl, pl, ru, sk, sv, tr. * Hebrew relationship calculator not loading. Fixes #13251. * Narweb: Person object has no get_father_handle. Fixes #13207. * Package Gramps 5.2.1 on macOS. * Restrict CI workflow to run on a single branch. * Don't show Navigation when we print a page. Fixes #13160. See the changelog for more details. https://gramps-project.org/bugs/changelog_page.php?version_id=114 You can obtain Gramps 5.2.2 from the GitHub release page. https://github.com/gramps-project/gramps/releases/tag/v5.2.2 |
From: Christopher H. <cd...@em...> - 2024-04-01 00:21:47
|
Because database schema changes tend to be more 'disruptive' I wonder if it makes sense to identify as many of the data model changes you want to make as possible and try to do them all at once. In doing so treat the object/data model update and necessary xml import/export support as a unit of work separate of updating all the editors, views, gramplets, reports, etc. All those enhancements to leverage the additional functionality the model changes enable can always be added incrementally afterwards. That is likely work many more hands can help participate in and it helps narrow and focus the scope of the set of changes that need to be made. The place enhancement changes tried not just to update the model but also update everything else to leverage it at the same time. Perhaps that is part of the reason it became too large and complex as it touched so many things as a result. Not sure that is the right approach, and it may not work for all the model changes that have been talked about, but may be worth considering. - Chris On Sun, 2024-03-31 at 16:52 +0100, Nick Hall via Gramps-devel wrote: > On 31/03/2024 13:40, David Straub wrote: > > > and I would even be willing to trial a much shorter time between > > > releases. > > I think it would be great to have a shorter cadence of feature > > releases, also because it's more motivating for (new) contributors > > if their enhancements land in the released version for themselves > > to enjoy. But since many of the new features you suggest require > > database changes, I am a bit worried about having a high cadence > > of_breaking_ changes. Personally I think database schema changes > > should not happen more than once a year, perhaps much more rarely. > > > > One possible SchemVer compatible policy could be: > > > > X.0.0 MAJOR - database schema changes or other major/breaking > > changes - target 1-0.5x/year > > *.X.0 MINOR - features - target 2-4x/per year > > *.*.X PATCH - bug fixes and translation updates (!) > > We should probably move away from setting targets. The availability > of > our developers is variable, and unforeseen circumstances such as > Covid > can always rear their heads again. > > Many enhancements are going to require database schema changes, > especially Gedcom 7.0 additions, so we will probably need to allow > them > in (*.X.0) minor/feature releases as we do at present. I'd prefer to > keep flexibility rather than introduce restrictions. > > Major (X.0.0) releases will probably still be quite infrequent. > > Let's try to capitalise on the momentum of the v5.2 release! > > I'll start separate threads to discuss allowing multi-user access and > web-accessible files in media paths. > > > 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-03-31 20:59:25
|
On 31/03/2024 19:40, David Straub wrote: > as already mentioned in the other thread, I think there are major > problems with using Gramps directly over a network connection, since a > lot of the code does not cope well with network latency, and dropping a > connection can easily lead to data loss. Everything is done > synchronously and there are lots of database round-trips even for simple > operations. Many of our users store their database on a network. Some of them access the database from more than one PC. The question I get asked is why can't they access the database from two PCs simultaneously? The answer is that there isn't much stopping them, but we are not quite there yet. > > The good news is, we already have a version of Gramps that works > perfectly with simultaneous, multi-user access to a SQLite database - > Gramps Web API. (And the next version will feature a shared undo log as > well - see the WIP athttps://github.com/gramps-project/gramps-web-api/pull/506, > based on the recently added functionality to provide a custom undo > database). The type of user I'm talking about probably doesn't want to use the Web API, or synchronize databases. > > My proposal would be to collect more user feedback what the actual use > case is. I personally think synchronization with a shared instance > running Gramps Web API is the best solution, and it works today; the > main disadvantage is that the sync addon is not great. So perhaps a > signficantly improvde sync addon added to core would be an option? > I've been receiving feedback on this for many years now. A significantly improved sync addon would be very popular. Whatever we decide, we can always enhance the sync addon. There are other reasons why we might want to make the changes I suggested. 1. At the moment an editor takes a snapshot of an object and saves it back when the "OK" is clicked. The locking that prevents conflicting access is part of the window manager. This is not ideal. For example, it is possible to run a tool when an editor is open. Consider the case where a tool modifies the object and then the "OK" is clicked in the editor. Committing a patched object rather than the original snapshot would solve this type of issue. In my prototype, it didn't even add any noticeable delay to exiting the editor. 2. The metadata in the database is only written back when closing the database. We had a report recently where a user lost metadata when their Gramps crashes. Again, this is not ideal. It would seem to be a better design to update the metadata when it changes. In this case there is no corruption or data loss. The user can simply do an export and import to restore the database. I can't see any real disadvantages with this approach, only benefits. I also don't want to prevent multi-user access. Users should be free to make a choice. They just have to be aware that network latency will impact performance. Regards, Nick. -------------- next part -------------- An HTML attachment was scrubbed... |
From: David S. <st...@pr...> - 2024-03-31 20:27:13
|
Hi, I am quite skeptical about this - I see two use cases for using media files from the web: 1) private files hosted in the cloud 2) publicly accessible files I think 1) is a valid use case, but using URLs as media path is not a solution, it does not handle authentication etc. - this would require a more general media handling like the Object Storage (aka S3) media handler in Gramps Web API. Concerning 2), I don't quite understand why users are interested in this - for a publicly accessible file, the URL is a source citation, but the file itself should still be downloaded and stored as a local media object - unless the user relies on the file being at the same URL for all times, which I don't think we can assume as genealogists. The fact that Gedcom allows this isn't a very strong argument in my opinion, since the format is defined by an organization that is interested in promoting their own web-based sources. In my opinion the best way to handle URLs in Gedcom media objects would be to download the file on Gedcom import. That would be straightforward to implement as well. Cheers, David Nick Hall via Gramps-devel <gra...@li...> schrieb am Sonntag, 31. März 2024 um 21:37: > > > Devs, > > In Gedcom 7.0, the file path of a media object can contain an URL. In > particular: > > "A URL with scheme ftp , http , or https refers to a web-accessible file." > > > I started to look at this in pull request #1447 "Allowing web-accessible > file references in media objects": > > https://github.com/gramps-project/gramps/pull/1447 > > Unfortunately, I didn't have time to get very far. > > > See also pull request #1200 "Internet tab added to Media category.": > > https://github.com/gramps-project/gramps/pull/1200 > > This is where we decided that the Gedcom approach was better than adding > more Internet tabs. > > > Is anyone interested in this feature? > > > Regards, > > > Nick. > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: <Emy...@ya...> - 2024-03-31 20:05:46
|
Note that GEDCOM imports have a Preferences Option for Tagging and setting a Citation during import. This sabotages the ability to use the Last Modified to find the more recent data in Merges. Perhaps import could reset Modified Date to the timestamps in the GEDCOM (or other data format imports?) record AFTER tagging/citing would be a workaround? On Sun, Mar 31, 2024 at 1:34 PM, Per Starbäck<pe...@st...> wrote: I don't know if this is relevant here, but it is related. I think it would be very useful to have some general framework for synchronising some data with an external source. It should keep track of what it has seen earlier from that external source and what the user has marked as up-to-date. And then when the external source is checked again it will see what has changed since last time and indicate which profiles or other information you might want to take a look at because of new info. Examples: * You have a distant cousin who is also doing genealogy, so part of your tree is of interest to them as well. You don't really work together, but now and then the cousin sends you a Gedcom (exported from whatever system they are using -- maybe not Gramps) with their current subtree. Then you get a report of changes since last time. "The birth date for person X is changed from May 2 to May 12; Person Y.now has a place of death", etc; which you can look through.The crucial point is that the new data is compared not primarily to *your* data, but to the previous version from the cousin. So if the cousin has standardized a name differently than you have you will not get a report about that each time, because that's old info you already have thought about. Only when the cousin has changed something you want to take a new look. Ideally the report should ignore any change where the new values agree with that's in your (current) tree though. * Besides working locally you also put (some of) your data on a network tree, for example Wikitree, or you have links to other web pages describing the person/place, for example Wikidata. In these cases the synching could be done often and automatically in the background. You'll get a report saying for example that a recent Wikitree edit has changed who the father is for a particular person you have in your database, and then you can check what that's about. Maybe this framework I'm imagining doesn't require anything new from Gramps as such? Den sön 31 mars 2024 kl 19:32 skrev Nick Hall via Gramps-devel <gra...@li...>: > > Devs, > > Following a comment in the "Roadmap for v5.3" thread, I'll start a > discussion here. > > This has been discussed before, so I'll start with some background. We > chose to run the BSDDB backend in single-user mode for performance > reasons. A lock file prevented multi-user access, and breaking this > lock to run two connections at once was bad news. In fact, I expect > that some people have lost data in the past by doing this. > > We get requests on a fairly regular basis from users who would like to > access a Gramps database stored on a LAN from more than one desktop. > The responses from our last user survey also indicated that people would > like to see this functionality. > > With the introduction of the SQLite backend the situation changed. This > database can handle multi-user access and some years ago I wrote a > prototype to investigate further. My approach was to update the editors > so that they only applied changes to the database in a commit rather > then an updated snapshot. This was a success, but I identified two > problems: > > * Database metadata is not shared because it is only written back at the > end of a session. > > * The undo log is not shared because it is stored on the client-side and > not in the database. > > At this point I put the project on the back burner. It became a medium > to long-term goal. > > The current situation is that multi-user access works, but I wouldn't > want to make it public yet. Anyone who breaks a lock and runs two > instances by mistake isn't going to get into the problems of the BSDDB > backend. > > I'd be happy to look at this again. > > > Regards, > > > Nick. > > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel _______________________________________________ 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-03-31 19:37:28
|
Devs, In Gedcom 7.0, the file path of a media object can contain an URL. In particular: "A URL with scheme ftp , http , or https refers to a web-accessible file." I started to look at this in pull request #1447 "Allowing web-accessible file references in media objects": https://github.com/gramps-project/gramps/pull/1447 Unfortunately, I didn't have time to get very far. See also pull request #1200 "Internet tab added to Media category.": https://github.com/gramps-project/gramps/pull/1200 This is where we decided that the Gedcom approach was better than adding more Internet tabs. Is anyone interested in this feature? Regards, Nick. |
From: David S. <st...@pr...> - 2024-03-31 18:41:16
|
Hi all, as already mentioned in the other thread, I think there are major problems with using Gramps directly over a network connection, since a lot of the code does not cope well with network latency, and dropping a connection can easily lead to data loss. Everything is done synchronously and there are lots of database round-trips even for simple operations. The good news is, we already have a version of Gramps that works perfectly with simultaneous, multi-user access to a SQLite database - Gramps Web API. (And the next version will feature a shared undo log as well - see the WIP at https://github.com/gramps-project/gramps-web-api/pull/506, based on the recently added functionality to provide a custom undo database). My proposal would be to collect more user feedback what the actual use case is. I personally think synchronization with a shared instance running Gramps Web API is the best solution, and it works today; the main disadvantage is that the sync addon is not great. So perhaps a signficantly improvde sync addon added to core would be an option? Concerning the "partial sync/merge" mentioned by Per: I agree this is a common use case, but in general it is very difficult. For partial sync of Gramps-based trees, the Import Merge Addon is our best option. For non-Gramps-based (WikiTree etc.), we would at least need some kind of UID support. Happy Easter! David Per Starbäck <pe...@st...> schrieb am Sonntag, 31. März 2024 um 20:33: > > > I don't know if this is relevant here, but it is related. > > I think it would be very useful to have some general framework for > synchronising some data with an external source. It should keep track > of what it has seen earlier from that external source and what the > user has marked as up-to-date. And then when the external source is > checked again it will see what has changed since last time and > indicate which profiles or other information you might want to take a > look at because of new info. > > Examples: > * You have a distant cousin who is also doing genealogy, so part of > your tree is of interest to them as well. You don't really work > together, but now and then the cousin sends you a Gedcom (exported > from whatever system they are using -- maybe not Gramps) with their > current subtree. Then you get a report of changes since last time. > "The birth date for person X is changed from May 2 to May 12; Person Y > now has a place of death", etc; which you can look through.The crucial > point is that the new data is compared not primarily to your data, > but to the previous version from the cousin. So if the cousin has > standardized a name differently than you have you will not get a > report about that each time, because that's old info you already have > thought about. Only when the cousin has changed something you want to > take a new look. Ideally the report should ignore any change where the > new values agree with that's in your (current) tree though. > > * Besides working locally you also put (some of) your data on a > network tree, for example Wikitree, or you have links to other web > pages describing the person/place, for example Wikidata. In these > cases the synching could be done often and automatically in the > background. You'll get a report saying for example that a recent > Wikitree edit has changed who the father is for a particular person > you have in your database, and then you can check what that's about. > > Maybe this framework I'm imagining doesn't require anything new from > Gramps as such? > > Den sön 31 mars 2024 kl 19:32 skrev Nick Hall via Gramps-devel > gra...@li...: > > > Devs, > > > > Following a comment in the "Roadmap for v5.3" thread, I'll start a > > discussion here. > > > > This has been discussed before, so I'll start with some background. We > > chose to run the BSDDB backend in single-user mode for performance > > reasons. A lock file prevented multi-user access, and breaking this > > lock to run two connections at once was bad news. In fact, I expect > > that some people have lost data in the past by doing this. > > > > We get requests on a fairly regular basis from users who would like to > > access a Gramps database stored on a LAN from more than one desktop. > > The responses from our last user survey also indicated that people would > > like to see this functionality. > > > > With the introduction of the SQLite backend the situation changed. This > > database can handle multi-user access and some years ago I wrote a > > prototype to investigate further. My approach was to update the editors > > so that they only applied changes to the database in a commit rather > > then an updated snapshot. This was a success, but I identified two > > problems: > > > > * Database metadata is not shared because it is only written back at the > > end of a session. > > > > * The undo log is not shared because it is stored on the client-side and > > not in the database. > > > > At this point I put the project on the back burner. It became a medium > > to long-term goal. > > > > The current situation is that multi-user access works, but I wouldn't > > want to make it public yet. Anyone who breaks a lock and runs two > > instances by mistake isn't going to get into the problems of the BSDDB > > backend. > > > > I'd be happy to look at this again. > > > > Regards, > > > > Nick. > > > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Per S. <pe...@st...> - 2024-03-31 18:34:08
|
I don't know if this is relevant here, but it is related. I think it would be very useful to have some general framework for synchronising some data with an external source. It should keep track of what it has seen earlier from that external source and what the user has marked as up-to-date. And then when the external source is checked again it will see what has changed since last time and indicate which profiles or other information you might want to take a look at because of new info. Examples: * You have a distant cousin who is also doing genealogy, so part of your tree is of interest to them as well. You don't really work together, but now and then the cousin sends you a Gedcom (exported from whatever system they are using -- maybe not Gramps) with their current subtree. Then you get a report of changes since last time. "The birth date for person X is changed from May 2 to May 12; Person Y now has a place of death", etc; which you can look through.The crucial point is that the new data is compared not primarily to *your* data, but to the previous version from the cousin. So if the cousin has standardized a name differently than you have you will not get a report about that each time, because that's old info you already have thought about. Only when the cousin has changed something you want to take a new look. Ideally the report should ignore any change where the new values agree with that's in your (current) tree though. * Besides working locally you also put (some of) your data on a network tree, for example Wikitree, or you have links to other web pages describing the person/place, for example Wikidata. In these cases the synching could be done often and automatically in the background. You'll get a report saying for example that a recent Wikitree edit has changed who the father is for a particular person you have in your database, and then you can check what that's about. Maybe this framework I'm imagining doesn't require anything new from Gramps as such? Den sön 31 mars 2024 kl 19:32 skrev Nick Hall via Gramps-devel <gra...@li...>: > > Devs, > > Following a comment in the "Roadmap for v5.3" thread, I'll start a > discussion here. > > This has been discussed before, so I'll start with some background. We > chose to run the BSDDB backend in single-user mode for performance > reasons. A lock file prevented multi-user access, and breaking this > lock to run two connections at once was bad news. In fact, I expect > that some people have lost data in the past by doing this. > > We get requests on a fairly regular basis from users who would like to > access a Gramps database stored on a LAN from more than one desktop. > The responses from our last user survey also indicated that people would > like to see this functionality. > > With the introduction of the SQLite backend the situation changed. This > database can handle multi-user access and some years ago I wrote a > prototype to investigate further. My approach was to update the editors > so that they only applied changes to the database in a commit rather > then an updated snapshot. This was a success, but I identified two > problems: > > * Database metadata is not shared because it is only written back at the > end of a session. > > * The undo log is not shared because it is stored on the client-side and > not in the database. > > At this point I put the project on the back burner. It became a medium > to long-term goal. > > The current situation is that multi-user access works, but I wouldn't > want to make it public yet. Anyone who breaks a lock and runs two > instances by mistake isn't going to get into the problems of the BSDDB > backend. > > I'd be happy to look at this again. > > > Regards, > > > Nick. > > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Nick H. <ni...@gr...> - 2024-03-31 17:31:35
|
Devs, Following a comment in the "Roadmap for v5.3" thread, I'll start a discussion here. This has been discussed before, so I'll start with some background. We chose to run the BSDDB backend in single-user mode for performance reasons. A lock file prevented multi-user access, and breaking this lock to run two connections at once was bad news. In fact, I expect that some people have lost data in the past by doing this. We get requests on a fairly regular basis from users who would like to access a Gramps database stored on a LAN from more than one desktop. The responses from our last user survey also indicated that people would like to see this functionality. With the introduction of the SQLite backend the situation changed. This database can handle multi-user access and some years ago I wrote a prototype to investigate further. My approach was to update the editors so that they only applied changes to the database in a commit rather then an updated snapshot. This was a success, but I identified two problems: * Database metadata is not shared because it is only written back at the end of a session. * The undo log is not shared because it is stored on the client-side and not in the database. At this point I put the project on the back burner. It became a medium to long-term goal. The current situation is that multi-user access works, but I wouldn't want to make it public yet. Anyone who breaks a lock and runs two instances by mistake isn't going to get into the problems of the BSDDB backend. I'd be happy to look at this again. Regards, Nick. |
From: Nick H. <ni...@gr...> - 2024-03-31 15:52:33
|
On 31/03/2024 13:40, David Straub wrote: >> and I would even be willing to trial a much shorter time between releases. > I think it would be great to have a shorter cadence of feature releases, also because it's more motivating for (new) contributors if their enhancements land in the released version for themselves to enjoy. But since many of the new features you suggest require database changes, I am a bit worried about having a high cadence of_breaking_ changes. Personally I think database schema changes should not happen more than once a year, perhaps much more rarely. > > One possible SchemVer compatible policy could be: > > X.0.0 MAJOR - database schema changes or other major/breaking changes - target 1-0.5x/year > *.X.0 MINOR - features - target 2-4x/per year > *.*.X PATCH - bug fixes and translation updates (!) We should probably move away from setting targets. The availability of our developers is variable, and unforeseen circumstances such as Covid can always rear their heads again. Many enhancements are going to require database schema changes, especially Gedcom 7.0 additions, so we will probably need to allow them in (*.X.0) minor/feature releases as we do at present. I'd prefer to keep flexibility rather than introduce restrictions. Major (X.0.0) releases will probably still be quite infrequent. Let's try to capitalise on the momentum of the v5.2 release! I'll start separate threads to discuss allowing multi-user access and web-accessible files in media paths. Nick. -------------- next part -------------- An HTML attachment was scrubbed... |
From: David S. <st...@pr...> - 2024-03-31 12:40:51
|
Hi Nick, great to hear, some random thoughts from my side: > and I would even be willing to trial a much shorter time between releases. I think it would be great to have a shorter cadence of feature releases, also because it's more motivating for (new) contributors if their enhancements land in the released version for themselves to enjoy. But since many of the new features you suggest require database changes, I am a bit worried about having a high cadence of _breaking_ changes. Personally I think database schema changes should not happen more than once a year, perhaps much more rarely. One possible SchemVer compatible policy could be: X.0.0 MAJOR - database schema changes or other major/breaking changes - target 1-0.5x/year *.X.0 MINOR - features - target 2-4x/per year *.*.X PATCH - bug fixes and translation updates (!) > Allowing multi-user access. I suggest to have a detailed discussion about architecture before deciding on an approach. Having worked with network-based Gramps for a while now, in my opinion the current architecture of Gramps Desktop is not suited for use over the network in presence of network latency and possible loss of connection - everything is synchronous. Making it asynchronous, one basically ends up with Gramps Web API (not referring to the web app, but to the REST API). As a passionate Gramps Desktop user, I wouldn't want to loose the ability to edit my tree offline in an underground archive; so synchronization (using Web API or not) rather than direct network access might be more promising. > Some Gedcom related enhancements will probably be less controversial I suggest to add GEDCOM 7 support to the list. Other apps (thinking about the German-based commercial ones...) will use this as a selling point. > Allow web-accessible files in media paths. I think there are many pitfalls here. Would be happy to contribute lessons learned from Web API. I also suggest to have an architecture discussion before committing to an approach. In my opinion, it would make sense to replace all the direct open() calls in the code by a dedicated abstract media handler, where web accessible files can be one possible implementation. Happy Easter! David Nick Hall via Gramps-devel <gra...@li...> schrieb am Freitag, 29. März 2024 um 19:40: > > > Devs, > > Now that the release of v5.2 is behind us, it is time to think about the > roadmap for the next major release. > > Firstly, we need to decide on a schedule. The timeframe for v5.2 was > obviously far too long. The interval between major releases should > really be no longer than a year, and I would even be willing to trial a > much shorter time between releases. > > As usual this is also the time to suggest policy changes. > > Then we need to discuss what major goals to set and any database model > changes they may require. Suggestions have already been made. > > There are some big long-standing topics such as: > > * Using JSON as the raw representation of objects. > * Allowing multi-user access. > * Improvements to the Gramps types. > * Modelling of ships and heirlooms - Perhaps creating a new "Thing" > primary object? > * Place enhancements - will depend on other decisions made. > > Some Gedcom related enhancements will probably be less controversial: > > * Add creation date to primary objects. > * Add identifier structure to primary objects. > * Allow web-accessible files in media paths. > * Add dates to individual and family attributes. > * Add time and phrase to date objects. > * New Submitter primary object. > * Add translations to notes. > > Feel free to mention anything else. I have probably forgotten something > and new suggestions are always welcome. > > Regards, > > > Nick. > > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: <Emy...@ya...> - 2024-03-31 00:38:12
|
That would also be helpful for the ChromeOS Chromebooks. Where the "drop" portion of drag'n'drop does not work. On Saturday, March 30, 2024 at 07:05:34 PM CDT, Nick Hall via Gramps-devel <gra...@li...> wrote: That seems reasonable to me. I suggest that you start by compiling a list of changes that need to be made. Nick. On 29/03/2024 20:42, David Lynch wrote: > I propose: > > * Enable use of all Gramps' features, including the clipboards, using > keyboard only, without mouse. > > I have reduced my mouse usage with AutoHotkey scripts but results are > limited. A more complete solution would need redesign. > > _______________________________________________ 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-03-31 00:05:18
|
That seems reasonable to me. I suggest that you start by compiling a list of changes that need to be made. Nick. On 29/03/2024 20:42, David Lynch wrote: > I propose: > > * Enable use of all Gramps' features, including the clipboards, using > keyboard only, without mouse. > > I have reduced my mouse usage with AutoHotkey scripts but results are > limited. A more complete solution would need redesign. > > |
From: Nick H. <ni...@gr...> - 2024-03-30 23:52:29
|
Our documentation is confusing, and both 4.1.0 and 4.2.0 are described as major releases in the announcements. I just continued what I thought was the Gramps convention. Looking back further I see that the term "feature release" was used for a minor release. In the future I suggest we use the terms major, feature and maintenance. I agree that we need to be flexible. Lets set schedules on a release by release basis. Nick. On 29/03/2024 20:27, John Ralls wrote: > Nick, > > Maybe consider a more flexible feature introduction to more frequent > “major” releases (which are really “minor” releases given our 3-part > numbering system: v6.0.0 would be a “major” release). Regardless of what > you call them it’s hard to get major changes like multi-user access, > JSON objects, or Gtk4 done in a year. > > Regards, > John Ralls -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2024-03-29 18:40:53
|
Devs, Now that the release of v5.2 is behind us, it is time to think about the roadmap for the next major release. Firstly, we need to decide on a schedule. The timeframe for v5.2 was obviously far too long. The interval between major releases should really be no longer than a year, and I would even be willing to trial a much shorter time between releases. As usual this is also the time to suggest policy changes. Then we need to discuss what major goals to set and any database model changes they may require. Suggestions have already been made. There are some big long-standing topics such as: * Using JSON as the raw representation of objects. * Allowing multi-user access. * Improvements to the Gramps types. * Modelling of ships and heirlooms - Perhaps creating a new "Thing" primary object? * Place enhancements - will depend on other decisions made. Some Gedcom related enhancements will probably be less controversial: * Add creation date to primary objects. * Add identifier structure to primary objects. * Allow web-accessible files in media paths. * Add dates to individual and family attributes. * Add time and phrase to date objects. * New Submitter primary object. * Add translations to notes. Feel free to mention anything else. I have probably forgotten something and new suggestions are always welcome. Regards, Nick. |
From: John R. <jr...@ce...> - 2024-03-28 19:41:09
|
macOS dmgs for 5.2.1 are on Sourceforge and Github. Regards, John Ralls |
From: Nick H. <ni...@gr...> - 2024-03-28 19:03:40
|
I have just uploaded v5.2.1 to PyPI. Nick. On 27/03/2024 12:21, David Straub via Gramps-devel wrote: > Hi, > > can we also get the updated PyPI package for 5.2.1? Would be > straightforward to auto-release that using a Github action in the > future. > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... |
From: David S. <st...@pr...> - 2024-03-27 12:22:23
|
Hi, can we also get the updated PyPI package for 5.2.1? Would be straightforward to auto-release that using a Github action in the future. Thanks, David Bruno Cornec via Gramps-devel <gra...@li...> schrieb am Mittwoch, 27. März 2024 um 12:18: > > > Hello, > > I tend to use instead rpmfind for that: > http://rpmfind.net/linux/rpm2html/search.php?query=GRAMPS&submit=Search+...&system=Mageia&arch= > > We do not really use madb for that, but that coule be indeed an > improvement to make. > > BTW the push is in fact just currently done ! > Bruno. > > > Emy...@ya... said on Mon, Mar 25, 2024 at 03:53:33PM +0000: > > > Date: Mon, 25 Mar 2024 15:53:33 +0000 (UTC) > > From: "Emy...@ya..." emy...@ya... > > Subject: Re: [Gramps-devel] [Gramps-announce] Gramps 5.2.1 released > > To: br...@vi..., Gramps Development List > > gra...@li... > > Reply-To: "Emy...@ya..." emy...@ya... > > X-Mailer: WebService/1.1.22205 YahooMailAndroidMobile > > > > Thanks Bruno! > > Wow, navigating the Mageia App Db is complicated. Or maybe I should be looking elsewhere? > > https://madb.mageia.org/ > > > > Is there a way to show the unfiltered list? It looks like the primary distribtions: Cauldron, Latest stable (9), previous stable (8) all have multiple variants (aarch64, armv5tl, armv7hl, i586, x86_64) that have to be checked for their Gramps versions? > > Can we see all the Versions at one time? I'd like to update the Linux distribution > > > > On Mon, Mar 25, 2024 at 10:21 AM, Bruno Cor...@vi... wrote: Hello, > > > > Pushed to Mageia Cauldron. > > > > Bruno. > > > > john said on Mon, Mar 25, 2024 at 09:12:51AM +0100: > > > > > I'm traveling through Wednesday so I won't be able to make the macOS bundles until Thursday. > > > > > > > On Mar 25, 2024, at 01:01, Nick Hall via Gramps-announce gra...@li... wrote: > > > > Version 5.2.1 - a new maintenance release, has been released 2024-03-24. > > > -- > Des infos sur la musique ancienne -- http://www.musique-ancienne.org > Des infos sur les logiciels libres -- http://www.HyPer-Linux.org > Home, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, > Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order) > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |