Nabble - GRAMPS - Dev

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

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

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

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
>>>
>>
>

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
>

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
>>
>>
>
>

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
>
>
>

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>>>
> >>
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>

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>>> >>
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>

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>>> >>
>>> >
>>> >
>>> >
>>> >
>>>
>>
>>
>>
>>
>

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

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
>>
>

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

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
>

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

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
>

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
>> >>
>> >
>> >
>> >
>> >
>>
>
>
>
>

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
>

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

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
> >>
> >
> >
> >
> >
>

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

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
>>
>
>
>
>

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
>

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
>

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
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>

Gramps-3.1.3

2009-12-02T06:27:14Z

Hello,

I saw the changelog on bug-tracker for next stable release (3.1.3) :
http://www.gramps-project.org/bugs/view_all_bug_page.php?filter=14974

I checked fixes for my reported issues and used this code since last
months, but maybe some changes like gtk.Tooltips() deprecation on Gtk
could still block a tool, a report or a dialog, no ?
http://www.gramps-project.org/bugs/view.php?id=3063

Note, I have started to look at changes on Gedcom management.
I will re-test it tonight.

Best Regards,
Jérôme R.

------------------------------------------------------------------------------
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

Re: new error crashes on startup

2009-12-02T04:12:43Z

Rob, try deleting your .gramps/gramps32.ini file, and try again. Do
you have any plugins not loading (under Help -> Plugin Status ->
Loaded Plugins, do you see any that are failing?) If this continues,
please post a bug so we don't forget.

-Doug

On Tue, Dec 1, 2009 at 7:06 PM, Rob Healey <robhealey1@...> wrote:

> Greetings:
>
> I have Gramps updated to current svn, but now I also have a crash without
> even opening the program...
> 3666: ERROR: grampsgui.py: line 395: Gramps failed to start.
> Traceback (most recent call last):
> File "/home/Frog/gramps32/src/gui/grampsgui.py", line 375, in __startgramps
> Gramps(argparser)
> File "/home/Frog/gramps32/src/gui/grampsgui.py", line 297, in __init__
> self.vm = ViewManager(dbstate, DEFAULT_SIDEBAR_ORDER)
> File "/home/Frog/gramps32/src/gui/viewmanager.py", line 272, in __init__
> self.__build_main_window()
> File "/home/Frog/gramps32/src/gui/viewmanager.py", line 330, in
> __build_main_window
> self.uimanager, self.progress_monitor, self)
> File "/home/Frog/gramps32/src/DisplayState.py", line 325, in __init__
> self.last_bar = self.status.insert(min_width=15, ralign=True)
> File "/home/Frog/gramps32/src/widgets/statusbar.py", line 167, in insert
> label.set_alignment(xalign=1.0, yalign=0.5)
> AttributeError: 'gtk.HBox' object has no attribute 'set_alignment'
>
> 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
>
>

Re: Custom Tool is causing problems with events in DB

2009-12-02T01:08:34Z

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

> Whenever you retrieve an object from the database, you should check
> that it is really an object before using it. That can be as simple
> as:
>
> if not event:
> return # didn't get an event
>
> to as specific as something like:
>
> if not isinstance(event, EventType):
> return # don't know what I got, but it's not an event!
>
> it could be that you are deleting the event objects, but not all the
> references to them. If so, you'll need to do a Rebuild Reference Maps
> when you are done running your custom tool.

Yes,

so the None comes from obtaining an event that no longer is present in
the database, which means that None is returned.

Looking at your code,
event_refs = [event.ref for event in person.get_event_ref_list()]
can contain duplicate ref handles, so
event_refs = set([event.ref for event in person.get_event_ref_list()])
would be more appropriate as it will remove the duplicates.

Benny

