Nabble - GRAMPS

Media Rectangles for all images

2009-12-05T03:23:12Z

Greetings all:

I think that I have finally added media rectangles to all the images in NarrativeWeb! Please test it all out completely. Please report issues to me...

Any comments or helpful thoughts will be greatly appreciated. Svn up to r13715... The bug report is #2698

Sincerely yours,
Rob G. Healey

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

From forum: GRAMPS - Dev

Re: Loose Coupling?

2009-12-05T01:08:14Z

2009/12/5 Doug Blank <doug.blank@...>:

> On Sat, Dec 5, 2009 at 12:07 AM, Doug Blank <doug.blank@...> wrote:
>> On Fri, Dec 4, 2009 at 7:35 AM, Doug Blank <doug.blank@...> wrote:
>>> Benny,
>>>
>>> Thanks for the feedback. This sounds exactly like the trade-offs
>>> between "loose" and "strong" coupling.
>>>
>>> On the one hand, we currently have exact control over what loads and
>>> where items are placed because we use strongly coupling. On the other
>>> hand, if we want loose coupling, we need to be able to solve those
>>> issues without relying on coupling. I think we can get a good balance
>>> between controlling some parts without having to specify in other
>>> files too much detail.
>>>
>>> What I would like to do is think about how this control could come
>>> "bottom up" (in the plugin) rather than "top down" (in the code that
>>> loads the plugin). That would allow new plugin types without having
>>> strong coupling. (Or maybe you are right... just have a pre-specified
>>> default order to get started).
>>>
>>> I agree: the goal would be for the ordering of Views to be the same as
>>> now, but would allow for future, new view types (and for the user to
>>> be able to rearrange these).
>>>
>>> I'll work on that...
>>
>> Trunk revision 13705 now contains these changes, now with loose
>> coupling. Please test this out, and see if this looks robust. The main
>> difference is that one can now make up a new view type, and add pages
>> to it without having to edit any file other than the plugin you're
>> defining. There are currently 13 view types now, so we may want to
>> look at Nick's treeview idea for Views sooner than later. I can
>> imagine a "Time" view too that might show calendars and timelines...
>>
>> In any event, these current set of changes include:
>>
>> - new config "interface.view-categories" that defines the known
>> categories, in order
>> - if a loaded view cat is not in "view-categories", then it comes
>> next, in alphabetic order
>> - views now set their category in registration, category = (name,
>> translated-name)
>> - toolbar shows view *names* (from registration), not title (so you
>> can change in registration)
>> - should work with gettext and views show in native locale
>> - predefined pages should be first; if more, they follow
>> - tested with multiple gramplets views, works fine
>>
>> To add more than one gramplet page, you can put
>> anothergrampletview.gpr.py in src/plugins/view/ (has to be there, next
>> to grampletview.py) with this in it:
>>
>> register(VIEW,
>> id = 'grampletview2',
>> name = _("Gramplet View 2"),
>> description = _("The view allowing to see Gramplets"),
>> version = '1.0',
>> status = STABLE,
>> fname = 'grampletview.py',
>> authors = [u"The Gramps project"],
>> authors_email = ["http://gramps-project.org"],
>> category = ("Gramplets", _("Gramplets")),
>> viewclass = 'GrampletView',
>> )
>>
>> Note that it has a different ID from the other gramplet view, and the
>> name is used in toolbar. That's all you have to do (and BTW gramplets
>> remember what page they came from).
>
> FYI: Two (or more) gramplet pages doesn't quite work completely...
> when you close gramps, both pages save their settings in the same
> file. That can be fixed fairly easily by saving based on view page
> name...
>
> -Doug

This is the kind of testing we need :-)

I would expect that due to the sidebar not being on top of a
gtk.scrolledwindow, that adding many view categories gives a bad
interface too, so we probably need to add the buttons to a
scrolledwindow ...

Benny

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

From forum: GRAMPS - Dev

Re: Loose Coupling?

2009-12-04T22:43:10Z

On Sat, Dec 5, 2009 at 12:07 AM, Doug Blank <doug.blank@...> wrote:

> On Fri, Dec 4, 2009 at 7:35 AM, Doug Blank <doug.blank@...> wrote:
>> Benny,
>>
>> Thanks for the feedback. This sounds exactly like the trade-offs
>> between "loose" and "strong" coupling.
>>
>> On the one hand, we currently have exact control over what loads and
>> where items are placed because we use strongly coupling. On the other
>> hand, if we want loose coupling, we need to be able to solve those
>> issues without relying on coupling. I think we can get a good balance
>> between controlling some parts without having to specify in other
>> files too much detail.
>>
>> What I would like to do is think about how this control could come
>> "bottom up" (in the plugin) rather than "top down" (in the code that
>> loads the plugin). That would allow new plugin types without having
>> strong coupling. (Or maybe you are right... just have a pre-specified
>> default order to get started).
>>
>> I agree: the goal would be for the ordering of Views to be the same as
>> now, but would allow for future, new view types (and for the user to
>> be able to rearrange these).
>>
>> I'll work on that...
>
> Trunk revision 13705 now contains these changes, now with loose
> coupling. Please test this out, and see if this looks robust. The main
> difference is that one can now make up a new view type, and add pages
> to it without having to edit any file other than the plugin you're
> defining. There are currently 13 view types now, so we may want to
> look at Nick's treeview idea for Views sooner than later. I can
> imagine a "Time" view too that might show calendars and timelines...
>
> In any event, these current set of changes include:
>
> - new config "interface.view-categories" that defines the known
> categories, in order
> - if a loaded view cat is not in "view-categories", then it comes
> next, in alphabetic order
> - views now set their category in registration, category = (name,
> translated-name)
> - toolbar shows view *names* (from registration), not title (so you
> can change in registration)
> - should work with gettext and views show in native locale
> - predefined pages should be first; if more, they follow
> - tested with multiple gramplets views, works fine
>
> To add more than one gramplet page, you can put
> anothergrampletview.gpr.py in src/plugins/view/ (has to be there, next
> to grampletview.py) with this in it:
>
> register(VIEW,
> id = 'grampletview2',
> name = _("Gramplet View 2"),
> description = _("The view allowing to see Gramplets"),
> version = '1.0',
> status = STABLE,
> fname = 'grampletview.py',
> authors = [u"The Gramps project"],
> authors_email = ["http://gramps-project.org"],
> category = ("Gramplets", _("Gramplets")),
> viewclass = 'GrampletView',
> )
>
> Note that it has a different ID from the other gramplet view, and the
> name is used in toolbar. That's all you have to do (and BTW gramplets
> remember what page they came from).

FYI: Two (or more) gramplet pages doesn't quite work completely...
when you close gramps, both pages save their settings in the same
file. That can be fixed fairly easily by saving based on view page
name...

-Doug

> The one item I didn't really like is that category is a tuple of the
> form ("Category name", _("Category name")). Need both trans and
> untrans versions. But I liked that the best of all of the
> alternatives.
>
> Currently, there is no way other than editing the gramps32.ini to
> change the order of view categories.
>
> -Doug
>
>> -Doug
>>
>> On Fri, Dec 4, 2009 at 5:39 AM, Benny Malengier
>> <benny.malengier@...> wrote:
>>> 2009/12/4 Doug Blank <doug.blank@...>:
>>>> Devs,
>>>>
>>>> One thing I have come to appreciate in working with Django is its
>>>> consistent use of the idea of "loose coupling". I wasn't real familiar
>>>> with the philosophy before, but when I began to understand it, I
>>>> realized that this is exactly one of the things that Gramps doesn't
>>>> have and has always bothered me. In fact, I would describe Gramps as
>>>> strongly coupled.
>>>>
>>>> The philosophy can be read about in detail in any number of places
>>>> (for example, [1]). In a word: "Coupling refers to the degree of
>>>> direct knowledge that one class has of another." Many people interpret
>>>> this also as "the degree of direct knowledge that one part of the code
>>>> has of another part." A good test of the idea is: how many files do
>>>> you have to edit in order to add new code?
>>>>
>>>> I am currently wrestling with this idea in working with the View
>>>> display code. Currently, we have a plugin category ID for every type
>>>> of view. But loose coupling would suggest that there is no need to
>>>> pre-specify these types; they could be discovered when we load the
>>>> plugins. (This is just an example of loose coupling, but the idea
>>>> could be used in many places throughout gramps).
>>>>
>>>> For example, say that I want to add a new kind of View... perhaps a
>>>> Data Entry view (let's call the view category "Certificates" and the
>>>> view "Census"). Currently, we would have to edit a number of files to
>>>> add the new view type to define and expose this. On the other hand,
>>>> loose coupling says: Gramps doesn't know about view types, and will
>>>> just define the views as needed. This seems to be a more Pythonic
>>>> approach, and makes extending a project much easier (there are no
>>>> additional files to find and edit).
>>>>
>>>> One downside is that you won't discover a misnamed View type until you
>>>> see that the view is showing up in the wrong place. But this would of
>>>> course be obvious the instant you run the code. Strongly coupled code
>>>> (like gramps currently is) might immediately give an error and crash
>>>> on a mislabeled view (or would just put it in the wrong category) but
>>>> would require knowledge about the view in multiple places.
>>>>
>>>> I'd like to advocate more loose coupling in gramps, but wonder if
>>>> there is resistance to this philosophy, and if so, why. Feedback
>>>> appreciated.
>>>
>>> Well, the code you refer to is like that because we want the user
>>> interface to look a certain way, and hence presets what can be
>>> possible, and presets the order in which views will be shown in the
>>> interface sidebar.
>>>
>>> If you don't need this control, that code can go out, and you have no
>>> more coupling, but I believe we need to guard how Gramps ends up
>>> looking without allowing for plugins to just create some sort of
>>> anarchy.
>>>
>>> So, it is the same as the preset order in the reports or tools menu.
>>> I think things are still logical:
>>> --> plugins/pluginreg.py knows how a gpr.py file defines a view plugin.
>>> --> because we preset the allowed categories, pluginreg.py also
>>> defines this and does not load plugins that are in unknown category
>>> --> gui/grampsgui.py has a function to obtain registered views, import
>>> the files, and order them as we want them for the gramps interface.
>>> --> gui/viewmanager.py uses the API of a generic view to drive the interface.
>>>
>>> I do not see much coupling here, just that we want some control you
>>> would rather have we do not have. It is easy to change the code to
>>> have some predefined categories of views, and then allow for extra
>>> categories behind that as defined in view plugins. We then would still
>>> have the desired control of the interface (show the views we want on
>>> startup in the order of Gramps). Feel free to change the code like
>>> that, so remove the MISC category, create a GRAMPLET category, and
>>> then allow plugins to register to unknown categories, which the
>>> interface code appends to the end of the viewcategories in the
>>> sidebar.
>>>
>>> Note that in the future we would want to add reordering views in the
>>> sidebar, so the control over how the views look like is something we
>>> want for the 'default-out-of-the-box' experience, not something that
>>> users would not be allowed to change (as they could in 3.1.x by
>>> changing the listing in the ini file).
>>>
>>> As an aside:
>>> 1/ I think it would be interesting if you offer in gramps-addons, a
>>> second gramplet view. So the user would download this (it would be
>>> only a gpr.py file) and then the gramplet category has two views in
>>> which gramplets can be shown
>>> 2/ I did not finish the changes yet. What still has to happen: the
>>> view menu must contain a configure option (like the toolbar icon which
>>> I would allow to hide via the preferences), or perhaps a configure
>>> menu with entry for each shown view. The view menu should also offer a
>>> way to switch to another view in the category for those cases the
>>> toolbar is not visible. The column order dialog would move into the
>>> view configuration.
>>>
>>> To come back to the original question, yes, loose coupling is a nice
>>> aim. However, in Gui code you will need some model class that controls
>>> the view, and you will also need API's that other classes then need to
>>> implement. Obviously, API changes lead to a host of changes that need
>>> to be done in other files, I see no way around that.
>>>
>>> Benny
>>>
>>>> -Doug
>>>>
>>>> [1] - http://en.wikipedia.org/wiki/Loose_coupling
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>>> a free event focused on virtualization and cloud computing.
>>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>>> _______________________________________________
>>>> Gramps-devel mailing list
>>>> Gramps-devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>>
>>>
>>
>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

From forum: GRAMPS - Dev

Re: Loose Coupling?

2009-12-04T21:07:47Z

On Fri, Dec 4, 2009 at 7:35 AM, Doug Blank <doug.blank@...> wrote:

> Benny,
>
> Thanks for the feedback. This sounds exactly like the trade-offs
> between "loose" and "strong" coupling.
>
> On the one hand, we currently have exact control over what loads and
> where items are placed because we use strongly coupling. On the other
> hand, if we want loose coupling, we need to be able to solve those
> issues without relying on coupling. I think we can get a good balance
> between controlling some parts without having to specify in other
> files too much detail.
>
> What I would like to do is think about how this control could come
> "bottom up" (in the plugin) rather than "top down" (in the code that
> loads the plugin). That would allow new plugin types without having
> strong coupling. (Or maybe you are right... just have a pre-specified
> default order to get started).
>
> I agree: the goal would be for the ordering of Views to be the same as
> now, but would allow for future, new view types (and for the user to
> be able to rearrange these).
>
> I'll work on that...

Trunk revision 13705 now contains these changes, now with loose
coupling. Please test this out, and see if this looks robust. The main
difference is that one can now make up a new view type, and add pages
to it without having to edit any file other than the plugin you're
defining. There are currently 13 view types now, so we may want to
look at Nick's treeview idea for Views sooner than later. I can
imagine a "Time" view too that might show calendars and timelines...

In any event, these current set of changes include:

- new config "interface.view-categories" that defines the known
categories, in order
- if a loaded view cat is not in "view-categories", then it comes
next, in alphabetic order
- views now set their category in registration, category = (name,
translated-name)
- toolbar shows view *names* (from registration), not title (so you
can change in registration)
- should work with gettext and views show in native locale
- predefined pages should be first; if more, they follow
- tested with multiple gramplets views, works fine

To add more than one gramplet page, you can put
anothergrampletview.gpr.py in src/plugins/view/ (has to be there, next
to grampletview.py) with this in it:

register(VIEW,
id = 'grampletview2',
name = _("Gramplet View 2"),
description = _("The view allowing to see Gramplets"),
version = '1.0',
status = STABLE,
fname = 'grampletview.py',
authors = [u"The Gramps project"],
authors_email = ["http://gramps-project.org"],
category = ("Gramplets", _("Gramplets")),
viewclass = 'GrampletView',
)

Note that it has a different ID from the other gramplet view, and the
name is used in toolbar. That's all you have to do (and BTW gramplets
remember what page they came from).

The one item I didn't really like is that category is a tuple of the
form ("Category name", _("Category name")). Need both trans and
untrans versions. But I liked that the best of all of the
alternatives.

Currently, there is no way other than editing the gramps32.ini to
change the order of view categories.

-Doug

> -Doug
>
> On Fri, Dec 4, 2009 at 5:39 AM, Benny Malengier
> <benny.malengier@...> wrote:
>> 2009/12/4 Doug Blank <doug.blank@...>:
>>> Devs,
>>>
>>> One thing I have come to appreciate in working with Django is its
>>> consistent use of the idea of "loose coupling". I wasn't real familiar
>>> with the philosophy before, but when I began to understand it, I
>>> realized that this is exactly one of the things that Gramps doesn't
>>> have and has always bothered me. In fact, I would describe Gramps as
>>> strongly coupled.
>>>
>>> The philosophy can be read about in detail in any number of places
>>> (for example, [1]). In a word: "Coupling refers to the degree of
>>> direct knowledge that one class has of another." Many people interpret
>>> this also as "the degree of direct knowledge that one part of the code
>>> has of another part." A good test of the idea is: how many files do
>>> you have to edit in order to add new code?
>>>
>>> I am currently wrestling with this idea in working with the View
>>> display code. Currently, we have a plugin category ID for every type
>>> of view. But loose coupling would suggest that there is no need to
>>> pre-specify these types; they could be discovered when we load the
>>> plugins. (This is just an example of loose coupling, but the idea
>>> could be used in many places throughout gramps).
>>>
>>> For example, say that I want to add a new kind of View... perhaps a
>>> Data Entry view (let's call the view category "Certificates" and the
>>> view "Census"). Currently, we would have to edit a number of files to
>>> add the new view type to define and expose this. On the other hand,
>>> loose coupling says: Gramps doesn't know about view types, and will
>>> just define the views as needed. This seems to be a more Pythonic
>>> approach, and makes extending a project much easier (there are no
>>> additional files to find and edit).
>>>
>>> One downside is that you won't discover a misnamed View type until you
>>> see that the view is showing up in the wrong place. But this would of
>>> course be obvious the instant you run the code. Strongly coupled code
>>> (like gramps currently is) might immediately give an error and crash
>>> on a mislabeled view (or would just put it in the wrong category) but
>>> would require knowledge about the view in multiple places.
>>>
>>> I'd like to advocate more loose coupling in gramps, but wonder if
>>> there is resistance to this philosophy, and if so, why. Feedback
>>> appreciated.
>>
>> Well, the code you refer to is like that because we want the user
>> interface to look a certain way, and hence presets what can be
>> possible, and presets the order in which views will be shown in the
>> interface sidebar.
>>
>> If you don't need this control, that code can go out, and you have no
>> more coupling, but I believe we need to guard how Gramps ends up
>> looking without allowing for plugins to just create some sort of
>> anarchy.
>>
>> So, it is the same as the preset order in the reports or tools menu.
>> I think things are still logical:
>> --> plugins/pluginreg.py knows how a gpr.py file defines a view plugin.
>> --> because we preset the allowed categories, pluginreg.py also
>> defines this and does not load plugins that are in unknown category
>> --> gui/grampsgui.py has a function to obtain registered views, import
>> the files, and order them as we want them for the gramps interface.
>> --> gui/viewmanager.py uses the API of a generic view to drive the interface.
>>
>> I do not see much coupling here, just that we want some control you
>> would rather have we do not have. It is easy to change the code to
>> have some predefined categories of views, and then allow for extra
>> categories behind that as defined in view plugins. We then would still
>> have the desired control of the interface (show the views we want on
>> startup in the order of Gramps). Feel free to change the code like
>> that, so remove the MISC category, create a GRAMPLET category, and
>> then allow plugins to register to unknown categories, which the
>> interface code appends to the end of the viewcategories in the
>> sidebar.
>>
>> Note that in the future we would want to add reordering views in the
>> sidebar, so the control over how the views look like is something we
>> want for the 'default-out-of-the-box' experience, not something that
>> users would not be allowed to change (as they could in 3.1.x by
>> changing the listing in the ini file).
>>
>> As an aside:
>> 1/ I think it would be interesting if you offer in gramps-addons, a
>> second gramplet view. So the user would download this (it would be
>> only a gpr.py file) and then the gramplet category has two views in
>> which gramplets can be shown
>> 2/ I did not finish the changes yet. What still has to happen: the
>> view menu must contain a configure option (like the toolbar icon which
>> I would allow to hide via the preferences), or perhaps a configure
>> menu with entry for each shown view. The view menu should also offer a
>> way to switch to another view in the category for those cases the
>> toolbar is not visible. The column order dialog would move into the
>> view configuration.
>>
>> To come back to the original question, yes, loose coupling is a nice
>> aim. However, in Gui code you will need some model class that controls
>> the view, and you will also need API's that other classes then need to
>> implement. Obviously, API changes lead to a host of changes that need
>> to be done in other files, I see no way around that.
>>
>> Benny
>>
>>> -Doug
>>>
>>> [1] - http://en.wikipedia.org/wiki/Loose_coupling
>>>
>>> ------------------------------------------------------------------------------
>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>> a free event focused on virtualization and cloud computing.
>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>> _______________________________________________
>>> Gramps-devel mailing list
>>> Gramps-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>
>>
>

From forum: GRAMPS - Dev

Re: Transferring .gramps folder to new version?

2009-12-04T16:48:51Z

On Fri, Dec 4, 2009 at 5:00 PM, Theo Tulley <tj.tulley@...> wrote:
> I have just installed the new version "Helena" - LinuxMint 8 and as I
> believe Gramps 3.2 is announced for release on December 6th I am waiting
> for that before I install Gramps.
>
> Please, will the hidden .gramps folder in my /home/user directory from
> Gramps 3.1.1.2 under LinuxMint 7 be fully compatible with Gramps 3.2,
> and thus make all my data available to it?
>
> LinuxMint 8 is based on Ubuntu 9.10.

Theo,

Gramps 3.2 isn't expected until March 2010. But 3.1.3 is just about
ready. This is just a bug fix update. If you aren't experiencing any
issues with 3.1.2 then there isn't a compelling reason to upgrade.

Since 3.1.3 is a bugfix update, then it will work fine with your
current .gramps folder.

The plan is for 3.2 to also be fine with that folder, but there may be
some upgrading of your database that will need to be done. We'll
announce more about that next year.

However, it is very important to export your data as Gramps XML or
Gramps Gpkg BEFORE updating major parts of your OS, or changing
versions of your OS. For example, it may be that the new code that
interfaces with your database is slightly different from the code that
created your database in the old environment. Always a good idea to
have an XML version available as a backup.

Hope that helps,

-Doug

> Yours hopefully, -
>
> Theo Tulley.
> tj.tulley@...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: Optimizing SQL with Gramps-Connect

2009-12-04T16:39:14Z

On Fri, Dec 4, 2009 at 6:13 PM, Huey Brantley <hpbrantley@...> wrote:
> Maybe I didn't understand or didn't make my question clear.
>
> Keep in mind I know very little about Python, however, what I was
> referring to was allowing
> MySQL to handle the table joins, not django. Then you could have views
> (MySQL 5.0+ required) established with whatever data and indexes you
> want. This wouldn't require multiple column indexes in django. Am I
> just way out in left field with this?

Yes, a little out in left field :)

Actually, what you say makes some sense, if you don't know what Django
is. Django is a web framework (written in Python) which completely
abstracts away all of the database details. That means that you can
switch between database backends with absolutely no trouble at all and
everything will work perfectly.

So, it may be the case that some particular product has some special
property to make one thing easy, but we're more interested in being
able to work very well with a large number of databases. Small, simple
ones for ease of use (sqlite) and mighty, powerful ones for large
trees and extreme use (MySQL, postgresl, etc.)

Django is a very stable framework that is undergoing active
development. Although they don't currently have multi-column indexes
(without resorting to raw SQL), I suspect they will at some point. It
is just a little bit of raw SQL that we'll have to watch carefully to
make sure it works fine.

-Doug

> Benny Malengier wrote:
>> 2009/11/23 Nick Hall <nick__hall@...>:
>>
>>> In general, you would want to avoid raw SQL where possible.
>>>
>>> For optimisation, the django debugging tools will let you see what
>>> queries are being run. This will allow the database designer to decide
>>> what indexes are needed for best performance.
>>>
>>> Unfortunately, there seems to be a limitation with django at the moment
>>> that prevents indexes to be defined on multiple columns without using
>>> raw SQL.
>>>
>>
>> Let's put this in perspective. There are few instances where the first
>> index has many duplicates, requiring a second index on a second column
>> (slower database, while retrieving eg 30 items of the index table,
>> then sorting them before view is really fast). In Gramps it is needed
>> as there are too many duplicates with one and the same surname. I
>> remain convinced however it is better to have a new column with the
>> required name format (even better to do it in strxfrm format). Like
>> this the admin of a gramps-connect website can set a name format in
>> the preferences, and have that used for the index.
>> After all, if a user would like sorting on
>> prefix, surname, suffix, given name
>> then our index on surname is uselesss.
>>
>> Benny
>>
>>
>>> Nick.
>>>
>>> hpbrantley@... wrote:
>>>
>>>> Why would you want to embed the sql queries in the code and not use an
>>>> optimized view?
>>>>
>>>> On Nov 22, 2009 12:52pm, Nick Hall <nick__hall@...> wrote:
>>>>
>>>>>
>>>>>
>>>>> Doug Blank wrote:
>>>>>
>>>>>
>>>>>> On Sun, Nov 22, 2009 at 11:32 AM, Nick Hall
>>>>>>
>>>> nick__hall@...> wrote:
>>>>
>>>>>>> Doug,
>>>>>>>
>>>>>>> Thanks for the update.
>>>>>>>
>>>>>>> With SQL you will have to think about what indexes you need in
>>>>>>>
>>>> order to get
>>>>
>>>>>>> good performance. When the queries get more complex you should
>>>>>>>
>>>> consider
>>>>
>>>>>>> using a SQL profiler.
>>>>>>>
>>>>>> Nick,
>>>>>>
>>>>>> I'm out of my area of knowledge here, so hopefully some of you can
>>>>>>
>>>>>> step in and teach us better ways to do this. The only profiling I know
>>>>>>
>>>>>> know is what is in the debug_toolbar. If you have additional pointers,
>>>>>>
>>>>>> please do share.
>>>>>>
>>>>>
>>>>> There are profilers available for the database back-ends. They allow
>>>>>
>>>>> you to see how the database engine actually evaluates the query and what
>>>>>
>>>>> indexes it uses. For complex queries it can be useful to check that the
>>>>>
>>>>> each step uses an appropriate index.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> Will writing raw SQL affect the back-end database
>>>>>>>
>>>>>>> portability in any way?
>>>>>>>
>>>>>> A good question, and I think why people say that Django doesn't
>>>>>>
>>>>>> support multi-column indexing. If it were portable, then Django would
>>>>>>
>>>>>> have a way of doing it. However, I just added a new directory in
>>>>>>
>>>>>> trunk/src/web/grampsdb/sql/ and I think the SQL in there is fairly
>>>>>>
>>>>>> generic. If not, we may need versions for the big three variations
>>>>>>
>>>>>> (MySQL, PostgreSQL, and Sqlite). See [1] to make sure I understand the
>>>>>>
>>>>>> issue correctly,
>>>>>>
>>>>>
>>>>> Your first link leads to a request to support multiple-column primary
>>>>>
>>>>> keys which you don't need. I have looked at the documentation though
>>>>>
>>>>> and can't see support for multiple-column indexes. The closest thing I
>>>>>
>>>>> found was the unique_together meta option.
>>>>>
>>>>>
>>>>>
>>>>> http://docs.djangoproject.com/en/dev/ref/models/options/#unique-together
>>>>>
>>>>>
>>>>>
>>>>> This isn't what you want either.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> and [2] regarding sql portability issues.
>>>>>>
>>>>>
>>>>> It seems that the best way is to try to write generic code, then there
>>>>>
>>>>> is the facility to make it back-end specific if necessary.
>>>>>
>>>>>
>>>>>
>>>>> Hopefully I'll get some time to look at Gramps-Connect in more
>>>>>
>>>> detail soon.
>>>>
>>>>>
>>>>> Nick.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> It's looking good though, and the performance is also pleasing.
>>>>>>>
>>>>>> Yes, so far so good!
>>>>>>
>>>>>> -Doug
>>>>>>
>>>>>> [1]
>>>>>>
>>>> http://stackoverflow.com/questions/1578195/django-create-index-non-unique-multiple-column
>>>>
>>>>>> [2]
>>>>>>
>>>> http://docs.djangoproject.com/en/dev/howto/initial-data/#database-backend-specific-sql-data
>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Nick.
>>>>>>>
>>>>>>> Doug Blank wrote:
>>>>>>>
>>>>>>>> For those interested in how to work on Gramps-Connect and SQL, I've
>>>>>>>>
>>>>>>>> put some information on the blog:
>>>>>>>>
>>>>>>>> http://blog.gramps-project.org/?p=192
>>>>>>>>
>>>>>>>> -Doug
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>>>>
>>>> 30-Day
>>>>
>>>>> trial. Simplify your report design, integration and deployment - and
>>>>>
>>>> focus on
>>>>
>>>>> what you do best, core application coding. Discover what's new with
>>>>>
>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Gramps-devel mailing list
>>>>>
>>>>> Gramps-devel@...
>>>>>
>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>>>
>>>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>>> trial. Simplify your report design, integration and deployment - and focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Gramps-devel mailing list
>>> Gramps-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>
>>>
>>
>>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

From forum: GRAMPS - Dev

Re: Optimizing SQL with Gramps-Connect

2009-12-04T15:13:55Z

Maybe I didn't understand or didn't make my question clear.

Keep in mind I know very little about Python, however, what I was
referring to was allowing
MySQL to handle the table joins, not django. Then you could have views
(MySQL 5.0+ required) established with whatever data and indexes you
want. This wouldn't require multiple column indexes in django. Am I
just way out in left field with this?

Benny Malengier wrote:

> 2009/11/23 Nick Hall <nick__hall@...>:
>
>> In general, you would want to avoid raw SQL where possible.
>>
>> For optimisation, the django debugging tools will let you see what
>> queries are being run. This will allow the database designer to decide
>> what indexes are needed for best performance.
>>
>> Unfortunately, there seems to be a limitation with django at the moment
>> that prevents indexes to be defined on multiple columns without using
>> raw SQL.
>>
>
> Let's put this in perspective. There are few instances where the first
> index has many duplicates, requiring a second index on a second column
> (slower database, while retrieving eg 30 items of the index table,
> then sorting them before view is really fast). In Gramps it is needed
> as there are too many duplicates with one and the same surname. I
> remain convinced however it is better to have a new column with the
> required name format (even better to do it in strxfrm format). Like
> this the admin of a gramps-connect website can set a name format in
> the preferences, and have that used for the index.
> After all, if a user would like sorting on
> prefix, surname, suffix, given name
> then our index on surname is uselesss.
>
> Benny
>
>
>> Nick.
>>
>> hpbrantley@... wrote:
>>
>>> Why would you want to embed the sql queries in the code and not use an
>>> optimized view?
>>>
>>> On Nov 22, 2009 12:52pm, Nick Hall <nick__hall@...> wrote:
>>>
>>>>
>>>>
>>>> Doug Blank wrote:
>>>>
>>>>
>>>>> On Sun, Nov 22, 2009 at 11:32 AM, Nick Hall
>>>>>
>>> nick__hall@...> wrote:
>>>
>>>>>> Doug,
>>>>>>
>>>>>> Thanks for the update.
>>>>>>
>>>>>> With SQL you will have to think about what indexes you need in
>>>>>>
>>> order to get
>>>
>>>>>> good performance. When the queries get more complex you should
>>>>>>
>>> consider
>>>
>>>>>> using a SQL profiler.
>>>>>>
>>>>> Nick,
>>>>>
>>>>> I'm out of my area of knowledge here, so hopefully some of you can
>>>>>
>>>>> step in and teach us better ways to do this. The only profiling I know
>>>>>
>>>>> know is what is in the debug_toolbar. If you have additional pointers,
>>>>>
>>>>> please do share.
>>>>>
>>>>
>>>> There are profilers available for the database back-ends. They allow
>>>>
>>>> you to see how the database engine actually evaluates the query and what
>>>>
>>>> indexes it uses. For complex queries it can be useful to check that the
>>>>
>>>> each step uses an appropriate index.
>>>>
>>>>
>>>>
>>>>
>>>>>> Will writing raw SQL affect the back-end database
>>>>>>
>>>>>> portability in any way?
>>>>>>
>>>>> A good question, and I think why people say that Django doesn't
>>>>>
>>>>> support multi-column indexing. If it were portable, then Django would
>>>>>
>>>>> have a way of doing it. However, I just added a new directory in
>>>>>
>>>>> trunk/src/web/grampsdb/sql/ and I think the SQL in there is fairly
>>>>>
>>>>> generic. If not, we may need versions for the big three variations
>>>>>
>>>>> (MySQL, PostgreSQL, and Sqlite). See [1] to make sure I understand the
>>>>>
>>>>> issue correctly,
>>>>>
>>>>
>>>> Your first link leads to a request to support multiple-column primary
>>>>
>>>> keys which you don't need. I have looked at the documentation though
>>>>
>>>> and can't see support for multiple-column indexes. The closest thing I
>>>>
>>>> found was the unique_together meta option.
>>>>
>>>>
>>>>
>>>> http://docs.djangoproject.com/en/dev/ref/models/options/#unique-together
>>>>
>>>>
>>>>
>>>> This isn't what you want either.
>>>>
>>>>
>>>>
>>>>
>>>>> and [2] regarding sql portability issues.
>>>>>
>>>>
>>>> It seems that the best way is to try to write generic code, then there
>>>>
>>>> is the facility to make it back-end specific if necessary.
>>>>
>>>>
>>>>
>>>> Hopefully I'll get some time to look at Gramps-Connect in more
>>>>
>>> detail soon.
>>>
>>>>
>>>> Nick.
>>>>
>>>>
>>>>
>>>>
>>>>>> It's looking good though, and the performance is also pleasing.
>>>>>>
>>>>> Yes, so far so good!
>>>>>
>>>>> -Doug
>>>>>
>>>>> [1]
>>>>>
>>> http://stackoverflow.com/questions/1578195/django-create-index-non-unique-multiple-column
>>>
>>>>> [2]
>>>>>
>>> http://docs.djangoproject.com/en/dev/howto/initial-data/#database-backend-specific-sql-data
>>>
>>>>>> Regards,
>>>>>>
>>>>>> Nick.
>>>>>>
>>>>>> Doug Blank wrote:
>>>>>>
>>>>>>> For those interested in how to work on Gramps-Connect and SQL, I've
>>>>>>>
>>>>>>> put some information on the blog:
>>>>>>>
>>>>>>> http://blog.gramps-project.org/?p=192
>>>>>>>
>>>>>>> -Doug
>>>>>>>
>>>>
>>>>
>>>>
>>> ------------------------------------------------------------------------------
>>>
>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>>>
>>> 30-Day
>>>
>>>> trial. Simplify your report design, integration and deployment - and
>>>>
>>> focus on
>>>
>>>> what you do best, core application coding. Discover what's new with
>>>>
>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>>>
>>>> _______________________________________________
>>>>
>>>> Gramps-devel mailing list
>>>>
>>>> Gramps-devel@...
>>>>
>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>>
>>>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>
>
>

From forum: GRAMPS - Dev

Transferring .gramps folder to new version?

2009-12-04T14:00:41Z

I have just installed the new version "Helena" - LinuxMint 8 and as I
believe Gramps 3.2 is announced for release on December 6th I am waiting
for that before I install Gramps.

Please, will the hidden .gramps folder in my /home/user directory from
Gramps 3.1.1.2 under LinuxMint 7 be fully compatible with Gramps 3.2,
and thus make all my data available to it?

LinuxMint 8 is based on Ubuntu 9.10.

Yours hopefully, -

Theo Tulley.
tj.tulley@...

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: Licensing thoughts from the old guy

2009-12-04T07:46:40Z

Hi everyone. There is a little of my code lying around in Gramps too so
I guess I should express an opinion.

I liked the 'GPLv2 or optionally a later version' attitude of Gramps
when I started to contribute and I liked Don's view about the philosophy
of Gramps.

I always considered going GPL was a way of saying that we trust the FSF
to get the licensing issues right. I still believe that for community
projects like Gramps this is the correct and most pragmatic approach.