>
>
> On Tue, Dec 1, 2009 at 4:57 PM, Jon Clements <joncle@...> wrote:
>> Hi all,
>>
>> I hope this is the right list to post to, as the others lists didn't
>> seem appropriate.
>>
>> Gramps 3.1.1 (as I'm needing to remain compatible with a user running
>> the Portable edition for Windows) built from source on Ubuntu 9.04.
>>
>> I've written a tool which basically removes duplicate events (simply
>> based on type & year to start, but will be 'smarter' later), which runs
>> successfully (judging by the fact the events disappear from the event
>> tab). Please see http://pastebin.com/m716e3fb9 - it's short.
>>
>> However, if I then want to run the 'create event descriptions' (which
>> the above code was modeled on) tool, I get the following error message:
>>
>> 751626: ERROR: _Tool.py: line 252: Failed to start tool.
>> Traceback (most recent call last):
>> File "/usr/local/share/gramps/PluginUtils/_Tool.py", line 248, in gui_tool
>> tool_class(dbstate, uistate, options_class, name, callback)
>> File "/usr/local/share/gramps/plugins/tool/EventNames.py", line 74, in
>> __init__
>> self.run()
>> File "/usr/local/share/gramps/plugins/tool/EventNames.py", line 92, in run
>> if event.get_description() == "":
>> AttributeError: 'NoneType' object has no attribute 'get_description'
>>
>> Where are the None objects coming from in the database? I'm guessing I
>> haven't deleted them properly, and there's some sort of dangling
>> reference somewhere which is still classed as an event, but unusable as
>> one?
>>
>> I'm sure it's me doing something stupid, but I'd appreciate some pointers.
>>
>> Please yell if I can provide further information that may be of use.
>>
>> Cheers,
>>
>> Jon.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> --
> 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
>

new error crashes on startup

2009-12-01T16:06:24Z

Greetings:

I have Gramps updated to current svn, but now I also have a crash without even opening the program...

3666: ERROR: grampsgui.py: line 395: Gramps failed to start.
Traceback (most recent call last):
File "/home/Frog/gramps32/src/gui/grampsgui.py", line 375, in __startgramps
Gramps(argparser)
File "/home/Frog/gramps32/src/gui/grampsgui.py", line 297, in __init__
self.vm = ViewManager(dbstate, DEFAULT_SIDEBAR_ORDER)
File "/home/Frog/gramps32/src/gui/viewmanager.py", line 272, in __init__
self.__build_main_window()
File "/home/Frog/gramps32/src/gui/viewmanager.py", line 330, in __build_main_window
self.uimanager, self.progress_monitor, self)
File "/home/Frog/gramps32/src/DisplayState.py", line 325, in __init__
self.last_bar = self.status.insert(min_width=15, ralign=True)
File "/home/Frog/gramps32/src/widgets/statusbar.py", line 167, in insert
label.set_alignment(xalign=1.0, yalign=0.5)
AttributeError: 'gtk.HBox' object has no attribute 'set_alignment'

Sincerely yours,

Rob G. Healey

Re: Custom Tool is causing problems with events in DB

2009-12-01T14:05:45Z

Whenever you retrieve an object from the database, you should check
that it is really an object before using it. That can be as simple
as:

if not event:
return # didn't get an event

to as specific as something like:

if not isinstance(event, EventType):
return # don't know what I got, but it's not an event!

it could be that you are deleting the event objects, but not all the
references to them. If so, you'll need to do a Rebuild Reference Maps
when you are done running your custom tool.

On Tue, Dec 1, 2009 at 4:57 PM, Jon Clements <joncle@...> wrote:

> Hi all,
>
> I hope this is the right list to post to, as the others lists didn't
> seem appropriate.
>
> Gramps 3.1.1 (as I'm needing to remain compatible with a user running
> the Portable edition for Windows) built from source on Ubuntu 9.04.
>
> I've written a tool which basically removes duplicate events (simply
> based on type & year to start, but will be 'smarter' later), which runs
> successfully (judging by the fact the events disappear from the event
> tab). Please see http://pastebin.com/m716e3fb9 - it's short.
>
> However, if I then want to run the 'create event descriptions' (which
> the above code was modeled on) tool, I get the following error message:
>
> 751626: ERROR: _Tool.py: line 252: Failed to start tool.
> Traceback (most recent call last):
> File "/usr/local/share/gramps/PluginUtils/_Tool.py", line 248, in gui_tool
> tool_class(dbstate, uistate, options_class, name, callback)
> File "/usr/local/share/gramps/plugins/tool/EventNames.py", line 74, in
> __init__
> self.run()
> File "/usr/local/share/gramps/plugins/tool/EventNames.py", line 92, in run
> if event.get_description() == "":
> AttributeError: 'NoneType' object has no attribute 'get_description'
>
> Where are the None objects coming from in the database? I'm guessing I
> haven't deleted them properly, and there's some sort of dangling
> reference somewhere which is still classed as an event, but unusable as
> one?
>
> I'm sure it's me doing something stupid, but I'd appreciate some pointers.
>
> Please yell if I can provide further information that may be of use.
>
> Cheers,
>
> Jon.
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

--
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

Custom Tool is causing problems with events in DB

2009-12-01T13:57:29Z

Hi all,

I hope this is the right list to post to, as the others lists didn't
seem appropriate.

Gramps 3.1.1 (as I'm needing to remain compatible with a user running
the Portable edition for Windows) built from source on Ubuntu 9.04.

I've written a tool which basically removes duplicate events (simply
based on type & year to start, but will be 'smarter' later), which runs
successfully (judging by the fact the events disappear from the event
tab). Please see http://pastebin.com/m716e3fb9 - it's short.

However, if I then want to run the 'create event descriptions' (which
the above code was modeled on) tool, I get the following error message:

751626: ERROR: _Tool.py: line 252: Failed to start tool.
Traceback (most recent call last):
File "/usr/local/share/gramps/PluginUtils/_Tool.py", line 248, in gui_tool
tool_class(dbstate, uistate, options_class, name, callback)
File "/usr/local/share/gramps/plugins/tool/EventNames.py", line 74, in
__init__
self.run()
File "/usr/local/share/gramps/plugins/tool/EventNames.py", line 92, in run
if event.get_description() == "":
AttributeError: 'NoneType' object has no attribute 'get_description'

Where are the None objects coming from in the database? I'm guessing I
haven't deleted them properly, and there's some sort of dangling
reference somewhere which is still classed as an event, but unusable as
one?

I'm sure it's me doing something stupid, but I'd appreciate some pointers.

Please yell if I can provide further information that may be of use.

Cheers,

Jon.

------------------------------------------------------------------------------
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

Re: 0003400: Media Files associated to living persons are not blacklisted

2009-11-30T13:13:23Z

Dear Duncan:

I had never thought of it like that, but you are correct..

Sincerely yours,

Rob G. Healey

On Mon, Nov 30, 2009 at 5:01 AM, Duncan Lithgow <duncan.lithgow@...> wrote:

I've just filed this bug report which I think needs wider discussion:
http://www.gramps-project.org/bugs/view.php?id=3400

The report is:

At the moment the only media file which is hidden by the 'living
people' privacy filter is the first file (typically an image of the
person).

Surely all associated media files should be black listed when a person
is regarded as living? Even if you argue that images of someone
without their name are meaningless and harmless, still, media files
containing private correspondence and put to the web by Gramps can be
a big breach of trust between the researcher and their family.

Confidentiality and trust are key for getting living relatives to open
up and talk about their lives. Their data needs better protection, we
should lean to being overly cautious and work back from there.

Duncan

------------------------------------------------------------------------------
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

Re: Trunk > Narrative Website: AttributeError: 'PlacePage' object has no attribute 'bibli'

2009-11-30T13:05:39Z

Dear Benny and Gary:

If the mistake was my fault, I agree that I should fix it... At that point I am not sure if it was me or not because I didn't see the one who did it in the first place...

I have been messing around with trunk and NarrativeWeb a lot here lately...

Sincerely,

Rob G. Healey

On Mon, Nov 30, 2009 at 12:17 AM, Benny Malengier <benny.malengier@...> wrote:

2009/11/29 Duncan Lithgow <duncan.lithgow@...>:
> Thanks. Could someone remind me - do we always use the tracker for
> bugs in trunk? I had the impression that for trunk we just check with
> an email first because trunk is constantly hitting small bugs.

If you know the person responsible, you make a bug and assign it to
the person who introduced the bug.
Otherwise, making a bug and assigning to the roadmap is the only way
to keep track of issues. Obviously a glaring bug as the one you find
here will be fixed before release, but more simple ones easily get
forgotten (eg, in the filter editor, do rules now not print wrong in
the listview?)

Benny

> Duncan

>
> ------------------------------------------------------------------------------
> 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

Re: Licensing thoughts from the old guy

2009-11-30T09:23:36Z

Hello Benny

> On the other hand, I think it is good that
> things like Gedcom to gramps-xml conversion can be done under GPL and
> not AGPL, as we want to encourage maximum use of the gramps-xml
> format, even if the conversion is done as a web service.