The FSF has decided that GPLv2 is not able to deal with new developments
in the technical and legal space. I am not a lawyer and I have to put my
trust in someone. So I will go with their judgment.

I think that you should change the license to "AGPL or optionally a
later version" now for two reasons:

- firstly it deals with the immediate issue of covering the
gramps-connect elements of the project with the same philosophy as the
rest of gramps.
- secondly because it will establish the principle of license upgrades
while most of the contributers are still around to agree to it (even if
you don't strictly need their agreement).

Just my opinion.

Wishing you all well.

Richard

Don Allingham wrote:

> Brian asked me to throw my two cents into the licensing discussion.
> Please forgive me, because I'm a bit out of the loop on things. So if I
> am a bit redundant on some topics, I apologize.
>
> Many of you probably don't know who I am (and even more of you probably
> don't care), but Brian asked, so I'm responding. I am the one who
> started this project almost nine years ago, and ran it for about seven.
>
> I had to go back a bit in the archives to find out what exactly
> gramps-connect is, and to see what the debate is. Please correct me if
> I'm wrong, but the concern seems to be that the gramps-connect project
> provides an opportunity for people to make changes to the program that
> become widely available without contributing back the changes.
>
> When I created the gramps project, the idea was to provide a completely
> open project that could not be taken proprietary. Had I wished that, the
> project would have been released that under the BSD license. The GPLv2
> is more than adequate for a desktop project. For web based projects, the
> GPLv2 tends to fall a bit short of this goal. This is the reason the
> GPLv3 was created.
>
> To me, the solution seems to be to have two separate releases - the
> gramps program (a desktop GTK based program) and the gramps-connect
> system (a web based platform). Keep gramps under the GPLv2, and release
> gramps-connect as GPLv3 (or AGPLv3). When linked with the gramps-connect
> code, the GPLv2 based gramps code becomes GPLv3 (one of the side effects
> of the "GPLv2 or later" clause).
>
> So, even when reports are released as GPLv2 with gramps, they cannot be
> modified without contributing back to the project when used with
> gramps-connect (because they would then fall under the GPLv3).
>
> Two releases seems to make much more sense to me, since you really don't
> want to bog down gramps with Django and other dependencies.
>
> However, from the looks of it, anything that happens would be compatible
> with the GPLv2, under which I released all of my code.
>
> Don
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T06:02:51Z

Error is fixed on rev13701

http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=13701

I thought "unicode for truncation" means "need to be unicode before use of replace function on '\n'. But if you say it is rather related to len(note), so Peter's improvement should be still present. If correct, we just need to do the change on trunk too.

--- En date de : Ven 4.12.09, Benny Malengier <benny.malengier@...> a écrit :

> De: Benny Malengier <benny.malengier@...>
> Objet: Re: Re: [Gramps-devel] Re : preparing for 3.1.3
> À: "Jérôme" <romjerome@...>
> Cc: "Gramps Development List" <gramps-devel@...>
> Date: Vendredi 4 Décembre 2009, 14h38
> jerome, please commit your last
> suggested change and test. It should
> work just fine.
>
> Benny
>
> 2009/12/4 <peter.talken@...>:
> > Folks,
> >
> > I'm not at home now, so I can't do anything. Will be
> back on Sunday afternoon.
> >
> > /Peter
> >
> >
> >>----Ursprungligt meddelande----
> >>Från: benny.malengier@...
> >>Datum: 2009-12-04 09:47
> >>Till: "Peter Landgren"<peter.talken@...>
> >>Kopia: "Gramps Development List"<gramps-devel@...>
> >>Ärende: Re: [Gramps-devel] Re : preparing for
> 3.1.3
> >>
> >>Peter, I now remember what this was about.
> >>Can you fix this today in the Scratchpad code? You
> probably still have
> >>your testcase.
> >>
> >>> #String must be unicode for truncation to
> work for non ascii characters
> >>> - note = unicode(note)
> >>> note = value.get().replace('\n', '
> ')
> >>> + note = unicode(note)
> >>
> >>I think should be correct, no? It wouds be better
> if the comment says:
> >> #String must be unicode for slicing to work for
> non ascii characters
> >>and still obtain unicode
> >>
> >>Benny
> >>
> >>2009/12/4 jerome <romjerome@...>:
> >>>> Jerome, do your patch with value for now.
> >>>
> >>> I thought it was the right thing to do (keep
> Peter's improvement and use
> > after the assignment), but I didn't test it ...
> >>>
> >>> 16663: ERROR: gramps.py: line 160: Unhandled
> exception
> >>> Traceback (most recent call last):
> >>> File "src/ScratchPad.py", line 1137, in
> object_drag_data_received
> >>> o = wrapper_class(self.dbstate,sel_data)
> >>> File "src/ScratchPad.py", line 328, in
> __init__
> >>> note = value.get().replace('\n', ' ')
> >>> AttributeError: 'unicode' object has no
> attribute 'get'
> >>>
> >>> value = self._db.get_note_from_handle(handle)
> >>>
> >>>
> >>> #String must be unicode for truncation to
> work for non ascii characters
> >>> - note = unicode(note)
> >>> note = value.get().replace('\n', '
> ')
> >>> + note = unicode(note)
> >>
> >>Yes, just revert to the old
> >>>
> >>> is working but looking at the comment I
> suppose it makes no real sense !
> >>>
> >>>
> >>>
> >>> --- En date de : Jeu 3.12.09, Benny Malengier
> <benny.malengier@...>
> a
> > écrit :
> >>>
> >>>> De: Benny Malengier <benny.malengier@...>
> >>>> Objet: Re: [Gramps-devel] Re : preparing
> for 3.1.3
> >>>> À: "jerome" <romjerome@...>,
> "Peter Landgren" <peter.talken@...>
> >>>> Cc: "Gramps Development List" <gramps-devel@...>
> >>>> Date: Jeudi 3 Décembre 2009, 22h12
> >>>> Yes, bug introduced here:
> >>>> http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps31/src/ScratchPad.py?view=diff&r1=13168&r2=13169
> >>>>
> >>>> Peter, as you introduced this, you
> remember why? As said in
> >>>> other
> >>>> parts, notes should already be unicode, so
> no need to
> >>>> convert them. I
> >>>> would think these changed lines may be
> removed. They don't
> >>>> harm
> >>>> however.
> >>>>
> >>>> Jerome, do your patch with value for now.
> >>>>
> >>>> Benny
> >>>>
> >>>> 2009/12/3 jerome <romjerome@...>:
> >>>> > or should be something like :
> >>>> >
> >>>> > #String must be unicode for
> truncation to work for non
> >>>> ascii characters
> >>>> > - note = unicode(note)
> >>>> > + value = unicode(value)
> >>>> > note =
> value.get().replace('\n', ' ')
> >>>> >
> >>>> >
> >>>> > --- En date de : Jeu 3.12.09, jerome
> <romjerome@...>
> >>>> a écrit :
> >>>> >
> >>>> >> De: jerome <romjerome@...>
> >>>> >> Objet: Re: [Gramps-devel] Re :
> preparing for
> >>>> 3.1.3
> >>>> >> À: "Benny Malengier" <benny.malengier@...>
> >>>> >> Cc: "Gramps Development List"
> <gramps-devel@...>
> >>>> >> Date: Jeudi 3 Décembre 2009,
> 18h44
> >>>> >> /!\ there is an unfixed bug/crash
> on
> >>>> >> 3.1.3-SVN :
> >>>> >>
> >>>> >> 116251: ERROR: gramps.py: line
> 160: Unhandled
> >>>> exception
> >>>> >> Traceback (most recent call
> last):
> >>>> >> File "src/ScratchPad.py", line
> 1137, in
> >>>> >> object_drag_data_received
> >>>> >> o =
> wrapper_class(self.dbstate,sel_data)
> >>>> >> File "src/ScratchPad.py", line
> 327, in
> >>>> __init__
> >>>> >> note = unicode(note)
> >>>> >> UnboundLocalError: local variable
> 'note'
> >>>> referenced before
> >>>> >> assignment
> >>>> >>
> >>>> >> patch should be easy :
> >>>> >>
> >>>> >> #String must be
> unicode for
> >>>> >> truncation to work for non ascii
> characters
> >>>> >> - note =
> unicode(note)
> >>>> >> note =
> >>>> >> value.get().replace('\n', ' ')
> >>>> >> + note =
> unicode(note)
> >>>> >>
> >>>> >> To reproduce it :
> >>>> >>
> >>>> >> 1. Go on Note View
> >>>> >> 2. Try to drag and drop a note
> oject reference
> >>>> from
> >>>> >> NoteView to clipboard
> >>>> >>
> >>>> >>
> >>>> >> Should I commit change ?
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> --- En date de : Jeu 3.12.09,
> Jérôme <romjerome@...>
> >>>> >> a écrit :
> >>>> >>
> >>>> >> > De: Jérôme <romjerome@...>
> >>>> >> > Objet: Re: [Gramps-devel] Re
> : preparing for
> >>>> 3.1.3
> >>>> >> > À: "Benny Malengier" <benny.malengier@...>
> >>>> >> > Cc: "Gramps Development
> List" <gramps-devel@...>
> >>>> >> > Date: Jeudi 3 Décembre
> 2009, 17h28
> >>>> >> > Benny,
> >>>> >> >
> >>>> >> > >>> 2. On source
> reference
> >>>> (repository):
> >>>> >> > >>> 2 CALN
> >>>> >> > >>> 3 MEDI Book
> >>>> >> > >>> will be a
> custom translated
> >>>> media type
> >>>> >> on
> >>>> >> > export
> >>>> >> > >>> 2 CALN
> >>>> >> > >>> 3 MEDI Livre
> >>>> >> > >>>
> >>>> >> > >>> I suppose there
> is no error
> >>>> because I do
> >>>> >> not
> >>>> >> > loose data, but it is
> strange !
> >>>> >> > >>
> >>>> >> > >> Ok, I'll look at
> that, make a bug
> >>>> ticket (or
> >>>> >> > reopen the previous one.
> >>>> >> > >> The old code
> ignored MEDI tag, I
> >>>> suppose the
> >>>> >> new
> >>>> >> > code will write it
> >>>> >> > >> out but not in
> English, it should be
> >>>> easy to
> >>>> >> adapt
> >>>> >> > the writegedcom for
> >>>> >> > >> this, other types
> already write out
> >>>> the
> >>>> >> english
> >>>> >> > version (probably). Or
> >>>> >> > >> are other types
> also written out in
> >>>> French?
> >>>> >> It
> >>>> >> > would make some sense,
> >>>> >> > >> GEDCOM programs
> need not know that
> >>>> Book is
> >>>> >> Livre
> >>>> >> >
> >>>> >> > Looks like not a bug ...
> >>>> >> > I used Gramps without
> translations ($ python
> >>>> >> > src/gramps.py), and this
> >>>> >> > was already present on
> 3.1.2. There is no
> >>>> regression
> >>>> >> for
> >>>> >> > this on next
> >>>> >> > release.
> >>>> >> >
> >>>> >> > http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
> >>>> >> > http://www.gramps-project.org/bugs/view.php?id=3374>>>
> >> >
> >>>> >> > Code writes value (not tag)
> in english if you
> >>>> are
> >>>> >> using
> >>>> >> > Gramps in
> >>>> >> > English and translated value
> into french if
> >>>> you are
> >>>> >> using
> >>>> >> > Gramps in
> >>>> >> > French !
> >>>> >> >
> >>>> >> > On my 'localized' Gedcom, I
> get :
> >>>> >> >
> >>>> >> > 1 EVEN
> >>>> >> > 2 TYPE Mariage
> >>>> >> > 1 EVEN
> >>>> >> > 2 TYPE Élection
> >>>> >> > 1 EVEN
> >>>> >> > 2 TYPE Résidence
> >>>> >> > 2 CALN
> >>>> >> > 3 MEDI Livre
> >>>> >> >
> >>>> >> > which sounds correct with
> this custom data
> >>>> and after
> >>>> >> > looking at the
> >>>> >> > Gedcom header :
> >>>> >> >
> >>>> >> > 1 GEDC
> >>>> >> > 2 VERS 5.5
> >>>> >> > 2 FORM LINEAGE-LINKED
> >>>> >> > 1 CHAR UTF-8
> >>>> >> > 1 LANG French
> >>>> >> >
> >>>> >> > TAG do not use non-ASCII
> characters and
> >>>> values are
> >>>> >> custom
> >>>> >> > data.
> >>>> >> > So, I suppose that's not a
> bug !
> >>>> >> >
> >>>> >> > > Or are other types also
> written out in
> >>>> French?
> >>>> >> >
> >>>> >> > yes it is coherent, only
> custom or Gramps'
> >>>> types (not
> >>>> >> on
> >>>> >> > Gedcom spec)
> >>>> >> >
> >>>> >> > This kind of thing must be
> surely forget by
> >>>> the many
> >>>> >> tests
> >>>> >> > which check
> >>>> >> > Gedcom support... They look
> at custom tag
> >>>> (_CUSTOM)
> >>>> >> but not
> >>>> >> > on values
> >>>> >> > used into the program.
> >>>> >> >
> >>>> >> > It's really nice to have
> this international
> >>>> support !
> >>>> >> :)
> >>>> >> > (I say this now but maybe it
> was me who has
> >>>> grumbled
> >>>> >> at the
> >>>> >> > time and I
> >>>> >> > do not remember !!!)
> >>>> >> >
> >>>> >> >
> >>>> >> > Thanks !
> >>>> >> >
> >>>> >> > Jérôme
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> > Benny Malengier a écrit :
> >>>> >> > > 2009/11/24 jerome
> <romjerome@...>:
> >>>> >> > >>> Jerome, your
> mail is a bit
> >>>> confusing.
> >>>> >> > >> Sorry. I am testing
> Gedcom
> >>>> management
> >>>> >> changes.
> >>>> >> > >> First, I have tried
> to export a
> >>>> database
> >>>> >> (Family
> >>>> >> > Tree) to Gedcom format, but
> a dialog pops-up
> >>>> something
> >>>> >> like
> >>>> >> > "Gramps cannot write
> /tmp/..." during write
> >>>> person
> >>>> >> process.
> >>>> >> > Gedcom was not properly
> generated and I ran
> >>>> repair DB
> >>>> >> tools
> >>>> >> > on my opened Family Tree.
> Then no more
> >>>> message and
> >>>> >> > Gramps-3.1.3 has generated a
> complete
> >>>> Gedcom.
> >>>> >> > >>
> >>>> >> > >> Looking at diff
> between the first
> >>>> one and
> >>>> >> the
> >>>> >> > second one.
> >>>> >> > >> I suppose the
> problem was just
> >>>> "around"
> >>>> >> CHANGE
> >>>> >> > TIME (as I know this has
> been improved on
> >>>> 3.1.3) and
> >>>> >> lines
> >>>> >> > "not written" on the broken
> gedcom could be
> >>>> :
> >>>> >> > >> 1 CHAN
> >>>> >> > >> 2 DATE 24 NOV 2009
> >>>> >> > >> 3 TIME 14:29:13
> >>>> >> > >>
> >>>> >> > >> Sorry, I cannot
> very well explain
> >>>> this :(
> >>>> >> > >> I suppose Gramps
> was not able to
> >>>> write 1
> >>>> >> CHAN, but
> >>>> >> > I cannot say : "Gramps is
> not able to write
> >>>> this",
> >>>> >> because
> >>>> >> > process freeze, no error or
> bug report
> >>>> dialog, just
> >>>> >> Gedcom
> >>>> >> > was not complete.
> >>>> >> > >>
> >>>> >> > >>> because old
> gramps wrote out
> >>>> french
> >>>> >> dates?
> >>>> >> > >> Do you think this
> could be an OS
> >>>> issue ?
> >>>> >> python
> >>>> >> > time module ?
> >>>> >> > >
> >>>> >> > > No, it should work ok,
> the old code was
> >>>> >> completely
> >>>> >> > ignoring CHAN
> >>>> >> > > group, the new code
> parses it correctly,
> >>>> and it
> >>>> >> is
> >>>> >> > written out
> >>>> >> > > correctly.
> >>>> >> > >>> For the second
> issue, is this a
> >>>> >> regression?
> >>>> >> > That is could Gramps 3.1.2
> read
> >>>> >> > >> I will try to test
> it.
> >>>> >> > >>
> >>>> >> > >> But seems there is
> still many
> >>>> problems with
> >>>> >> Gedcom
> >>>> >> > management ...
> >>>> >> > >>
> >>>> >> > >> I am loosing some
> data by making a
> >>>> diff
> >>>> >> between :
> >>>> >> > >> a Gedcom generated
> by Gramps and a
> >>>> new one,
> >>>> >> > imported into a new Family
> Tree then
> >>>> exported.
> >>>> >> > >>
> >>>> >> > >> 1. dates with
> calendar, like :
> >>>> >> > >> 2 DATE @#DFRENCH
> R@ 24 VEND 12
> >>>> >> > >> are not properly
> imported by
> >>>> Gramps-3.1.3 and
> >>>> >> will
> >>>> >> > return a textual date :
> >>>> >> > >> 2 DATE 24 VEND
> 12
> >>>> >> > >
> >>>> >> > > This should have been
> like this in
> >>>> 3.1.2, it
> >>>> >> means the
> >>>> >> > Date module
> >>>> >> > > that reads it cannot
> read the @, make a
> >>>> bug
> >>>> >> ticket,
> >>>> >> > but I do not thing
> >>>> >> > > it is a regression.
> >>>> >> > >> 2. On source
> reference
> >>>> (repository):
> >>>> >> > >> 2 CALN
> >>>> >> > >> 3 MEDI Book
> >>>> >> > >> will be a custom
> translated media
> >>>> type on
> >>>> >> export
> >>>> >> > >> 2 CALN
> >>>> >> > >> 3 MEDI Livre
> >>>> >> > >>
> >>>> >> > >> I suppose there is
> no error because
> >>>> I do not
> >>>> >> loose
> >>>> >> > data, but it is strange !
> >>>> >> > >
> >>>> >> > > Ok, I'll look at that,
> make a bug ticket
> >>>> (or
> >>>> >> reopen
> >>>> >> > the previous one.
> >>>> >> > > The old code ignored
> MEDI tag, I suppose
> >>>> the new
> >>>> >> code
> >>>> >> > will write it
> >>>> >> > > out but not in English,
> it should be
> >>>> easy to
> >>>> >> adapt the
> >>>> >> > writegedcom for
> >>>> >> > > this, other types
> already write out the
> >>>> english
> >>>> >> > version (probably). Or
> >>>> >> > > are other types also
> written out in
> >>>> French? It
> >>>> >> would
> >>>> >> > make some sense,
> >>>> >> > > GEDCOM programs need
> not know that Book
> >>>> is Livre
> >>>> >> > >
> >>>> >> > >> 3. References on
> Media Objects are
> >>>> ignored
> >>>> >> on
> >>>> >> > export
> >>>> >> > >> I started with 662
> references into
> >>>> my Family
> >>>> >> Tree
> >>>> >> > and after a Gedcom import
> into a new Family
> >>>> Tree, I
> >>>> >> kept 18,
> >>>> >> > which was not media object,
> only urls on
> >>>> person object
> >>>> >> !!!)
> >>>> >> > >>
> >>>> >> > >> I do not see any
> problem yet on
> >>>> Gramps XML
> >>>> >> > management, and maybe some
> of this issues has
> >>>> been
> >>>> >> already
> >>>> >> > reported. I remember
> something like "Gedcom
> >>>> generated
> >>>> >> by
> >>>> >> > Gramps imported into
> Gramps".
> >>>> >> > >>
> >>>> >> > >> I suppose
> "references on Media
> >>>> Objects" and
> >>>> >> the "1
> >>>> >> > OBJE
> >>>> >> > >> 2 FORM" (url on
> person) are
> >>>> related.
> >>>> >> > >
> >>>> >> > > This is the first I
> hear about this.
> >>>> >> > > I do not like coding in
> GEDCOM, I do not
> >>>> use it
> >>>> >> !!!
> >>>> >> > >
> >>>> >> > > Benny
> >>>> >> > >
> >>>> >> > >>
> >>>> >> > >> I will look at
> Gedcom regression.
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> > >> Jérôme
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> > >> --- En date de :
> Mar 24.11.09,
> >>>> Benny
> >>>> >> Malengier
> >>>> >> > <benny.malengier@...>
> >>>> >> > a écrit :
> >>>> >> > >>
> >>>> >> > >>> De: Benny
> Malengier <benny.malengier@...>
> >>>> >> > >>> Objet: Re: Re :
> preparing for
> >>>> 3.1.3
> >>>> >> > >>> À: "jerome"
> <romjerome@...>
> >>>> >> > >>> Cc: "Gramps
> Development List"
> >>>> <gramps-devel@...>,
> >>>> >> > "Stéphane Charette" <stephanecharette@...>
> >>>> >> > >>> Date: Mardi 24
> Novembre 2009,
> >>>> 15h24
> >>>> >> > >>> Jerome, your
> mail is a bit
> >>>> >> > >>> confusing.
> >>>> >> > >>>
> >>>> >> > >>> Are you saying
> the old gedcom
> >>>> crashes now
> >>>> >> on
> >>>> >> > import because
> >>>> >> > >>> old gramps
> >>>> >> > >>> wrote out
> french dates? Or is
> >>>> there no
> >>>> >> problem
> >>>> >> > (I see no
> >>>> >> > >>> crash report
> >>>> >> > >>> in this mail)
> >>>> >> > >>>
> >>>> >> > >>> For the second
> issue, is this a
> >>>> >> regression?
> >>>> >> > That is could
> >>>> >> > >>> Gramps 3.1.2
> read
> >>>> >> > >>>
> >>>> >> > >>>> 1 OBJE
> >>>> >> > >>>> 2 FORM URL
> >>>> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
> >>>> >> > >>> Benny
> >>>> >> > >>>
> >>>> >> > >>> 2009/11/24
> jerome <romjerome@...>:
> >>>> >> > >>>>> so we
> can prepare for
> >>>> 3.1.3.
> >>>> >> Could
> >>>> >> > >>>>>
> everyone test perhaps a
> >>>> GEDCOM
> >>>> >> and an
> >>>> >> > XML export
> >>>> >> > >>> of their
> >>>> >> > >>>>> data
> >>>> >> > >>>>>
> (filtered somehow), and
> >>>> then
> >>>> >> import
> >>>> >> > again in an
> >>>> >> > >>> empty tree.
> >>>> >> > >>>>> The
> last
> >>>> >> > >>>>> things
> changes are
> >>>> related to
> >>>> >> that,
> >>>> >> > and GEDCOM
> >>>> >> > >>> changes are
> >>>> >> > >>>>>
> sensitive.
> >>>> >> > >>>> I have
> started to test
> >>>> import from
> >>>> >> > Gramps-3.1.3 to
> >>>> >> > >>> Gramps-3.1.3
> >>>> >> > >>>> (Ubuntu
> 9.04, python 2.6)
> >>>> >> > >>>>
> >>>> >> > >>>> ///// 1
> warning during
> >>>> Gramps
> >>>> >> > session ///////
> >>>> >> > >>>>
> (gramps.py:4609): CRITICAL
> >>>> **:
> >>>> >> > >>>
> murrine_style_draw_focus:
> >>>> assertion
> >>>> >> `height
> >>>> >> > >= -1'
> >>>> >> > >>> failed
> >>>> >> > >>>> ///// 1
> problem on GEDCOM
> >>>> export
> >>>> >> ///////
> >>>> >> > >>>>
> >>>> >> > >>>> "Cannot
> write file ..."
> >>>> message on
> >>>> >> dialog
> >>>> >> > (on write
> >>>> >> > >>> persons)
> >>>> >> > >>>> Fixed after
> running rebuild
> >>>> 2nd
> >>>> >> indices
> >>>> >> > and "Check
> >>>> >> > >>> & Repair"
> tools. (no problem
> >>>> with
> >>>> >> Gramps
> >>>> >> > XML format)
> >>>> >> > >>>> Re-test is
> OK.
> >>>> >> > >>>> Pass
> without error by using
> >>>> :
> >>>> >> > >>>>
> >>>> >> > >>>> 1 CHAN
> >>>> >> > >>>> 2 DATE 24
> NOV 2009
> >>>> >> > >>>> 3 TIME
> 14:29:13
> >>>> >> > >>>>
> >>>> >> > >>>> Looks like
> first test has
> >>>> blocked
> >>>> >> just
> >>>> >> > before "change
> >>>> >> > >>> time" on person
> object !
> >>>> >> > >>>> /!\ I used
> my testing
> >>>> database
> >>>> >> (generated
> >>>> >> > before new
> >>>> >> > >>> time management
> on Gedcom
> >>>> >> > >>>> /////
> problem on GEDCOM
> >>>> import
> >>>> >> ///////
> >>>> >> > >>>>
> >>>> >> > >>>> WARNING
> .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer http://www.geneanet.org/contact.php3?source=bouly78
> >>>> >> > >>>> WARNING
> .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer http://www.geneanet.org/rgentner>>> >>
> >
> >>>>> WARNING .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer
> >>>> >> > >>>> WARNING
> .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer
> >>>> >> > >>>> WARNING
> .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer
> >>>> >> > >>>> WARNING
> .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=henriks
> >>>> >> > >>>> WARNING
> .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
> >>>> >> > >>>> WARNING
> .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=myriague
> >>>> >> > >>>> WARNING
> .GedcomImport:
> >>>> Impossible
> >>>> >> > d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
> >>>> >> > >>>>
> >>>> >> > >>>> =>
> Cannot import url
> >>>> >> > >>>>
> >>>> >> > >>>> was
> generated by
> >>>> Gramps-3.1.3 :
> >>>> >> > >>>>
> >>>> >> > >>>> 0 @I1802@
> INDI
> >>>> >> > >>>> 1 NAME
> Florent /SCHMITT/
> >>>> >> > >>>> 2 GIVN
> Florent
> >>>> >> > >>>> 2 SURN
> SCHMITT
> >>>> >> > >>>> 1 SEX M
> >>>> >> > >>>> 1 OBJE
> >>>> >> > >>>> 2 FORM URL
> >>>> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
> >>>> >> > >>>>
> >>>> >> > >>>> Now, I will
> try to see any
> >>>> diff on
> >>>> >> data
> >>>> >> > (Gedcom,
> >>>> >> > >>> Gramps XML)
> >>>> >> > >>>>
> >>>> >> > >>>>
> >>>> >> > >>>> Jérôme
> R.
> >>>> >> > >>>>
> >>>> >> > >>>>
> >>>> >> > >>>> --- En date
> de : Dim
> >>>> 22.11.09, Benny
> >>>> >> > Malengier <benny.malengier@...>
> >>>> >> > >>> a écrit :
> >>>> >> > >>>>> De:
> Benny Malengier
> >>>> <benny.malengier@...>
> >>>> >> > >>>>> Objet:
> preparing for
> >>>> 3.1.3
> >>>> >> > >>>>> À:
> "Gramps Development
> >>>> List"
> >>>> >> <gramps-devel@...>,
> >>>> >> > >>> "Jérôme"
> <romjerome@...>,
> >>>> >> > >>> "Stéphane
> Charette" <stephanecharette@...>
> >>>> >> > >>>>> Date:
> Dimanche 22
> >>>> Novembre 2009,
> >>>> >> > 10h11
> >>>> >> > >>>>> All,
> the roadmap is
> >>>> now on
> >>>> >> > >>>>> 100%,
> so we can prepare
> >>>> for
> >>>> >> 3.1.3.
> >>>> >> > Could
> >>>> >> > >>>>>
> everyone test perhaps a
> >>>> GEDCOM
> >>>> >> and an
> >>>> >> > XML export
> >>>> >> > >>> of their
> >>>> >> > >>>>> data
> >>>> >> > >>>>>
> (filtered somehow), and
> >>>> then
> >>>> >> import
> >>>> >> > again in an
> >>>> >> > >>> empty tree.
> >>>> >> > >>>>> The
> last
> >>>> >> > >>>>> things
> changes are
> >>>> related to
> >>>> >> that,
> >>>> >> > and GEDCOM
> >>>> >> > >>> changes are
> >>>> >> > >>>>>
> sensitive.
> >>>> >> > >>>>>
> >>>> >> > >>>>> Jerome,
> can you check
> >>>> the po file
> >>>> >> is
> >>>> >> > up to date,
> >>>> >> > >>> perhaps
> >>>> >> > >>>>> send
> mail to
> >>>> >> > >>>>>
> translators with %
> >>>> completion of
> >>>> >> their
> >>>> >> > language
> >>>> >> > >>> as
> >>>> >> > >>>>>
> information?
> >>>> >> > >>>>>
> >>>> >> > >>>>>
> Stephane, do you have
> >>>> time
> >>>> >> somewhere
> >>>> >> > in the coming
> >>>> >> > >>> weeks to
> >>>> >> > >>>>> push
> out
> >>>> >> > >>>>> 3.1.3?
> I would like to
> >>>> see in
> >>>> >> the
> >>>> >> > release notes
> >>>> >> > >>> something
> >>>> >> > >>>>> in the
> line
> >>>> >> > >>>>> of
> 'While the Gramps
> >>>> developers
> >>>> >> are
> >>>> >> > working on a
> >>>> >> > >>> super 3.2
> >>>> >> > >>>>> release
> in
> >>>> >> > >>>>> a
> couple of months, they
> >>>> still
> >>>> >> had
> >>>> >> > time for a
> >>>> >> > >>> minor bug fix
> >>>> >> > >>>>>
> release.
> >>>> >> > >>>>>
> >>>> >> > >>>>> The
> roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
> >>>> >> > >>>>>
> contains main content of
> >>>> this
> >>>> >> release.
> >>>> >> > I think the
> >>>> >> > >>> most
> >>>> >> > >>>>>
> striking:
> >>>> >> > >>>>>
> >>>> >> > >>>>> * the
> annoying tooltip
> >>>> messages
> >>>> >> in
> >>>> >> > latest distro's
> >>>> >> > >>> are no
> >>>> >> > >>>>> longer
> present
> >>>> >> > >>>>> * some
> GEDCOM fixes
> >>>> (timestamp
> >>>> >> on
> >>>> >> > persons now
> >>>> >> > >>> kept, MEDI
> >>>> >> > >>>>> import,
> ...)
> >>>> >> > >>>>> * some
> data that was not
> >>>> present
> >>>> >> in
> >>>> >> > filtered data
> >>>> >> > >>> is now
> >>>> >> > >>>>>
> present
> >>>> >> > >>>>> (source
> page, ...)
> >>>> >> > >>>>> *
> windows / or \ paths
> >>>> in
> >>>> >> webreport
> >>>> >> > cleaned up
> >>>> >> > >>>>> * ...
> >>>> >> > >>>>>
> >>>> >> > >>>>> Benny
> >>>> >> > >>>>>
> >>>> >> > >>>>
> >>>> >> > >>>>
> >>>> >> > >>>>
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> > >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >>
> >>>>
> >
> ------------------------------------------------------------------------------
> >>>> >> > Join us December 9, 2009 for
> the Red Hat
> >>>> Virtual
> >>>> >> > Experience,
> >>>> >> > a free event focused on
> virtualization and
> >>>> cloud
> >>>> >> computing.
> >>>> >> >
> >>>> >> > Attend in-depth sessions
> from your desk. Your
> >>>> couch.
> >>>> >> > Anywhere.
> >>>> >> > http://p.sf.net/sfu/redhat-sfdev2dev>>>
> >> >
> >>>>
> _______________________________________________
> >>>> >> > Gramps-devel mailing list
> >>>> >> > Gramps-devel@...
> >>>> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>>> >> >
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >>
> >>>>
> >
> ------------------------------------------------------------------------------
> >>>> >> Join us December 9, 2009 for
> > the Red Hat Virtual
> >>>> >> Experience,
> >>>> >> a free event focused on
> virtualization and cloud
> >>>> computing.
> >>>> >>
> >>>> >> Attend in-depth sessions from
> your desk. Your
> >>>> couch.
> >>>> >> Anywhere.
> >>>> >> http://p.sf.net/sfu/redhat-sfdev2dev>>>
> >>
> > _______________________________________________
> >>>> >> Gramps-devel mailing list
> >>>> >> Gramps-
> > devel@...
> >>>> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel>>>
> >>
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T05:38:23Z

jerome, please commit your last suggested change and test. It should
work just fine.

Benny

2009/12/4 <peter.talken@...>:

> Folks,
>
> I'm not at home now, so I can't do anything. Will be back on Sunday afternoon.
>
> /Peter
>
>
>>----Ursprungligt meddelande----
>>Från: benny.malengier@...
>>Datum: 2009-12-04 09:47
>>Till: "Peter Landgren"<peter.talken@...>
>>Kopia: "Gramps Development List"<gramps-devel@...>
>>Ärende: Re: [Gramps-devel] Re : preparing for 3.1.3
>>
>>Peter, I now remember what this was about.
>>Can you fix this today in the Scratchpad code? You probably still have
>>your testcase.
>>
>>> #String must be unicode for truncation to work for non ascii characters
>>> - note = unicode(note)
>>> note = value.get().replace('\n', ' ')
>>> + note = unicode(note)
>>
>>I think should be correct, no? It wouds be better if the comment says:
>> #String must be unicode for slicing to work for non ascii characters
>>and still obtain unicode
>>
>>Benny
>>
>>2009/12/4 jerome <romjerome@...>:
>>>> Jerome, do your patch with value for now.
>>>
>>> I thought it was the right thing to do (keep Peter's improvement and use
> after the assignment), but I didn't test it ...
>>>
>>> 16663: ERROR: gramps.py: line 160: Unhandled exception
>>> Traceback (most recent call last):
>>> File "src/ScratchPad.py", line 1137, in object_drag_data_received
>>> o = wrapper_class(self.dbstate,sel_data)
>>> File "src/ScratchPad.py", line 328, in __init__
>>> note = value.get().replace('\n', ' ')
>>> AttributeError: 'unicode' object has no attribute 'get'
>>>
>>> value = self._db.get_note_from_handle(handle)
>>>
>>>
>>> #String must be unicode for truncation to work for non ascii characters
>>> - note = unicode(note)
>>> note = value.get().replace('\n', ' ')
>>> + note = unicode(note)
>>
>>Yes, just revert to the old
>>>
>>> is working but looking at the comment I suppose it makes no real sense !
>>>
>>>
>>>
>>> --- En date de : Jeu 3.12.09, Benny Malengier <benny.malengier@...> a
> écrit :
>>>
>>>> De: Benny Malengier <benny.malengier@...>
>>>> Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
>>>> À: "jerome" <romjerome@...>, "Peter Landgren" <peter.talken@...>
>>>> Cc: "Gramps Development List" <gramps-devel@...>
>>>> Date: Jeudi 3 Décembre 2009, 22h12
>>>> Yes, bug introduced here:
>>>> http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps31/src/ScratchPad.py?view=diff&r1=13168&r2=13169
>>>>
>>>> Peter, as you introduced this, you remember why? As said in
>>>> other
>>>> parts, notes should already be unicode, so no need to
>>>> convert them. I
>>>> would think these changed lines may be removed. They don't
>>>> harm
>>>> however.
>>>>
>>>> Jerome, do your patch with value for now.
>>>>
>>>> Benny
>>>>
>>>> 2009/12/3 jerome <romjerome@...>:
>>>> > or should be something like :
>>>> >
>>>> > #String must be unicode for truncation to work for non
>>>> ascii characters
>>>> > - note = unicode(note)
>>>> > + value = unicode(value)
>>>> > note = value.get().replace('\n', ' ')
>>>> >
>>>> >
>>>> > --- En date de : Jeu 3.12.09, jerome <romjerome@...>
>>>> a écrit :
>>>> >
>>>> >> De: jerome <romjerome@...>
>>>> >> Objet: Re: [Gramps-devel] Re : preparing for
>>>> 3.1.3
>>>> >> À: "Benny Malengier" <benny.malengier@...>
>>>> >> Cc: "Gramps Development List" <gramps-devel@...>
>>>> >> Date: Jeudi 3 Décembre 2009, 18h44
>>>> >> /!\ there is an unfixed bug/crash on
>>>> >> 3.1.3-SVN :
>>>> >>
>>>> >> 116251: ERROR: gramps.py: line 160: Unhandled
>>>> exception
>>>> >> Traceback (most recent call last):
>>>> >> File "src/ScratchPad.py", line 1137, in
>>>> >> object_drag_data_received
>>>> >> o = wrapper_class(self.dbstate,sel_data)
>>>> >> File "src/ScratchPad.py", line 327, in
>>>> __init__
>>>> >> note = unicode(note)
>>>> >> UnboundLocalError: local variable 'note'
>>>> referenced before
>>>> >> assignment
>>>> >>
>>>> >> patch should be easy :
>>>> >>
>>>> >> #String must be unicode for
>>>> >> truncation to work for non ascii characters
>>>> >> - note = unicode(note)
>>>> >> note =
>>>> >> value.get().replace('\n', ' ')
>>>> >> + note = unicode(note)
>>>> >>
>>>> >> To reproduce it :
>>>> >>
>>>> >> 1. Go on Note View
>>>> >> 2. Try to drag and drop a note oject reference
>>>> from
>>>> >> NoteView to clipboard
>>>> >>
>>>> >>
>>>> >> Should I commit change ?
>>>> >>
>>>> >>
>>>> >>
>>>> >> --- En date de : Jeu 3.12.09, Jérôme <romjerome@...>
>>>> >> a écrit :
>>>> >>
>>>> >> > De: Jérôme <romjerome@...>
>>>> >> > Objet: Re: [Gramps-devel] Re : preparing for
>>>> 3.1.3
>>>> >> > À: "Benny Malengier" <benny.malengier@...>
>>>> >> > Cc: "Gramps Development List" <gramps-devel@...>
>>>> >> > Date: Jeudi 3 Décembre 2009, 17h28
>>>> >> > Benny,
>>>> >> >
>>>> >> > >>> 2. On source reference
>>>> (repository):
>>>> >> > >>> 2 CALN
>>>> >> > >>> 3 MEDI Book
>>>> >> > >>> will be a custom translated
>>>> media type
>>>> >> on
>>>> >> > export
>>>> >> > >>> 2 CALN
>>>> >> > >>> 3 MEDI Livre
>>>> >> > >>>
>>>> >> > >>> I suppose there is no error
>>>> because I do
>>>> >> not
>>>> >> > loose data, but it is strange !
>>>> >> > >>
>>>> >> > >> Ok, I'll look at that, make a bug
>>>> ticket (or
>>>> >> > reopen the previous one.
>>>> >> > >> The old code ignored MEDI tag, I
>>>> suppose the
>>>> >> new
>>>> >> > code will write it
>>>> >> > >> out but not in English, it should be
>>>> easy to
>>>> >> adapt
>>>> >> > the writegedcom for
>>>> >> > >> this, other types already write out
>>>> the
>>>> >> english
>>>> >> > version (probably). Or
>>>> >> > >> are other types also written out in
>>>> French?
>>>> >> It
>>>> >> > would make some sense,
>>>> >> > >> GEDCOM programs need not know that
>>>> Book is
>>>> >> Livre
>>>> >> >
>>>> >> > Looks like not a bug ...
>>>> >> > I used Gramps without translations ($ python
>>>> >> > src/gramps.py), and this
>>>> >> > was already present on 3.1.2. There is no
>>>> regression
>>>> >> for
>>>> >> > this on next
>>>> >> > release.
>>>> >> >
>>>> >> > http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
>>>> >> > http://www.gramps-project.org/bugs/view.php?id=3374>>> >> >
>>>> >> > Code writes value (not tag) in english if you
>>>> are
>>>> >> using
>>>> >> > Gramps in
>>>> >> > English and translated value into french if
>>>> you are
>>>> >> using
>>>> >> > Gramps in
>>>> >> > French !
>>>> >> >
>>>> >> > On my 'localized' Gedcom, I get :
>>>> >> >
>>>> >> > 1 EVEN
>>>> >> > 2 TYPE Mariage
>>>> >> > 1 EVEN
>>>> >> > 2 TYPE Élection
>>>> >> > 1 EVEN
>>>> >> > 2 TYPE Résidence
>>>> >> > 2 CALN
>>>> >> > 3 MEDI Livre
>>>> >> >
>>>> >> > which sounds correct with this custom data
>>>> and after
>>>> >> > looking at the
>>>> >> > Gedcom header :
>>>> >> >
>>>> >> > 1 GEDC
>>>> >> > 2 VERS 5.5
>>>> >> > 2 FORM LINEAGE-LINKED
>>>> >> > 1 CHAR UTF-8
>>>> >> > 1 LANG French
>>>> >> >
>>>> >> > TAG do not use non-ASCII characters and
>>>> values are
>>>> >> custom
>>>> >> > data.
>>>> >> > So, I suppose that's not a bug !
>>>> >> >
>>>> >> > > Or are other types also written out in
>>>> French?
>>>> >> >
>>>> >> > yes it is coherent, only custom or Gramps'
>>>> types (not
>>>> >> on
>>>> >> > Gedcom spec)
>>>> >> >
>>>> >> > This kind of thing must be surely forget by
>>>> the many
>>>> >> tests
>>>> >> > which check
>>>> >> > Gedcom support... They look at custom tag
>>>> (_CUSTOM)
>>>> >> but not
>>>> >> > on values
>>>> >> > used into the program.
>>>> >> >
>>>> >> > It's really nice to have this international
>>>> support !
>>>> >> :)
>>>> >> > (I say this now but maybe it was me who has
>>>> grumbled
>>>> >> at the
>>>> >> > time and I
>>>> >> > do not remember !!!)
>>>> >> >
>>>> >> >
>>>> >> > Thanks !
>>>> >> >
>>>> >> > Jérôme
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > Benny Malengier a écrit :
>>>> >> > > 2009/11/24 jerome <romjerome@...>:
>>>> >> > >>> Jerome, your mail is a bit
>>>> confusing.
>>>> >> > >> Sorry. I am testing Gedcom
>>>> management
>>>> >> changes.
>>>> >> > >> First, I have tried to export a
>>>> database
>>>> >> (Family
>>>> >> > Tree) to Gedcom format, but a dialog pops-up
>>>> something
>>>> >> like
>>>> >> > "Gramps cannot write /tmp/..." during write
>>>> person
>>>> >> process.
>>>> >> > Gedcom was not properly generated and I ran
>>>> repair DB
>>>> >> tools
>>>> >> > on my opened Family Tree. Then no more
>>>> message and
>>>> >> > Gramps-3.1.3 has generated a complete
>>>> Gedcom.
>>>> >> > >>
>>>> >> > >> Looking at diff between the first
>>>> one and
>>>> >> the
>>>> >> > second one.
>>>> >> > >> I suppose the problem was just
>>>> "around"
>>>> >> CHANGE
>>>> >> > TIME (as I know this has been improved on
>>>> 3.1.3) and
>>>> >> lines
>>>> >> > "not written" on the broken gedcom could be
>>>> :
>>>> >> > >> 1 CHAN
>>>> >> > >> 2 DATE 24 NOV 2009
>>>> >> > >> 3 TIME 14:29:13
>>>> >> > >>
>>>> >> > >> Sorry, I cannot very well explain
>>>> this :(
>>>> >> > >> I suppose Gramps was not able to
>>>> write 1
>>>> >> CHAN, but
>>>> >> > I cannot say : "Gramps is not able to write
>>>> this",
>>>> >> because
>>>> >> > process freeze, no error or bug report
>>>> dialog, just
>>>> >> Gedcom
>>>> >> > was not complete.
>>>> >> > >>
>>>> >> > >>> because old gramps wrote out
>>>> french
>>>> >> dates?
>>>> >> > >> Do you think this could be an OS
>>>> issue ?
>>>> >> python
>>>> >> > time module ?
>>>> >> > >
>>>> >> > > No, it should work ok, the old code was
>>>> >> completely
>>>> >> > ignoring CHAN
>>>> >> > > group, the new code parses it correctly,
>>>> and it
>>>> >> is
>>>> >> > written out
>>>> >> > > correctly.
>>>> >> > >>> For the second issue, is this a
>>>> >> regression?
>>>> >> > That is could Gramps 3.1.2 read
>>>> >> > >> I will try to test it.
>>>> >> > >>
>>>> >> > >> But seems there is still many
>>>> problems with
>>>> >> Gedcom
>>>> >> > management ...
>>>> >> > >>
>>>> >> > >> I am loosing some data by making a
>>>> diff
>>>> >> between :
>>>> >> > >> a Gedcom generated by Gramps and a
>>>> new one,
>>>> >> > imported into a new Family Tree then
>>>> exported.
>>>> >> > >>
>>>> >> > >> 1. dates with calendar, like :
>>>> >> > >> 2 DATE @#DFRENCH R@ 24 VEND 12
>>>> >> > >> are not properly imported by
>>>> Gramps-3.1.3 and
>>>> >> will
>>>> >> > return a textual date :
>>>> >> > >> 2 DATE 24 VEND 12
>>>> >> > >
>>>> >> > > This should have been like this in
>>>> 3.1.2, it
>>>> >> means the
>>>> >> > Date module
>>>> >> > > that reads it cannot read the @, make a
>>>> bug
>>>> >> ticket,
>>>> >> > but I do not thing
>>>> >> > > it is a regression.
>>>> >> > >> 2. On source reference
>>>> (repository):
>>>> >> > >> 2 CALN
>>>> >> > >> 3 MEDI Book
>>>> >> > >> will be a custom translated media
>>>> type on
>>>> >> export
>>>> >> > >> 2 CALN
>>>> >> > >> 3 MEDI Livre
>>>> >> > >>
>>>> >> > >> I suppose there is no error because
>>>> I do not
>>>> >> loose
>>>> >> > data, but it is strange !
>>>> >> > >
>>>> >> > > Ok, I'll look at that, make a bug ticket
>>>> (or
>>>> >> reopen
>>>> >> > the previous one.
>>>> >> > > The old code ignored MEDI tag, I suppose
>>>> the new
>>>> >> code
>>>> >> > will write it
>>>> >> > > out but not in English, it should be
>>>> easy to
>>>> >> adapt the
>>>> >> > writegedcom for
>>>> >> > > this, other types already write out the
>>>> english
>>>> >> > version (probably). Or
>>>> >> > > are other types also written out in
>>>> French? It
>>>> >> would
>>>> >> > make some sense,
>>>> >> > > GEDCOM programs need not know that Book
>>>> is Livre
>>>> >> > >
>>>> >> > >> 3. References on Media Objects are
>>>> ignored
>>>> >> on
>>>> >> > export
>>>> >> > >> I started with 662 references into
>>>> my Family
>>>> >> Tree
>>>> >> > and after a Gedcom import into a new Family
>>>> Tree, I
>>>> >> kept 18,
>>>> >> > which was not media object, only urls on
>>>> person object
>>>> >> !!!)
>>>> >> > >>
>>>> >> > >> I do not see any problem yet on
>>>> Gramps XML
>>>> >> > management, and maybe some of this issues has
>>>> been
>>>> >> already
>>>> >> > reported. I remember something like "Gedcom
>>>> generated
>>>> >> by
>>>> >> > Gramps imported into Gramps".
>>>> >> > >>
>>>> >> > >> I suppose "references on Media
>>>> Objects" and
>>>> >> the "1
>>>> >> > OBJE
>>>> >> > >> 2 FORM" (url on person) are
>>>> related.
>>>> >> > >
>>>> >> > > This is the first I hear about this.
>>>> >> > > I do not like coding in GEDCOM, I do not
>>>> use it
>>>> >> !!!
>>>> >> > >
>>>> >> > > Benny
>>>> >> > >
>>>> >> > >>
>>>> >> > >> I will look at Gedcom regression.
>>>> >> > >>
>>>> >> > >>
>>>> >> > >> Jérôme
>>>> >> > >>
>>>> >> > >>
>>>> >> > >> --- En date de : Mar 24.11.09,
>>>> Benny
>>>> >> Malengier
>>>> >> > <benny.malengier@...>
>>>> >> > a écrit :
>>>> >> > >>
>>>> >> > >>> De: Benny Malengier <benny.malengier@...>
>>>> >> > >>> Objet: Re: Re : preparing for
>>>> 3.1.3
>>>> >> > >>> À: "jerome" <romjerome@...>
>>>> >> > >>> Cc: "Gramps Development List"
>>>> <gramps-devel@...>,
>>>> >> > "Stéphane Charette" <stephanecharette@...>
>>>> >> > >>> Date: Mardi 24 Novembre 2009,
>>>> 15h24
>>>> >> > >>> Jerome, your mail is a bit
>>>> >> > >>> confusing.
>>>> >> > >>>
>>>> >> > >>> Are you saying the old gedcom
>>>> crashes now
>>>> >> on
>>>> >> > import because
>>>> >> > >>> old gramps
>>>> >> > >>> wrote out french dates? Or is
>>>> there no
>>>> >> problem
>>>> >> > (I see no
>>>> >> > >>> crash report
>>>> >> > >>> in this mail)
>>>> >> > >>>
>>>> >> > >>> For the second issue, is this a
>>>> >> regression?
>>>> >> > That is could
>>>> >> > >>> Gramps 3.1.2 read
>>>> >> > >>>
>>>> >> > >>>> 1 OBJE
>>>> >> > >>>> 2 FORM URL
>>>> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>>>> >> > >>> Benny
>>>> >> > >>>
>>>> >> > >>> 2009/11/24 jerome <romjerome@...>:
>>>> >> > >>>>> so we can prepare for
>>>> 3.1.3.
>>>> >> Could
>>>> >> > >>>>> everyone test perhaps a
>>>> GEDCOM
>>>> >> and an
>>>> >> > XML export
>>>> >> > >>> of their
>>>> >> > >>>>> data
>>>> >> > >>>>> (filtered somehow), and
>>>> then
>>>> >> import
>>>> >> > again in an
>>>> >> > >>> empty tree.
>>>> >> > >>>>> The last
>>>> >> > >>>>> things changes are
>>>> related to
>>>> >> that,
>>>> >> > and GEDCOM
>>>> >> > >>> changes are
>>>> >> > >>>>> sensitive.
>>>> >> > >>>> I have started to test
>>>> import from
>>>> >> > Gramps-3.1.3 to
>>>> >> > >>> Gramps-3.1.3
>>>> >> > >>>> (Ubuntu 9.04, python 2.6)
>>>> >> > >>>>
>>>> >> > >>>> ///// 1 warning during
>>>> Gramps
>>>> >> > session ///////
>>>> >> > >>>> (gramps.py:4609): CRITICAL
>>>> **:
>>>> >> > >>> murrine_style_draw_focus:
>>>> assertion
>>>> >> `height
>>>> >> > >= -1'
>>>> >> > >>> failed
>>>> >> > >>>> ///// 1 problem on GEDCOM
>>>> export
>>>> >> ///////
>>>> >> > >>>>
>>>> >> > >>>> "Cannot write file ..."
>>>> message on
>>>> >> dialog
>>>> >> > (on write
>>>> >> > >>> persons)
>>>> >> > >>>> Fixed after running rebuild
>>>> 2nd
>>>> >> indices
>>>> >> > and "Check
>>>> >> > >>> & Repair" tools. (no problem
>>>> with
>>>> >> Gramps
>>>> >> > XML format)
>>>> >> > >>>> Re-test is OK.
>>>> >> > >>>> Pass without error by using
>>>> :
>>>> >> > >>>>
>>>> >> > >>>> 1 CHAN
>>>> >> > >>>> 2 DATE 24 NOV 2009
>>>> >> > >>>> 3 TIME 14:29:13
>>>> >> > >>>>
>>>> >> > >>>> Looks like first test has
>>>> blocked
>>>> >> just
>>>> >> > before "change
>>>> >> > >>> time" on person object !
>>>> >> > >>>> /!\ I used my testing
>>>> database
>>>> >> (generated
>>>> >> > before new
>>>> >> > >>> time management on Gedcom
>>>> >> > >>>> ///// problem on GEDCOM
>>>> import
>>>> >> ///////
>>>> >> > >>>>
>>>> >> > >>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer http://www.geneanet.org/contact.php3?source=bouly78
>>>> >> > >>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer http://www.geneanet.org/rgentner>>> >> >
>>>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer
>>>> >> > >>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer
>>>> >> > >>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer
>>>> >> > >>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=henriks
>>>> >> > >>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
>>>> >> > >>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=myriague
>>>> >> > >>>> WARNING .GedcomImport:
>>>> Impossible
>>>> >> > d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
>>>> >> > >>>>
>>>> >> > >>>> => Cannot import url
>>>> >> > >>>>
>>>> >> > >>>> was generated by
>>>> Gramps-3.1.3 :
>>>> >> > >>>>
>>>> >> > >>>> 0 @I1802@ INDI
>>>> >> > >>>> 1 NAME Florent /SCHMITT/
>>>> >> > >>>> 2 GIVN Florent
>>>> >> > >>>> 2 SURN SCHMITT
>>>> >> > >>>> 1 SEX M
>>>> >> > >>>> 1 OBJE
>>>> >> > >>>> 2 FORM URL
>>>> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>>>> >> > >>>>
>>>> >> > >>>> Now, I will try to see any
>>>> diff on
>>>> >> data
>>>> >> > (Gedcom,
>>>> >> > >>> Gramps XML)
>>>> >> > >>>>
>>>> >> > >>>>
>>>> >> > >>>> Jérôme R.
>>>> >> > >>>>
>>>> >> > >>>>
>>>> >> > >>>> --- En date de : Dim
>>>> 22.11.09, Benny
>>>> >> > Malengier <benny.malengier@...>
>>>> >> > >>> a écrit :
>>>> >> > >>>>> De: Benny Malengier
>>>> <benny.malengier@...>
>>>> >> > >>>>> Objet: preparing for
>>>> 3.1.3
>>>> >> > >>>>> À: "Gramps Development
>>>> List"
>>>> >> <gramps-devel@...>,
>>>> >> > >>> "Jérôme" <romjerome@...>,
>>>> >> > >>> "Stéphane Charette" <stephanecharette@...>
>>>> >> > >>>>> Date: Dimanche 22
>>>> Novembre 2009,
>>>> >> > 10h11
>>>> >> > >>>>> All, the roadmap is
>>>> now on
>>>> >> > >>>>> 100%, so we can prepare
>>>> for
>>>> >> 3.1.3.
>>>> >> > Could
>>>> >> > >>>>> everyone test perhaps a
>>>> GEDCOM
>>>> >> and an
>>>> >> > XML export
>>>> >> > >>> of their
>>>> >> > >>>>> data
>>>> >> > >>>>> (filtered somehow), and
>>>> then
>>>> >> import
>>>> >> > again in an
>>>> >> > >>> empty tree.
>>>> >> > >>>>> The last
>>>> >> > >>>>> things changes are
>>>> related to
>>>> >> that,
>>>> >> > and GEDCOM
>>>> >> > >>> changes are
>>>> >> > >>>>> sensitive.
>>>> >> > >>>>>
>>>> >> > >>>>> Jerome, can you check
>>>> the po file
>>>> >> is
>>>> >> > up to date,
>>>> >> > >>> perhaps
>>>> >> > >>>>> send mail to
>>>> >> > >>>>> translators with %
>>>> completion of
>>>> >> their
>>>> >> > language
>>>> >> > >>> as
>>>> >> > >>>>> information?
>>>> >> > >>>>>
>>>> >> > >>>>> Stephane, do you have
>>>> time
>>>> >> somewhere
>>>> >> > in the coming
>>>> >> > >>> weeks to
>>>> >> > >>>>> push out
>>>> >> > >>>>> 3.1.3? I would like to
>>>> see in
>>>> >> the
>>>> >> > release notes
>>>> >> > >>> something
>>>> >> > >>>>> in the line
>>>> >> > >>>>> of 'While the Gramps
>>>> developers
>>>> >> are
>>>> >> > working on a
>>>> >> > >>> super 3.2
>>>> >> > >>>>> release in
>>>> >> > >>>>> a couple of months, they
>>>> still
>>>> >> had
>>>> >> > time for a
>>>> >> > >>> minor bug fix
>>>> >> > >>>>> release.
>>>> >> > >>>>>
>>>> >> > >>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
>>>> >> > >>>>> contains main content of
>>>> this
>>>> >> release.
>>>> >> > I think the
>>>> >> > >>> most
>>>> >> > >>>>> striking:
>>>> >> > >>>>>
>>>> >> > >>>>> * the annoying tooltip
>>>> messages
>>>> >> in
>>>> >> > latest distro's
>>>> >> > >>> are no
>>>> >> > >>>>> longer present
>>>> >> > >>>>> * some GEDCOM fixes
>>>> (timestamp
>>>> >> on
>>>> >> > persons now
>>>> >> > >>> kept, MEDI
>>>> >> > >>>>> import, ...)
>>>> >> > >>>>> * some data that was not
>>>> present
>>>> >> in
>>>> >> > filtered data
>>>> >> > >>> is now
>>>> >> > >>>>> present
>>>> >> > >>>>> (source page, ...)
>>>> >> > >>>>> * windows / or \ paths
>>>> in
>>>> >> webreport
>>>> >> > cleaned up
>>>> >> > >>>>> * ...
>>>> >> > >>>>>
>>>> >> > >>>>> Benny
>>>> >> > >>>>>
>>>> >> > >>>>
>>>> >> > >>>>
>>>> >> > >>>>
>>>> >> > >>
>>>> >> > >>
>>>> >> > >>
>>>> >> > >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>>
> ------------------------------------------------------------------------------
>>>> >> > Join us December 9, 2009 for the Red Hat
>>>> Virtual
>>>> >> > Experience,
>>>> >> > a free event focused on virtualization and
>>>> cloud
>>>> >> computing.
>>>> >> >
>>>> >> > Attend in-depth sessions from your desk. Your
>>>> couch.
>>>> >> > Anywhere.
>>>> >> > http://p.sf.net/sfu/redhat-sfdev2dev>>> >> >
>>>> _______________________________________________
>>>> >> > Gramps-devel mailing list
>>>> >> > Gramps-devel@...
>>>> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>>
> ------------------------------------------------------------------------------
>>>> >> Join us December 9, 2009 for
> the Red Hat Virtual
>>>> >> Experience,
>>>> >> a free event focused on virtualization and cloud
>>>> computing.
>>>> >>
>>>> >> Attend in-depth sessions from your desk. Your
>>>> couch.
>>>> >> Anywhere.
>>>> >> http://p.sf.net/sfu/redhat-sfdev2dev>>> >>
> _______________________________________________
>>>> >> Gramps-devel mailing list
>>>> >> Gramps-
> devel@...
>>>> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel>>> >>
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T05:35:32Z

Folks,

I'm not at home now, so I can't do anything. Will be back on Sunday afternoon.

/Peter

>----Ursprungligt meddelande----
>Från: benny.malengier@...
>Datum: 2009-12-04 09:47
>Till: "Peter Landgren"<peter.talken@...>
>Kopia: "Gramps Development List"<gramps-devel@...>
>Ärende: Re: [Gramps-devel] Re : preparing for 3.1.3
>
>Peter, I now remember what this was about.
>Can you fix this today in the Scratchpad code? You probably still have
>your testcase.
>
>> #String must be unicode for truncation to work for non ascii characters
>> - note = unicode(note)
>> note = value.get().replace('\n', ' ')
>> + note = unicode(note)
>
>I think should be correct, no? It wouds be better if the comment says:
> #String must be unicode for slicing to work for non ascii characters
>and still obtain unicode
>
>Benny
>
>2009/12/4 jerome <romjerome@...>:
>>> Jerome, do your patch with value for now.
>>
>> I thought it was the right thing to do (keep Peter's improvement and use

after the assignment), but I didn't test it ...

>>
>> 16663: ERROR: gramps.py: line 160: Unhandled exception
>> Traceback (most recent call last):
>> File "src/ScratchPad.py", line 1137, in object_drag_data_received
>> o = wrapper_class(self.dbstate,sel_data)
>> File "src/ScratchPad.py", line 328, in __init__
>> note = value.get().replace('\n', ' ')
>> AttributeError: 'unicode' object has no attribute 'get'
>>
>> value = self._db.get_note_from_handle(handle)
>>
>>
>> #String must be unicode for truncation to work for non ascii characters
>> - note = unicode(note)
>> note = value.get().replace('\n', ' ')
>> + note = unicode(note)
>
>Yes, just revert to the old
>>
>> is working but looking at the comment I suppose it makes no real sense !
>>
>>
>>
>> --- En date de : Jeu 3.12.09, Benny Malengier <benny.malengier@...> a

écrit :

>>
>>> De: Benny Malengier <benny.malengier@...>
>>> Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
>>> À: "jerome" <romjerome@...>, "Peter Landgren" <peter.talken@...>
>>> Cc: "Gramps Development List" <gramps-devel@...>
>>> Date: Jeudi 3 Décembre 2009, 22h12
>>> Yes, bug introduced here:
>>> http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps31/src/ScratchPad.py?view=diff&r1=13168&r2=13169
>>>
>>> Peter, as you introduced this, you remember why? As said in
>>> other
>>> parts, notes should already be unicode, so no need to
>>> convert them. I
>>> would think these changed lines may be removed. They don't
>>> harm
>>> however.
>>>
>>> Jerome, do your patch with value for now.
>>>
>>> Benny
>>>
>>> 2009/12/3 jerome <romjerome@...>:
>>> > or should be something like :
>>> >
>>> > #String must be unicode for truncation to work for non
>>> ascii characters
>>> > - note = unicode(note)
>>> > + value = unicode(value)
>>> > note = value.get().replace('\n', ' ')
>>> >
>>> >
>>> > --- En date de : Jeu 3.12.09, jerome <romjerome@...>
>>> a écrit :
>>> >
>>> >> De: jerome <romjerome@...>
>>> >> Objet: Re: [Gramps-devel] Re : preparing for
>>> 3.1.3
>>> >> À: "Benny Malengier" <benny.malengier@...>
>>> >> Cc: "Gramps Development List" <gramps-devel@...>
>>> >> Date: Jeudi 3 Décembre 2009, 18h44
>>> >> /!\ there is an unfixed bug/crash on
>>> >> 3.1.3-SVN :
>>> >>
>>> >> 116251: ERROR: gramps.py: line 160: Unhandled
>>> exception
>>> >> Traceback (most recent call last):
>>> >> File "src/ScratchPad.py", line 1137, in
>>> >> object_drag_data_received
>>> >> o = wrapper_class(self.dbstate,sel_data)
>>> >> File "src/ScratchPad.py", line 327, in
>>> __init__
>>> >> note = unicode(note)
>>> >> UnboundLocalError: local variable 'note'
>>> referenced before
>>> >> assignment
>>> >>
>>> >> patch should be easy :
>>> >>
>>> >> #String must be unicode for
>>> >> truncation to work for non ascii characters
>>> >> - note = unicode(note)
>>> >> note =
>>> >> value.get().replace('\n', ' ')
>>> >> + note = unicode(note)
>>> >>
>>> >> To reproduce it :
>>> >>
>>> >> 1. Go on Note View
>>> >> 2. Try to drag and drop a note oject reference
>>> from
>>> >> NoteView to clipboard
>>> >>
>>> >>
>>> >> Should I commit change ?
>>> >>
>>> >>
>>> >>
>>> >> --- En date de : Jeu 3.12.09, Jérôme <romjerome@...>
>>> >> a écrit :
>>> >>
>>> >> > De: Jérôme <romjerome@...>
>>> >> > Objet: Re: [Gramps-devel] Re : preparing for
>>> 3.1.3
>>> >> > À: "Benny Malengier" <benny.malengier@...>
>>> >> > Cc: "Gramps Development List" <gramps-devel@...>
>>> >> > Date: Jeudi 3 Décembre 2009, 17h28
>>> >> > Benny,
>>> >> >
>>> >> > >>> 2. On source reference
>>> (repository):
>>> >> > >>> 2 CALN
>>> >> > >>> 3 MEDI Book
>>> >> > >>> will be a custom translated
>>> media type
>>> >> on
>>> >> > export
>>> >> > >>> 2 CALN
>>> >> > >>> 3 MEDI Livre
>>> >> > >>>
>>> >> > >>> I suppose there is no error
>>> because I do
>>> >> not
>>> >> > loose data, but it is strange !
>>> >> > >>
>>> >> > >> Ok, I'll look at that, make a bug
>>> ticket (or
>>> >> > reopen the previous one.
>>> >> > >> The old code ignored MEDI tag, I
>>> suppose the
>>> >> new
>>> >> > code will write it
>>> >> > >> out but not in English, it should be
>>> easy to
>>> >> adapt
>>> >> > the writegedcom for
>>> >> > >> this, other types already write out
>>> the
>>> >> english
>>> >> > version (probably). Or
>>> >> > >> are other types also written out in
>>> French?
>>> >> It
>>> >> > would make some sense,
>>> >> > >> GEDCOM programs need not know that
>>> Book is
>>> >> Livre
>>> >> >
>>> >> > Looks like not a bug ...
>>> >> > I used Gramps without translations ($ python
>>> >> > src/gramps.py), and this
>>> >> > was already present on 3.1.2. There is no
>>> regression
>>> >> for
>>> >> > this on next
>>> >> > release.
>>> >> >
>>> >> > http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
>>> >> > http://www.gramps-project.org/bugs/view.php?id=3374>>> >> >
>>> >> > Code writes value (not tag) in english if you
>>> are
>>> >> using
>>> >> > Gramps in
>>> >> > English and translated value into french if
>>> you are
>>> >> using
>>> >> > Gramps in
>>> >> > French !
>>> >> >
>>> >> > On my 'localized' Gedcom, I get :
>>> >> >
>>> >> > 1 EVEN
>>> >> > 2 TYPE Mariage
>>> >> > 1 EVEN
>>> >> > 2 TYPE Élection
>>> >> > 1 EVEN
>>> >> > 2 TYPE Résidence
>>> >> > 2 CALN
>>> >> > 3 MEDI Livre
>>> >> >
>>> >> > which sounds correct with this custom data
>>> and after
>>> >> > looking at the
>>> >> > Gedcom header :
>>> >> >
>>> >> > 1 GEDC
>>> >> > 2 VERS 5.5
>>> >> > 2 FORM LINEAGE-LINKED
>>> >> > 1 CHAR UTF-8
>>> >> > 1 LANG French
>>> >> >
>>> >> > TAG do not use non-ASCII characters and
>>> values are
>>> >> custom
>>> >> > data.
>>> >> > So, I suppose that's not a bug !
>>> >> >
>>> >> > > Or are other types also written out in
>>> French?
>>> >> >
>>> >> > yes it is coherent, only custom or Gramps'
>>> types (not
>>> >> on
>>> >> > Gedcom spec)
>>> >> >
>>> >> > This kind of thing must be surely forget by
>>> the many
>>> >> tests
>>> >> > which check
>>> >> > Gedcom support... They look at custom tag
>>> (_CUSTOM)
>>> >> but not
>>> >> > on values
>>> >> > used into the program.
>>> >> >
>>> >> > It's really nice to have this international
>>> support !
>>> >> :)
>>> >> > (I say this now but maybe it was me who has
>>> grumbled
>>> >> at the
>>> >> > time and I
>>> >> > do not remember !!!)
>>> >> >
>>> >> >
>>> >> > Thanks !
>>> >> >
>>> >> > Jérôme
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > Benny Malengier a écrit :
>>> >> > > 2009/11/24 jerome <romjerome@...>:
>>> >> > >>> Jerome, your mail is a bit
>>> confusing.
>>> >> > >> Sorry. I am testing Gedcom
>>> management
>>> >> changes.
>>> >> > >> First, I have tried to export a
>>> database
>>> >> (Family
>>> >> > Tree) to Gedcom format, but a dialog pops-up
>>> something
>>> >> like
>>> >> > "Gramps cannot write /tmp/..." during write
>>> person
>>> >> process.
>>> >> > Gedcom was not properly generated and I ran
>>> repair DB
>>> >> tools
>>> >> > on my opened Family Tree. Then no more
>>> message and
>>> >> > Gramps-3.1.3 has generated a complete
>>> Gedcom.
>>> >> > >>
>>> >> > >> Looking at diff between the first
>>> one and
>>> >> the
>>> >> > second one.
>>> >> > >> I suppose the problem was just
>>> "around"
>>> >> CHANGE
>>> >> > TIME (as I know this has been improved on
>>> 3.1.3) and
>>> >> lines
>>> >> > "not written" on the broken gedcom could be
>>> :
>>> >> > >> 1 CHAN
>>> >> > >> 2 DATE 24 NOV 2009
>>> >> > >> 3 TIME 14:29:13
>>> >> > >>
>>> >> > >> Sorry, I cannot very well explain
>>> this :(
>>> >> > >> I suppose Gramps was not able to
>>> write 1
>>> >> CHAN, but
>>> >> > I cannot say : "Gramps is not able to write
>>> this",
>>> >> because
>>> >> > process freeze, no error or bug report
>>> dialog, just
>>> >> Gedcom
>>> >> > was not complete.
>>> >> > >>
>>> >> > >>> because old gramps wrote out
>>> french
>>> >> dates?
>>> >> > >> Do you think this could be an OS
>>> issue ?
>>> >> python
>>> >> > time module ?
>>> >> > >
>>> >> > > No, it should work ok, the old code was
>>> >> completely
>>> >> > ignoring CHAN
>>> >> > > group, the new code parses it correctly,
>>> and it
>>> >> is
>>> >> > written out
>>> >> > > correctly.
>>> >> > >>> For the second issue, is this a
>>> >> regression?
>>> >> > That is could Gramps 3.1.2 read
>>> >> > >> I will try to test it.
>>> >> > >>
>>> >> > >> But seems there is still many
>>> problems with
>>> >> Gedcom
>>> >> > management ...
>>> >> > >>
>>> >> > >> I am loosing some data by making a
>>> diff
>>> >> between :
>>> >> > >> a Gedcom generated by Gramps and a
>>> new one,
>>> >> > imported into a new Family Tree then
>>> exported.
>>> >> > >>
>>> >> > >> 1. dates with calendar, like :
>>> >> > >> 2 DATE @#DFRENCH R@ 24 VEND 12
>>> >> > >> are not properly imported by
>>> Gramps-3.1.3 and
>>> >> will
>>> >> > return a textual date :
>>> >> > >> 2 DATE 24 VEND 12
>>> >> > >
>>> >> > > This should have been like this in
>>> 3.1.2, it
>>> >> means the
>>> >> > Date module
>>> >> > > that reads it cannot read the @, make a
>>> bug
>>> >> ticket,
>>> >> > but I do not thing
>>> >> > > it is a regression.
>>> >> > >> 2. On source reference
>>> (repository):
>>> >> > >> 2 CALN
>>> >> > >> 3 MEDI Book
>>> >> > >> will be a custom translated media
>>> type on
>>> >> export
>>> >> > >> 2 CALN
>>> >> > >> 3 MEDI Livre
>>> >> > >>
>>> >> > >> I suppose there is no error because
>>> I do not
>>> >> loose
>>> >> > data, but it is strange !
>>> >> > >
>>> >> > > Ok, I'll look at that, make a bug ticket
>>> (or
>>> >> reopen
>>> >> > the previous one.
>>> >> > > The old code ignored MEDI tag, I suppose
>>> the new
>>> >> code
>>> >> > will write it
>>> >> > > out but not in English, it should be
>>> easy to
>>> >> adapt the
>>> >> > writegedcom for
>>> >> > > this, other types already write out the
>>> english
>>> >> > version (probably). Or
>>> >> > > are other types also written out in
>>> French? It
>>> >> would
>>> >> > make some sense,
>>> >> > > GEDCOM programs need not know that Book
>>> is Livre
>>> >> > >
>>> >> > >> 3. References on Media Objects are
>>> ignored
>>> >> on
>>> >> > export
>>> >> > >> I started with 662 references into
>>> my Family
>>> >> Tree
>>> >> > and after a Gedcom import into a new Family
>>> Tree, I
>>> >> kept 18,
>>> >> > which was not media object, only urls on
>>> person object
>>> >> !!!)
>>> >> > >>
>>> >> > >> I do not see any problem yet on
>>> Gramps XML
>>> >> > management, and maybe some of this issues has
>>> been
>>> >> already
>>> >> > reported. I remember something like "Gedcom
>>> generated
>>> >> by
>>> >> > Gramps imported into Gramps".
>>> >> > >>
>>> >> > >> I suppose "references on Media
>>> Objects" and
>>> >> the "1
>>> >> > OBJE
>>> >> > >> 2 FORM" (url on person) are
>>> related.
>>> >> > >
>>> >> > > This is the first I hear about this.
>>> >> > > I do not like coding in GEDCOM, I do not
>>> use it
>>> >> !!!
>>> >> > >
>>> >> > > Benny
>>> >> > >
>>> >> > >>
>>> >> > >> I will look at Gedcom regression.
>>> >> > >>
>>> >> > >>
>>> >> > >> Jérôme
>>> >> > >>
>>> >> > >>
>>> >> > >> --- En date de : Mar 24.11.09,
>>> Benny
>>> >> Malengier
>>> >> > <benny.malengier@...>
>>> >> > a écrit :
>>> >> > >>
>>> >> > >>> De: Benny Malengier <benny.malengier@...>
>>> >> > >>> Objet: Re: Re : preparing for
>>> 3.1.3
>>> >> > >>> À: "jerome" <romjerome@...>
>>> >> > >>> Cc: "Gramps Development List"
>>> <gramps-devel@...>,
>>> >> > "Stéphane Charette" <stephanecharette@...>
>>> >> > >>> Date: Mardi 24 Novembre 2009,
>>> 15h24
>>> >> > >>> Jerome, your mail is a bit
>>> >> > >>> confusing.
>>> >> > >>>
>>> >> > >>> Are you saying the old gedcom
>>> crashes now
>>> >> on
>>> >> > import because
>>> >> > >>> old gramps
>>> >> > >>> wrote out french dates? Or is
>>> there no
>>> >> problem
>>> >> > (I see no
>>> >> > >>> crash report
>>> >> > >>> in this mail)
>>> >> > >>>
>>> >> > >>> For the second issue, is this a
>>> >> regression?
>>> >> > That is could
>>> >> > >>> Gramps 3.1.2 read
>>> >> > >>>
>>> >> > >>>> 1 OBJE
>>> >> > >>>> 2 FORM URL
>>> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>>> >> > >>> Benny
>>> >> > >>>
>>> >> > >>> 2009/11/24 jerome <romjerome@...>:
>>> >> > >>>>> so we can prepare for
>>> 3.1.3.
>>> >> Could
>>> >> > >>>>> everyone test perhaps a
>>> GEDCOM
>>> >> and an
>>> >> > XML export
>>> >> > >>> of their
>>> >> > >>>>> data
>>> >> > >>>>> (filtered somehow), and
>>> then
>>> >> import
>>> >> > again in an
>>> >> > >>> empty tree.
>>> >> > >>>>> The last
>>> >> > >>>>> things changes are
>>> related to
>>> >> that,
>>> >> > and GEDCOM
>>> >> > >>> changes are
>>> >> > >>>>> sensitive.
>>> >> > >>>> I have started to test
>>> import from
>>> >> > Gramps-3.1.3 to
>>> >> > >>> Gramps-3.1.3
>>> >> > >>>> (Ubuntu 9.04, python 2.6)
>>> >> > >>>>
>>> >> > >>>> ///// 1 warning during
>>> Gramps
>>> >> > session ///////
>>> >> > >>>> (gramps.py:4609): CRITICAL
>>> **:
>>> >> > >>> murrine_style_draw_focus:
>>> assertion
>>> >> `height
>>> >> > >= -1'
>>> >> > >>> failed
>>> >> > >>>> ///// 1 problem on GEDCOM
>>> export
>>> >> ///////
>>> >> > >>>>
>>> >> > >>>> "Cannot write file ..."
>>> message on
>>> >> dialog
>>> >> > (on write
>>> >> > >>> persons)
>>> >> > >>>> Fixed after running rebuild
>>> 2nd
>>> >> indices
>>> >> > and "Check
>>> >> > >>> & Repair" tools. (no problem
>>> with
>>> >> Gramps
>>> >> > XML format)
>>> >> > >>>> Re-test is OK.
>>> >> > >>>> Pass without error by using
>>> :
>>> >> > >>>>
>>> >> > >>>> 1 CHAN
>>> >> > >>>> 2 DATE 24 NOV 2009
>>> >> > >>>> 3 TIME 14:29:13
>>> >> > >>>>
>>> >> > >>>> Looks like first test has
>>> blocked
>>> >> just
>>> >> > before "change
>>> >> > >>> time" on person object !
>>> >> > >>>> /!\ I used my testing
>>> database
>>> >> (generated
>>> >> > before new
>>> >> > >>> time management on Gedcom
>>> >> > >>>> ///// problem on GEDCOM
>>> import
>>> >> ///////
>>> >> > >>>>
>>> >> > >>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer http://www.geneanet.org/contact.php3?source=bouly78
>>> >> > >>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer http://www.geneanet.org/rgentner>>> >> >
>>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer
>>> >> > >>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer
>>> >> > >>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer
>>> >> > >>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=henriks
>>> >> > >>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
>>> >> > >>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer http://gw1.geneanet.org/index.php3?b=myriague
>>> >> > >>>> WARNING .GedcomImport:
>>> Impossible
>>> >> > d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
>>> >> > >>>>
>>> >> > >>>> => Cannot import url
>>> >> > >>>>
>>> >> > >>>> was generated by
>>> Gramps-3.1.3 :
>>> >> > >>>>
>>> >> > >>>> 0 @I1802@ INDI
>>> >> > >>>> 1 NAME Florent /SCHMITT/
>>> >> > >>>> 2 GIVN Florent
>>> >> > >>>> 2 SURN SCHMITT
>>> >> > >>>> 1 SEX M
>>> >> > >>>> 1 OBJE
>>> >> > >>>> 2 FORM URL
>>> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>>> >> > >>>>
>>> >> > >>>> Now, I will try to see any
>>> diff on
>>> >> data
>>> >> > (Gedcom,
>>> >> > >>> Gramps XML)
>>> >> > >>>>
>>> >> > >>>>
>>> >> > >>>> Jérôme R.
>>> >> > >>>>
>>> >> > >>>>
>>> >> > >>>> --- En date de : Dim
>>> 22.11.09, Benny
>>> >> > Malengier <benny.malengier@...>
>>> >> > >>> a écrit :
>>> >> > >>>>> De: Benny Malengier
>>> <benny.malengier@...>
>>> >> > >>>>> Objet: preparing for
>>> 3.1.3
>>> >> > >>>>> À: "Gramps Development
>>> List"
>>> >> <gramps-devel@...>,
>>> >> > >>> "Jérôme" <romjerome@...>,
>>> >> > >>> "Stéphane Charette" <stephanecharette@...>
>>> >> > >>>>> Date: Dimanche 22
>>> Novembre 2009,
>>> >> > 10h11
>>> >> > >>>>> All, the roadmap is
>>> now on
>>> >> > >>>>> 100%, so we can prepare
>>> for
>>> >> 3.1.3.
>>> >> > Could
>>> >> > >>>>> everyone test perhaps a
>>> GEDCOM
>>> >> and an
>>> >> > XML export
>>> >> > >>> of their
>>> >> > >>>>> data
>>> >> > >>>>> (filtered somehow), and
>>> then
>>> >> import
>>> >> > again in an
>>> >> > >>> empty tree.
>>> >> > >>>>> The last
>>> >> > >>>>> things changes are
>>> related to
>>> >> that,
>>> >> > and GEDCOM
>>> >> > >>> changes are
>>> >> > >>>>> sensitive.
>>> >> > >>>>>
>>> >> > >>>>> Jerome, can you check
>>> the po file
>>> >> is
>>> >> > up to date,
>>> >> > >>> perhaps
>>> >> > >>>>> send mail to
>>> >> > >>>>> translators with %
>>> completion of
>>> >> their
>>> >> > language
>>> >> > >>> as
>>> >> > >>>>> information?
>>> >> > >>>>>
>>> >> > >>>>> Stephane, do you have
>>> time
>>> >> somewhere
>>> >> > in the coming
>>> >> > >>> weeks to
>>> >> > >>>>> push out
>>> >> > >>>>> 3.1.3? I would like to
>>> see in
>>> >> the
>>> >> > release notes
>>> >> > >>> something
>>> >> > >>>>> in the line
>>> >> > >>>>> of 'While the Gramps
>>> developers
>>> >> are
>>> >> > working on a
>>> >> > >>> super 3.2
>>> >> > >>>>> release in
>>> >> > >>>>> a couple of months, they
>>> still
>>> >> had
>>> >> > time for a
>>> >> > >>> minor bug fix
>>> >> > >>>>> release.
>>> >> > >>>>>
>>> >> > >>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
>>> >> > >>>>> contains main content of
>>> this
>>> >> release.
>>> >> > I think the
>>> >> > >>> most
>>> >> > >>>>> striking:
>>> >> > >>>>>
>>> >> > >>>>> * the annoying tooltip
>>> messages
>>> >> in
>>> >> > latest distro's
>>> >> > >>> are no
>>> >> > >>>>> longer present
>>> >> > >>>>> * some GEDCOM fixes
>>> (timestamp
>>> >> on
>>> >> > persons now
>>> >> > >>> kept, MEDI
>>> >> > >>>>> import, ...)
>>> >> > >>>>> * some data that was not
>>> present
>>> >> in
>>> >> > filtered data
>>> >> > >>> is now
>>> >> > >>>>> present
>>> >> > >>>>> (source page, ...)
>>> >> > >>>>> * windows / or \ paths
>>> in
>>> >> webreport
>>> >> > cleaned up
>>> >> > >>>>> * ...
>>> >> > >>>>>
>>> >> > >>>>> Benny
>>> >> > >>>>>
>>> >> > >>>>
>>> >> > >>>>
>>> >> > >>>>
>>> >> > >>
>>> >> > >>
>>> >> > >>
>>> >> > >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>>

------------------------------------------------------------------------------

>>> >> > Join us December 9, 2009 for the Red Hat
>>> Virtual
>>> >> > Experience,
>>> >> > a free event focused on virtualization and
>>> cloud
>>> >> computing.
>>> >> >
>>> >> > Attend in-depth sessions from your desk. Your
>>> couch.
>>> >> > Anywhere.
>>> >> > http://p.sf.net/sfu/redhat-sfdev2dev>>> >> >
>>> _______________________________________________
>>> >> > Gramps-devel mailing list
>>> >> > Gramps-devel@...
>>> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>>

------------------------------------------------------------------------------
>>> >> Join us December 9, 2009 for
the Red Hat Virtual
>>> >> Experience,
>>> >> a free event focused on virtualization and cloud
>>> computing.
>>> >>
>>> >> Attend in-depth sessions from your desk. Your
>>> couch.
>>> >> Anywhere.
>>> >> http://p.sf.net/sfu/redhat-sfdev2dev>>> >>
_______________________________________________
>>> >> Gramps-devel mailing list
>>> >> Gramps-
devel@...

>>> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel>>> >>
>>> >
>>> >
>>> >
>>> >
>>>
>>
>>
>>
>>
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T05:29:10Z

Sometimes strings where of type 'str' and when such strings was cut off in the
middle of a utf-8 sequence, strange characters was shown on the display. And an
error message was output on tyhe console. Coverting 'str' to 'unicode' solved
this minor error. I have no idea why some strings in notes where of type 'str'
and some of type 'unicode'.

/Peter

>----Ursprungligt meddelande----
>Från: benny.malengier@...
>Datum: 2009-12-03 22:12
>Till: "jerome"<romjerome@...>, "Peter Landgren"<peter.talken@...>
>Kopia: "Gramps Development List"<gramps-devel@...>
>Ärende: Re: [Gramps-devel] Re : preparing for 3.1.3
>
>Yes, bug introduced here:
>http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps31/src/ScratchPad.py?view=diff&r1=13168&r2=13169
>
>Peter, as you introduced this, you remember why? As said in other
>parts, notes should already be unicode, so no need to convert them. I
>would think these changed lines may be removed. They don't harm
>however.
>
>Jerome, do your patch with value for now.
>
>Benny
>
>2009/12/3 jerome <romjerome@...>:
>> or should be something like :
>>
>> #String must be unicode for truncation to work for non ascii characters
>> - note = unicode(note)
>> + value = unicode(value)
>> note = value.get().replace('\n', ' ')
>>
>>
>> --- En date de : Jeu 3.12.09, jerome <romjerome@...> a écrit :
>>
>>> De: jerome <romjerome@...>
>>> Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
>>> À: "Benny Malengier" <benny.malengier@...>
>>> Cc: "Gramps Development List" <gramps-devel@...>
>>> Date: Jeudi 3 Décembre 2009, 18h44
>>> /!\ there is an unfixed bug/crash on
>>> 3.1.3-SVN :
>>>
>>> 116251: ERROR: gramps.py: line 160: Unhandled exception
>>> Traceback (most recent call last):
>>> File "src/ScratchPad.py", line 1137, in
>>> object_drag_data_received
>>> o = wrapper_class(self.dbstate,sel_data)
>>> File "src/ScratchPad.py", line 327, in __init__
>>> note = unicode(note)
>>> UnboundLocalError: local variable 'note' referenced before
>>> assignment
>>>
>>> patch should be easy :
>>>
>>> #String must be unicode for
>>> truncation to work for non ascii characters
>>> - note = unicode(note)
>>> note =
>>> value.get().replace('\n', ' ')
>>> + note = unicode(note)
>>>
>>> To reproduce it :
>>>
>>> 1. Go on Note View
>>> 2. Try to drag and drop a note oject reference from
>>> NoteView to clipboard
>>>
>>>
>>> Should I commit change ?
>>>
>>>
>>>
>>> --- En date de : Jeu 3.12.09, Jérôme <romjerome@...>
>>> a écrit :
>>>
>>> > De: Jérôme <romjerome@...>
>>> > Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
>>> > À: "Benny Malengier" <benny.malengier@...>
>>> > Cc: "Gramps Development List" <gramps-devel@...>
>>> > Date: Jeudi 3 Décembre 2009, 17h28
>>> > Benny,
>>> >
>>> > >>> 2. On source reference (repository):
>>> > >>> 2 CALN
>>> > >>> 3 MEDI Book
>>> > >>> will be a custom translated media type
>>> on
>>> > export
>>> > >>> 2 CALN
>>> > >>> 3 MEDI Livre
>>> > >>>
>>> > >>> I suppose there is no error because I do
>>> not
>>> > loose data, but it is strange !
>>> > >>
>>> > >> Ok, I'll look at that, make a bug ticket (or
>>> > reopen the previous one.
>>> > >> The old code ignored MEDI tag, I suppose the
>>> new
>>> > code will write it
>>> > >> out but not in English, it should be easy to
>>> adapt
>>> > the writegedcom for
>>> > >> this, other types already write out the
>>> english
>>> > version (probably). Or
>>> > >> are other types also written out in French?
>>> It
>>> > would make some sense,
>>> > >> GEDCOM programs need not know that Book is
>>> Livre
>>> >
>>> > Looks like not a bug ...
>>> > I used Gramps without translations ($ python
>>> > src/gramps.py), and this
>>> > was already present on 3.1.2. There is no regression
>>> for
>>> > this on next
>>> > release.
>>> >
>>> > http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
>>> > http://www.gramps-project.org/bugs/view.php?id=3374>>> >
>>> > Code writes value (not tag) in english if you are
>>> using
>>> > Gramps in
>>> > English and translated value into french if you are
>>> using
>>> > Gramps in
>>> > French !
>>> >
>>> > On my 'localized' Gedcom, I get :
>>> >
>>> > 1 EVEN
>>> > 2 TYPE Mariage
>>> > 1 EVEN
>>> > 2 TYPE Élection
>>> > 1 EVEN
>>> > 2 TYPE Résidence
>>> > 2 CALN
>>> > 3 MEDI Livre
>>> >
>>> > which sounds correct with this custom data and after
>>> > looking at the
>>> > Gedcom header :
>>> >
>>> > 1 GEDC
>>> > 2 VERS 5.5
>>> > 2 FORM LINEAGE-LINKED
>>> > 1 CHAR UTF-8
>>> > 1 LANG French
>>> >
>>> > TAG do not use non-ASCII characters and values are
>>> custom
>>> > data.
>>> > So, I suppose that's not a bug !
>>> >
>>> > > Or are other types also written out in French?
>>> >
>>> > yes it is coherent, only custom or Gramps' types (not
>>> on
>>> > Gedcom spec)
>>> >
>>> > This kind of thing must be surely forget by the many
>>> tests
>>> > which check
>>> > Gedcom support... They look at custom tag (_CUSTOM)
>>> but not
>>> > on values
>>> > used into the program.
>>> >
>>> > It's really nice to have this international support !
>>> :)
>>> > (I say this now but maybe it was me who has grumbled
>>> at the
>>> > time and I
>>> > do not remember !!!)
>>> >
>>> >
>>> > Thanks !
>>> >
>>> > Jérôme
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Benny Malengier a écrit :
>>> > > 2009/11/24 jerome <romjerome@...>:
>>> > >>> Jerome, your mail is a bit confusing.
>>> > >> Sorry. I am testing Gedcom management
>>> changes.
>>> > >> First, I have tried to export a database
>>> (Family
>>> > Tree) to Gedcom format, but a dialog pops-up something
>>> like
>>> > "Gramps cannot write /tmp/..." during write person
>>> process.
>>> > Gedcom was not properly generated and I ran repair DB
>>> tools
>>> > on my opened Family Tree. Then no more message and
>>> > Gramps-3.1.3 has generated a complete Gedcom.
>>> > >>
>>> > >> Looking at diff between the first one and
>>> the
>>> > second one.
>>> > >> I suppose the problem was just "around"
>>> CHANGE
>>> > TIME (as I know this has been improved on 3.1.3) and
>>> lines
>>> > "not written" on the broken gedcom could be :
>>> > >> 1 CHAN
>>> > >> 2 DATE 24 NOV 2009
>>> > >> 3 TIME 14:29:13
>>> > >>
>>> > >> Sorry, I cannot very well explain this :(
>>> > >> I suppose Gramps was not able to write 1
>>> CHAN, but
>>> > I cannot say : "Gramps is not able to write this",
>>> because
>>> > process freeze, no error or bug report dialog, just
>>> Gedcom
>>> > was not complete.
>>> > >>
>>> > >>> because old gramps wrote out french
>>> dates?
>>> > >> Do you think this could be an OS issue ?
>>> python
>>> > time module ?
>>> > >
>>> > > No, it should work ok, the old code was
>>> completely
>>> > ignoring CHAN
>>> > > group, the new code parses it correctly, and it
>>> is
>>> > written out
>>> > > correctly.
>>> > >>> For the second issue, is this a
>>> regression?
>>> > That is could Gramps 3.1.2 read
>>> > >> I will try to test it.
>>> > >>
>>> > >> But seems there is still many problems with
>>> Gedcom
>>> > management ...
>>> > >>
>>> > >> I am loosing some data by making a diff
>>> between :
>>> > >> a Gedcom generated by Gramps and a new one,
>>> > imported into a new Family Tree then exported.
>>> > >>
>>> > >> 1. dates with calendar, like :
>>> > >> 2 DATE @#DFRENCH R@ 24 VEND 12
>>> > >> are not properly imported by Gramps-3.1.3 and
>>> will
>>> > return a textual date :
>>> > >> 2 DATE 24 VEND 12
>>> > >
>>> > > This should have been like this in 3.1.2, it
>>> means the
>>> > Date module
>>> > > that reads it cannot read the @, make a bug
>>> ticket,
>>> > but I do not thing
>>> > > it is a regression.
>>> > >> 2. On source reference (repository):
>>> > >> 2 CALN
>>> > >> 3 MEDI Book
>>> > >> will be a custom translated media type on
>>> export
>>> > >> 2 CALN
>>> > >> 3 MEDI Livre
>>> > >>
>>> > >> I suppose there is no error because I do not
>>> loose
>>> > data, but it is strange !
>>> > >
>>> > > Ok, I'll look at that, make a bug ticket (or
>>> reopen
>>> > the previous one.
>>> > > The old code ignored MEDI tag, I suppose the new
>>> code
>>> > will write it
>>> > > out but not in English, it should be easy to
>>> adapt the
>>> > writegedcom for
>>> > > this, other types already write out the english
>>> > version (probably). Or
>>> > > are other types also written out in French? It
>>> would
>>> > make some sense,
>>> > > GEDCOM programs need not know that Book is Livre
>>> > >
>>> > >> 3. References on Media Objects are ignored
>>> on
>>> > export
>>> > >> I started with 662 references into my Family
>>> Tree
>>> > and after a Gedcom import into a new Family Tree, I
>>> kept 18,
>>> > which was not media object, only urls on person object
>>> !!!)
>>> > >>
>>> > >> I do not see any problem yet on Gramps XML
>>> > management, and maybe some of this issues has been
>>> already
>>> > reported. I remember something like "Gedcom generated
>>> by
>>> > Gramps imported into Gramps".
>>> > >>
>>> > >> I suppose "references on Media Objects" and
>>> the "1
>>> > OBJE
>>> > >> 2 FORM" (url on person) are related.
>>> > >
>>> > > This is the first I hear about this.
>>> > > I do not like coding in GEDCOM, I do not use it
>>> !!!
>>> > >
>>> > > Benny
>>> > >
>>> > >>
>>> > >> I will look at Gedcom regression.
>>> > >>
>>> > >>
>>> > >> Jérôme
>>> > >>
>>> > >>
>>> > >> --- En date de : Mar 24.11.09, Benny
>>> Malengier
>>> > <benny.malengier@...>
>>> > a écrit :
>>> > >>
>>> > >>> De: Benny Malengier <benny.malengier@...>
>>> > >>> Objet: Re: Re : preparing for 3.1.3
>>> > >>> À: "jerome" <romjerome@...>
>>> > >>> Cc: "Gramps Development List" <gramps-devel@....

net>,

>>> > "Stéphane Charette" <stephanecharette@...>
>>> > >>> Date: Mardi 24 Novembre 2009, 15h24
>>> > >>> Jerome, your mail is a bit
>>> > >>> confusing.
>>> > >>>
>>> > >>> Are you saying the old gedcom crashes now
>>> on
>>> > import because
>>> > >>> old gramps
>>> > >>> wrote out french dates? Or is there no
>>> problem
>>> > (I see no
>>> > >>> crash report
>>> > >>> in this mail)
>>> > >>>
>>> > >>> For the second issue, is this a
>>> regression?
>>> > That is could
>>> > >>> Gramps 3.1.2 read
>>> > >>>
>>> > >>>> 1 OBJE
>>> > >>>> 2 FORM URL
>>> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm>>> >
>>> Benny
>>> > >>>
>>> > >>> 2009/11/24 jerome <romjerome@...>:
>>> > >>>>> so we can prepare for 3.1.3.
>>> Could
>>> > >>>>> everyone test perhaps a GEDCOM
>>> and an
>>> > XML export
>>> > >>> of their
>>> > >>>>> data
>>> > >>>>> (filtered somehow), and then
>>> import
>>> > again in an
>>> > >>> empty tree.
>>> > >>>>> The last
>>> > >>>>> things changes are related to
>>> that,
>>> > and GEDCOM
>>> > >>> changes are
>>> > >>>>> sensitive.
>>> > >>>> I have started to test import from
>>> > Gramps-3.1.3 to
>>> > >>> Gramps-3.1.3
>>> > >>>> (Ubuntu 9.04, python 2.6)
>>> > >>>>
>>> > >>>> ///// 1 warning during Gramps
>>> > session ///////
>>> > >>>> (gramps.py:4609): CRITICAL **:
>>> > >>> murrine_style_draw_focus: assertion
>>> `height
>>> > >= -1'
>>> > >>> failed
>>> > >>>> ///// 1 problem on GEDCOM export
>>> ///////
>>> > >>>>
>>> > >>>> "Cannot write file ..." message on
>>> dialog
>>> > (on write
>>> > >>> persons)
>>> > >>>> Fixed after running rebuild 2nd
>>> indices
>>> > and "Check
>>> > >>> & Repair" tools. (no problem with
>>> Gramps
>>> > XML format)
>>> > >>>> Re-test is OK.
>>> > >>>> Pass without error by using :
>>> > >>>>
>>> > >>>> 1 CHAN
>>> > >>>> 2 DATE 24 NOV 2009
>>> > >>>> 3 TIME 14:29:13
>>> > >>>>
>>> > >>>> Looks like first test has blocked
>>> just
>>> > before "change
>>> > >>> time" on person object !
>>> > >>>> /!\ I used my testing database
>>> (generated
>>> > before new
>>> > >>> time management on Gedcom
>>> > >>>> ///// problem on GEDCOM import
>>> ///////
>>> > >>>>
>>> > >>>> WARNING .GedcomImport: Impossible
>>> > d'importer http://www.geneanet.org/contact.php3?source=bouly78
>>> > >>>> WARNING .GedcomImport: Impossible
>>> > d'importer http://www.geneanet.org/rgentner>>> > >>>> WARNING .

GedcomImport: Impossible
>>> > d'importer
>>> > >>>> WARNING .GedcomImport:
Impossible
>>> > d'importer
>>> > >>>>
WARNING .GedcomImport: Impossible
>>> > d'importer
>>> > >>>> WARNING .GedcomImport: Impossible
>>> > d'importer http://gw1.geneanet.org/index.php3?b=henriks>>> > >>>>
WARNING .GedcomImport: Impossible
>>> > d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan>>> > >>>>
WARNING .GedcomImport: Impossible
>>> > d'importer http://gw1.geneanet.org/index.php3?b=myriague>>> > >>>>
WARNING .GedcomImport: Impossible

>>> > d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm>>> >
>>>>
>>> > >>>> => Cannot import url
>>> > >>>>
>>> > >>>> was generated by Gramps-3.1.3 :
>>> > >>>>
>>> > >>>> 0 @I1802@ INDI
>>> > >>>> 1 NAME Florent /SCHMITT/
>>> > >>>> 2 GIVN Florent
>>> > >>>> 2 SURN SCHMITT
>>> > >>>> 1 SEX M
>>> > >>>> 1 OBJE
>>> > >>>> 2 FORM URL
>>> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>>> > >>>>
>>> > >>>> Now, I will try to see any diff on
>>> data
>>> > (Gedcom,
>>> > >>> Gramps XML)
>>> > >>>>
>>> > >>>>
>>> > >>>> Jérôme R.
>>> > >>>>
>>> > >>>>
>>> > >>>> --- En date de : Dim 22.11.09, Benny
>>> > Malengier <benny.malengier@...>
>>> > >>> a écrit :
>>> > >>>>> De: Benny Malengier <benny.malengier@...>
>>> > >>>>> Objet: preparing for 3.1.3
>>> > >>>>> À: "Gramps Development List"
>>> <gramps-devel@...>,
>>> > >>> "Jérôme" <romjerome@...>,
>>> > >>> "Stéphane Charette" <stephanecharette@...>
>>> > >>>>> Date: Dimanche 22 Novembre 2009,
>>> > 10h11
>>> > >>>>> All, the roadmap is now on
>>> > >>>>> 100%, so we can prepare for
>>> 3.1.3.
>>> > Could
>>> > >>>>> everyone test perhaps a GEDCOM
>>> and an
>>> > XML export
>>> > >>> of their
>>> > >>>>> data
>>> > >>>>> (filtered somehow), and then
>>> import
>>> > again in an
>>> > >>> empty tree.
>>> > >>>>> The last
>>> > >>>>> things changes are related to
>>> that,
>>> > and GEDCOM
>>> > >>> changes are
>>> > >>>>> sensitive.
>>> > >>>>>
>>> > >>>>> Jerome, can you check the po file
>>> is
>>> > up to date,
>>> > >>> perhaps
>>> > >>>>> send mail to
>>> > >>>>> translators with % completion of
>>> their
>>> > language
>>> > >>> as
>>> > >>>>> information?
>>> > >>>>>
>>> > >>>>> Stephane, do you have time
>>> somewhere
>>> > in the coming
>>> > >>> weeks to
>>> > >>>>> push out
>>> > >>>>> 3.1.3? I would like to see in
>>> the
>>> > release notes
>>> > >>> something
>>> > >>>>> in the line
>>> > >>>>> of 'While the Gramps developers
>>> are
>>> > working on a
>>> > >>> super 3.2
>>> > >>>>> release in
>>> > >>>>> a couple of months, they still
>>> had
>>> > time for a
>>> > >>> minor bug fix
>>> > >>>>> release.
>>> > >>>>>
>>> > >>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
>>> > >>>>> contains main content of this
>>> release.
>>> > I think the
>>> > >>> most
>>> > >>>>> striking:
>>> > >>>>>
>>> > >>>>> * the annoying tooltip

messages

>>> in
>>> > latest distro's
>>> > >>> are no
>>> > >>>>> longer present
>>> > >>>>> * some GEDCOM fixes (timestamp
>>> on
>>> > persons now
>>> > >>> kept, MEDI
>>> > >>>>> import, ...)
>>> > >>>>> * some data that was not present
>>> in
>>> > filtered data
>>> > >>> is now
>>> > >>>>> present
>>> > >>>>> (source page, ...)
>>> > >>>>> * windows / or \ paths in
>>> webreport
>>> > cleaned up
>>> > >>>>> * ...
>>> > >>>>>
>>> > >>>>> Benny
>>> > >>>>>
>>> > >>>>
>>> > >>>>
>>> > >>>>
>>> > >>
>>> > >>
>>> > >>
>>> > >
>>> >
>>> >
>>> >
>>>

------------------------------------------------------------------------------
>>> > Join us December 9, 2009 for the Red Hat Virtual
>>> > Experience,
>>> > a free event focused on virtualization and cloud
>>> computing.
>>> >
>>> > Attend in-depth sessions from your desk. Your couch.
>>> > Anywhere.
>>> > http://p.sf.net/sfu/redhat-sfdev2dev>>> >
_______________________________________________
>>> > Gramps-devel mailing list
>>> > Gramps-devel@lists.
sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/gramps-devel>>> >
>>>
>>>
>>>
>>>
>>>
------------------------------------------------------------------------------
>>> Join us December 9, 2009 for the Red Hat Virtual
>>> Experience,
>>> a free event focused on virtualization and cloud
computing.
>>>
>>> Attend in-depth sessions from your desk. Your couch.
>>> Anywhere.
>>> http://p.sf.net/sfu/redhat-sfdev2dev>>>
_______________________________________________
>>> Gramps-devel mailing list
>>> Gramps-devel@lists.
sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel>>>
>>
>>
>>
>>
>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

From forum: GRAMPS - Dev

Re: Loose Coupling?

2009-12-04T04:35:48Z

Benny,

Thanks for the feedback. This sounds exactly like the trade-offs
between "loose" and "strong" coupling.

On the one hand, we currently have exact control over what loads and
where items are placed because we use strongly coupling. On the other
hand, if we want loose coupling, we need to be able to solve those
issues without relying on coupling. I think we can get a good balance
between controlling some parts without having to specify in other
files too much detail.

What I would like to do is think about how this control could come
"bottom up" (in the plugin) rather than "top down" (in the code that
loads the plugin). That would allow new plugin types without having
strong coupling. (Or maybe you are right... just have a pre-specified
default order to get started).

I agree: the goal would be for the ordering of Views to be the same as
now, but would allow for future, new view types (and for the user to
be able to rearrange these).

I'll work on that...

-Doug

On Fri, Dec 4, 2009 at 5:39 AM, Benny Malengier
<benny.malengier@...> wrote:

> 2009/12/4 Doug Blank <doug.blank@...>:
>> Devs,
>>
>> One thing I have come to appreciate in working with Django is its
>> consistent use of the idea of "loose coupling". I wasn't real familiar
>> with the philosophy before, but when I began to understand it, I
>> realized that this is exactly one of the things that Gramps doesn't
>> have and has always bothered me. In fact, I would describe Gramps as
>> strongly coupled.
>>
>> The philosophy can be read about in detail in any number of places
>> (for example, [1]). In a word: "Coupling refers to the degree of
>> direct knowledge that one class has of another." Many people interpret
>> this also as "the degree of direct knowledge that one part of the code
>> has of another part." A good test of the idea is: how many files do
>> you have to edit in order to add new code?
>>
>> I am currently wrestling with this idea in working with the View
>> display code. Currently, we have a plugin category ID for every type
>> of view. But loose coupling would suggest that there is no need to
>> pre-specify these types; they could be discovered when we load the
>> plugins. (This is just an example of loose coupling, but the idea
>> could be used in many places throughout gramps).
>>
>> For example, say that I want to add a new kind of View... perhaps a
>> Data Entry view (let's call the view category "Certificates" and the
>> view "Census"). Currently, we would have to edit a number of files to
>> add the new view type to define and expose this. On the other hand,
>> loose coupling says: Gramps doesn't know about view types, and will
>> just define the views as needed. This seems to be a more Pythonic
>> approach, and makes extending a project much easier (there are no
>> additional files to find and edit).
>>
>> One downside is that you won't discover a misnamed View type until you
>> see that the view is showing up in the wrong place. But this would of
>> course be obvious the instant you run the code. Strongly coupled code
>> (like gramps currently is) might immediately give an error and crash
>> on a mislabeled view (or would just put it in the wrong category) but
>> would require knowledge about the view in multiple places.
>>
>> I'd like to advocate more loose coupling in gramps, but wonder if
>> there is resistance to this philosophy, and if so, why. Feedback
>> appreciated.
>
> Well, the code you refer to is like that because we want the user
> interface to look a certain way, and hence presets what can be
> possible, and presets the order in which views will be shown in the
> interface sidebar.
>
> If you don't need this control, that code can go out, and you have no
> more coupling, but I believe we need to guard how Gramps ends up
> looking without allowing for plugins to just create some sort of
> anarchy.
>
> So, it is the same as the preset order in the reports or tools menu.
> I think things are still logical:
> --> plugins/pluginreg.py knows how a gpr.py file defines a view plugin.
> --> because we preset the allowed categories, pluginreg.py also
> defines this and does not load plugins that are in unknown category
> --> gui/grampsgui.py has a function to obtain registered views, import
> the files, and order them as we want them for the gramps interface.
> --> gui/viewmanager.py uses the API of a generic view to drive the interface.
>
> I do not see much coupling here, just that we want some control you
> would rather have we do not have. It is easy to change the code to
> have some predefined categories of views, and then allow for extra
> categories behind that as defined in view plugins. We then would still
> have the desired control of the interface (show the views we want on
> startup in the order of Gramps). Feel free to change the code like
> that, so remove the MISC category, create a GRAMPLET category, and
> then allow plugins to register to unknown categories, which the
> interface code appends to the end of the viewcategories in the
> sidebar.
>
> Note that in the future we would want to add reordering views in the
> sidebar, so the control over how the views look like is something we
> want for the 'default-out-of-the-box' experience, not something that
> users would not be allowed to change (as they could in 3.1.x by
> changing the listing in the ini file).
>
> As an aside:
> 1/ I think it would be interesting if you offer in gramps-addons, a
> second gramplet view. So the user would download this (it would be
> only a gpr.py file) and then the gramplet category has two views in
> which gramplets can be shown
> 2/ I did not finish the changes yet. What still has to happen: the
> view menu must contain a configure option (like the toolbar icon which
> I would allow to hide via the preferences), or perhaps a configure
> menu with entry for each shown view. The view menu should also offer a
> way to switch to another view in the category for those cases the
> toolbar is not visible. The column order dialog would move into the
> view configuration.
>
> To come back to the original question, yes, loose coupling is a nice
> aim. However, in Gui code you will need some model class that controls
> the view, and you will also need API's that other classes then need to
> implement. Obviously, API changes lead to a host of changes that need
> to be done in other files, I see no way around that.
>
> Benny
>
>> -Doug
>>
>> [1] - http://en.wikipedia.org/wiki/Loose_coupling
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>

From forum: GRAMPS - Dev

Re: Loose Coupling?

2009-12-04T03:57:47Z

+1

On 12/3/09, Doug Blank <doug.blank@...> wrote:

> Devs,
>
> One thing I have come to appreciate in working with Django is its
> consistent use of the idea of "loose coupling". I wasn't real familiar
> with the philosophy before, but when I began to understand it, I
> realized that this is exactly one of the things that Gramps doesn't
> have and has always bothered me. In fact, I would describe Gramps as
> strongly coupled.
>
> The philosophy can be read about in detail in any number of places
> (for example, [1]). In a word: "Coupling refers to the degree of
> direct knowledge that one class has of another." Many people interpret
> this also as "the degree of direct knowledge that one part of the code
> has of another part." A good test of the idea is: how many files do
> you have to edit in order to add new code?
>
> I am currently wrestling with this idea in working with the View
> display code. Currently, we have a plugin category ID for every type
> of view. But loose coupling would suggest that there is no need to
> pre-specify these types; they could be discovered when we load the
> plugins. (This is just an example of loose coupling, but the idea
> could be used in many places throughout gramps).
>
> For example, say that I want to add a new kind of View... perhaps a
> Data Entry view (let's call the view category "Certificates" and the
> view "Census"). Currently, we would have to edit a number of files to
> add the new view type to define and expose this. On the other hand,
> loose coupling says: Gramps doesn't know about view types, and will
> just define the views as needed. This seems to be a more Pythonic
> approach, and makes extending a project much easier (there are no
> additional files to find and edit).
>
> One downside is that you won't discover a misnamed View type until you
> see that the view is showing up in the wrong place. But this would of
> course be obvious the instant you run the code. Strongly coupled code
> (like gramps currently is) might immediately give an error and crash
> on a mislabeled view (or would just put it in the wrong category) but
> would require knowledge about the view in multiple places.
>
> I'd like to advocate more loose coupling in gramps, but wonder if
> there is resistance to this philosophy, and if so, why. Feedback
> appreciated.
>
> -Doug
>
> [1] - http://en.wikipedia.org/wiki/Loose_coupling
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

--
Sent from my mobile device

Gerald Britton

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

From forum: GRAMPS - Dev

Re: Loose Coupling?

2009-12-04T02:39:46Z

2009/12/4 Doug Blank <doug.blank@...>:

Well, the code you refer to is like that because we want the user
interface to look a certain way, and hence presets what can be
possible, and presets the order in which views will be shown in the
interface sidebar.

If you don't need this control, that code can go out, and you have no
more coupling, but I believe we need to guard how Gramps ends up
looking without allowing for plugins to just create some sort of
anarchy.

So, it is the same as the preset order in the reports or tools menu.
I think things are still logical:
--> plugins/pluginreg.py knows how a gpr.py file defines a view plugin.
--> because we preset the allowed categories, pluginreg.py also
defines this and does not load plugins that are in unknown category
--> gui/grampsgui.py has a function to obtain registered views, import
the files, and order them as we want them for the gramps interface.
--> gui/viewmanager.py uses the API of a generic view to drive the interface.

I do not see much coupling here, just that we want some control you
would rather have we do not have. It is easy to change the code to
have some predefined categories of views, and then allow for extra
categories behind that as defined in view plugins. We then would still
have the desired control of the interface (show the views we want on
startup in the order of Gramps). Feel free to change the code like
that, so remove the MISC category, create a GRAMPLET category, and
then allow plugins to register to unknown categories, which the
interface code appends to the end of the viewcategories in the
sidebar.

Note that in the future we would want to add reordering views in the
sidebar, so the control over how the views look like is something we
want for the 'default-out-of-the-box' experience, not something that
users would not be allowed to change (as they could in 3.1.x by
changing the listing in the ini file).

As an aside:
1/ I think it would be interesting if you offer in gramps-addons, a
second gramplet view. So the user would download this (it would be
only a gpr.py file) and then the gramplet category has two views in
which gramplets can be shown
2/ I did not finish the changes yet. What still has to happen: the
view menu must contain a configure option (like the toolbar icon which
I would allow to hide via the preferences), or perhaps a configure
menu with entry for each shown view. The view menu should also offer a
way to switch to another view in the category for those cases the
toolbar is not visible. The column order dialog would move into the
view configuration.

To come back to the original question, yes, loose coupling is a nice
aim. However, in Gui code you will need some model class that controls
the view, and you will also need API's that other classes then need to
implement. Obviously, API changes lead to a host of changes that need
to be done in other files, I see no way around that.

Benny

> -Doug
>
> [1] - http://en.wikipedia.org/wiki/Loose_coupling
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T01:13:14Z

What about HtmlView class on GeoView ?
Serges is still fixing something, no ?

http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=13699

Benny Malengier a écrit :

> 2009/12/4 Stéphane Charette <stephanecharette@...>:
>> On Thu, Dec 3, 2009 at 23:14, jerome <romjerome@...> wrote:
>>>> Jerome, do your patch with value for now.
>>> I thought it was the right thing to do (keep Peter's improvement and use after the assignment), but I didn't test it ...
>>
>> Are we still on track for 3.1.3 on Sunday? Disclaimer: I'm on a
>> business trip and wont be flying home until Saturday, so I don't even
>> know if everything builds correctly and/or works as expected.
>>
>> Assuming I have a green light from at least some of the regular
>> contributors, I will put together the 3.1.3 release at some point on
>> Sunday.
>
> Yes, the bug jerome talks about is easy to fix.
>
> All other things I have looked at are not regressions compared to
> 3.1.2, so can wait.
>
> Benny
>
>
>> Stéphane
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T01:06:58Z

I suppose most active translators have already commit their files.

For the bug, I do not know what should be done (revert, commit a patch).

I did not see regression from 3.1.2 to 3.1.3 on Gedcom and XML
import/export with my database & configuration/preferences.

Looking at change log :
http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
some issues were specific and I did not test all modifications ...

I could try to test "make distcheck", then local compilation to look at
possible issues ! My "build/compile" distribution is not the most recent
(OpenSuse 10.3), but if I get a problem, this could be reported and
fixed before the end of the week.

Jérôme

Stéphane Charette a écrit :

> On Thu, Dec 3, 2009 at 23:14, jerome <romjerome@...> wrote:
>>> Jerome, do your patch with value for now.
>> I thought it was the right thing to do (keep Peter's improvement and use after the assignment), but I didn't test it ...
>
>
> Are we still on track for 3.1.3 on Sunday? Disclaimer: I'm on a
> business trip and wont be flying home until Saturday, so I don't even
> know if everything builds correctly and/or works as expected.
>
> Assuming I have a green light from at least some of the regular
> contributors, I will put together the 3.1.3 release at some point on
> Sunday.
>
> Stéphane
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T00:47:13Z

Peter, I now remember what this was about.
Can you fix this today in the Scratchpad code? You probably still have
your testcase.

> #String must be unicode for truncation to work for non ascii characters
> - note = unicode(note)
> note = value.get().replace('\n', ' ')
> + note = unicode(note)

I think should be correct, no? It wouds be better if the comment says:
#String must be unicode for slicing to work for non ascii characters
and still obtain unicode

Benny

2009/12/4 jerome <romjerome@...>:

>> Jerome, do your patch with value for now.
>
> I thought it was the right thing to do (keep Peter's improvement and use after the assignment), but I didn't test it ...
>
> 16663: ERROR: gramps.py: line 160: Unhandled exception
> Traceback (most recent call last):
> File "src/ScratchPad.py", line 1137, in object_drag_data_received
> o = wrapper_class(self.dbstate,sel_data)
> File "src/ScratchPad.py", line 328, in __init__
> note = value.get().replace('\n', ' ')
> AttributeError: 'unicode' object has no attribute 'get'
>
> value = self._db.get_note_from_handle(handle)
>
>
> #String must be unicode for truncation to work for non ascii characters
> - note = unicode(note)
> note = value.get().replace('\n', ' ')
> + note = unicode(note)

Yes, just revert to the old

>
> is working but looking at the comment I suppose it makes no real sense !
>
>
>
> --- En date de : Jeu 3.12.09, Benny Malengier <benny.malengier@...> a écrit :
>
>> De: Benny Malengier <benny.malengier@...>
>> Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
>> À: "jerome" <romjerome@...>, "Peter Landgren" <peter.talken@...>
>> Cc: "Gramps Development List" <gramps-devel@...>
>> Date: Jeudi 3 Décembre 2009, 22h12
>> Yes, bug introduced here:
>> http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps31/src/ScratchPad.py?view=diff&r1=13168&r2=13169
>>
>> Peter, as you introduced this, you remember why? As said in
>> other
>> parts, notes should already be unicode, so no need to
>> convert them. I
>> would think these changed lines may be removed. They don't
>> harm
>> however.
>>
>> Jerome, do your patch with value for now.
>>
>> Benny
>>
>> 2009/12/3 jerome <romjerome@...>:
>> > or should be something like :
>> >
>> > #String must be unicode for truncation to work for non
>> ascii characters
>> > - note = unicode(note)
>> > + value = unicode(value)
>> > note = value.get().replace('\n', ' ')
>> >
>> >
>> > --- En date de : Jeu 3.12.09, jerome <romjerome@...>
>> a écrit :
>> >
>> >> De: jerome <romjerome@...>
>> >> Objet: Re: [Gramps-devel] Re : preparing for
>> 3.1.3
>> >> À: "Benny Malengier" <benny.malengier@...>
>> >> Cc: "Gramps Development List" <gramps-devel@...>
>> >> Date: Jeudi 3 Décembre 2009, 18h44
>> >> /!\ there is an unfixed bug/crash on
>> >> 3.1.3-SVN :
>> >>
>> >> 116251: ERROR: gramps.py: line 160: Unhandled
>> exception
>> >> Traceback (most recent call last):
>> >> File "src/ScratchPad.py", line 1137, in
>> >> object_drag_data_received
>> >> o = wrapper_class(self.dbstate,sel_data)
>> >> File "src/ScratchPad.py", line 327, in
>> __init__
>> >> note = unicode(note)
>> >> UnboundLocalError: local variable 'note'
>> referenced before
>> >> assignment
>> >>
>> >> patch should be easy :
>> >>
>> >> #String must be unicode for
>> >> truncation to work for non ascii characters
>> >> - note = unicode(note)
>> >> note =
>> >> value.get().replace('\n', ' ')
>> >> + note = unicode(note)
>> >>
>> >> To reproduce it :
>> >>
>> >> 1. Go on Note View
>> >> 2. Try to drag and drop a note oject reference
>> from
>> >> NoteView to clipboard
>> >>
>> >>
>> >> Should I commit change ?
>> >>
>> >>
>> >>
>> >> --- En date de : Jeu 3.12.09, Jérôme <romjerome@...>
>> >> a écrit :
>> >>
>> >> > De: Jérôme <romjerome@...>
>> >> > Objet: Re: [Gramps-devel] Re : preparing for
>> 3.1.3
>> >> > À: "Benny Malengier" <benny.malengier@...>
>> >> > Cc: "Gramps Development List" <gramps-devel@...>
>> >> > Date: Jeudi 3 Décembre 2009, 17h28
>> >> > Benny,
>> >> >
>> >> > >>> 2. On source reference
>> (repository):
>> >> > >>> 2 CALN
>> >> > >>> 3 MEDI Book
>> >> > >>> will be a custom translated
>> media type
>> >> on
>> >> > export
>> >> > >>> 2 CALN
>> >> > >>> 3 MEDI Livre
>> >> > >>>
>> >> > >>> I suppose there is no error
>> because I do
>> >> not
>> >> > loose data, but it is strange !
>> >> > >>
>> >> > >> Ok, I'll look at that, make a bug
>> ticket (or
>> >> > reopen the previous one.
>> >> > >> The old code ignored MEDI tag, I
>> suppose the
>> >> new
>> >> > code will write it
>> >> > >> out but not in English, it should be
>> easy to
>> >> adapt
>> >> > the writegedcom for
>> >> > >> this, other types already write out
>> the
>> >> english
>> >> > version (probably). Or
>> >> > >> are other types also written out in
>> French?
>> >> It
>> >> > would make some sense,
>> >> > >> GEDCOM programs need not know that
>> Book is
>> >> Livre
>> >> >
>> >> > Looks like not a bug ...
>> >> > I used Gramps without translations ($ python
>> >> > src/gramps.py), and this
>> >> > was already present on 3.1.2. There is no
>> regression
>> >> for
>> >> > this on next
>> >> > release.
>> >> >
>> >> > http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
>> >> > http://www.gramps-project.org/bugs/view.php?id=3374
>> >> >
>> >> > Code writes value (not tag) in english if you
>> are
>> >> using
>> >> > Gramps in
>> >> > English and translated value into french if
>> you are
>> >> using
>> >> > Gramps in
>> >> > French !
>> >> >
>> >> > On my 'localized' Gedcom, I get :
>> >> >
>> >> > 1 EVEN
>> >> > 2 TYPE Mariage
>> >> > 1 EVEN
>> >> > 2 TYPE Élection
>> >> > 1 EVEN
>> >> > 2 TYPE Résidence
>> >> > 2 CALN
>> >> > 3 MEDI Livre
>> >> >
>> >> > which sounds correct with this custom data
>> and after
>> >> > looking at the
>> >> > Gedcom header :
>> >> >
>> >> > 1 GEDC
>> >> > 2 VERS 5.5
>> >> > 2 FORM LINEAGE-LINKED
>> >> > 1 CHAR UTF-8
>> >> > 1 LANG French
>> >> >
>> >> > TAG do not use non-ASCII characters and
>> values are
>> >> custom
>> >> > data.
>> >> > So, I suppose that's not a bug !
>> >> >
>> >> > > Or are other types also written out in
>> French?
>> >> >
>> >> > yes it is coherent, only custom or Gramps'
>> types (not
>> >> on
>> >> > Gedcom spec)
>> >> >
>> >> > This kind of thing must be surely forget by
>> the many
>> >> tests
>> >> > which check
>> >> > Gedcom support... They look at custom tag
>> (_CUSTOM)
>> >> but not
>> >> > on values
>> >> > used into the program.
>> >> >
>> >> > It's really nice to have this international
>> support !
>> >> :)
>> >> > (I say this now but maybe it was me who has
>> grumbled
>> >> at the
>> >> > time and I
>> >> > do not remember !!!)
>> >> >
>> >> >
>> >> > Thanks !
>> >> >
>> >> > Jérôme
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Benny Malengier a écrit :
>> >> > > 2009/11/24 jerome <romjerome@...>:
>> >> > >>> Jerome, your mail is a bit
>> confusing.
>> >> > >> Sorry. I am testing Gedcom
>> management
>> >> changes.
>> >> > >> First, I have tried to export a
>> database
>> >> (Family
>> >> > Tree) to Gedcom format, but a dialog pops-up
>> something
>> >> like
>> >> > "Gramps cannot write /tmp/..." during write
>> person
>> >> process.
>> >> > Gedcom was not properly generated and I ran
>> repair DB
>> >> tools
>> >> > on my opened Family Tree. Then no more
>> message and
>> >> > Gramps-3.1.3 has generated a complete
>> Gedcom.
>> >> > >>
>> >> > >> Looking at diff between the first
>> one and
>> >> the
>> >> > second one.
>> >> > >> I suppose the problem was just
>> "around"
>> >> CHANGE
>> >> > TIME (as I know this has been improved on
>> 3.1.3) and
>> >> lines
>> >> > "not written" on the broken gedcom could be
>> :
>> >> > >> 1 CHAN
>> >> > >> 2 DATE 24 NOV 2009
>> >> > >> 3 TIME 14:29:13
>> >> > >>
>> >> > >> Sorry, I cannot very well explain
>> this :(
>> >> > >> I suppose Gramps was not able to
>> write 1
>> >> CHAN, but
>> >> > I cannot say : "Gramps is not able to write
>> this",
>> >> because
>> >> > process freeze, no error or bug report
>> dialog, just
>> >> Gedcom
>> >> > was not complete.
>> >> > >>
>> >> > >>> because old gramps wrote out
>> french
>> >> dates?
>> >> > >> Do you think this could be an OS
>> issue ?
>> >> python
>> >> > time module ?
>> >> > >
>> >> > > No, it should work ok, the old code was
>> >> completely
>> >> > ignoring CHAN
>> >> > > group, the new code parses it correctly,
>> and it
>> >> is
>> >> > written out
>> >> > > correctly.
>> >> > >>> For the second issue, is this a
>> >> regression?
>> >> > That is could Gramps 3.1.2 read
>> >> > >> I will try to test it.
>> >> > >>
>> >> > >> But seems there is still many
>> problems with
>> >> Gedcom
>> >> > management ...
>> >> > >>
>> >> > >> I am loosing some data by making a
>> diff
>> >> between :
>> >> > >> a Gedcom generated by Gramps and a
>> new one,
>> >> > imported into a new Family Tree then
>> exported.
>> >> > >>
>> >> > >> 1. dates with calendar, like :
>> >> > >> 2 DATE @#DFRENCH R@ 24 VEND 12
>> >> > >> are not properly imported by
>> Gramps-3.1.3 and
>> >> will
>> >> > return a textual date :
>> >> > >> 2 DATE 24 VEND 12
>> >> > >
>> >> > > This should have been like this in
>> 3.1.2, it
>> >> means the
>> >> > Date module
>> >> > > that reads it cannot read the @, make a
>> bug
>> >> ticket,
>> >> > but I do not thing
>> >> > > it is a regression.
>> >> > >> 2. On source reference
>> (repository):
>> >> > >> 2 CALN
>> >> > >> 3 MEDI Book
>> >> > >> will be a custom translated media
>> type on
>> >> export
>> >> > >> 2 CALN
>> >> > >> 3 MEDI Livre
>> >> > >>
>> >> > >> I suppose there is no error because
>> I do not
>> >> loose
>> >> > data, but it is strange !
>> >> > >
>> >> > > Ok, I'll look at that, make a bug ticket
>> (or
>> >> reopen
>> >> > the previous one.
>> >> > > The old code ignored MEDI tag, I suppose
>> the new
>> >> code
>> >> > will write it
>> >> > > out but not in English, it should be
>> easy to
>> >> adapt the
>> >> > writegedcom for
>> >> > > this, other types already write out the
>> english
>> >> > version (probably). Or
>> >> > > are other types also written out in
>> French? It
>> >> would
>> >> > make some sense,
>> >> > > GEDCOM programs need not know that Book
>> is Livre
>> >> > >
>> >> > >> 3. References on Media Objects are
>> ignored
>> >> on
>> >> > export
>> >> > >> I started with 662 references into
>> my Family
>> >> Tree
>> >> > and after a Gedcom import into a new Family
>> Tree, I
>> >> kept 18,
>> >> > which was not media object, only urls on
>> person object
>> >> !!!)
>> >> > >>
>> >> > >> I do not see any problem yet on
>> Gramps XML
>> >> > management, and maybe some of this issues has
>> been
>> >> already
>> >> > reported. I remember something like "Gedcom
>> generated
>> >> by
>> >> > Gramps imported into Gramps".
>> >> > >>
>> >> > >> I suppose "references on Media
>> Objects" and
>> >> the "1
>> >> > OBJE
>> >> > >> 2 FORM" (url on person) are
>> related.
>> >> > >
>> >> > > This is the first I hear about this.
>> >> > > I do not like coding in GEDCOM, I do not
>> use it
>> >> !!!
>> >> > >
>> >> > > Benny
>> >> > >
>> >> > >>
>> >> > >> I will look at Gedcom regression.
>> >> > >>
>> >> > >>
>> >> > >> Jérôme
>> >> > >>
>> >> > >>
>> >> > >> --- En date de : Mar 24.11.09,
>> Benny
>> >> Malengier
>> >> > <benny.malengier@...>
>> >> > a écrit :
>> >> > >>
>> >> > >>> De: Benny Malengier <benny.malengier@...>
>> >> > >>> Objet: Re: Re : preparing for
>> 3.1.3
>> >> > >>> À: "jerome" <romjerome@...>
>> >> > >>> Cc: "Gramps Development List"
>> <gramps-devel@...>,
>> >> > "Stéphane Charette" <stephanecharette@...>
>> >> > >>> Date: Mardi 24 Novembre 2009,
>> 15h24
>> >> > >>> Jerome, your mail is a bit
>> >> > >>> confusing.
>> >> > >>>
>> >> > >>> Are you saying the old gedcom
>> crashes now
>> >> on
>> >> > import because
>> >> > >>> old gramps
>> >> > >>> wrote out french dates? Or is
>> there no
>> >> problem
>> >> > (I see no
>> >> > >>> crash report
>> >> > >>> in this mail)
>> >> > >>>
>> >> > >>> For the second issue, is this a
>> >> regression?
>> >> > That is could
>> >> > >>> Gramps 3.1.2 read
>> >> > >>>
>> >> > >>>> 1 OBJE
>> >> > >>>> 2 FORM URL
>> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>> >> > >>> Benny
>> >> > >>>
>> >> > >>> 2009/11/24 jerome <romjerome@...>:
>> >> > >>>>> so we can prepare for
>> 3.1.3.
>> >> Could
>> >> > >>>>> everyone test perhaps a
>> GEDCOM
>> >> and an
>> >> > XML export
>> >> > >>> of their
>> >> > >>>>> data
>> >> > >>>>> (filtered somehow), and
>> then
>> >> import
>> >> > again in an
>> >> > >>> empty tree.
>> >> > >>>>> The last
>> >> > >>>>> things changes are
>> related to
>> >> that,
>> >> > and GEDCOM
>> >> > >>> changes are
>> >> > >>>>> sensitive.
>> >> > >>>> I have started to test
>> import from
>> >> > Gramps-3.1.3 to
>> >> > >>> Gramps-3.1.3
>> >> > >>>> (Ubuntu 9.04, python 2.6)
>> >> > >>>>
>> >> > >>>> ///// 1 warning during
>> Gramps
>> >> > session ///////
>> >> > >>>> (gramps.py:4609): CRITICAL
>> **:
>> >> > >>> murrine_style_draw_focus:
>> assertion
>> >> `height
>> >> > >= -1'
>> >> > >>> failed
>> >> > >>>> ///// 1 problem on GEDCOM
>> export
>> >> ///////
>> >> > >>>>
>> >> > >>>> "Cannot write file ..."
>> message on
>> >> dialog
>> >> > (on write
>> >> > >>> persons)
>> >> > >>>> Fixed after running rebuild
>> 2nd
>> >> indices
>> >> > and "Check
>> >> > >>> & Repair" tools. (no problem
>> with
>> >> Gramps
>> >> > XML format)
>> >> > >>>> Re-test is OK.
>> >> > >>>> Pass without error by using
>> :
>> >> > >>>>
>> >> > >>>> 1 CHAN
>> >> > >>>> 2 DATE 24 NOV 2009
>> >> > >>>> 3 TIME 14:29:13
>> >> > >>>>
>> >> > >>>> Looks like first test has
>> blocked
>> >> just
>> >> > before "change
>> >> > >>> time" on person object !
>> >> > >>>> /!\ I used my testing
>> database
>> >> (generated
>> >> > before new
>> >> > >>> time management on Gedcom
>> >> > >>>> ///// problem on GEDCOM
>> import
>> >> ///////
>> >> > >>>>
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer http://www.geneanet.org/contact.php3?source=bouly78
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer http://www.geneanet.org/rgentner
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer http://gw1.geneanet.org/index.php3?b=henriks
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer http://gw1.geneanet.org/index.php3?b=myriague
>> >> > >>>> WARNING .GedcomImport:
>> Impossible
>> >> > d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
>> >> > >>>>
>> >> > >>>> => Cannot import url
>> >> > >>>>
>> >> > >>>> was generated by
>> Gramps-3.1.3 :
>> >> > >>>>
>> >> > >>>> 0 @I1802@ INDI
>> >> > >>>> 1 NAME Florent /SCHMITT/
>> >> > >>>> 2 GIVN Florent
>> >> > >>>> 2 SURN SCHMITT
>> >> > >>>> 1 SEX M
>> >> > >>>> 1 OBJE
>> >> > >>>> 2 FORM URL
>> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>> >> > >>>>
>> >> > >>>> Now, I will try to see any
>> diff on
>> >> data
>> >> > (Gedcom,
>> >> > >>> Gramps XML)
>> >> > >>>>
>> >> > >>>>
>> >> > >>>> Jérôme R.
>> >> > >>>>
>> >> > >>>>
>> >> > >>>> --- En date de : Dim
>> 22.11.09, Benny
>> >> > Malengier <benny.malengier@...>
>> >> > >>> a écrit :
>> >> > >>>>> De: Benny Malengier
>> <benny.malengier@...>
>> >> > >>>>> Objet: preparing for
>> 3.1.3
>> >> > >>>>> À: "Gramps Development
>> List"
>> >> <gramps-devel@...>,
>> >> > >>> "Jérôme" <romjerome@...>,
>> >> > >>> "Stéphane Charette" <stephanecharette@...>
>> >> > >>>>> Date: Dimanche 22
>> Novembre 2009,
>> >> > 10h11
>> >> > >>>>> All, the roadmap is
>> now on
>> >> > >>>>> 100%, so we can prepare
>> for
>> >> 3.1.3.
>> >> > Could
>> >> > >>>>> everyone test perhaps a
>> GEDCOM
>> >> and an
>> >> > XML export
>> >> > >>> of their
>> >> > >>>>> data
>> >> > >>>>> (filtered somehow), and
>> then
>> >> import
>> >> > again in an
>> >> > >>> empty tree.
>> >> > >>>>> The last
>> >> > >>>>> things changes are
>> related to
>> >> that,
>> >> > and GEDCOM
>> >> > >>> changes are
>> >> > >>>>> sensitive.
>> >> > >>>>>
>> >> > >>>>> Jerome, can you check
>> the po file
>> >> is
>> >> > up to date,
>> >> > >>> perhaps
>> >> > >>>>> send mail to
>> >> > >>>>> translators with %
>> completion of
>> >> their
>> >> > language
>> >> > >>> as
>> >> > >>>>> information?
>> >> > >>>>>
>> >> > >>>>> Stephane, do you have
>> time
>> >> somewhere
>> >> > in the coming
>> >> > >>> weeks to
>> >> > >>>>> push out
>> >> > >>>>> 3.1.3? I would like to
>> see in
>> >> the
>> >> > release notes
>> >> > >>> something
>> >> > >>>>> in the line
>> >> > >>>>> of 'While the Gramps
>> developers
>> >> are
>> >> > working on a
>> >> > >>> super 3.2
>> >> > >>>>> release in
>> >> > >>>>> a couple of months, they
>> still
>> >> had
>> >> > time for a
>> >> > >>> minor bug fix
>> >> > >>>>> release.
>> >> > >>>>>
>> >> > >>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
>> >> > >>>>> contains main content of
>> this
>> >> release.
>> >> > I think the
>> >> > >>> most
>> >> > >>>>> striking:
>> >> > >>>>>
>> >> > >>>>> * the annoying tooltip
>> messages
>> >> in
>> >> > latest distro's
>> >> > >>> are no
>> >> > >>>>> longer present
>> >> > >>>>> * some GEDCOM fixes
>> (timestamp
>> >> on
>> >> > persons now
>> >> > >>> kept, MEDI
>> >> > >>>>> import, ...)
>> >> > >>>>> * some data that was not
>> present
>> >> in
>> >> > filtered data
>> >> > >>> is now
>> >> > >>>>> present
>> >> > >>>>> (source page, ...)
>> >> > >>>>> * windows / or \ paths
>> in
>> >> webreport
>> >> > cleaned up
>> >> > >>>>> * ...
>> >> > >>>>>
>> >> > >>>>> Benny
>> >> > >>>>>
>> >> > >>>>
>> >> > >>>>
>> >> > >>>>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >
>> >> >
>> >> >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > Join us December 9, 2009 for the Red Hat
>> Virtual
>> >> > Experience,
>> >> > a free event focused on virtualization and
>> cloud
>> >> computing.
>> >> >
>> >> > Attend in-depth sessions from your desk. Your
>> couch.
>> >> > Anywhere.
>> >> > http://p.sf.net/sfu/redhat-sfdev2dev
>> >> >
>> _______________________________________________
>> >> > Gramps-devel mailing list
>> >> > Gramps-devel@...
>> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> Join us December 9, 2009 for the Red Hat Virtual
>> >> Experience,
>> >> a free event focused on virtualization and cloud
>> computing.
>> >>
>> >> Attend in-depth sessions from your desk. Your
>> couch.
>> >> Anywhere.
>> >> http://p.sf.net/sfu/redhat-sfdev2dev
>> >> _______________________________________________
>> >> Gramps-devel mailing list
>> >> Gramps-devel@...
>> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>> >>
>> >
>> >
>> >
>> >
>>
>
>
>
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T00:43:51Z

2009/12/4 Stéphane Charette <stephanecharette@...>:

> On Thu, Dec 3, 2009 at 23:14, jerome <romjerome@...> wrote:
>>> Jerome, do your patch with value for now.
>>
>> I thought it was the right thing to do (keep Peter's improvement and use after the assignment), but I didn't test it ...
>
>
> Are we still on track for 3.1.3 on Sunday? Disclaimer: I'm on a
> business trip and wont be flying home until Saturday, so I don't even
> know if everything builds correctly and/or works as expected.
>
> Assuming I have a green light from at least some of the regular
> contributors, I will put together the 3.1.3 release at some point on
> Sunday.

Yes, the bug jerome talks about is easy to fix.

All other things I have looked at are not regressions compared to
3.1.2, so can wait.

Benny

>
> Stéphane
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-04T00:25:23Z

On Thu, Dec 3, 2009 at 23:14, jerome <romjerome@...> wrote:
>> Jerome, do your patch with value for now.
>
> I thought it was the right thing to do (keep Peter's improvement and use after the assignment), but I didn't test it ...

Are we still on track for 3.1.3 on Sunday? Disclaimer: I'm on a
business trip and wont be flying home until Saturday, so I don't even
know if everything builds correctly and/or works as expected.

Assuming I have a green light from at least some of the regular
contributors, I will put together the 3.1.3 release at some point on
Sunday.

Stéphane

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-03T23:14:26Z

> Jerome, do your patch with value for now.

I thought it was the right thing to do (keep Peter's improvement and use after the assignment), but I didn't test it ...

16663: ERROR: gramps.py: line 160: Unhandled exception
Traceback (most recent call last):
File "src/ScratchPad.py", line 1137, in object_drag_data_received
o = wrapper_class(self.dbstate,sel_data)
File "src/ScratchPad.py", line 328, in __init__
note = value.get().replace('\n', ' ')
AttributeError: 'unicode' object has no attribute 'get'

value = self._db.get_note_from_handle(handle)

#String must be unicode for truncation to work for non ascii characters
- note = unicode(note)
note = value.get().replace('\n', ' ')
+ note = unicode(note)

is working but looking at the comment I suppose it makes no real sense !

--- En date de : Jeu 3.12.09, Benny Malengier <benny.malengier@...> a écrit :

> De: Benny Malengier <benny.malengier@...>
> Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
> À: "jerome" <romjerome@...>, "Peter Landgren" <peter.talken@...>
> Cc: "Gramps Development List" <gramps-devel@...>
> Date: Jeudi 3 Décembre 2009, 22h12
> Yes, bug introduced here:
> http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps31/src/ScratchPad.py?view=diff&r1=13168&r2=13169
>
> Peter, as you introduced this, you remember why? As said in
> other
> parts, notes should already be unicode, so no need to
> convert them. I
> would think these changed lines may be removed. They don't
> harm
> however.
>
> Jerome, do your patch with value for now.
>
> Benny
>
> 2009/12/3 jerome <romjerome@...>:
> > or should be something like :
> >
> > #String must be unicode for truncation to work for non
> ascii characters
> > - note = unicode(note)
> > + value = unicode(value)
> > note = value.get().replace('\n', ' ')
> >
> >
> > --- En date de : Jeu 3.12.09, jerome <romjerome@...>
> a écrit :
> >
> >> De: jerome <romjerome@...>
> >> Objet: Re: [Gramps-devel] Re : preparing for
> 3.1.3
> >> À: "Benny Malengier" <benny.malengier@...>
> >> Cc: "Gramps Development List" <gramps-devel@...>
> >> Date: Jeudi 3 Décembre 2009, 18h44
> >> /!\ there is an unfixed bug/crash on
> >> 3.1.3-SVN :
> >>
> >> 116251: ERROR: gramps.py: line 160: Unhandled
> exception
> >> Traceback (most recent call last):
> >> File "src/ScratchPad.py", line 1137, in
> >> object_drag_data_received
> >> o = wrapper_class(self.dbstate,sel_data)
> >> File "src/ScratchPad.py", line 327, in
> __init__
> >> note = unicode(note)
> >> UnboundLocalError: local variable 'note'
> referenced before
> >> assignment
> >>
> >> patch should be easy :
> >>
> >> #String must be unicode for
> >> truncation to work for non ascii characters
> >> - note = unicode(note)
> >> note =
> >> value.get().replace('\n', ' ')
> >> + note = unicode(note)
> >>
> >> To reproduce it :
> >>
> >> 1. Go on Note View
> >> 2. Try to drag and drop a note oject reference
> from
> >> NoteView to clipboard
> >>
> >>
> >> Should I commit change ?
> >>
> >>
> >>
> >> --- En date de : Jeu 3.12.09, Jérôme <romjerome@...>
> >> a écrit :
> >>
> >> > De: Jérôme <romjerome@...>
> >> > Objet: Re: [Gramps-devel] Re : preparing for
> 3.1.3
> >> > À: "Benny Malengier" <benny.malengier@...>
> >> > Cc: "Gramps Development List" <gramps-devel@...>
> >> > Date: Jeudi 3 Décembre 2009, 17h28
> >> > Benny,
> >> >
> >> > >>> 2. On source reference
> (repository):
> >> > >>> 2 CALN
> >> > >>> 3 MEDI Book
> >> > >>> will be a custom translated
> media type
> >> on
> >> > export
> >> > >>> 2 CALN
> >> > >>> 3 MEDI Livre
> >> > >>>
> >> > >>> I suppose there is no error
> because I do
> >> not
> >> > loose data, but it is strange !
> >> > >>
> >> > >> Ok, I'll look at that, make a bug
> ticket (or
> >> > reopen the previous one.
> >> > >> The old code ignored MEDI tag, I
> suppose the
> >> new
> >> > code will write it
> >> > >> out but not in English, it should be
> easy to
> >> adapt
> >> > the writegedcom for
> >> > >> this, other types already write out
> the
> >> english
> >> > version (probably). Or
> >> > >> are other types also written out in
> French?
> >> It
> >> > would make some sense,
> >> > >> GEDCOM programs need not know that
> Book is
> >> Livre
> >> >
> >> > Looks like not a bug ...
> >> > I used Gramps without translations ($ python
> >> > src/gramps.py), and this
> >> > was already present on 3.1.2. There is no
> regression
> >> for
> >> > this on next
> >> > release.
> >> >
> >> > http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
> >> > http://www.gramps-project.org/bugs/view.php?id=3374
> >> >
> >> > Code writes value (not tag) in english if you
> are
> >> using
> >> > Gramps in
> >> > English and translated value into french if
> you are
> >> using
> >> > Gramps in
> >> > French !
> >> >
> >> > On my 'localized' Gedcom, I get :
> >> >
> >> > 1 EVEN
> >> > 2 TYPE Mariage
> >> > 1 EVEN
> >> > 2 TYPE Élection
> >> > 1 EVEN
> >> > 2 TYPE Résidence
> >> > 2 CALN
> >> > 3 MEDI Livre
> >> >
> >> > which sounds correct with this custom data
> and after
> >> > looking at the
> >> > Gedcom header :
> >> >
> >> > 1 GEDC
> >> > 2 VERS 5.5
> >> > 2 FORM LINEAGE-LINKED
> >> > 1 CHAR UTF-8
> >> > 1 LANG French
> >> >
> >> > TAG do not use non-ASCII characters and
> values are
> >> custom
> >> > data.
> >> > So, I suppose that's not a bug !
> >> >
> >> > > Or are other types also written out in
> French?
> >> >
> >> > yes it is coherent, only custom or Gramps'
> types (not
> >> on
> >> > Gedcom spec)
> >> >
> >> > This kind of thing must be surely forget by
> the many
> >> tests
> >> > which check
> >> > Gedcom support... They look at custom tag
> (_CUSTOM)
> >> but not
> >> > on values
> >> > used into the program.
> >> >
> >> > It's really nice to have this international
> support !
> >> :)
> >> > (I say this now but maybe it was me who has
> grumbled
> >> at the
> >> > time and I
> >> > do not remember !!!)
> >> >
> >> >
> >> > Thanks !
> >> >
> >> > Jérôme
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Benny Malengier a écrit :
> >> > > 2009/11/24 jerome <romjerome@...>:
> >> > >>> Jerome, your mail is a bit
> confusing.
> >> > >> Sorry. I am testing Gedcom
> management
> >> changes.
> >> > >> First, I have tried to export a
> database
> >> (Family
> >> > Tree) to Gedcom format, but a dialog pops-up
> something
> >> like
> >> > "Gramps cannot write /tmp/..." during write
> person
> >> process.
> >> > Gedcom was not properly generated and I ran
> repair DB
> >> tools
> >> > on my opened Family Tree. Then no more
> message and
> >> > Gramps-3.1.3 has generated a complete
> Gedcom.
> >> > >>
> >> > >> Looking at diff between the first
> one and
> >> the
> >> > second one.
> >> > >> I suppose the problem was just
> "around"
> >> CHANGE
> >> > TIME (as I know this has been improved on
> 3.1.3) and
> >> lines
> >> > "not written" on the broken gedcom could be
> :
> >> > >> 1 CHAN
> >> > >> 2 DATE 24 NOV 2009
> >> > >> 3 TIME 14:29:13
> >> > >>
> >> > >> Sorry, I cannot very well explain
> this :(
> >> > >> I suppose Gramps was not able to
> write 1
> >> CHAN, but
> >> > I cannot say : "Gramps is not able to write
> this",
> >> because
> >> > process freeze, no error or bug report
> dialog, just
> >> Gedcom
> >> > was not complete.
> >> > >>
> >> > >>> because old gramps wrote out
> french
> >> dates?
> >> > >> Do you think this could be an OS
> issue ?
> >> python
> >> > time module ?
> >> > >
> >> > > No, it should work ok, the old code was
> >> completely
> >> > ignoring CHAN
> >> > > group, the new code parses it correctly,
> and it
> >> is
> >> > written out
> >> > > correctly.
> >> > >>> For the second issue, is this a
> >> regression?
> >> > That is could Gramps 3.1.2 read
> >> > >> I will try to test it.
> >> > >>
> >> > >> But seems there is still many
> problems with
> >> Gedcom
> >> > management ...
> >> > >>
> >> > >> I am loosing some data by making a
> diff
> >> between :
> >> > >> a Gedcom generated by Gramps and a
> new one,
> >> > imported into a new Family Tree then
> exported.
> >> > >>
> >> > >> 1. dates with calendar, like :
> >> > >> 2 DATE @#DFRENCH R@ 24 VEND 12
> >> > >> are not properly imported by
> Gramps-3.1.3 and
> >> will
> >> > return a textual date :
> >> > >> 2 DATE 24 VEND 12
> >> > >
> >> > > This should have been like this in
> 3.1.2, it
> >> means the
> >> > Date module
> >> > > that reads it cannot read the @, make a
> bug
> >> ticket,
> >> > but I do not thing
> >> > > it is a regression.
> >> > >> 2. On source reference
> (repository):
> >> > >> 2 CALN
> >> > >> 3 MEDI Book
> >> > >> will be a custom translated media
> type on
> >> export
> >> > >> 2 CALN
> >> > >> 3 MEDI Livre
> >> > >>
> >> > >> I suppose there is no error because
> I do not
> >> loose
> >> > data, but it is strange !
> >> > >
> >> > > Ok, I'll look at that, make a bug ticket
> (or
> >> reopen
> >> > the previous one.
> >> > > The old code ignored MEDI tag, I suppose
> the new
> >> code
> >> > will write it
> >> > > out but not in English, it should be
> easy to
> >> adapt the
> >> > writegedcom for
> >> > > this, other types already write out the
> english
> >> > version (probably). Or
> >> > > are other types also written out in
> French? It
> >> would
> >> > make some sense,
> >> > > GEDCOM programs need not know that Book
> is Livre
> >> > >
> >> > >> 3. References on Media Objects are
> ignored
> >> on
> >> > export
> >> > >> I started with 662 references into
> my Family
> >> Tree
> >> > and after a Gedcom import into a new Family
> Tree, I
> >> kept 18,
> >> > which was not media object, only urls on
> person object
> >> !!!)
> >> > >>
> >> > >> I do not see any problem yet on
> Gramps XML
> >> > management, and maybe some of this issues has
> been
> >> already
> >> > reported. I remember something like "Gedcom
> generated
> >> by
> >> > Gramps imported into Gramps".
> >> > >>
> >> > >> I suppose "references on Media
> Objects" and
> >> the "1
> >> > OBJE
> >> > >> 2 FORM" (url on person) are
> related.
> >> > >
> >> > > This is the first I hear about this.
> >> > > I do not like coding in GEDCOM, I do not
> use it
> >> !!!
> >> > >
> >> > > Benny
> >> > >
> >> > >>
> >> > >> I will look at Gedcom regression.
> >> > >>
> >> > >>
> >> > >> Jérôme
> >> > >>
> >> > >>
> >> > >> --- En date de : Mar 24.11.09,
> Benny
> >> Malengier
> >> > <benny.malengier@...>
> >> > a écrit :
> >> > >>
> >> > >>> De: Benny Malengier <benny.malengier@...>
> >> > >>> Objet: Re: Re : preparing for
> 3.1.3
> >> > >>> À: "jerome" <romjerome@...>
> >> > >>> Cc: "Gramps Development List"
> <gramps-devel@...>,
> >> > "Stéphane Charette" <stephanecharette@...>
> >> > >>> Date: Mardi 24 Novembre 2009,
> 15h24
> >> > >>> Jerome, your mail is a bit
> >> > >>> confusing.
> >> > >>>
> >> > >>> Are you saying the old gedcom
> crashes now
> >> on
> >> > import because
> >> > >>> old gramps
> >> > >>> wrote out french dates? Or is
> there no
> >> problem
> >> > (I see no
> >> > >>> crash report
> >> > >>> in this mail)
> >> > >>>
> >> > >>> For the second issue, is this a
> >> regression?
> >> > That is could
> >> > >>> Gramps 3.1.2 read
> >> > >>>
> >> > >>>> 1 OBJE
> >> > >>>> 2 FORM URL
> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
> >> > >>> Benny
> >> > >>>
> >> > >>> 2009/11/24 jerome <romjerome@...>:
> >> > >>>>> so we can prepare for
> 3.1.3.
> >> Could
> >> > >>>>> everyone test perhaps a
> GEDCOM
> >> and an
> >> > XML export
> >> > >>> of their
> >> > >>>>> data
> >> > >>>>> (filtered somehow), and
> then
> >> import
> >> > again in an
> >> > >>> empty tree.
> >> > >>>>> The last
> >> > >>>>> things changes are
> related to
> >> that,
> >> > and GEDCOM
> >> > >>> changes are
> >> > >>>>> sensitive.
> >> > >>>> I have started to test
> import from
> >> > Gramps-3.1.3 to
> >> > >>> Gramps-3.1.3
> >> > >>>> (Ubuntu 9.04, python 2.6)
> >> > >>>>
> >> > >>>> ///// 1 warning during
> Gramps
> >> > session ///////
> >> > >>>> (gramps.py:4609): CRITICAL
> **:
> >> > >>> murrine_style_draw_focus:
> assertion
> >> `height
> >> > >= -1'
> >> > >>> failed
> >> > >>>> ///// 1 problem on GEDCOM
> export
> >> ///////
> >> > >>>>
> >> > >>>> "Cannot write file ..."
> message on
> >> dialog
> >> > (on write
> >> > >>> persons)
> >> > >>>> Fixed after running rebuild
> 2nd
> >> indices
> >> > and "Check
> >> > >>> & Repair" tools. (no problem
> with
> >> Gramps
> >> > XML format)
> >> > >>>> Re-test is OK.
> >> > >>>> Pass without error by using
> :
> >> > >>>>
> >> > >>>> 1 CHAN
> >> > >>>> 2 DATE 24 NOV 2009
> >> > >>>> 3 TIME 14:29:13
> >> > >>>>
> >> > >>>> Looks like first test has
> blocked
> >> just
> >> > before "change
> >> > >>> time" on person object !
> >> > >>>> /!\ I used my testing
> database
> >> (generated
> >> > before new
> >> > >>> time management on Gedcom
> >> > >>>> ///// problem on GEDCOM
> import
> >> ///////
> >> > >>>>
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer http://www.geneanet.org/contact.php3?source=bouly78
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer http://www.geneanet.org/rgentner
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer http://gw1.geneanet.org/index.php3?b=henriks
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer http://gw1.geneanet.org/index.php3?b=myriague
> >> > >>>> WARNING .GedcomImport:
> Impossible
> >> > d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
> >> > >>>>
> >> > >>>> => Cannot import url
> >> > >>>>
> >> > >>>> was generated by
> Gramps-3.1.3 :
> >> > >>>>
> >> > >>>> 0 @I1802@ INDI
> >> > >>>> 1 NAME Florent /SCHMITT/
> >> > >>>> 2 GIVN Florent
> >> > >>>> 2 SURN SCHMITT
> >> > >>>> 1 SEX M
> >> > >>>> 1 OBJE
> >> > >>>> 2 FORM URL
> >> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
> >> > >>>>
> >> > >>>> Now, I will try to see any
> diff on
> >> data
> >> > (Gedcom,
> >> > >>> Gramps XML)
> >> > >>>>
> >> > >>>>
> >> > >>>> Jérôme R.
> >> > >>>>
> >> > >>>>
> >> > >>>> --- En date de : Dim
> 22.11.09, Benny
> >> > Malengier <benny.malengier@...>
> >> > >>> a écrit :
> >> > >>>>> De: Benny Malengier
> <benny.malengier@...>
> >> > >>>>> Objet: preparing for
> 3.1.3
> >> > >>>>> À: "Gramps Development
> List"
> >> <gramps-devel@...>,
> >> > >>> "Jérôme" <romjerome@...>,
> >> > >>> "Stéphane Charette" <stephanecharette@...>
> >> > >>>>> Date: Dimanche 22
> Novembre 2009,
> >> > 10h11
> >> > >>>>> All, the roadmap is
> now on
> >> > >>>>> 100%, so we can prepare
> for
> >> 3.1.3.
> >> > Could
> >> > >>>>> everyone test perhaps a
> GEDCOM
> >> and an
> >> > XML export
> >> > >>> of their
> >> > >>>>> data
> >> > >>>>> (filtered somehow), and
> then
> >> import
> >> > again in an
> >> > >>> empty tree.
> >> > >>>>> The last
> >> > >>>>> things changes are
> related to
> >> that,
> >> > and GEDCOM
> >> > >>> changes are
> >> > >>>>> sensitive.
> >> > >>>>>
> >> > >>>>> Jerome, can you check
> the po file
> >> is
> >> > up to date,
> >> > >>> perhaps
> >> > >>>>> send mail to
> >> > >>>>> translators with %
> completion of
> >> their
> >> > language
> >> > >>> as
> >> > >>>>> information?
> >> > >>>>>
> >> > >>>>> Stephane, do you have
> time
> >> somewhere
> >> > in the coming
> >> > >>> weeks to
> >> > >>>>> push out
> >> > >>>>> 3.1.3? I would like to
> see in
> >> the
> >> > release notes
> >> > >>> something
> >> > >>>>> in the line
> >> > >>>>> of 'While the Gramps
> developers
> >> are
> >> > working on a
> >> > >>> super 3.2
> >> > >>>>> release in
> >> > >>>>> a couple of months, they
> still
> >> had
> >> > time for a
> >> > >>> minor bug fix
> >> > >>>>> release.
> >> > >>>>>
> >> > >>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
> >> > >>>>> contains main content of
> this
> >> release.
> >> > I think the
> >> > >>> most
> >> > >>>>> striking:
> >> > >>>>>
> >> > >>>>> * the annoying tooltip
> messages
> >> in
> >> > latest distro's
> >> > >>> are no
> >> > >>>>> longer present
> >> > >>>>> * some GEDCOM fixes
> (timestamp
> >> on
> >> > persons now
> >> > >>> kept, MEDI
> >> > >>>>> import, ...)
> >> > >>>>> * some data that was not
> present
> >> in
> >> > filtered data
> >> > >>> is now
> >> > >>>>> present
> >> > >>>>> (source page, ...)
> >> > >>>>> * windows / or \ paths
> in
> >> webreport
> >> > cleaned up
> >> > >>>>> * ...
> >> > >>>>>
> >> > >>>>> Benny
> >> > >>>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >> >
> >>
> ------------------------------------------------------------------------------
> >> > Join us December 9, 2009 for the Red Hat
> Virtual
> >> > Experience,
> >> > a free event focused on virtualization and
> cloud
> >> computing.
> >> >
> >> > Attend in-depth sessions from your desk. Your
> couch.
> >> > Anywhere.
> >> > http://p.sf.net/sfu/redhat-sfdev2dev
> >> >
> _______________________________________________
> >> > Gramps-devel mailing list
> >> > Gramps-devel@...
> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >> >
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Join us December 9, 2009 for the Red Hat Virtual
> >> Experience,
> >> a free event focused on virtualization and cloud
> computing.
> >>
> >> Attend in-depth sessions from your desk. Your
> couch.
> >> Anywhere.
> >> http://p.sf.net/sfu/redhat-sfdev2dev
> >> _______________________________________________
> >> Gramps-devel mailing list
> >> Gramps-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>
> >
> >
> >
> >
>

From forum: GRAMPS - Dev

Loose Coupling?

2009-12-03T18:11:29Z

Devs,

One thing I have come to appreciate in working with Django is its
consistent use of the idea of "loose coupling". I wasn't real familiar
with the philosophy before, but when I began to understand it, I
realized that this is exactly one of the things that Gramps doesn't
have and has always bothered me. In fact, I would describe Gramps as
strongly coupled.

The philosophy can be read about in detail in any number of places
(for example, [1]). In a word: "Coupling refers to the degree of
direct knowledge that one class has of another." Many people interpret
this also as "the degree of direct knowledge that one part of the code
has of another part." A good test of the idea is: how many files do
you have to edit in order to add new code?

I am currently wrestling with this idea in working with the View
display code. Currently, we have a plugin category ID for every type
of view. But loose coupling would suggest that there is no need to
pre-specify these types; they could be discovered when we load the
plugins. (This is just an example of loose coupling, but the idea
could be used in many places throughout gramps).

For example, say that I want to add a new kind of View... perhaps a
Data Entry view (let's call the view category "Certificates" and the
view "Census"). Currently, we would have to edit a number of files to
add the new view type to define and expose this. On the other hand,
loose coupling says: Gramps doesn't know about view types, and will
just define the views as needed. This seems to be a more Pythonic
approach, and makes extending a project much easier (there are no
additional files to find and edit).

One downside is that you won't discover a misnamed View type until you
see that the view is showing up in the wrong place. But this would of
course be obvious the instant you run the code. Strongly coupled code
(like gramps currently is) might immediately give an error and crash
on a mislabeled view (or would just put it in the wrong category) but
would require knowledge about the view in multiple places.

I'd like to advocate more loose coupling in gramps, but wonder if
there is resistance to this philosophy, and if so, why. Feedback
appreciated.

-Doug

[1] - http://en.wikipedia.org/wiki/Loose_coupling

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-devel mailing list
Gramps-devel@...
https://lists.sourceforge.net/lists/listinfo/gramps-devel

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-03T13:12:58Z

Yes, bug introduced here:
http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps31/src/ScratchPad.py?view=diff&r1=13168&r2=13169

Peter, as you introduced this, you remember why? As said in other
parts, notes should already be unicode, so no need to convert them. I
would think these changed lines may be removed. They don't harm
however.

Jerome, do your patch with value for now.

Benny

2009/12/3 jerome <romjerome@...>:

> or should be something like :
>
> #String must be unicode for truncation to work for non ascii characters
> - note = unicode(note)
> + value = unicode(value)
> note = value.get().replace('\n', ' ')
>
>
> --- En date de : Jeu 3.12.09, jerome <romjerome@...> a écrit :
>
>> De: jerome <romjerome@...>
>> Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
>> À: "Benny Malengier" <benny.malengier@...>
>> Cc: "Gramps Development List" <gramps-devel@...>
>> Date: Jeudi 3 Décembre 2009, 18h44
>> /!\ there is an unfixed bug/crash on
>> 3.1.3-SVN :
>>
>> 116251: ERROR: gramps.py: line 160: Unhandled exception
>> Traceback (most recent call last):
>> File "src/ScratchPad.py", line 1137, in
>> object_drag_data_received
>> o = wrapper_class(self.dbstate,sel_data)
>> File "src/ScratchPad.py", line 327, in __init__
>> note = unicode(note)
>> UnboundLocalError: local variable 'note' referenced before
>> assignment
>>
>> patch should be easy :
>>
>> #String must be unicode for
>> truncation to work for non ascii characters
>> - note = unicode(note)
>> note =
>> value.get().replace('\n', ' ')
>> + note = unicode(note)
>>
>> To reproduce it :
>>
>> 1. Go on Note View
>> 2. Try to drag and drop a note oject reference from
>> NoteView to clipboard
>>
>>
>> Should I commit change ?
>>
>>
>>
>> --- En date de : Jeu 3.12.09, Jérôme <romjerome@...>
>> a écrit :
>>
>> > De: Jérôme <romjerome@...>
>> > Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
>> > À: "Benny Malengier" <benny.malengier@...>
>> > Cc: "Gramps Development List" <gramps-devel@...>
>> > Date: Jeudi 3 Décembre 2009, 17h28
>> > Benny,
>> >
>> > >>> 2. On source reference (repository):
>> > >>> 2 CALN
>> > >>> 3 MEDI Book
>> > >>> will be a custom translated media type
>> on
>> > export
>> > >>> 2 CALN
>> > >>> 3 MEDI Livre
>> > >>>
>> > >>> I suppose there is no error because I do
>> not
>> > loose data, but it is strange !
>> > >>
>> > >> Ok, I'll look at that, make a bug ticket (or
>> > reopen the previous one.
>> > >> The old code ignored MEDI tag, I suppose the
>> new
>> > code will write it
>> > >> out but not in English, it should be easy to
>> adapt
>> > the writegedcom for
>> > >> this, other types already write out the
>> english
>> > version (probably). Or
>> > >> are other types also written out in French?
>> It
>> > would make some sense,
>> > >> GEDCOM programs need not know that Book is
>> Livre
>> >
>> > Looks like not a bug ...
>> > I used Gramps without translations ($ python
>> > src/gramps.py), and this
>> > was already present on 3.1.2. There is no regression
>> for
>> > this on next
>> > release.
>> >
>> > http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
>> > http://www.gramps-project.org/bugs/view.php?id=3374
>> >
>> > Code writes value (not tag) in english if you are
>> using
>> > Gramps in
>> > English and translated value into french if you are
>> using
>> > Gramps in
>> > French !
>> >
>> > On my 'localized' Gedcom, I get :
>> >
>> > 1 EVEN
>> > 2 TYPE Mariage
>> > 1 EVEN
>> > 2 TYPE Élection
>> > 1 EVEN
>> > 2 TYPE Résidence
>> > 2 CALN
>> > 3 MEDI Livre
>> >
>> > which sounds correct with this custom data and after
>> > looking at the
>> > Gedcom header :
>> >
>> > 1 GEDC
>> > 2 VERS 5.5
>> > 2 FORM LINEAGE-LINKED
>> > 1 CHAR UTF-8
>> > 1 LANG French
>> >
>> > TAG do not use non-ASCII characters and values are
>> custom
>> > data.
>> > So, I suppose that's not a bug !
>> >
>> > > Or are other types also written out in French?
>> >
>> > yes it is coherent, only custom or Gramps' types (not
>> on
>> > Gedcom spec)
>> >
>> > This kind of thing must be surely forget by the many
>> tests
>> > which check
>> > Gedcom support... They look at custom tag (_CUSTOM)
>> but not
>> > on values
>> > used into the program.
>> >
>> > It's really nice to have this international support !
>> :)
>> > (I say this now but maybe it was me who has grumbled
>> at the
>> > time and I
>> > do not remember !!!)
>> >
>> >
>> > Thanks !
>> >
>> > Jérôme
>> >
>> >
>> >
>> >
>> >
>> > Benny Malengier a écrit :
>> > > 2009/11/24 jerome <romjerome@...>:
>> > >>> Jerome, your mail is a bit confusing.
>> > >> Sorry. I am testing Gedcom management
>> changes.
>> > >> First, I have tried to export a database
>> (Family
>> > Tree) to Gedcom format, but a dialog pops-up something
>> like
>> > "Gramps cannot write /tmp/..." during write person
>> process.
>> > Gedcom was not properly generated and I ran repair DB
>> tools
>> > on my opened Family Tree. Then no more message and
>> > Gramps-3.1.3 has generated a complete Gedcom.
>> > >>
>> > >> Looking at diff between the first one and
>> the
>> > second one.
>> > >> I suppose the problem was just "around"
>> CHANGE
>> > TIME (as I know this has been improved on 3.1.3) and
>> lines
>> > "not written" on the broken gedcom could be :
>> > >> 1 CHAN
>> > >> 2 DATE 24 NOV 2009
>> > >> 3 TIME 14:29:13
>> > >>
>> > >> Sorry, I cannot very well explain this :(
>> > >> I suppose Gramps was not able to write 1
>> CHAN, but
>> > I cannot say : "Gramps is not able to write this",
>> because
>> > process freeze, no error or bug report dialog, just
>> Gedcom
>> > was not complete.
>> > >>
>> > >>> because old gramps wrote out french
>> dates?
>> > >> Do you think this could be an OS issue ?
>> python
>> > time module ?
>> > >
>> > > No, it should work ok, the old code was
>> completely
>> > ignoring CHAN
>> > > group, the new code parses it correctly, and it
>> is
>> > written out
>> > > correctly.
>> > >>> For the second issue, is this a
>> regression?
>> > That is could Gramps 3.1.2 read
>> > >> I will try to test it.
>> > >>
>> > >> But seems there is still many problems with
>> Gedcom
>> > management ...
>> > >>
>> > >> I am loosing some data by making a diff
>> between :
>> > >> a Gedcom generated by Gramps and a new one,
>> > imported into a new Family Tree then exported.
>> > >>
>> > >> 1. dates with calendar, like :
>> > >> 2 DATE @#DFRENCH R@ 24 VEND 12
>> > >> are not properly imported by Gramps-3.1.3 and
>> will
>> > return a textual date :
>> > >> 2 DATE 24 VEND 12
>> > >
>> > > This should have been like this in 3.1.2, it
>> means the
>> > Date module
>> > > that reads it cannot read the @, make a bug
>> ticket,
>> > but I do not thing
>> > > it is a regression.
>> > >> 2. On source reference (repository):
>> > >> 2 CALN
>> > >> 3 MEDI Book
>> > >> will be a custom translated media type on
>> export
>> > >> 2 CALN
>> > >> 3 MEDI Livre
>> > >>
>> > >> I suppose there is no error because I do not
>> loose
>> > data, but it is strange !
>> > >
>> > > Ok, I'll look at that, make a bug ticket (or
>> reopen
>> > the previous one.
>> > > The old code ignored MEDI tag, I suppose the new
>> code
>> > will write it
>> > > out but not in English, it should be easy to
>> adapt the
>> > writegedcom for
>> > > this, other types already write out the english
>> > version (probably). Or
>> > > are other types also written out in French? It
>> would
>> > make some sense,
>> > > GEDCOM programs need not know that Book is Livre
>> > >
>> > >> 3. References on Media Objects are ignored
>> on
>> > export
>> > >> I started with 662 references into my Family
>> Tree
>> > and after a Gedcom import into a new Family Tree, I
>> kept 18,
>> > which was not media object, only urls on person object
>> !!!)
>> > >>
>> > >> I do not see any problem yet on Gramps XML
>> > management, and maybe some of this issues has been
>> already
>> > reported. I remember something like "Gedcom generated
>> by
>> > Gramps imported into Gramps".
>> > >>
>> > >> I suppose "references on Media Objects" and
>> the "1
>> > OBJE
>> > >> 2 FORM" (url on person) are related.
>> > >
>> > > This is the first I hear about this.
>> > > I do not like coding in GEDCOM, I do not use it
>> !!!
>> > >
>> > > Benny
>> > >
>> > >>
>> > >> I will look at Gedcom regression.
>> > >>
>> > >>
>> > >> Jérôme
>> > >>
>> > >>
>> > >> --- En date de : Mar 24.11.09, Benny
>> Malengier
>> > <benny.malengier@...>
>> > a écrit :
>> > >>
>> > >>> De: Benny Malengier <benny.malengier@...>
>> > >>> Objet: Re: Re : preparing for 3.1.3
>> > >>> À: "jerome" <romjerome@...>
>> > >>> Cc: "Gramps Development List" <gramps-devel@...>,
>> > "Stéphane Charette" <stephanecharette@...>
>> > >>> Date: Mardi 24 Novembre 2009, 15h24
>> > >>> Jerome, your mail is a bit
>> > >>> confusing.
>> > >>>
>> > >>> Are you saying the old gedcom crashes now
>> on
>> > import because
>> > >>> old gramps
>> > >>> wrote out french dates? Or is there no
>> problem
>> > (I see no
>> > >>> crash report
>> > >>> in this mail)
>> > >>>
>> > >>> For the second issue, is this a
>> regression?
>> > That is could
>> > >>> Gramps 3.1.2 read
>> > >>>
>> > >>>> 1 OBJE
>> > >>>> 2 FORM URL
>> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>> > >>> Benny
>> > >>>
>> > >>> 2009/11/24 jerome <romjerome@...>:
>> > >>>>> so we can prepare for 3.1.3.
>> Could
>> > >>>>> everyone test perhaps a GEDCOM
>> and an
>> > XML export
>> > >>> of their
>> > >>>>> data
>> > >>>>> (filtered somehow), and then
>> import
>> > again in an
>> > >>> empty tree.
>> > >>>>> The last
>> > >>>>> things changes are related to
>> that,
>> > and GEDCOM
>> > >>> changes are
>> > >>>>> sensitive.
>> > >>>> I have started to test import from
>> > Gramps-3.1.3 to
>> > >>> Gramps-3.1.3
>> > >>>> (Ubuntu 9.04, python 2.6)
>> > >>>>
>> > >>>> ///// 1 warning during Gramps
>> > session ///////
>> > >>>> (gramps.py:4609): CRITICAL **:
>> > >>> murrine_style_draw_focus: assertion
>> `height
>> > >= -1'
>> > >>> failed
>> > >>>> ///// 1 problem on GEDCOM export
>> ///////
>> > >>>>
>> > >>>> "Cannot write file ..." message on
>> dialog
>> > (on write
>> > >>> persons)
>> > >>>> Fixed after running rebuild 2nd
>> indices
>> > and "Check
>> > >>> & Repair" tools. (no problem with
>> Gramps
>> > XML format)
>> > >>>> Re-test is OK.
>> > >>>> Pass without error by using :
>> > >>>>
>> > >>>> 1 CHAN
>> > >>>> 2 DATE 24 NOV 2009
>> > >>>> 3 TIME 14:29:13
>> > >>>>
>> > >>>> Looks like first test has blocked
>> just
>> > before "change
>> > >>> time" on person object !
>> > >>>> /!\ I used my testing database
>> (generated
>> > before new
>> > >>> time management on Gedcom
>> > >>>> ///// problem on GEDCOM import
>> ///////
>> > >>>>
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer http://www.geneanet.org/contact.php3?source=bouly78
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer http://www.geneanet.org/rgentner
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer http://gw1.geneanet.org/index.php3?b=henriks
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer http://gw1.geneanet.org/index.php3?b=myriague
>> > >>>> WARNING .GedcomImport: Impossible
>> > d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
>> > >>>>
>> > >>>> => Cannot import url
>> > >>>>
>> > >>>> was generated by Gramps-3.1.3 :
>> > >>>>
>> > >>>> 0 @I1802@ INDI
>> > >>>> 1 NAME Florent /SCHMITT/
>> > >>>> 2 GIVN Florent
>> > >>>> 2 SURN SCHMITT
>> > >>>> 1 SEX M
>> > >>>> 1 OBJE
>> > >>>> 2 FORM URL
>> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>> > >>>>
>> > >>>> Now, I will try to see any diff on
>> data
>> > (Gedcom,
>> > >>> Gramps XML)
>> > >>>>
>> > >>>>
>> > >>>> Jérôme R.
>> > >>>>
>> > >>>>
>> > >>>> --- En date de : Dim 22.11.09, Benny
>> > Malengier <benny.malengier@...>
>> > >>> a écrit :
>> > >>>>> De: Benny Malengier <benny.malengier@...>
>> > >>>>> Objet: preparing for 3.1.3
>> > >>>>> À: "Gramps Development List"
>> <gramps-devel@...>,
>> > >>> "Jérôme" <romjerome@...>,
>> > >>> "Stéphane Charette" <stephanecharette@...>
>> > >>>>> Date: Dimanche 22 Novembre 2009,
>> > 10h11
>> > >>>>> All, the roadmap is now on
>> > >>>>> 100%, so we can prepare for
>> 3.1.3.
>> > Could
>> > >>>>> everyone test perhaps a GEDCOM
>> and an
>> > XML export
>> > >>> of their
>> > >>>>> data
>> > >>>>> (filtered somehow), and then
>> import
>> > again in an
>> > >>> empty tree.
>> > >>>>> The last
>> > >>>>> things changes are related to
>> that,
>> > and GEDCOM
>> > >>> changes are
>> > >>>>> sensitive.
>> > >>>>>
>> > >>>>> Jerome, can you check the po file
>> is
>> > up to date,
>> > >>> perhaps
>> > >>>>> send mail to
>> > >>>>> translators with % completion of
>> their
>> > language
>> > >>> as
>> > >>>>> information?
>> > >>>>>
>> > >>>>> Stephane, do you have time
>> somewhere
>> > in the coming
>> > >>> weeks to
>> > >>>>> push out
>> > >>>>> 3.1.3? I would like to see in
>> the
>> > release notes
>> > >>> something
>> > >>>>> in the line
>> > >>>>> of 'While the Gramps developers
>> are
>> > working on a
>> > >>> super 3.2
>> > >>>>> release in
>> > >>>>> a couple of months, they still
>> had
>> > time for a
>> > >>> minor bug fix
>> > >>>>> release.
>> > >>>>>
>> > >>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
>> > >>>>> contains main content of this
>> release.
>> > I think the
>> > >>> most
>> > >>>>> striking:
>> > >>>>>
>> > >>>>> * the annoying tooltip messages
>> in
>> > latest distro's
>> > >>> are no
>> > >>>>> longer present
>> > >>>>> * some GEDCOM fixes (timestamp
>> on
>> > persons now
>> > >>> kept, MEDI
>> > >>>>> import, ...)
>> > >>>>> * some data that was not present
>> in
>> > filtered data
>> > >>> is now
>> > >>>>> present
>> > >>>>> (source page, ...)
>> > >>>>> * windows / or \ paths in
>> webreport
>> > cleaned up
>> > >>>>> * ...
>> > >>>>>
>> > >>>>> Benny
>> > >>>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>
>> > >>
>> > >>
>> > >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Join us December 9, 2009 for the Red Hat Virtual
>> > Experience,
>> > a free event focused on virtualization and cloud
>> computing.
>> >
>> > Attend in-depth sessions from your desk. Your couch.
>> > Anywhere.
>> > http://p.sf.net/sfu/redhat-sfdev2dev
>> > _______________________________________________
>> > Gramps-devel mailing list
>> > Gramps-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>> >
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual
>> Experience,
>> a free event focused on virtualization and cloud computing.
>>
>> Attend in-depth sessions from your desk. Your couch.
>> Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>
>
>
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-03T09:51:08Z

or should be something like :

#String must be unicode for truncation to work for non ascii characters
- note = unicode(note)
+ value = unicode(value)
note = value.get().replace('\n', ' ')

--- En date de : Jeu 3.12.09, jerome <romjerome@...> a écrit :

> De: jerome <romjerome@...>
> Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
> À: "Benny Malengier" <benny.malengier@...>
> Cc: "Gramps Development List" <gramps-devel@...>
> Date: Jeudi 3 Décembre 2009, 18h44
> /!\ there is an unfixed bug/crash on
> 3.1.3-SVN :
>
> 116251: ERROR: gramps.py: line 160: Unhandled exception
> Traceback (most recent call last):
> File "src/ScratchPad.py", line 1137, in
> object_drag_data_received
> o = wrapper_class(self.dbstate,sel_data)
> File "src/ScratchPad.py", line 327, in __init__
> note = unicode(note)
> UnboundLocalError: local variable 'note' referenced before
> assignment
>
> patch should be easy :
>
> #String must be unicode for
> truncation to work for non ascii characters
> - note = unicode(note)
> note =
> value.get().replace('\n', ' ')
> + note = unicode(note)
>
> To reproduce it :
>
> 1. Go on Note View
> 2. Try to drag and drop a note oject reference from
> NoteView to clipboard
>
>
> Should I commit change ?
>
>
>
> --- En date de : Jeu 3.12.09, Jérôme <romjerome@...>
> a écrit :
>
> > De: Jérôme <romjerome@...>
> > Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
> > À: "Benny Malengier" <benny.malengier@...>
> > Cc: "Gramps Development List" <gramps-devel@...>
> > Date: Jeudi 3 Décembre 2009, 17h28
> > Benny,
> >
> > >>> 2. On source reference (repository):
> > >>> 2 CALN
> > >>> 3 MEDI Book
> > >>> will be a custom translated media type
> on
> > export
> > >>> 2 CALN
> > >>> 3 MEDI Livre
> > >>>
> > >>> I suppose there is no error because I do
> not
> > loose data, but it is strange !
> > >>
> > >> Ok, I'll look at that, make a bug ticket (or
> > reopen the previous one.
> > >> The old code ignored MEDI tag, I suppose the
> new
> > code will write it
> > >> out but not in English, it should be easy to
> adapt
> > the writegedcom for
> > >> this, other types already write out the
> english
> > version (probably). Or
> > >> are other types also written out in French?
> It
> > would make some sense,
> > >> GEDCOM programs need not know that Book is
> Livre
> >
> > Looks like not a bug ...
> > I used Gramps without translations ($ python
> > src/gramps.py), and this
> > was already present on 3.1.2. There is no regression
> for
> > this on next
> > release.
> >
> > http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
> > http://www.gramps-project.org/bugs/view.php?id=3374
> >
> > Code writes value (not tag) in english if you are
> using
> > Gramps in
> > English and translated value into french if you are
> using
> > Gramps in
> > French !
> >
> > On my 'localized' Gedcom, I get :
> >
> > 1 EVEN
> > 2 TYPE Mariage
> > 1 EVEN
> > 2 TYPE Élection
> > 1 EVEN
> > 2 TYPE Résidence
> > 2 CALN
> > 3 MEDI Livre
> >
> > which sounds correct with this custom data and after
> > looking at the
> > Gedcom header :
> >
> > 1 GEDC
> > 2 VERS 5.5
> > 2 FORM LINEAGE-LINKED
> > 1 CHAR UTF-8
> > 1 LANG French
> >
> > TAG do not use non-ASCII characters and values are
> custom
> > data.
> > So, I suppose that's not a bug !
> >
> > > Or are other types also written out in French?
> >
> > yes it is coherent, only custom or Gramps' types (not
> on
> > Gedcom spec)
> >
> > This kind of thing must be surely forget by the many
> tests
> > which check
> > Gedcom support... They look at custom tag (_CUSTOM)
> but not
> > on values
> > used into the program.
> >
> > It's really nice to have this international support !
> :)
> > (I say this now but maybe it was me who has grumbled
> at the
> > time and I
> > do not remember !!!)
> >
> >
> > Thanks !
> >
> > Jérôme
> >
> >
> >
> >
> >
> > Benny Malengier a écrit :
> > > 2009/11/24 jerome <romjerome@...>:
> > >>> Jerome, your mail is a bit confusing.
> > >> Sorry. I am testing Gedcom management
> changes.
> > >> First, I have tried to export a database
> (Family
> > Tree) to Gedcom format, but a dialog pops-up something
> like
> > "Gramps cannot write /tmp/..." during write person
> process.
> > Gedcom was not properly generated and I ran repair DB
> tools
> > on my opened Family Tree. Then no more message and
> > Gramps-3.1.3 has generated a complete Gedcom.
> > >>
> > >> Looking at diff between the first one and
> the
> > second one.
> > >> I suppose the problem was just "around"
> CHANGE
> > TIME (as I know this has been improved on 3.1.3) and
> lines
> > "not written" on the broken gedcom could be :
> > >> 1 CHAN
> > >> 2 DATE 24 NOV 2009
> > >> 3 TIME 14:29:13
> > >>
> > >> Sorry, I cannot very well explain this :(
> > >> I suppose Gramps was not able to write 1
> CHAN, but
> > I cannot say : "Gramps is not able to write this",
> because
> > process freeze, no error or bug report dialog, just
> Gedcom
> > was not complete.
> > >>
> > >>> because old gramps wrote out french
> dates?
> > >> Do you think this could be an OS issue ?
> python
> > time module ?
> > >
> > > No, it should work ok, the old code was
> completely
> > ignoring CHAN
> > > group, the new code parses it correctly, and it
> is
> > written out
> > > correctly.
> > >>> For the second issue, is this a
> regression?
> > That is could Gramps 3.1.2 read
> > >> I will try to test it.
> > >>
> > >> But seems there is still many problems with
> Gedcom
> > management ...
> > >>
> > >> I am loosing some data by making a diff
> between :
> > >> a Gedcom generated by Gramps and a new one,
> > imported into a new Family Tree then exported.
> > >>
> > >> 1. dates with calendar, like :
> > >> 2 DATE @#DFRENCH R@ 24 VEND 12
> > >> are not properly imported by Gramps-3.1.3 and
> will
> > return a textual date :
> > >> 2 DATE 24 VEND 12
> > >
> > > This should have been like this in 3.1.2, it
> means the
> > Date module
> > > that reads it cannot read the @, make a bug
> ticket,
> > but I do not thing
> > > it is a regression.
> > >> 2. On source reference (repository):
> > >> 2 CALN
> > >> 3 MEDI Book
> > >> will be a custom translated media type on
> export
> > >> 2 CALN
> > >> 3 MEDI Livre
> > >>
> > >> I suppose there is no error because I do not
> loose
> > data, but it is strange !
> > >
> > > Ok, I'll look at that, make a bug ticket (or
> reopen
> > the previous one.
> > > The old code ignored MEDI tag, I suppose the new
> code
> > will write it
> > > out but not in English, it should be easy to
> adapt the
> > writegedcom for
> > > this, other types already write out the english
> > version (probably). Or
> > > are other types also written out in French? It
> would
> > make some sense,
> > > GEDCOM programs need not know that Book is Livre
> > >
> > >> 3. References on Media Objects are ignored
> on
> > export
> > >> I started with 662 references into my Family
> Tree
> > and after a Gedcom import into a new Family Tree, I
> kept 18,
> > which was not media object, only urls on person object
> !!!)
> > >>
> > >> I do not see any problem yet on Gramps XML
> > management, and maybe some of this issues has been
> already
> > reported. I remember something like "Gedcom generated
> by
> > Gramps imported into Gramps".
> > >>
> > >> I suppose "references on Media Objects" and
> the "1
> > OBJE
> > >> 2 FORM" (url on person) are related.
> > >
> > > This is the first I hear about this.
> > > I do not like coding in GEDCOM, I do not use it
> !!!
> > >
> > > Benny
> > >
> > >>
> > >> I will look at Gedcom regression.
> > >>
> > >>
> > >> Jérôme
> > >>
> > >>
> > >> --- En date de : Mar 24.11.09, Benny
> Malengier
> > <benny.malengier@...>
> > a écrit :
> > >>
> > >>> De: Benny Malengier <benny.malengier@...>
> > >>> Objet: Re: Re : preparing for 3.1.3
> > >>> À: "jerome" <romjerome@...>
> > >>> Cc: "Gramps Development List" <gramps-devel@...>,
> > "Stéphane Charette" <stephanecharette@...>
> > >>> Date: Mardi 24 Novembre 2009, 15h24
> > >>> Jerome, your mail is a bit
> > >>> confusing.
> > >>>
> > >>> Are you saying the old gedcom crashes now
> on
> > import because
> > >>> old gramps
> > >>> wrote out french dates? Or is there no
> problem
> > (I see no
> > >>> crash report
> > >>> in this mail)
> > >>>
> > >>> For the second issue, is this a
> regression?
> > That is could
> > >>> Gramps 3.1.2 read
> > >>>
> > >>>> 1 OBJE
> > >>>> 2 FORM URL
> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
> > >>> Benny
> > >>>
> > >>> 2009/11/24 jerome <romjerome@...>:
> > >>>>> so we can prepare for 3.1.3.
> Could
> > >>>>> everyone test perhaps a GEDCOM
> and an
> > XML export
> > >>> of their
> > >>>>> data
> > >>>>> (filtered somehow), and then
> import
> > again in an
> > >>> empty tree.
> > >>>>> The last
> > >>>>> things changes are related to
> that,
> > and GEDCOM
> > >>> changes are
> > >>>>> sensitive.
> > >>>> I have started to test import from
> > Gramps-3.1.3 to
> > >>> Gramps-3.1.3
> > >>>> (Ubuntu 9.04, python 2.6)
> > >>>>
> > >>>> ///// 1 warning during Gramps
> > session ///////
> > >>>> (gramps.py:4609): CRITICAL **:
> > >>> murrine_style_draw_focus: assertion
> `height
> > >= -1'
> > >>> failed
> > >>>> ///// 1 problem on GEDCOM export
> ///////
> > >>>>
> > >>>> "Cannot write file ..." message on
> dialog
> > (on write
> > >>> persons)
> > >>>> Fixed after running rebuild 2nd
> indices
> > and "Check
> > >>> & Repair" tools. (no problem with
> Gramps
> > XML format)
> > >>>> Re-test is OK.
> > >>>> Pass without error by using :
> > >>>>
> > >>>> 1 CHAN
> > >>>> 2 DATE 24 NOV 2009
> > >>>> 3 TIME 14:29:13
> > >>>>
> > >>>> Looks like first test has blocked
> just
> > before "change
> > >>> time" on person object !
> > >>>> /!\ I used my testing database
> (generated
> > before new
> > >>> time management on Gedcom
> > >>>> ///// problem on GEDCOM import
> ///////
> > >>>>
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer http://www.geneanet.org/contact.php3?source=bouly78
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer http://www.geneanet.org/rgentner
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer http://gw1.geneanet.org/index.php3?b=henriks
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer http://gw1.geneanet.org/index.php3?b=myriague
> > >>>> WARNING .GedcomImport: Impossible
> > d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
> > >>>>
> > >>>> => Cannot import url
> > >>>>
> > >>>> was generated by Gramps-3.1.3 :
> > >>>>
> > >>>> 0 @I1802@ INDI
> > >>>> 1 NAME Florent /SCHMITT/
> > >>>> 2 GIVN Florent
> > >>>> 2 SURN SCHMITT
> > >>>> 1 SEX M
> > >>>> 1 OBJE
> > >>>> 2 FORM URL
> > >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
> > >>>>
> > >>>> Now, I will try to see any diff on
> data
> > (Gedcom,
> > >>> Gramps XML)
> > >>>>
> > >>>>
> > >>>> Jérôme R.
> > >>>>
> > >>>>
> > >>>> --- En date de : Dim 22.11.09, Benny
> > Malengier <benny.malengier@...>
> > >>> a écrit :
> > >>>>> De: Benny Malengier <benny.malengier@...>
> > >>>>> Objet: preparing for 3.1.3
> > >>>>> À: "Gramps Development List"
> <gramps-devel@...>,
> > >>> "Jérôme" <romjerome@...>,
> > >>> "Stéphane Charette" <stephanecharette@...>
> > >>>>> Date: Dimanche 22 Novembre 2009,
> > 10h11
> > >>>>> All, the roadmap is now on
> > >>>>> 100%, so we can prepare for
> 3.1.3.
> > Could
> > >>>>> everyone test perhaps a GEDCOM
> and an
> > XML export
> > >>> of their
> > >>>>> data
> > >>>>> (filtered somehow), and then
> import
> > again in an
> > >>> empty tree.
> > >>>>> The last
> > >>>>> things changes are related to
> that,
> > and GEDCOM
> > >>> changes are
> > >>>>> sensitive.
> > >>>>>
> > >>>>> Jerome, can you check the po file
> is
> > up to date,
> > >>> perhaps
> > >>>>> send mail to
> > >>>>> translators with % completion of
> their
> > language
> > >>> as
> > >>>>> information?
> > >>>>>
> > >>>>> Stephane, do you have time
> somewhere
> > in the coming
> > >>> weeks to
> > >>>>> push out
> > >>>>> 3.1.3? I would like to see in
> the
> > release notes
> > >>> something
> > >>>>> in the line
> > >>>>> of 'While the Gramps developers
> are
> > working on a
> > >>> super 3.2
> > >>>>> release in
> > >>>>> a couple of months, they still
> had
> > time for a
> > >>> minor bug fix
> > >>>>> release.
> > >>>>>
> > >>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
> > >>>>> contains main content of this
> release.
> > I think the
> > >>> most
> > >>>>> striking:
> > >>>>>
> > >>>>> * the annoying tooltip messages
> in
> > latest distro's
> > >>> are no
> > >>>>> longer present
> > >>>>> * some GEDCOM fixes (timestamp
> on
> > persons now
> > >>> kept, MEDI
> > >>>>> import, ...)
> > >>>>> * some data that was not present
> in
> > filtered data
> > >>> is now
> > >>>>> present
> > >>>>> (source page, ...)
> > >>>>> * windows / or \ paths in
> webreport
> > cleaned up
> > >>>>> * ...
> > >>>>>
> > >>>>> Benny
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> > >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Join us December 9, 2009 for the Red Hat Virtual
> > Experience,
> > a free event focused on virtualization and cloud
> computing.
> >
> > Attend in-depth sessions from your desk. Your couch.
> > Anywhere.
> > http://p.sf.net/sfu/redhat-sfdev2dev
> > _______________________________________________
> > Gramps-devel mailing list
> > Gramps-devel@...
> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual
> Experience,
> a free event focused on virtualization and cloud computing.
>
> Attend in-depth sessions from your desk. Your couch.
> Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-03T09:44:35Z

/!\ there is an unfixed bug/crash on 3.1.3-SVN :

116251: ERROR: gramps.py: line 160: Unhandled exception
Traceback (most recent call last):
File "src/ScratchPad.py", line 1137, in object_drag_data_received
o = wrapper_class(self.dbstate,sel_data)
File "src/ScratchPad.py", line 327, in __init__
note = unicode(note)
UnboundLocalError: local variable 'note' referenced before assignment

patch should be easy :

#String must be unicode for truncation to work for non ascii characters
- note = unicode(note)
note = value.get().replace('\n', ' ')
+ note = unicode(note)

To reproduce it :

1. Go on Note View
2. Try to drag and drop a note oject reference from NoteView to clipboard

Should I commit change ?

--- En date de : Jeu 3.12.09, Jérôme <romjerome@...> a écrit :

> De: Jérôme <romjerome@...>
> Objet: Re: [Gramps-devel] Re : preparing for 3.1.3
> À: "Benny Malengier" <benny.malengier@...>
> Cc: "Gramps Development List" <gramps-devel@...>
> Date: Jeudi 3 Décembre 2009, 17h28
> Benny,
>
> >>> 2. On source reference (repository):
> >>> 2 CALN
> >>> 3 MEDI Book
> >>> will be a custom translated media type on
> export
> >>> 2 CALN
> >>> 3 MEDI Livre
> >>>
> >>> I suppose there is no error because I do not
> loose data, but it is strange !
> >>
> >> Ok, I'll look at that, make a bug ticket (or
> reopen the previous one.
> >> The old code ignored MEDI tag, I suppose the new
> code will write it
> >> out but not in English, it should be easy to adapt
> the writegedcom for
> >> this, other types already write out the english
> version (probably). Or
> >> are other types also written out in French? It
> would make some sense,
> >> GEDCOM programs need not know that Book is Livre
>
> Looks like not a bug ...
> I used Gramps without translations ($ python
> src/gramps.py), and this
> was already present on 3.1.2. There is no regression for
> this on next
> release.
>
> http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
> http://www.gramps-project.org/bugs/view.php?id=3374
>
> Code writes value (not tag) in english if you are using
> Gramps in
> English and translated value into french if you are using
> Gramps in
> French !
>
> On my 'localized' Gedcom, I get :
>
> 1 EVEN
> 2 TYPE Mariage
> 1 EVEN
> 2 TYPE Élection
> 1 EVEN
> 2 TYPE Résidence
> 2 CALN
> 3 MEDI Livre
>
> which sounds correct with this custom data and after
> looking at the
> Gedcom header :
>
> 1 GEDC
> 2 VERS 5.5
> 2 FORM LINEAGE-LINKED
> 1 CHAR UTF-8
> 1 LANG French
>
> TAG do not use non-ASCII characters and values are custom
> data.
> So, I suppose that's not a bug !
>
> > Or are other types also written out in French?
>
> yes it is coherent, only custom or Gramps' types (not on
> Gedcom spec)
>
> This kind of thing must be surely forget by the many tests
> which check
> Gedcom support... They look at custom tag (_CUSTOM) but not
> on values
> used into the program.
>
> It's really nice to have this international support ! :)
> (I say this now but maybe it was me who has grumbled at the
> time and I
> do not remember !!!)
>
>
> Thanks !
>
> Jérôme
>
>
>
>
>
> Benny Malengier a écrit :
> > 2009/11/24 jerome <romjerome@...>:
> >>> Jerome, your mail is a bit confusing.
> >> Sorry. I am testing Gedcom management changes.
> >> First, I have tried to export a database (Family
> Tree) to Gedcom format, but a dialog pops-up something like
> "Gramps cannot write /tmp/..." during write person process.
> Gedcom was not properly generated and I ran repair DB tools
> on my opened Family Tree. Then no more message and
> Gramps-3.1.3 has generated a complete Gedcom.
> >>
> >> Looking at diff between the first one and the
> second one.
> >> I suppose the problem was just "around" CHANGE
> TIME (as I know this has been improved on 3.1.3) and lines
> "not written" on the broken gedcom could be :
> >> 1 CHAN
> >> 2 DATE 24 NOV 2009
> >> 3 TIME 14:29:13
> >>
> >> Sorry, I cannot very well explain this :(
> >> I suppose Gramps was not able to write 1 CHAN, but
> I cannot say : "Gramps is not able to write this", because
> process freeze, no error or bug report dialog, just Gedcom
> was not complete.
> >>
> >>> because old gramps wrote out french dates?
> >> Do you think this could be an OS issue ? python
> time module ?
> >
> > No, it should work ok, the old code was completely
> ignoring CHAN
> > group, the new code parses it correctly, and it is
> written out
> > correctly.
> >>> For the second issue, is this a regression?
> That is could Gramps 3.1.2 read
> >> I will try to test it.
> >>
> >> But seems there is still many problems with Gedcom
> management ...
> >>
> >> I am loosing some data by making a diff between :
> >> a Gedcom generated by Gramps and a new one,
> imported into a new Family Tree then exported.
> >>
> >> 1. dates with calendar, like :
> >> 2 DATE @#DFRENCH R@ 24 VEND 12
> >> are not properly imported by Gramps-3.1.3 and will
> return a textual date :
> >> 2 DATE 24 VEND 12
> >
> > This should have been like this in 3.1.2, it means the
> Date module
> > that reads it cannot read the @, make a bug ticket,
> but I do not thing
> > it is a regression.
> >> 2. On source reference (repository):
> >> 2 CALN
> >> 3 MEDI Book
> >> will be a custom translated media type on export
> >> 2 CALN
> >> 3 MEDI Livre
> >>
> >> I suppose there is no error because I do not loose
> data, but it is strange !
> >
> > Ok, I'll look at that, make a bug ticket (or reopen
> the previous one.
> > The old code ignored MEDI tag, I suppose the new code
> will write it
> > out but not in English, it should be easy to adapt the
> writegedcom for
> > this, other types already write out the english
> version (probably). Or
> > are other types also written out in French? It would
> make some sense,
> > GEDCOM programs need not know that Book is Livre
> >
> >> 3. References on Media Objects are ignored on
> export
> >> I started with 662 references into my Family Tree
> and after a Gedcom import into a new Family Tree, I kept 18,
> which was not media object, only urls on person object !!!)
> >>
> >> I do not see any problem yet on Gramps XML
> management, and maybe some of this issues has been already
> reported. I remember something like "Gedcom generated by
> Gramps imported into Gramps".
> >>
> >> I suppose "references on Media Objects" and the "1
> OBJE
> >> 2 FORM" (url on person) are related.
> >
> > This is the first I hear about this.
> > I do not like coding in GEDCOM, I do not use it !!!
> >
> > Benny
> >
> >>
> >> I will look at Gedcom regression.
> >>
> >>
> >> Jérôme
> >>
> >>
> >> --- En date de : Mar 24.11.09, Benny Malengier
> <benny.malengier@...>
> a écrit :
> >>
> >>> De: Benny Malengier <benny.malengier@...>
> >>> Objet: Re: Re : preparing for 3.1.3
> >>> À: "jerome" <romjerome@...>
> >>> Cc: "Gramps Development List" <gramps-devel@...>,
> "Stéphane Charette" <stephanecharette@...>
> >>> Date: Mardi 24 Novembre 2009, 15h24
> >>> Jerome, your mail is a bit
> >>> confusing.
> >>>
> >>> Are you saying the old gedcom crashes now on
> import because
> >>> old gramps
> >>> wrote out french dates? Or is there no problem
> (I see no
> >>> crash report
> >>> in this mail)
> >>>
> >>> For the second issue, is this a regression?
> That is could
> >>> Gramps 3.1.2 read
> >>>
> >>>> 1 OBJE
> >>>> 2 FORM URL
> >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
> >>> Benny
> >>>
> >>> 2009/11/24 jerome <romjerome@...>:
> >>>>> so we can prepare for 3.1.3. Could
> >>>>> everyone test perhaps a GEDCOM and an
> XML export
> >>> of their
> >>>>> data
> >>>>> (filtered somehow), and then import
> again in an
> >>> empty tree.
> >>>>> The last
> >>>>> things changes are related to that,
> and GEDCOM
> >>> changes are
> >>>>> sensitive.
> >>>> I have started to test import from
> Gramps-3.1.3 to
> >>> Gramps-3.1.3
> >>>> (Ubuntu 9.04, python 2.6)
> >>>>
> >>>> ///// 1 warning during Gramps
> session ///////
> >>>> (gramps.py:4609): CRITICAL **:
> >>> murrine_style_draw_focus: assertion `height
> >= -1'
> >>> failed
> >>>> ///// 1 problem on GEDCOM export ///////
> >>>>
> >>>> "Cannot write file ..." message on dialog
> (on write
> >>> persons)
> >>>> Fixed after running rebuild 2nd indices
> and "Check
> >>> & Repair" tools. (no problem with Gramps
> XML format)
> >>>> Re-test is OK.
> >>>> Pass without error by using :
> >>>>
> >>>> 1 CHAN
> >>>> 2 DATE 24 NOV 2009
> >>>> 3 TIME 14:29:13
> >>>>
> >>>> Looks like first test has blocked just
> before "change
> >>> time" on person object !
> >>>> /!\ I used my testing database (generated
> before new
> >>> time management on Gedcom
> >>>> ///// problem on GEDCOM import ///////
> >>>>
> >>>> WARNING .GedcomImport: Impossible
> d'importer http://www.geneanet.org/contact.php3?source=bouly78
> >>>> WARNING .GedcomImport: Impossible
> d'importer http://www.geneanet.org/rgentner
> >>>> WARNING .GedcomImport: Impossible
> d'importer
> >>>> WARNING .GedcomImport: Impossible
> d'importer
> >>>> WARNING .GedcomImport: Impossible
> d'importer
> >>>> WARNING .GedcomImport: Impossible
> d'importer http://gw1.geneanet.org/index.php3?b=henriks
> >>>> WARNING .GedcomImport: Impossible
> d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
> >>>> WARNING .GedcomImport: Impossible
> d'importer http://gw1.geneanet.org/index.php3?b=myriague
> >>>> WARNING .GedcomImport: Impossible
> d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
> >>>>
> >>>> => Cannot import url
> >>>>
> >>>> was generated by Gramps-3.1.3 :
> >>>>
> >>>> 0 @I1802@ INDI
> >>>> 1 NAME Florent /SCHMITT/
> >>>> 2 GIVN Florent
> >>>> 2 SURN SCHMITT
> >>>> 1 SEX M
> >>>> 1 OBJE
> >>>> 2 FORM URL
> >>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
> >>>>
> >>>> Now, I will try to see any diff on data
> (Gedcom,
> >>> Gramps XML)
> >>>>
> >>>>
> >>>> Jérôme R.
> >>>>
> >>>>
> >>>> --- En date de : Dim 22.11.09, Benny
> Malengier <benny.malengier@...>
> >>> a écrit :
> >>>>> De: Benny Malengier <benny.malengier@...>
> >>>>> Objet: preparing for 3.1.3
> >>>>> À: "Gramps Development List" <gramps-devel@...>,
> >>> "Jérôme" <romjerome@...>,
> >>> "Stéphane Charette" <stephanecharette@...>
> >>>>> Date: Dimanche 22 Novembre 2009,
> 10h11
> >>>>> All, the roadmap is now on
> >>>>> 100%, so we can prepare for 3.1.3.
> Could
> >>>>> everyone test perhaps a GEDCOM and an
> XML export
> >>> of their
> >>>>> data
> >>>>> (filtered somehow), and then import
> again in an
> >>> empty tree.
> >>>>> The last
> >>>>> things changes are related to that,
> and GEDCOM
> >>> changes are
> >>>>> sensitive.
> >>>>>
> >>>>> Jerome, can you check the po file is
> up to date,
> >>> perhaps
> >>>>> send mail to
> >>>>> translators with % completion of their
> language
> >>> as
> >>>>> information?
> >>>>>
> >>>>> Stephane, do you have time somewhere
> in the coming
> >>> weeks to
> >>>>> push out
> >>>>> 3.1.3? I would like to see in the
> release notes
> >>> something
> >>>>> in the line
> >>>>> of 'While the Gramps developers are
> working on a
> >>> super 3.2
> >>>>> release in
> >>>>> a couple of months, they still had
> time for a
> >>> minor bug fix
> >>>>> release.
> >>>>>
> >>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
> >>>>> contains main content of this release.
> I think the
> >>> most
> >>>>> striking:
> >>>>>
> >>>>> * the annoying tooltip messages in
> latest distro's
> >>> are no
> >>>>> longer present
> >>>>> * some GEDCOM fixes (timestamp on
> persons now
> >>> kept, MEDI
> >>>>> import, ...)
> >>>>> * some data that was not present in
> filtered data
> >>> is now
> >>>>> present
> >>>>> (source page, ...)
> >>>>> * windows / or \ paths in webreport
> cleaned up
> >>>>> * ...
> >>>>>
> >>>>> Benny
> >>>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual
> Experience,
> a free event focused on virtualization and cloud computing.
>
> Attend in-depth sessions from your desk. Your couch.
> Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

From forum: GRAMPS - Dev

Re: Re : preparing for 3.1.3

2009-12-03T08:28:26Z

Benny,

>>> 2. On source reference (repository):
>>> 2 CALN
>>> 3 MEDI Book
>>> will be a custom translated media type on export
>>> 2 CALN
>>> 3 MEDI Livre
>>>
>>> I suppose there is no error because I do not loose data, but it is strange !
>>
>> Ok, I'll look at that, make a bug ticket (or reopen the previous one.
>> The old code ignored MEDI tag, I suppose the new code will write it
>> out but not in English, it should be easy to adapt the writegedcom for
>> this, other types already write out the english version (probably). Or
>> are other types also written out in French? It would make some sense,
>> GEDCOM programs need not know that Book is Livre

Looks like not a bug ...
I used Gramps without translations ($ python src/gramps.py), and this
was already present on 3.1.2. There is no regression for this on next
release.

http://www.gramps-project.org/bugs/changelog_page.php?version_id=15
http://www.gramps-project.org/bugs/view.php?id=3374

Code writes value (not tag) in english if you are using Gramps in
English and translated value into french if you are using Gramps in
French !

On my 'localized' Gedcom, I get :

1 EVEN
2 TYPE Mariage
1 EVEN
2 TYPE Élection
1 EVEN
2 TYPE Résidence
2 CALN
3 MEDI Livre

which sounds correct with this custom data and after looking at the
Gedcom header :

1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
1 LANG French

TAG do not use non-ASCII characters and values are custom data.
So, I suppose that's not a bug !

> Or are other types also written out in French?

yes it is coherent, only custom or Gramps' types (not on Gedcom spec)

This kind of thing must be surely forget by the many tests which check
Gedcom support... They look at custom tag (_CUSTOM) but not on values
used into the program.

It's really nice to have this international support ! :)
(I say this now but maybe it was me who has grumbled at the time and I
do not remember !!!)

Thanks !

Jérôme

Benny Malengier a écrit :

> 2009/11/24 jerome <romjerome@...>:
>>> Jerome, your mail is a bit confusing.
>> Sorry. I am testing Gedcom management changes.
>> First, I have tried to export a database (Family Tree) to Gedcom format, but a dialog pops-up something like "Gramps cannot write /tmp/..." during write person process. Gedcom was not properly generated and I ran repair DB tools on my opened Family Tree. Then no more message and Gramps-3.1.3 has generated a complete Gedcom.
>>
>> Looking at diff between the first one and the second one.
>> I suppose the problem was just "around" CHANGE TIME (as I know this has been improved on 3.1.3) and lines "not written" on the broken gedcom could be :
>> 1 CHAN
>> 2 DATE 24 NOV 2009
>> 3 TIME 14:29:13
>>
>> Sorry, I cannot very well explain this :(
>> I suppose Gramps was not able to write 1 CHAN, but I cannot say : "Gramps is not able to write this", because process freeze, no error or bug report dialog, just Gedcom was not complete.
>>
>>> because old gramps wrote out french dates?
>> Do you think this could be an OS issue ? python time module ?
>
> No, it should work ok, the old code was completely ignoring CHAN
> group, the new code parses it correctly, and it is written out
> correctly.
>>> For the second issue, is this a regression? That is could Gramps 3.1.2 read
>> I will try to test it.
>>
>> But seems there is still many problems with Gedcom management ...
>>
>> I am loosing some data by making a diff between :
>> a Gedcom generated by Gramps and a new one, imported into a new Family Tree then exported.
>>
>> 1. dates with calendar, like :
>> 2 DATE @#DFRENCH R@ 24 VEND 12
>> are not properly imported by Gramps-3.1.3 and will return a textual date :
>> 2 DATE 24 VEND 12
>
> This should have been like this in 3.1.2, it means the Date module
> that reads it cannot read the @, make a bug ticket, but I do not thing
> it is a regression.
>> 2. On source reference (repository):
>> 2 CALN
>> 3 MEDI Book
>> will be a custom translated media type on export
>> 2 CALN
>> 3 MEDI Livre
>>
>> I suppose there is no error because I do not loose data, but it is strange !
>
> Ok, I'll look at that, make a bug ticket (or reopen the previous one.
> The old code ignored MEDI tag, I suppose the new code will write it
> out but not in English, it should be easy to adapt the writegedcom for
> this, other types already write out the english version (probably). Or
> are other types also written out in French? It would make some sense,
> GEDCOM programs need not know that Book is Livre
>
>> 3. References on Media Objects are ignored on export
>> I started with 662 references into my Family Tree and after a Gedcom import into a new Family Tree, I kept 18, which was not media object, only urls on person object !!!)
>>
>> I do not see any problem yet on Gramps XML management, and maybe some of this issues has been already reported. I remember something like "Gedcom generated by Gramps imported into Gramps".
>>
>> I suppose "references on Media Objects" and the "1 OBJE
>> 2 FORM" (url on person) are related.
>
> This is the first I hear about this.
> I do not like coding in GEDCOM, I do not use it !!!
>
> Benny
>
>>
>> I will look at Gedcom regression.
>>
>>
>> Jérôme
>>
>>
>> --- En date de : Mar 24.11.09, Benny Malengier <benny.malengier@...> a écrit :
>>
>>> De: Benny Malengier <benny.malengier@...>
>>> Objet: Re: Re : preparing for 3.1.3
>>> À: "jerome" <romjerome@...>
>>> Cc: "Gramps Development List" <gramps-devel@...>, "Stéphane Charette" <stephanecharette@...>
>>> Date: Mardi 24 Novembre 2009, 15h24
>>> Jerome, your mail is a bit
>>> confusing.
>>>
>>> Are you saying the old gedcom crashes now on import because
>>> old gramps
>>> wrote out french dates? Or is there no problem (I see no
>>> crash report
>>> in this mail)
>>>
>>> For the second issue, is this a regression? That is could
>>> Gramps 3.1.2 read
>>>
>>>> 1 OBJE
>>>> 2 FORM URL
>>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>>> Benny
>>>
>>> 2009/11/24 jerome <romjerome@...>:
>>>>> so we can prepare for 3.1.3. Could
>>>>> everyone test perhaps a GEDCOM and an XML export
>>> of their
>>>>> data
>>>>> (filtered somehow), and then import again in an
>>> empty tree.
>>>>> The last
>>>>> things changes are related to that, and GEDCOM
>>> changes are
>>>>> sensitive.
>>>> I have started to test import from Gramps-3.1.3 to
>>> Gramps-3.1.3
>>>> (Ubuntu 9.04, python 2.6)
>>>>
>>>> ///// 1 warning during Gramps session ///////
>>>> (gramps.py:4609): CRITICAL **:
>>> murrine_style_draw_focus: assertion `height >= -1'
>>> failed
>>>> ///// 1 problem on GEDCOM export ///////
>>>>
>>>> "Cannot write file ..." message on dialog (on write
>>> persons)
>>>> Fixed after running rebuild 2nd indices and "Check
>>> & Repair" tools. (no problem with Gramps XML format)
>>>> Re-test is OK.
>>>> Pass without error by using :
>>>>
>>>> 1 CHAN
>>>> 2 DATE 24 NOV 2009
>>>> 3 TIME 14:29:13
>>>>
>>>> Looks like first test has blocked just before "change
>>> time" on person object !
>>>> /!\ I used my testing database (generated before new
>>> time management on Gedcom
>>>> ///// problem on GEDCOM import ///////
>>>>
>>>> WARNING .GedcomImport: Impossible d'importer http://www.geneanet.org/contact.php3?source=bouly78
>>>> WARNING .GedcomImport: Impossible d'importer http://www.geneanet.org/rgentner
>>>> WARNING .GedcomImport: Impossible d'importer
>>>> WARNING .GedcomImport: Impossible d'importer
>>>> WARNING .GedcomImport: Impossible d'importer
>>>> WARNING .GedcomImport: Impossible d'importer http://gw1.geneanet.org/index.php3?b=henriks
>>>> WARNING .GedcomImport: Impossible d'importer http://gw1.geneanet.org/index.php3?b=gengiskhan
>>>> WARNING .GedcomImport: Impossible d'importer http://gw1.geneanet.org/index.php3?b=myriague
>>>> WARNING .GedcomImport: Impossible d'importer http://www.festival-mozart.com/compositeurs/schmitt.htm
>>>>
>>>> => Cannot import url
>>>>
>>>> was generated by Gramps-3.1.3 :
>>>>
>>>> 0 @I1802@ INDI
>>>> 1 NAME Florent /SCHMITT/
>>>> 2 GIVN Florent
>>>> 2 SURN SCHMITT
>>>> 1 SEX M
>>>> 1 OBJE
>>>> 2 FORM URL
>>>> 2 FILE http://www.festival-mozart.com/compositeurs/schmitt.htm
>>>>
>>>> Now, I will try to see any diff on data (Gedcom,
>>> Gramps XML)
>>>>
>>>>
>>>> Jérôme R.
>>>>
>>>>
>>>> --- En date de : Dim 22.11.09, Benny Malengier <benny.malengier@...>
>>> a écrit :
>>>>> De: Benny Malengier <benny.malengier@...>
>>>>> Objet: preparing for 3.1.3
>>>>> À: "Gramps Development List" <gramps-devel@...>,
>>> "Jérôme" <romjerome@...>,
>>> "Stéphane Charette" <stephanecharette@...>
>>>>> Date: Dimanche 22 Novembre 2009, 10h11
>>>>> All, the roadmap is now on
>>>>> 100%, so we can prepare for 3.1.3. Could
>>>>> everyone test perhaps a GEDCOM and an XML export
>>> of their
>>>>> data
>>>>> (filtered somehow), and then import again in an
>>> empty tree.
>>>>> The last
>>>>> things changes are related to that, and GEDCOM
>>> changes are
>>>>> sensitive.
>>>>>
>>>>> Jerome, can you check the po file is up to date,
>>> perhaps
>>>>> send mail to
>>>>> translators with % completion of their language
>>> as
>>>>> information?
>>>>>
>>>>> Stephane, do you have time somewhere in the coming
>>> weeks to
>>>>> push out
>>>>> 3.1.3? I would like to see in the release notes
>>> something
>>>>> in the line
>>>>> of 'While the Gramps developers are working on a
>>> super 3.2
>>>>> release in
>>>>> a couple of months, they still had time for a
>>> minor bug fix
>>>>> release.
>>>>>
>>>>> The roadmap http://www.gramps-project.org/bugs/roadmap_page.php?version_id=15
>>>>> contains main content of this release. I think the
>>> most
>>>>> striking:
>>>>>
>>>>> * the annoying tooltip messages in latest distro's
>>> are no
>>>>> longer present
>>>>> * some GEDCOM fixes (timestamp on persons now
>>> kept, MEDI
>>>>> import, ...)
>>>>> * some data that was not present in filtered data
>>> is now
>>>>> present
>>>>> (source page, ...)
>>>>> * windows / or \ paths in webreport cleaned up
>>>>> * ...
>>>>>
>>>>> Benny
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>

From forum: GRAMPS - Dev

Re: Error when trying to add media into Album

2009-12-03T06:09:06Z

2009/12/3 Vitali Samurov <vvs@...>:
> Hi,
>
> just found from your mail about preferences.
>
> I changed 'Base path for relative media paths' to correct one and now I'm
> able to add new media! Wow, it was easy :)
>
> Btw, should I run media utility and change e.g. relative path to an
> absolute?

As to your preference. If you plan on running the dataset on different
computers, then using the relative path is the best.

Benny

>
> Br,
>
> Vitali
>
> ----- Исходное сообщение -----
>
> Ah yes. True for relative paths. However still not automatic. At best
>
> its semi-automatic using the media manager.
>
> On 12/3/09, Benny Malengier <benny.malengier@...> wrote:
>
>> 2009/12/2 Gerald Britton <gerald.britton@...>:
>
>>> Aha, I think I see. The gramps database only records the location of
>
>>> the media file. If you change the location of a media file, you have
>
>>> to (manually) change the database entry. It sounds like you did that
>
>>> part. Next, when adding a new item, you need to navigate to the
>
>>> folder where it is found. Is that where you get the error? Gramps
>
>>> should not be keeping a base directory from which to find files, I
>
>>> think.
>
>>>
>
>>
>
>> Actually, it does for relative paths, so paths not starting with / or
>
>> in windows with a drive letter. You find it in the Edit-->
>
>> Preferences. After import of a gpkg, it will point to the gpkg
>
>> location.
>
>>
>
>> Note that there is no need to manually change directory paths of media
>
>> files, there is a media manager in the tools menu for that. So if you
>
>> move your media files to another directory, use the media manager to
>
>> change the directories in Gramps too.
>
>>
>
>> About your problem with the media filename, open a person and add a
>
>> media reference, then use the browse button to select the picture you
>
>> have problems with. Make sure 'relative path' is not checked if you do
>
>> not want to use the relative path of the preferences. Click ok, then
>
>> compare the path as calculated by Gramps, with the one you entered
>
>> yourself.
>
>>
>
>> Benny
>
>>> On Wed, Dec 2, 2009 at 11:25 AM, Vitali Samurov <vvs@...> wrote:
>
>>>> Hi!
>
>>>>
>
>>>> sorry, I'm not on the GRAMPS PC right now (will send screenshots later).
>
>>>>
>
>>>> But today I've managed to reproduce the same error on my previous PC,
>
>>>> where
>
>>>> from I imported database.
>
>>>>
>
>>>> Media files have been located at this directory
>
>>>>
>
>>>> /home/GRAMPS_19-Nov-09.gpkd.media/Desktop/..../Images
>
>>>>
>
>>>> It was a result of importing from USB stick.
>
>>>>
>
>>>> Then I deleted this folder and run 'Check and Recovery database'
>>>> utility.
>
>>>> It
>
>>>> found all missed links to the media files, and I corrected it manually
>>>> to
>
>>>>
>
>>>> /home/Desktop/.../Images
>
>>>>
>
>>>> So, after I finished, utility did not find any errors, all media files
>
>>>> where
>
>>>> correctly linked.
>
>>>>
>
>>>> But if I try to add new document into Media base, I have same error.
>
>>>>
>
>>>> Looks like GRAMPS is trying to load JPEG from the old path with
>
>>>> GRAMPS_19-Nov-09.gpkd.media folder
>
>>>>
>
>>>> Br,
>
>>>>
>
>>>> Vitali
>
>>>>
>
>>>> ----- Исходное сообщение -----
>
>>>>
>
>>>> OK -- could you please send screenshots of the error you get and the
>
>>>>
>
>>>> directory with the file in it?
>
>>>>
>
>>>> On Wed, Dec 2, 2009 at 1:34 AM, Vitali Samurov <vvs@...> wrote:
>
>>>>
>
>>>>> Hi,
>
>>>>
>
>>>>>
>
>>>>
>
>>>>> the directory from error message - /home/desktop/......./<filename>.jpg
>
>>>>
>
>>>>> exists.
>
>>>>
>
>>>>> I can open image file by viewer.
>
>>>>
>
>>>>> Is it possible that GRAMPS has another directory somewhere in the
>
>>>>
>
>>>>> configuration?
>
>>>>
>
>>>>>
>
>>>>
>
>>>>> Forgot to say that I've imported the whole GRAMPS database from another
>
>>>>> PC.
>
>>>>
>
>>>>>
>
>>>>
>
>>>>> Br,
>
>>>>
>
>>>>> Vitali
>
>>>>
>
>>>>>
>
>>>>
>
>>>>> Gerald Britton wrote:
>
>>>>
>
>>>>>>
>
>>>>
>
>>>>>> Maybe the file is not in the directory?
>
>>>>
>
>>>>>>
>
>>>>
>
>>>>>> On 12/1/09, Vitali Samurov <vvs@...> wrote:
>
>>>>
>
>>>>>>
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>> Hi,
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>> I have such a message, when trying to add new media file into the
>
>>>>
>
>>>>>>> 'Media' database:
>
>>>>
>
>>>>>>> "Cannot import /home ........ .jpg The filename supplied could
>>>>>>> not
>
>>>>
>
>>>>>>> be found"
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>> All existing media records are OK, 'Check and Repair Database'
>>>>>>> utility
>
>>>>
>
>>>>>>> does not find any mistakes.
>
>>>>
>
>>>>>>> JPEGs are exists in the the folder - I can open it in the viewer.
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>> What could be the reason?
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>> I'm using GRAMPS 3.1.2-1, compiled from sources in Debian 5.0.3
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>> Br,
>
>>>>
>
>>>>>>> Vitali
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>>
>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>
>>>>
>
>>>>>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>
>>>>
>
>>>>>>> a free event focused on virtualization and cloud computing.
>
>>>>
>
>>>>>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>
>>>>
>
>>>>>>> http://p.sf.net/sfu/redhat-sfdev2dev
>
>>>>
>
>>>>>>> _______________________________________________
>
>>>>
>
>>>>>>> Gramps-users mailing list
>
>>>>
>
>>>>>>> Gramps-users@...
>
>>>>
>
>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>>
>
>>>>
>
>>>>>>
>
>>>>
>
>>>>>>
>
>>>>
>
>>>>>
>
>>>>
>
>>>>>
>
>>>>
>
>>>> --
>
>>>>
>
>>>> Gerald Britton
>
>>>
>
>>>
>
>>>
>
>>> --
>
>>> Gerald Britton
>
>>>
>
>>>
>>> ------------------------------------------------------------------------------
>
>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>
>>> a free event focused on virtualization and cloud computing.
>
>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>
>>> http://p.sf.net/sfu/redhat-sfdev2dev
>
>>> _______________________________________________
>
>>> Gramps-users mailing list
>
>>> Gramps-users@...
>
>>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>
>>>
>
>>
>
> --
>
> Sent from my mobile device
>
> Gerald Britton

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: Error when trying to add media into Album

2009-12-03T04:27:13Z

Hi,

just found from your mail about preferences.

I changed 'Base path for relative media paths' to correct one and now I'm able to add new media! Wow, it was easy :)

Btw, should I run media utility and change e.g. relative path to an absolute?

Br,

Vitali

----- Исходное сообщение -----

Ah yes. True for relative paths. However still not automatic. At best

its semi-automatic using the media manager.

On 12/3/09, Benny Malengier <benny.malengier@...> wrote:

> 2009/12/2 Gerald Britton <gerald.britton@...>:

>> Aha, I think I see. The gramps database only records the location of

>> the media file. If you change the location of a media file, you have

>> to (manually) change the database entry. It sounds like you did that

>> part. Next, when adding a new item, you need to navigate to the

>> folder where it is found. Is that where you get the error? Gramps

>> should not be keeping a base directory from which to find files, I

>> think.

> Actually, it does for relative paths, so paths not starting with / or

> in windows with a drive letter. You find it in the Edit-->

> Preferences. After import of a gpkg, it will point to the gpkg

> location.

> Note that there is no need to manually change directory paths of media

> files, there is a media manager in the tools menu for that. So if you

> move your media files to another directory, use the media manager to

> change the directories in Gramps too.

> About your problem with the media filename, open a person and add a

> media reference, then use the browse button to select the picture you

> have problems with. Make sure 'relative path' is not checked if you do

> not want to use the relative path of the preferences. Click ok, then

> compare the path as calculated by Gramps, with the one you entered

> yourself.

> Benny

>> On Wed, Dec 2, 2009 at 11:25 AM, Vitali Samurov <vvs@...> wrote:

>>> Hi!

>>>

>>> sorry, I'm not on the GRAMPS PC right now (will send screenshots later).

>>>

>>> But today I've managed to reproduce the same error on my previous PC,

>>> where

>>> from I imported database.

>>>

>>> Media files have been located at this directory

>>>

>>> /home/GRAMPS_19-Nov-09.gpkd.media/Desktop/..../Images

>>>

>>> It was a result of importing from USB stick.

>>>

>>> Then I deleted this folder and run 'Check and Recovery database' utility.

>>> It

>>> found all missed links to the media files, and I corrected it manually to

>>>

>>> /home/Desktop/.../Images

>>>

>>> So, after I finished, utility did not find any errors, all media files

>>> where

>>> correctly linked.

>>>

>>> But if I try to add new document into Media base, I have same error.

>>>

>>> Looks like GRAMPS is trying to load JPEG from the old path with

>>> GRAMPS_19-Nov-09.gpkd.media folder

>>>

>>> Br,

>>>

>>> Vitali

>>>

>>> ----- Исходное сообщение -----

>>>

>>> OK -- could you please send screenshots of the error you get and the

>>>

>>> directory with the file in it?

>>>

>>> On Wed, Dec 2, 2009 at 1:34 AM, Vitali Samurov <vvs@...> wrote:

>>>

>>>> Hi,

>>>

>>>>

>>>

>>>> the directory from error message - /home/desktop/......./<filename>.jpg

>>>

>>>> exists.

>>>

>>>> I can open image file by viewer.

>>>

>>>> Is it possible that GRAMPS has another directory somewhere in the

>>>

>>>> configuration?

>>>

>>>>

>>>

>>>> Forgot to say that I've imported the whole GRAMPS database from another

>>>> PC.

>>>

>>>>

>>>

>>>> Br,

>>>

>>>> Vitali

>>>

>>>>

>>>

>>>> Gerald Britton wrote:

>>>

>>>>>

>>>

>>>>> Maybe the file is not in the directory?

>>>

>>>>>

>>>

>>>>> On 12/1/09, Vitali Samurov <vvs@...> wrote:

>>>

>>>>>

>>>

>>>>>>

>>>

>>>>>> Hi,

>>>

>>>>>>

>>>

>>>>>> I have such a message, when trying to add new media file into the

>>>

>>>>>> 'Media' database:

>>>

>>>>>> "Cannot import /home ........ .jpg The filename supplied could not

>>>

>>>>>> be found"

>>>

>>>>>>

>>>

>>>>>> All existing media records are OK, 'Check and Repair Database' utility

>>>

>>>>>> does not find any mistakes.

>>>

>>>>>> JPEGs are exists in the the folder - I can open it in the viewer.

>>>

>>>>>>

>>>

>>>>>> What could be the reason?

>>>

>>>>>>

>>>

>>>>>> I'm using GRAMPS 3.1.2-1, compiled from sources in Debian 5.0.3

>>>

>>>>>>

>>>

>>>>>> Br,

>>>

>>>>>> Vitali

>>>

>>>>>>

>>>

>>>>>>

>>>

>>>>>>

>>>

>>>>>>

>>>>>> ------------------------------------------------------------------------------

>>>

>>>>>> Join us December 9, 2009 for the Red Hat Virtual Experience,

>>>

>>>>>> a free event focused on virtualization and cloud computing.

>>>

>>>>>> Attend in-depth sessions from your desk. Your couch. Anywhere.

>>>

>>>>>> http://p.sf.net/sfu/redhat-sfdev2dev

>>>

>>>>>> _______________________________________________

>>>

>>>>>> Gramps-users mailing list

>>>

>>>>>> Gramps-users@...

>>>

>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-users

>>>

>>>>>>

>>>

>>>>>>

>>>

>>>>>

>>>

>>>>>

>>>

>>>>

>>>

>>>>

>>>

>>> --

>>>

>>> Gerald Britton

>> --

>> Gerald Britton

>> ------------------------------------------------------------------------------

>> Join us December 9, 2009 for the Red Hat Virtual Experience,

>> a free event focused on virtualization and cloud computing.

>> Attend in-depth sessions from your desk. Your couch. Anywhere.

>> http://p.sf.net/sfu/redhat-sfdev2dev

>> _______________________________________________

>> Gramps-users mailing list

>> Gramps-users@...

>> https://lists.sourceforge.net/lists/listinfo/gramps-users

Sent from my mobile device

Gerald Britton

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: Error when trying to add media into Album

2009-12-03T04:09:56Z

Ah yes. True for relative paths. However still not automatic. At best
its semi-automatic using the media manager.

On 12/3/09, Benny Malengier <benny.malengier@...> wrote:

> 2009/12/2 Gerald Britton <gerald.britton@...>:
>> Aha, I think I see. The gramps database only records the location of
>> the media file. If you change the location of a media file, you have
>> to (manually) change the database entry. It sounds like you did that
>> part. Next, when adding a new item, you need to navigate to the
>> folder where it is found. Is that where you get the error? Gramps
>> should not be keeping a base directory from which to find files, I
>> think.
>>
>
> Actually, it does for relative paths, so paths not starting with / or
> in windows with a drive letter. You find it in the Edit-->
> Preferences. After import of a gpkg, it will point to the gpkg
> location.
>
> Note that there is no need to manually change directory paths of media
> files, there is a media manager in the tools menu for that. So if you
> move your media files to another directory, use the media manager to
> change the directories in Gramps too.
>
> About your problem with the media filename, open a person and add a
> media reference, then use the browse button to select the picture you
> have problems with. Make sure 'relative path' is not checked if you do
> not want to use the relative path of the preferences. Click ok, then
> compare the path as calculated by Gramps, with the one you entered
> yourself.
>
> Benny
>> On Wed, Dec 2, 2009 at 11:25 AM, Vitali Samurov <vvs@...> wrote:
>>> Hi!
>>>
>>> sorry, I'm not on the GRAMPS PC right now (will send screenshots later).
>>>
>>> But today I've managed to reproduce the same error on my previous PC,
>>> where
>>> from I imported database.
>>>
>>> Media files have been located at this directory
>>>
>>> /home/GRAMPS_19-Nov-09.gpkd.media/Desktop/..../Images
>>>
>>> It was a result of importing from USB stick.
>>>
>>> Then I deleted this folder and run 'Check and Recovery database' utility.
>>> It
>>> found all missed links to the media files, and I corrected it manually to
>>>
>>> /home/Desktop/.../Images
>>>
>>> So, after I finished, utility did not find any errors, all media files
>>> where
>>> correctly linked.
>>>
>>> But if I try to add new document into Media base, I have same error.
>>>
>>> Looks like GRAMPS is trying to load JPEG from the old path with
>>> GRAMPS_19-Nov-09.gpkd.media folder
>>>
>>> Br,
>>>
>>> Vitali
>>>
>>> ----- Исходное сообщение -----
>>>
>>> OK -- could you please send screenshots of the error you get and the
>>>
>>> directory with the file in it?
>>>
>>> On Wed, Dec 2, 2009 at 1:34 AM, Vitali Samurov <vvs@...> wrote:
>>>
>>>> Hi,
>>>
>>>>
>>>
>>>> the directory from error message - /home/desktop/......./<filename>.jpg
>>>
>>>> exists.
>>>
>>>> I can open image file by viewer.
>>>
>>>> Is it possible that GRAMPS has another directory somewhere in the
>>>
>>>> configuration?
>>>
>>>>
>>>
>>>> Forgot to say that I've imported the whole GRAMPS database from another
>>>> PC.
>>>
>>>>
>>>
>>>> Br,
>>>
>>>> Vitali
>>>
>>>>
>>>
>>>> Gerald Britton wrote:
>>>
>>>>>
>>>
>>>>> Maybe the file is not in the directory?
>>>
>>>>>
>>>
>>>>> On 12/1/09, Vitali Samurov <vvs@...> wrote:
>>>
>>>>>
>>>
>>>>>>
>>>
>>>>>> Hi,
>>>
>>>>>>
>>>
>>>>>> I have such a message, when trying to add new media file into the
>>>
>>>>>> 'Media' database:
>>>
>>>>>> "Cannot import /home ........ .jpg The filename supplied could not
>>>
>>>>>> be found"
>>>
>>>>>>
>>>
>>>>>> All existing media records are OK, 'Check and Repair Database' utility
>>>
>>>>>> does not find any mistakes.
>>>
>>>>>> JPEGs are exists in the the folder - I can open it in the viewer.
>>>
>>>>>>
>>>
>>>>>> What could be the reason?
>>>
>>>>>>
>>>
>>>>>> I'm using GRAMPS 3.1.2-1, compiled from sources in Debian 5.0.3
>>>
>>>>>>
>>>
>>>>>> Br,
>>>
>>>>>> Vitali
>>>
>>>>>>
>>>
>>>>>>
>>>
>>>>>>
>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>
>>>>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>>
>>>>>> a free event focused on virtualization and cloud computing.
>>>
>>>>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>>
>>>>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>>
>>>>>> _______________________________________________
>>>
>>>>>> Gramps-users mailing list
>>>
>>>>>> Gramps-users@...
>>>
>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>>>
>>>>>>
>>>
>>>>>>
>>>
>>>>>
>>>
>>>>>
>>>
>>>>
>>>
>>>>
>>>
>>> --
>>>
>>> Gerald Britton
>>
>>
>>
>> --
>> Gerald Britton
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Gramps-users mailing list
>> Gramps-users@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>>
>

--
Sent from my mobile device

Gerald Britton

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: Reporting a Bug

2009-12-03T01:04:05Z

2009/12/1 Martin Goose <news2009@...>:
> On Mon, 30 Nov 2009 20:48:12 +0100, Duncan Lithgow wrote:
>
>> > What's the problem you're having with reporting this? I assume you're
>> trying to report this at the gramps bug tracker:
>> http://www.gramps-project.org/bugs/
>
> Just forgot what to do! Went back and now reported successfully.

You have my sympathy Martin, I'm not a fan of the bug tracking system
gramps uses...

Duncan

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: Error when trying to add media into Album

2009-12-03T00:05:35Z

2009/12/2 Gerald Britton <gerald.britton@...>:
> Aha, I think I see. The gramps database only records the location of
> the media file. If you change the location of a media file, you have
> to (manually) change the database entry. It sounds like you did that
> part. Next, when adding a new item, you need to navigate to the
> folder where it is found. Is that where you get the error? Gramps
> should not be keeping a base directory from which to find files, I
> think.
>

Actually, it does for relative paths, so paths not starting with / or
in windows with a drive letter. You find it in the Edit-->
Preferences. After import of a gpkg, it will point to the gpkg
location.

Note that there is no need to manually change directory paths of media
files, there is a media manager in the tools menu for that. So if you
move your media files to another directory, use the media manager to
change the directories in Gramps too.

About your problem with the media filename, open a person and add a
media reference, then use the browse button to select the picture you
have problems with. Make sure 'relative path' is not checked if you do
not want to use the relative path of the preferences. Click ok, then
compare the path as calculated by Gramps, with the one you entered
yourself.

Benny

> On Wed, Dec 2, 2009 at 11:25 AM, Vitali Samurov <vvs@...> wrote:
>> Hi!
>>
>> sorry, I'm not on the GRAMPS PC right now (will send screenshots later).
>>
>> But today I've managed to reproduce the same error on my previous PC, where
>> from I imported database.
>>
>> Media files have been located at this directory
>>
>> /home/GRAMPS_19-Nov-09.gpkd.media/Desktop/..../Images
>>
>> It was a result of importing from USB stick.
>>
>> Then I deleted this folder and run 'Check and Recovery database' utility. It
>> found all missed links to the media files, and I corrected it manually to
>>
>> /home/Desktop/.../Images
>>
>> So, after I finished, utility did not find any errors, all media files where
>> correctly linked.
>>
>> But if I try to add new document into Media base, I have same error.
>>
>> Looks like GRAMPS is trying to load JPEG from the old path with
>> GRAMPS_19-Nov-09.gpkd.media folder
>>
>> Br,
>>
>> Vitali
>>
>> ----- Исходное сообщение -----
>>
>> OK -- could you please send screenshots of the error you get and the
>>
>> directory with the file in it?
>>
>> On Wed, Dec 2, 2009 at 1:34 AM, Vitali Samurov <vvs@...> wrote:
>>
>>> Hi,
>>
>>>
>>
>>> the directory from error message - /home/desktop/......./<filename>.jpg
>>
>>> exists.
>>
>>> I can open image file by viewer.
>>
>>> Is it possible that GRAMPS has another directory somewhere in the
>>
>>> configuration?
>>
>>>
>>
>>> Forgot to say that I've imported the whole GRAMPS database from another
>>> PC.
>>
>>>
>>
>>> Br,
>>
>>> Vitali
>>
>>>
>>
>>> Gerald Britton wrote:
>>
>>>>
>>
>>>> Maybe the file is not in the directory?
>>
>>>>
>>
>>>> On 12/1/09, Vitali Samurov <vvs@...> wrote:
>>
>>>>
>>
>>>>>
>>
>>>>> Hi,
>>
>>>>>
>>
>>>>> I have such a message, when trying to add new media file into the
>>
>>>>> 'Media' database:
>>
>>>>> "Cannot import /home ........ .jpg The filename supplied could not
>>
>>>>> be found"
>>
>>>>>
>>
>>>>> All existing media records are OK, 'Check and Repair Database' utility
>>
>>>>> does not find any mistakes.
>>
>>>>> JPEGs are exists in the the folder - I can open it in the viewer.
>>
>>>>>
>>
>>>>> What could be the reason?
>>
>>>>>
>>
>>>>> I'm using GRAMPS 3.1.2-1, compiled from sources in Debian 5.0.3
>>
>>>>>
>>
>>>>> Br,
>>
>>>>> Vitali
>>
>>>>>
>>
>>>>>
>>
>>>>>
>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>
>>>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>>
>>>>> a free event focused on virtualization and cloud computing.
>>
>>>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>>
>>>>> http://p.sf.net/sfu/redhat-sfdev2dev
>>
>>>>> _______________________________________________
>>
>>>>> Gramps-users mailing list
>>
>>>>> Gramps-users@...
>>
>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>>
>>>>>
>>
>>>>>
>>
>>>>
>>
>>>>
>>
>>>
>>
>>>
>>
>> --
>>
>> Gerald Britton
>
>
>
> --
> Gerald Britton
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Gramps-users mailing list
> Gramps-users@...
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: Error when trying to add media into Album

2009-12-02T08:41:21Z

Aha, I think I see. The gramps database only records the location of
the media file. If you change the location of a media file, you have
to (manually) change the database entry. It sounds like you did that
part. Next, when adding a new item, you need to navigate to the
folder where it is found. Is that where you get the error? Gramps
should not be keeping a base directory from which to find files, I
think.

On Wed, Dec 2, 2009 at 11:25 AM, Vitali Samurov <vvs@...> wrote:

> Hi!
>
> sorry, I'm not on the GRAMPS PC right now (will send screenshots later).
>
> But today I've managed to reproduce the same error on my previous PC, where
> from I imported database.
>
> Media files have been located at this directory
>
> /home/GRAMPS_19-Nov-09.gpkd.media/Desktop/..../Images
>
> It was a result of importing from USB stick.
>
> Then I deleted this folder and run 'Check and Recovery database' utility. It
> found all missed links to the media files, and I corrected it manually to
>
> /home/Desktop/.../Images
>
> So, after I finished, utility did not find any errors, all media files where
> correctly linked.
>
> But if I try to add new document into Media base, I have same error.
>
> Looks like GRAMPS is trying to load JPEG from the old path with
> GRAMPS_19-Nov-09.gpkd.media folder
>
> Br,
>
> Vitali
>
> ----- Исходное сообщение -----
>
> OK -- could you please send screenshots of the error you get and the
>
> directory with the file in it?
>
> On Wed, Dec 2, 2009 at 1:34 AM, Vitali Samurov <vvs@...> wrote:
>
>> Hi,
>
>>
>
>> the directory from error message - /home/desktop/......./<filename>.jpg
>
>> exists.
>
>> I can open image file by viewer.
>
>> Is it possible that GRAMPS has another directory somewhere in the
>
>> configuration?
>
>>
>
>> Forgot to say that I've imported the whole GRAMPS database from another
>> PC.
>
>>
>
>> Br,
>
>> Vitali
>
>>
>
>> Gerald Britton wrote:
>
>>>
>
>>> Maybe the file is not in the directory?
>
>>>
>
>>> On 12/1/09, Vitali Samurov <vvs@...> wrote:
>
>>>
>
>>>>
>
>>>> Hi,
>
>>>>
>
>>>> I have such a message, when trying to add new media file into the
>
>>>> 'Media' database:
>
>>>> "Cannot import /home ........ .jpg The filename supplied could not
>
>>>> be found"
>
>>>>
>
>>>> All existing media records are OK, 'Check and Repair Database' utility
>
>>>> does not find any mistakes.
>
>>>> JPEGs are exists in the the folder - I can open it in the viewer.
>
>>>>
>
>>>> What could be the reason?
>
>>>>
>
>>>> I'm using GRAMPS 3.1.2-1, compiled from sources in Debian 5.0.3
>
>>>>
>
>>>> Br,
>
>>>> Vitali
>
>>>>
>
>>>>
>
>>>>
>
>>>>
>>>> ------------------------------------------------------------------------------
>
>>>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>
>>>> a free event focused on virtualization and cloud computing.
>
>>>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>
>>>> http://p.sf.net/sfu/redhat-sfdev2dev
>
>>>> _______________________________________________
>
>>>> Gramps-users mailing list
>
>>>> Gramps-users@...
>
>>>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>
>>>>
>
>>>>
>
>>>
>
>>>
>
>>
>
>>
>
> --
>
> Gerald Britton

--
Gerald Britton

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: Error when trying to add media into Album

2009-12-02T08:25:27Z

Hi!

sorry, I'm not on the GRAMPS PC right now (will send screenshots later).

But today I've managed to reproduce the same error on my previous PC, where from I imported database.

Media files have been located at this directory

/home/GRAMPS_19-Nov-09.gpkd.media/Desktop/..../Images

It was a result of importing from USB stick.

Then I deleted this folder and run 'Check and Recovery database' utility. It found all missed links to the media files, and I corrected it manually to

/home/Desktop/.../Images

So, after I finished, utility did not find any errors, all media files where correctly linked.

But if I try to add new document into Media base, I have same error.

Looks like GRAMPS is trying to load JPEG from the old path with GRAMPS_19-Nov-09.gpkd.media folder

Br,

Vitali

----- Исходное сообщение -----

OK -- could you please send screenshots of the error you get and the

directory with the file in it?

On Wed, Dec 2, 2009 at 1:34 AM, Vitali Samurov <vvs@...> wrote:

> Hi,

> the directory from error message - /home/desktop/......./<filename>.jpg

> exists.

> I can open image file by viewer.

> Is it possible that GRAMPS has another directory somewhere in the

> configuration?

> Forgot to say that I've imported the whole GRAMPS database from another PC.

> Br,

> Vitali

> Gerald Britton wrote:

>> Maybe the file is not in the directory?

>> On 12/1/09, Vitali Samurov <vvs@...> wrote:

>>>

>>> Hi,

>>>

>>> I have such a message, when trying to add new media file into the

>>> 'Media' database:

>>> "Cannot import /home ........ .jpg The filename supplied could not

>>> be found"

>>>

>>> All existing media records are OK, 'Check and Repair Database' utility

>>> does not find any mistakes.

>>> JPEGs are exists in the the folder - I can open it in the viewer.

>>>

>>> What could be the reason?

>>>

>>> I'm using GRAMPS 3.1.2-1, compiled from sources in Debian 5.0.3

>>>

>>> Br,

>>> Vitali

>>>

>>> ------------------------------------------------------------------------------

>>> Join us December 9, 2009 for the Red Hat Virtual Experience,

>>> a free event focused on virtualization and cloud computing.

>>> Attend in-depth sessions from your desk. Your couch. Anywhere.

>>> http://p.sf.net/sfu/redhat-sfdev2dev

>>> _______________________________________________

>>> Gramps-users mailing list

>>> Gramps-users@...

>>> https://lists.sourceforge.net/lists/listinfo/gramps-users

>>>

Gerald Britton

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User

Re: how to change pedigree view

2009-12-02T07:22:23Z

If you don't need to print the view, I click on the "Pedigree view" then
right click on the person you are interested in (e.g. father, grandfather)
and then select "siblings". If it is grayed out then no siblings exist in
the db for that person.
john

On Fri, 27 Nov 2009 09:12:19 -0500, artur.kutkiewicz@...
<artur.kutkiewicz@...> wrote:

> Hi !
> I'm working with GRAMPS just few days and I can find it as excellent
> tool. However, I have found limitation and don't know how to manage this.
> Usually, when displaying pedigree we can see the tree from the youngest
> person (on the left side of the window) to the oldest (on the right side
> of the window). So, we can see really very simple tree : son - father -
> grandfather. but we can't see father siblings and grandfather siblings.
> Do you know any method to view the three differently - from oldest to
> youngest to be able see father and grandfather siblings ?
> Artur
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Gramps-users mailing list
Gramps-users@...
https://lists.sourceforge.net/lists/listinfo/gramps-users

From forum: GRAMPS - User