Encouraging maximum use of Gramps XML is good, but I think the implementation needs protecting to prevent someone from hiding a modified version behind a web server which produces a modified, but incompatible, version of Gramps XML.

Bye

Gary

------------------------------------------------------------------------------
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

Re: [Gramps-users] GeoView : crash in ubuntu karmic

2009-11-30T08:11:27Z

Benny,

> GeoView is experimental because with 3.1.x there is no easy way to
> switch it off, and the only way to enable it for users is to
> distribute it with the default install.
> This is one of the reasons views are plugins in 3.2.

It was not a "real" patch... :-[
I know that views are plugins on 3.2 only and that GeoView is loaded on
DataView/_init_.py

try:
from GeoView import HtmlView, GeoView
except:
geopresent = False

I also know that we can remove some views (PedigreeView) without crash
on stable release... OK, it was not designed for that, maybe unsafe ?

I suppose we can try to remove (just for testing) some views on .ini
file, isn't it ?

> we really would like to avoid if it is due only to Geoview.

Why not enable/disable GeoView on .ini for testing ?

data-views=GrampletView,PersonView,RelationshipView,FamilyListView,PedigreeView,EventView,SourceView,PlaceView,MediaView,RepositoryView,NoteView

So GeoView should not be loaded, isn't it ?

If we still get a crash, then maybe there is something else !

Jérôme

Benny Malengier a écrit :

> Jerome,
>
> all the concerns raised here have been addressed in upcoming version 3.2
> GeoView is experimental because with 3.1.x there is no easy way to
> switch it off, and the only way to enable it for users is to
> distribute it with the default install.
> This is one of the reasons views are plugins in 3.2.
>
> So, for the 3.1.x series, Geoview remains experimental, but it should
> be stable. The problem with Karmic showed that just importing a lib
> can make Gramps crash, which is a behaviour we really would like to
> avoid if it is due only to Geoview. I think the changes of Serge in
> branch31 have fixed this issue.
>
> Benny
>
> 2009/11/30 Jérôme <romjerome@...>:
>> No, but suggest on first download :
>> http://www.gramps-project.org/wiki/index.php?title=Third-party_Plugins
>> documentation :
>> http://www.gramps-project.org/wiki/index.php?title=GeoView
>> and wiki manual :
>> http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Main_Window#HTML_View_.28optional.29
>>
>> I suppose, as most 3rd party-plugins, this is not a part of sources (tarball
>> for release). So users need to download this additionnal feature.
>>
>> See also minor goals on roadmap (3.2) :
>> http://www.gramps-project.org/wiki/index.php?title=Roadmap#Minor_goals
>>
>> Note, how do you enable GeoView ?
>> User need to modify the .ini file ... That's not very user-friendly.
>> If I take the risk to modify the stable code, then I know this could be
>> unstable and became experimental (not fully tested).
>>
>> Ohhhh I made a mistake !
>> GeoView is on tarball ... (see src/DataView/Makefile.am)
>>
>>> pkgdata_PYTHON = \
>>> __init__.py\
>>> GeoView.py\
>>> GrampletView.py\
>>> PersonView.py\
>>> RelationView.py\
>>> FamilyList.py\
>>> PedigreeView.py\
>>> EventView.py\
>>> SourceView.py\
>>> PlaceView.py\
>>> MediaView.py\
>>> NoteView.py\
>>> RepositoryView.py
>>>
>>> # _MapView.py
>> So, I could provide an easy fix for Ubuntu karmic ...
>>
>> src/DataView/Makefile.am
>>
>> pkgdata_PYTHON = \
>> __init__.py\
>> # GeoView.py\
>> GrampletView.py\
>>
>>
>> Note, I try to avoid to have the same plugin on multiple places
>> (.gramps/plugins /usr/share/gramps/plugins). Is it really safe to provide
>> GeoView on 3.1 *and* on 3r party plugins ?
>>
>>
>>
>> Jérôme
>>
>>
>>
>>
>> Duncan Lithgow a écrit :
>>> 2009/11/30 Jérôme <romjerome@...>:
>>>> GeoView is marked as experimental on 3.1.x, isn't it ?
>>> The text in the 'Internet Maps' tab of preferences does not suggest
>>> that GeoView is unstable
>>>
>>> Duncan
>>>
>>
>

------------------------------------------------------------------------------
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