gramps

On Jul 23, 2012, at 6:39 PM, Doug Blank wrote:

> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier
> <benny.malengier@...> wrote:
>> Ok,
>> 
>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk.
>> 
>> So crashes abound now. most fixes are simple, look at the changelog done for
>> equal code, and change likewise:
>> 
>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057
>> 
>> All glade files not touched yet should be opened in current glade for GTK3
>> and resaved, then fixed for layout problems. Seen changes in glade files
>> fixed already by me in case of issues.
>> 
>> For documentation links, and how to install the new requirements, see the
>> GEP:
>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion
>> 
>> Fixing the crashes in a part will make you acquinted with the new way of
>> working.
>> 
>> I'll fix futher things the coming days.
>> 
>> Main issue will probably be geography view which is now disabled. If needed
>> we will have to help out in porting the dependency. On the plus side, the
>> developer will know the code will be used immediately, helping to find bugs.
>> 
>> Benny
> 
> Great to see this happening!
> 
> BTW, I did have a strange hard-crash on Python 2.7.2 without the
> proper pygobject. (I'll no doubt be helping with this port, but I'm
> still working hard to get Gramps-Connect to a near-finished state. So,
> initially I'm just making sure that the CLI use of Gramps works ok
> even without the proper pygobject, as it should.)
> 
> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash
> without the ability to try/except when you try to import webkit from a
> Gramps plugin. However, if you "import gtk" early on, then later
> "import webkit" it won't crash. Just thought I'd mention this in case
> anyone is having trouble getting started on the new Gramps...

That's an interesting crash. Did you look at the C backtrace?

> shall we call this Gramps 4.0?

I think we'll need to have a bunch of testing releases, so we should probably call it 3.90.x for a while.

Regards,
John Ralls

On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jralls@...> wrote:
>
> On Jul 23, 2012, at 6:39 PM, Doug Blank wrote:
>
>> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier
>> <benny.malengier@...> wrote:
>>> Ok,
>>>
>>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk.
>>>
>>> So crashes abound now. most fixes are simple, look at the changelog done for
>>> equal code, and change likewise:
>>>
>>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057
>>>
>>> All glade files not touched yet should be opened in current glade for GTK3
>>> and resaved, then fixed for layout problems. Seen changes in glade files
>>> fixed already by me in case of issues.
>>>
>>> For documentation links, and how to install the new requirements, see the
>>> GEP:
>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion
>>>
>>> Fixing the crashes in a part will make you acquinted with the new way of
>>> working.
>>>
>>> I'll fix futher things the coming days.
>>>
>>> Main issue will probably be geography view which is now disabled. If needed
>>> we will have to help out in porting the dependency. On the plus side, the
>>> developer will know the code will be used immediately, helping to find bugs.
>>>
>>> Benny
>>
>> Great to see this happening!
>>
>> BTW, I did have a strange hard-crash on Python 2.7.2 without the
>> proper pygobject. (I'll no doubt be helping with this port, but I'm
>> still working hard to get Gramps-Connect to a near-finished state. So,
>> initially I'm just making sure that the CLI use of Gramps works ok
>> even without the proper pygobject, as it should.)
>>
>> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash
>> without the ability to try/except when you try to import webkit from a
>> Gramps plugin. However, if you "import gtk" early on, then later
>> "import webkit" it won't crash. Just thought I'd mention this in case
>> anyone is having trouble getting started on the new Gramps...
>
> That's an interesting crash. Did you look at the C backtrace?
>
>> shall we call this Gramps 4.0?
>
> I think we'll need to have a bunch of testing releases, so we should probably call it 3.90.x for a while.

I guess with Gramps the x.9 status is implied. For example, trunk has
been called "3.3" and "3.4" at various times (and is "3.5" currently)
so that the addon version numbers will match. (The addons need to
match at least major version number with Gramps.) SVN versions get
appended onto the displayed version number (after updating const.py
with ./autogen.sh), so we always can tell one is running trunk.

Since we don't have an official release until it is really ready (and
usually follow that up with a few point releases) the name is really
just a place holder. But I thought it might be nice to move it from
"3.5" to "4.0" to indicate that trunk is now on a
backwards-incompatible path, and give a clear point for people's
reference.

-Doug

> Regards,
> John Ralls
>

On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jralls@...> wrote:
>
> On Jul 23, 2012, at 6:39 PM, Doug Blank wrote:
>
>> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier
>> <benny.malengier@...> wrote:
>>> Ok,
>>>
>>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk.
>>>
>>> So crashes abound now. most fixes are simple, look at the changelog done for
>>> equal code, and change likewise:
>>>
>>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057
>>>
>>> All glade files not touched yet should be opened in current glade for GTK3
>>> and resaved, then fixed for layout problems. Seen changes in glade files
>>> fixed already by me in case of issues.
>>>
>>> For documentation links, and how to install the new requirements, see the
>>> GEP:
>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion
>>>
>>> Fixing the crashes in a part will make you acquinted with the new way of
>>> working.
>>>
>>> I'll fix futher things the coming days.
>>>
>>> Main issue will probably be geography view which is now disabled. If needed
>>> we will have to help out in porting the dependency. On the plus side, the
>>> developer will know the code will be used immediately, helping to find bugs.
>>>
>>> Benny
>>
>> Great to see this happening!
>>
>> BTW, I did have a strange hard-crash on Python 2.7.2 without the
>> proper pygobject. (I'll no doubt be helping with this port, but I'm
>> still working hard to get Gramps-Connect to a near-finished state. So,
>> initially I'm just making sure that the CLI use of Gramps works ok
>> even without the proper pygobject, as it should.)
>>
>> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash
>> without the ability to try/except when you try to import webkit from a
>> Gramps plugin. However, if you "import gtk" early on, then later
>> "import webkit" it won't crash. Just thought I'd mention this in case
>> anyone is having trouble getting started on the new Gramps...
>
> That's an interesting crash. Did you look at the C backtrace?

How do you get a C backtrace?

I was only able to narrow down the problem by using strace, and
entering commands one at a time in an interactive Python shell.

-Doug

>> shall we call this Gramps 4.0?
>
> I think we'll need to have a bunch of testing releases, so we should probably call it 3.90.x for a while.
>
> Regards,
> John Ralls
>

On Jul 23, 2012, at 8:37 PM, Doug Blank wrote:

> On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jralls@...> wrote:
>> 
>> On Jul 23, 2012, at 6:39 PM, Doug Blank wrote:
>> 
>>> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier
>>> <benny.malengier@...> wrote:
>>>> Ok,
>>>> 
>>>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk.
>>>> 
>>>> So crashes abound now. most fixes are simple, look at the changelog done for
>>>> equal code, and change likewise:
>>>> 
>>>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057
>>>> 
>>>> All glade files not touched yet should be opened in current glade for GTK3
>>>> and resaved, then fixed for layout problems. Seen changes in glade files
>>>> fixed already by me in case of issues.
>>>> 
>>>> For documentation links, and how to install the new requirements, see the
>>>> GEP:
>>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion
>>>> 
>>>> Fixing the crashes in a part will make you acquinted with the new way of
>>>> working.
>>>> 
>>>> I'll fix futher things the coming days.
>>>> 
>>>> Main issue will probably be geography view which is now disabled. If needed
>>>> we will have to help out in porting the dependency. On the plus side, the
>>>> developer will know the code will be used immediately, helping to find bugs.
>>>> 
>>>> Benny
>>> 
>>> Great to see this happening!
>>> 
>>> BTW, I did have a strange hard-crash on Python 2.7.2 without the
>>> proper pygobject. (I'll no doubt be helping with this port, but I'm
>>> still working hard to get Gramps-Connect to a near-finished state. So,
>>> initially I'm just making sure that the CLI use of Gramps works ok
>>> even without the proper pygobject, as it should.)
>>> 
>>> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash
>>> without the ability to try/except when you try to import webkit from a
>>> Gramps plugin. However, if you "import gtk" early on, then later
>>> "import webkit" it won't crash. Just thought I'd mention this in case
>>> anyone is having trouble getting started on the new Gramps...
>> 
>> That's an interesting crash. Did you look at the C backtrace?
> 
> How do you get a C backtrace?
> 
> I was only able to narrow down the problem by using strace, and
> entering commands one at a time in an interactive Python shell.

The easy way is to use a Mac, which always writes a backtrace in its crash reports. ;-)

Otherwise:

$ > gdb python
(gdb) set env GRAMPSHOME /path/to/gramps/src
(gdb) set env PYTHONPATH $PYTHONPATH:$GRAMPSHOME
(gdb) r $GRAMPSHOME/gramps.py
...after the crash...
(gdb) bt

This works best if you have the debug symbols installed for everything relevant, or are running from a self-built tree. Frankly,
given the current state of pygi, I really recommend running the current git master for GLib, Gtk, GObject-Introspection, and
PyGobject -- built with debug, of course. Jhbuild makes that reasonably painless.

Regards,
John Ralls

On Jul 23, 2012, at 8:34 PM, Doug Blank wrote:

> On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jralls@...> wrote:
>> 
>> On Jul 23, 2012, at 6:39 PM, Doug Blank wrote:
>> 
>>> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier
>>> <benny.malengier@...> wrote:
>>>> Ok,
>>>> 
>>>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk.
>>>> 
>>>> So crashes abound now. most fixes are simple, look at the changelog done for
>>>> equal code, and change likewise:
>>>> 
>>>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057
>>>> 
>>>> All glade files not touched yet should be opened in current glade for GTK3
>>>> and resaved, then fixed for layout problems. Seen changes in glade files
>>>> fixed already by me in case of issues.
>>>> 
>>>> For documentation links, and how to install the new requirements, see the
>>>> GEP:
>>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion
>>>> 
>>>> Fixing the crashes in a part will make you acquinted with the new way of
>>>> working.
>>>> 
>>>> I'll fix futher things the coming days.
>>>> 
>>>> Main issue will probably be geography view which is now disabled. If needed
>>>> we will have to help out in porting the dependency. On the plus side, the
>>>> developer will know the code will be used immediately, helping to find bugs.
>>>> 
>>>> Benny
>>> 
>>> Great to see this happening!
>>> 
>>> BTW, I did have a strange hard-crash on Python 2.7.2 without the
>>> proper pygobject. (I'll no doubt be helping with this port, but I'm
>>> still working hard to get Gramps-Connect to a near-finished state. So,
>>> initially I'm just making sure that the CLI use of Gramps works ok
>>> even without the proper pygobject, as it should.)
>>> 
>>> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash
>>> without the ability to try/except when you try to import webkit from a
>>> Gramps plugin. However, if you "import gtk" early on, then later
>>> "import webkit" it won't crash. Just thought I'd mention this in case
>>> anyone is having trouble getting started on the new Gramps...
>> 
>> That's an interesting crash. Did you look at the C backtrace?
>> 
>>> shall we call this Gramps 4.0?
>> 
>> I think we'll need to have a bunch of testing releases, so we should probably call it 3.90.x for a while.
> 
> I guess with Gramps the x.9 status is implied. For example, trunk has
> been called "3.3" and "3.4" at various times (and is "3.5" currently)
> so that the addon version numbers will match. (The addons need to
> match at least major version number with Gramps.) SVN versions get
> appended onto the displayed version number (after updating const.py
> with ./autogen.sh), so we always can tell one is running trunk.
> 
> Since we don't have an official release until it is really ready (and
> usually follow that up with a few point releases) the name is really
> just a place holder. But I thought it might be nice to move it from
> "3.5" to "4.0" to indicate that trunk is now on a
> backwards-incompatible path, and give a clear point for people's
> reference.

OK. I'd forgotten about the plugin requirement, so my suggestion followed the Gnome practice.
But it's definitely time for a new major number. 

Thanks to BDB being a bit of a moving target, I think everyone's used to backwards-incompatiblity. :-\.

Regards,
John Ralls

2012/7/24 Doug Blank <doug.blank@...>

> On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jralls@...> wrote:
> >
> > On Jul 23, 2012, at 6:39 PM, Doug Blank wrote:
> >
> >> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier
> >> <benny.malengier@...> wrote:
> >>> Ok,
> >>>
> >>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk.
> >>>
> >>> So crashes abound now. most fixes are simple, look at the changelog
> done for
> >>> equal code, and change likewise:
> >>>
> >>>
> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057
> >>>
> >>> All glade files not touched yet should be opened in current glade for
> GTK3
> >>> and resaved, then fixed for layout problems. Seen changes in glade
> files
> >>> fixed already by me in case of issues.
> >>>
> >>> For documentation links, and how to install the new requirements, see
> the
> >>> GEP:
> >>>
> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion
> >>>
> >>> Fixing the crashes in a part will make you acquinted with the new way
> of
> >>> working.
> >>>
> >>> I'll fix futher things the coming days.
> >>>
> >>> Main issue will probably be geography view which is now disabled. If
> needed
> >>> we will have to help out in porting the dependency. On the plus side,
> the
> >>> developer will know the code will be used immediately, helping to find
> bugs.
> >>>
> >>> Benny
> >>
> >> Great to see this happening!
> >>
> >> BTW, I did have a strange hard-crash on Python 2.7.2 without the
> >> proper pygobject. (I'll no doubt be helping with this port, but I'm
> >> still working hard to get Gramps-Connect to a near-finished state. So,
> >> initially I'm just making sure that the CLI use of Gramps works ok
> >> even without the proper pygobject, as it should.)
> >>
> >> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash
> >> without the ability to try/except when you try to import webkit from a
> >> Gramps plugin. However, if you "import gtk" early on, then later
> >> "import webkit" it won't crash. Just thought I'd mention this in case
> >> anyone is having trouble getting started on the new Gramps...
> >
> > That's an interesting crash. Did you look at the C backtrace?
> >
> >> shall we call this Gramps 4.0?
> >
> > I think we'll need to have a bunch of testing releases, so we should
> probably call it 3.90.x for a while.
>
> I guess with Gramps the x.9 status is implied. For example, trunk has
> been called "3.3" and "3.4" at various times (and is "3.5" currently)
> so that the addon version numbers will match. (The addons need to
> match at least major version number with Gramps.) SVN versions get
> appended onto the displayed version number (after updating const.py
> with ./autogen.sh), so we always can tell one is running trunk.
>
> Since we don't have an official release until it is really ready (and
> usually follow that up with a few point releases) the name is really
> just a place holder. But I thought it might be nice to move it from
> "3.5" to "4.0" to indicate that trunk is now on a
> backwards-incompatible path, and give a clear point for people's
> reference.
>

Yes, this should be version 4.0 later.
Can you do the changes? As you know gramps-addons better, you should have a
good view on what to change.

It is a pity we can't do the 3.99 thing, but a release called 4.0-0.alpha
is not a big issue if communication is done correctly.

About webkit, we are not to do import gtk anywhere in the code! In the docs
I read they claim this leads to issues. As geography is not ready, I also
did not test htmlview.
As to allowing lower gi version number for CLI, that is not a problem.

B.


> -Doug
>
> > Regards,
> > John Ralls
> >
>

On Tue, Jul 24, 2012 at 2:54 AM, Benny Malengier
<benny.malengier@...> wrote:
>
>
> 2012/7/24 Doug Blank <doug.blank@...>
>>
>> On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jralls@...> wrote:
>> >
>> > On Jul 23, 2012, at 6:39 PM, Doug Blank wrote:
>> >
>> >> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier
>> >> <benny.malengier@...> wrote:
>> >>> Ok,
>> >>>
>> >>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk.
>> >>>
>> >>> So crashes abound now. most fixes are simple, look at the changelog
>> >>> done for
>> >>> equal code, and change likewise:
>> >>>
>> >>>
>> >>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057
>> >>>
>> >>> All glade files not touched yet should be opened in current glade for
>> >>> GTK3
>> >>> and resaved, then fixed for layout problems. Seen changes in glade
>> >>> files
>> >>> fixed already by me in case of issues.
>> >>>
>> >>> For documentation links, and how to install the new requirements, see
>> >>> the
>> >>> GEP:
>> >>>
>> >>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion
>> >>>
>> >>> Fixing the crashes in a part will make you acquinted with the new way
>> >>> of
>> >>> working.
>> >>>
>> >>> I'll fix futher things the coming days.
>> >>>
>> >>> Main issue will probably be geography view which is now disabled. If
>> >>> needed
>> >>> we will have to help out in porting the dependency. On the plus side,
>> >>> the
>> >>> developer will know the code will be used immediately, helping to find
>> >>> bugs.
>> >>>
>> >>> Benny
>> >>
>> >> Great to see this happening!
>> >>
>> >> BTW, I did have a strange hard-crash on Python 2.7.2 without the
>> >> proper pygobject. (I'll no doubt be helping with this port, but I'm
>> >> still working hard to get Gramps-Connect to a near-finished state. So,
>> >> initially I'm just making sure that the CLI use of Gramps works ok
>> >> even without the proper pygobject, as it should.)
>> >>
>> >> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash
>> >> without the ability to try/except when you try to import webkit from a
>> >> Gramps plugin. However, if you "import gtk" early on, then later
>> >> "import webkit" it won't crash. Just thought I'd mention this in case
>> >> anyone is having trouble getting started on the new Gramps...
>> >
>> > That's an interesting crash. Did you look at the C backtrace?
>> >
>> >> shall we call this Gramps 4.0?
>> >
>> > I think we'll need to have a bunch of testing releases, so we should
>> > probably call it 3.90.x for a while.
>>
>> I guess with Gramps the x.9 status is implied. For example, trunk has
>> been called "3.3" and "3.4" at various times (and is "3.5" currently)
>> so that the addon version numbers will match. (The addons need to
>> match at least major version number with Gramps.) SVN versions get
>> appended onto the displayed version number (after updating const.py
>> with ./autogen.sh), so we always can tell one is running trunk.
>>
>> Since we don't have an official release until it is really ready (and
>> usually follow that up with a few point releases) the name is really
>> just a place holder. But I thought it might be nice to move it from
>> "3.5" to "4.0" to indicate that trunk is now on a
>> backwards-incompatible path, and give a clear point for people's
>> reference.
>
>
> Yes, this should be version 4.0 later.
> Can you do the changes? As you know gramps-addons better, you should have a
> good view on what to change.

Done. There appears to be an error in ./autogen.sh so make sure you at least:

cp src/gen/const.py.in src/gen/const.py

> It is a pity we can't do the 3.99 thing, but a release called 4.0-0.alpha is
> not a big issue if communication is done correctly.
>
> About webkit, we are not to do import gtk anywhere in the code! In the docs
> I read they claim this leads to issues. As geography is not ready, I also
> did not test htmlview.

Yes, I just meant this as a workaround. But I think I found the root
of the problem and made more notes at:
http://gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion

> As to allowing lower gi version number for CLI, that is not a problem.

As we approach the next release, it looks like it will be entirely
possible to have a core gramps package without GUI code, for use in
Gramps-Connect, etc. However, by moving all of the graphics subsystems
(including PDF creation) to pygobject and friends, that substantially
raises the bar for what is needed in a server-based install. For
example, I can run gramps-connect with Gramps 4.0 on Python 2.6,
Django 1.2 on an old Fedora 13 machine (in fact it is running on
http://gramps-connect.org right now). But, I had to use
src/plugins/lib/libcairodoc.py and src/plugins/docgen/pdfdoc.py from
Gramps 3.5 to allow PDF creation from the webserver.

I wonder how we can have both the newer versions, and the older
versions? Maybe we could add something else to the gpr file, so that
one would load in gramps-gtk, and the other in gramps-connect?

-Doug

> B.
>
>>
>> -Doug
>>
>> > Regards,
>> > John Ralls
>> >
>
>

2012/7/24 John Ralls <jralls@...>

> Frankly,
> given the current state of pygi, I really recommend running the current
> git master for GLib, Gtk, GObject-Introspection, and
> PyGobject -- built with debug, of course. Jhbuild makes that reasonably
> painless.
>
>
I tried jhbuild some months ago, but after two days of compiling, I gave
up, and just got the git tree of gobject.

There really should be better documentation for jhbuild, like, if you only
need gobject and gtk for gramps, how do you set up jhbuild up to the point
you have gramps working with the new libs

Benny


> Regards,
> John Ralls
>
>

On Jul 24, 2012, at 12:29 AM, Doug Blank wrote:

> On Tue, Jul 24, 2012 at 2:54 AM, Benny Malengier
> <benny.malengier@...> wrote:
>> 
>> 
>> 2012/7/24 Doug Blank <doug.blank@...>
>>> 
>>> On Mon, Jul 23, 2012 at 11:11 PM, John Ralls <jralls@...> wrote:
>>>> 
>>>> On Jul 23, 2012, at 6:39 PM, Doug Blank wrote:
>>>> 
>>>>> On Mon, Jul 23, 2012 at 5:05 PM, Benny Malengier
>>>>> <benny.malengier@...> wrote:
>>>>>> Ok,
>>>>>> 
>>>>>> Branch /branches/geps/gep-029-gtk3 has been reintegrated in trunk.
>>>>>> 
>>>>>> So crashes abound now. most fixes are simple, look at the changelog
>>>>>> done for
>>>>>> equal code, and change likewise:
>>>>>> 
>>>>>> 
>>>>>> http://gramps.svn.sourceforge.net/viewvc/gramps?limit_changes=0&view=revision&revision=20057
>>>>>> 
>>>>>> All glade files not touched yet should be opened in current glade for
>>>>>> GTK3
>>>>>> and resaved, then fixed for layout problems. Seen changes in glade
>>>>>> files
>>>>>> fixed already by me in case of issues.
>>>>>> 
>>>>>> For documentation links, and how to install the new requirements, see
>>>>>> the
>>>>>> GEP:
>>>>>> 
>>>>>> http://www.gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion
>>>>>> 
>>>>>> Fixing the crashes in a part will make you acquinted with the new way
>>>>>> of
>>>>>> working.
>>>>>> 
>>>>>> I'll fix futher things the coming days.
>>>>>> 
>>>>>> Main issue will probably be geography view which is now disabled. If
>>>>>> needed
>>>>>> we will have to help out in porting the dependency. On the plus side,
>>>>>> the
>>>>>> developer will know the code will be used immediately, helping to find
>>>>>> bugs.
>>>>>> 
>>>>>> Benny
>>>>> 
>>>>> Great to see this happening!
>>>>> 
>>>>> BTW, I did have a strange hard-crash on Python 2.7.2 without the
>>>>> proper pygobject. (I'll no doubt be helping with this port, but I'm
>>>>> still working hard to get Gramps-Connect to a near-finished state. So,
>>>>> initially I'm just making sure that the CLI use of Gramps works ok
>>>>> even without the proper pygobject, as it should.)
>>>>> 
>>>>> I found with Python 2.7.2+ on Ubuntu 11.10 that you can get a crash
>>>>> without the ability to try/except when you try to import webkit from a
>>>>> Gramps plugin. However, if you "import gtk" early on, then later
>>>>> "import webkit" it won't crash. Just thought I'd mention this in case
>>>>> anyone is having trouble getting started on the new Gramps...
>>>> 
>>>> That's an interesting crash. Did you look at the C backtrace?
>>>> 
>>>>> shall we call this Gramps 4.0?
>>>> 
>>>> I think we'll need to have a bunch of testing releases, so we should
>>>> probably call it 3.90.x for a while.
>>> 
>>> I guess with Gramps the x.9 status is implied. For example, trunk has
>>> been called "3.3" and "3.4" at various times (and is "3.5" currently)
>>> so that the addon version numbers will match. (The addons need to
>>> match at least major version number with Gramps.) SVN versions get
>>> appended onto the displayed version number (after updating const.py
>>> with ./autogen.sh), so we always can tell one is running trunk.
>>> 
>>> Since we don't have an official release until it is really ready (and
>>> usually follow that up with a few point releases) the name is really
>>> just a place holder. But I thought it might be nice to move it from
>>> "3.5" to "4.0" to indicate that trunk is now on a
>>> backwards-incompatible path, and give a clear point for people's
>>> reference.
>> 
>> 
>> Yes, this should be version 4.0 later.
>> Can you do the changes? As you know gramps-addons better, you should have a
>> good view on what to change.
> 
> Done. There appears to be an error in ./autogen.sh so make sure you at least:
> 
> cp src/gen/const.py.in src/gen/const.py
> 
>> It is a pity we can't do the 3.99 thing, but a release called 4.0-0.alpha is
>> not a big issue if communication is done correctly.
>> 
>> About webkit, we are not to do import gtk anywhere in the code! In the docs
>> I read they claim this leads to issues. As geography is not ready, I also
>> did not test htmlview.
> 
> Yes, I just meant this as a workaround. But I think I found the root
> of the problem and made more notes at:
> http://gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion

I don't see anything about webkit there. Was getting rid of the old gobject the solution?

Speaking of the Wiki page, should we open bugs to track the listed problems?

> 
>> As to allowing lower gi version number for CLI, that is not a problem.
> 
> As we approach the next release, it looks like it will be entirely
> possible to have a core gramps package without GUI code, for use in
> Gramps-Connect, etc. However, by moving all of the graphics subsystems
> (including PDF creation) to pygobject and friends, that substantially
> raises the bar for what is needed in a server-based install. For
> example, I can run gramps-connect with Gramps 4.0 on Python 2.6,
> Django 1.2 on an old Fedora 13 machine (in fact it is running on
> http://gramps-connect.org right now). But, I had to use
> src/plugins/lib/libcairodoc.py and src/plugins/docgen/pdfdoc.py from
> Gramps 3.5 to allow PDF creation from the webserver.
> 
> I wonder how we can have both the newer versions, and the older
> versions? Maybe we could add something else to the gpr file, so that
> one would load in gramps-gtk, and the other in gramps-connect?

Rename the pygtk versions and bring them back into trunk, then selectively import?

It occurs to me that we're being a bit aggressive in migrating to pygi: Thanks to Bug 679654 [1] (and maybe others), Gramps won't actually run on any current released Gtk. That means that even after the next release cycle it's only going to work on bleeding-edge distros like Ubuntu and Debian Unstable. That's going to freeze out a lot of users.

Regards,
John Ralls

[1] https://bugzilla.gnome.org/show_bug.cgi?id=679654

2012/7/24 John Ralls <jralls@...>

>
>
> It occurs to me that we're being a bit aggressive in migrating to pygi:
> Thanks to Bug 679654 [1] (and maybe others), Gramps won't actually run on
> any current released Gtk. That means that even after the next release cycle
> it's only going to work on bleeding-edge distros like Ubuntu and Debian
> Unstable. That's going to freeze out a lot of users.
>

4.0 is for april 2014. That is still a long way of. We will need the time
to verify everything works.
It will indeed only work on newer distro's, the current version of Gramps
will keep working however, and is solid.
GTK3 is now what, a year+ released? I hate spending time upgrading to new
versions, but unfortunately, to stand still is to die. How long still will
python 2.x be the default installed python? How long still will pygtk be
packaged? We have no other option than to go along.
Don't forget that soon (2 years) all new computers will have touchscreens,
and modern software will be expected to make use of it.

It is hateful to work with some old proprietary computing methods, like eg
matlab code, but the backward compatibility is something I very much
appreciate. I don't think any of my OSS code of 3 years ago will still work
on a newly installed linux due to changed APIs, which is sad.

Benny

Sorry, april 2013 off course

2012/7/24 Benny Malengier <benny.malengier@...>

>
>
> 2012/7/24 John Ralls <jralls@...>
>
>>
>>
>> It occurs to me that we're being a bit aggressive in migrating to pygi:
>> Thanks to Bug 679654 [1] (and maybe others), Gramps won't actually run on
>> any current released Gtk. That means that even after the next release cycle
>> it's only going to work on bleeding-edge distros like Ubuntu and Debian
>> Unstable. That's going to freeze out a lot of users.
>>
>
> 4.0 is for april 2014. That is still a long way of. We will need the time
> to verify everything works.
> It will indeed only work on newer distro's, the current version of Gramps
> will keep working however, and is solid.
> GTK3 is now what, a year+ released? I hate spending time upgrading to new
> versions, but unfortunately, to stand still is to die. How long still will
> python 2.x be the default installed python? How long still will pygtk be
> packaged? We have no other option than to go along.
> Don't forget that soon (2 years) all new computers will have touchscreens,
> and modern software will be expected to make use of it.
>
> It is hateful to work with some old proprietary computing methods, like eg
> matlab code, but the backward compatibility is something I very much
> appreciate. I don't think any of my OSS code of 3 years ago will still work
> on a newly installed linux due to changed APIs, which is sad.
>
> Benny
>
>

On Tue, Jul 24, 2012 at 11:07 AM, Benny Malengier
<benny.malengier@...> wrote:
>
>
> 2012/7/24 John Ralls <jralls@...>
>>
>>
>>
>> It occurs to me that we're being a bit aggressive in migrating to pygi:
>> Thanks to Bug 679654 [1] (and maybe others), Gramps won't actually run on
>> any current released Gtk. That means that even after the next release cycle
>> it's only going to work on bleeding-edge distros like Ubuntu and Debian
>> Unstable. That's going to freeze out a lot of users.
>
>
> 4.0 is for april 2014. That is still a long way of. We will need the time to
> verify everything works.
> It will indeed only work on newer distro's, the current version of Gramps
> will keep working however, and is solid.
> GTK3 is now what, a year+ released? I hate spending time upgrading to new
> versions, but unfortunately, to stand still is to die. How long still will
> python 2.x be the default installed python? How long still will pygtk be
> packaged? We have no other option than to go along.
> Don't forget that soon (2 years) all new computers will have touchscreens,
> and modern software will be expected to make use of it.
>
> It is hateful to work with some old proprietary computing methods, like eg
> matlab code, but the backward compatibility is something I very much
> appreciate. I don't think any of my OSS code of 3 years ago will still work
> on a newly installed linux due to changed APIs, which is sad.
>
> Benny
>

Yes, I feel the pain, but understand the motivation. The problem area
is for all of those "casual" gramps developers/translators/testers
that help because they are willing, can, and it isn't too much of a
burden. Well, this first step (like any first steps) is harder than it
should be. What can we do to make this easier for everyone? Some
ideas:

Is there a bleeding-edge server somewhere such that we could get
accounts, install everything needed for Gramps 4.0, and people could
log in remotely?

Would it be possible to abstract the GUI without too much work so that
it would work between gtk2/gtk3?  Probably not... I tried that with
gtk/tk (my first work with gramps) ... it did work, but wasn't
maintainable.

But maybe we could develop a really good Gramps Python Shell:

$ python src/gramps.py --shell
>>> dbstate.open("My Family Tree")
ok
>>> for p in dbstate.db.iter_people():
...   print p

That might allow some to continue work on various components, without
having to be bogged down with GUI issues. And might help with making
Gramps more scriptable.

(BTW, Gramps-connect is mostly unaffected by this, so that work
continues and could use
testers/translators/developers/css/javascript.)

In any event, without too much work I got my Ubuntu 12.04 working.
I've put additional notes on the web [1]. There will just be some work
that I can only do on this computer, for now.

-Doug

[1] - http://gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion

On Jul 24, 2012, at 8:07 AM, Benny Malengier wrote:

> Sorry, april 2013 off course

Which is *not* a "long way off". 

> 
> 2012/7/24 Benny Malengier <benny.malengier@...>
> 
> 
> 2012/7/24 John Ralls <jralls@...>
> 
> 
> It occurs to me that we're being a bit aggressive in migrating to pygi: Thanks to Bug 679654 [1] (and maybe others), Gramps won't actually run on any current released Gtk. That means that even after the next release cycle it's only going to work on bleeding-edge distros like Ubuntu and Debian Unstable. That's going to freeze out a lot of users.
> 
> 4.0 is for april 2014. That is still a long way of. We will need the time to verify everything works.
> It will indeed only work on newer distro's, the current version of Gramps will keep working however, and is solid.
> GTK3 is now what, a year+ released? I hate spending time upgrading to new versions, but unfortunately, to stand still is to die. How long still will python 2.x be the default installed python? How long still will pygtk be packaged? We have no other option than to go along.
> Don't forget that soon (2 years) all new computers will have touchscreens, and modern software will be expected to make use of it.

Gramps's interface doesn't care about how the user presses buttons, enters text, or scrolls windows. All of those interactions, whether by mouse, touchpad, or touchscreen are handled at a lower level than we're concerned with -- and Gtk2 handles them just fine. Yes, at some point there will be a new input technology that will require major work in Gdk, but that hasn't happened yet.

> 
> It is hateful to work with some old proprietary computing methods, like eg matlab code, but the backward compatibility is something I very much appreciate. I don't think any of my OSS code of 3 years ago will still work on a newly installed linux due to changed APIs, which is sad. 

Remember, I argued in favor of getting ready for Gtk3 two years ago when it suddenly changed from being an incremental upgrade of Gtk2 to a rather different environment. But it turns out that there are a lot of subtleties in using gobject-introspection and they're only starting to get exercised, and more bugs are likely. If we release 4.0 next April we may find that it runs only on developer machines with self-built Gtk stacks -- and on Macs, because I bundle a purpose-built Gtk stack.

Has anyone tried doing a Gtk3 build on Windows? 

I was actually thinking more of Doug's backend changes and his server-side PDF quandary. I know it's a PITA, but maybe we should consider allowing backend features to be backported to 3.4 or creating a 3.5 branch and head towards a dual version release in April.

Regards,
John Ralls

I like the idea of development continuing on a 3.5 branch,
in parallel with trunk's 4.0 for anything affecting both.

It could be initialized with a copy of trunk from just
before Benny merged the 400-plus changed GEPS029 files back.

It would mean slightly more work on the part of developers,
who would have to commit bug fixes to three places and
feature changes to two places, but I for one will be doing
that anyway since I am not willing to change my distribution
to Ubuntu (or Debian unstable, etc.).  I am currently doing
my development on gramps34 and only at the last minute do I
convert the patchfile into one for trunk.

Since I am not a GUI person and have no desire to learn, nor
do all my computing in a possibly buggy GTK3 world, that
seems like the best solution for me personally.

I can only wonder how many gramps users out there think the
same and would prefer to have a choice when the time comes.

On Tue, Jul 24, 2012 at 6:05 PM, Paul Franklin <pf.98052@...> wrote:
> I like the idea of development continuing on a 3.5 branch,
> in parallel with trunk's 4.0 for anything affecting both.

+1, especially if there were people willing to keep an eye to make
sure that non-gui changes were made to both. We could probably even
write some scripts to help make sure we don't miss anything.

-Doug

> It could be initialized with a copy of trunk from just
> before Benny merged the 400-plus changed GEPS029 files back.
>
> It would mean slightly more work on the part of developers,
> who would have to commit bug fixes to three places and
> feature changes to two places, but I for one will be doing
> that anyway since I am not willing to change my distribution
> to Ubuntu (or Debian unstable, etc.).  I am currently doing
> my development on gramps34 and only at the last minute do I
> convert the patchfile into one for trunk.
>
> Since I am not a GUI person and have no desire to learn, nor
> do all my computing in a possibly buggy GTK3 world, that
> seems like the best solution for me personally.
>
> I can only wonder how many gramps users out there think the
> same and would prefer to have a choice when the time comes.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

Benny,

> About your errors in
> http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_029:_GTK3-GObject_introspection_Conversion
>
> You can fix most yourself

I made changes on revision 20068
http://gramps.svn.sourceforge.net/viewvc/gramps?revision=20068&view=revision

Thanks!

> As written in the GEP page, unicode now by default uses ascii. I have no
> idea why. I fixed most of these things by adding the UTF-8 encoding as
> option
>
> unicode(, 'UTF-8')
>

Overkill for my config...
Maybe for Windows OS?

Note, it seems we made it wrong on launch (command line)!

  $ PYTHONPATH=/usr/local/lib/python2.7/site-packages/ python src/gramps.py

I will try to describe what I think is maybe wrong for testing gettext 
support with above command line.

I have the feeling that gettext is not passing through python 2.7!
It is like using python 3.0, which does not need to force unicode any 
more, right?

Testcase: if I only return 'pgettext.gettext(msgid)' # without 
unicode(), then I am passing the first step (but I get error on next 
python module with unicode(): personsidebarfilter).

ie. it should be possible to list all 'exceptions' using unicode(), 
which also need to be reviewed for python3[1] support (gramps 5.0 ???).


[1] 
http://docs.python.org/release/3.0.1/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit


Jérôme


Le 24/07/2012 09:56, Benny Malengier a écrit :
> Jerome,
>
> About your errors in
> http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_029:_GTK3-GObject_introspection_Conversion
>
>
> You can fix most yourself:
>
> NameError: global name 'GObject' is not defined
>
> Add at import section of the file:
>
> from gi.repository import GObject
>
> TypeError: pack_start() takes exactly 5 arguments (3 given)
>
> Common error, pack_start is now sig
> pack_start(gtkobj, expandval, fillval, paddingval)
>
> So pass True for expandval and fillval, and 0 for paddingval, so the error
>
> self.glade.get_object('vbox').pack_start(notebook, True)
>
> Should be
>
> self.glade.get_object('vbox').pack_start(notebook, True, True, 0)
>
> The most problematic to me are the decoding errors. As you see
>
>    File "geps029/share/gramps/gen/ggettext.py", line 48, in gettext
>      return unicode(pgettext.gettext(msgid))
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2:
>
> As written in the GEP page, unicode now by default uses ascii. I have no
> idea why. I fixed most of these things by adding the UTF-8 encoding as
> option
>
> unicode(pgettext.gettext(msgid), 'UTF-8')
>
> But I'm afraid there must be a more basic reason for these errors. As a
> workaround it should work.
>
> Benny
>
>
>

> I made changes on revision 20068
> http://gramps.svn.sourceforge.net/viewvc/gramps?revision=20068&view=revision

oops, you also made a change on last minutes...
It was revision 20067 !
http://gramps.svn.sourceforge.net/viewvc/gramps?revision=20067&view=revision


Le 24/07/2012 21:10, Jérôme a écrit :
> Benny,
>
>> About your errors in
>> http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_029:_GTK3-GObject_introspection_Conversion
>>
>> You can fix most yourself
>
> I made changes on revision 20068
> http://gramps.svn.sourceforge.net/viewvc/gramps?revision=20068&view=revision
>
> Thanks!
>
>> As written in the GEP page, unicode now by default uses ascii. I have no
>> idea why. I fixed most of these things by adding the UTF-8 encoding as
>> option
>>
>> unicode(, 'UTF-8')
>>
>
> Overkill for my config...
> Maybe for Windows OS?
>
> Note, it seems we made it wrong on launch (command line)!
>
>    $ PYTHONPATH=/usr/local/lib/python2.7/site-packages/ python src/gramps.py
>
> I will try to describe what I think is maybe wrong for testing gettext
> support with above command line.
>
> I have the feeling that gettext is not passing through python 2.7!
> It is like using python 3.0, which does not need to force unicode any
> more, right?
>
> Testcase: if I only return 'pgettext.gettext(msgid)' # without
> unicode(), then I am passing the first step (but I get error on next
> python module with unicode(): personsidebarfilter).
>
> ie. it should be possible to list all 'exceptions' using unicode(),
> which also need to be reviewed for python3[1] support (gramps 5.0 ???).
>
>
> [1]
> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit
>
>
> Jérôme
>
>
> Le 24/07/2012 09:56, Benny Malengier a écrit :
>> Jerome,
>>
>> About your errors in
>> http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_029:_GTK3-GObject_introspection_Conversion
>>
>>
>> You can fix most yourself:
>>
>> NameError: global name 'GObject' is not defined
>>
>> Add at import section of the file:
>>
>> from gi.repository import GObject
>>
>> TypeError: pack_start() takes exactly 5 arguments (3 given)
>>
>> Common error, pack_start is now sig
>> pack_start(gtkobj, expandval, fillval, paddingval)
>>
>> So pass True for expandval and fillval, and 0 for paddingval, so the error
>>
>> self.glade.get_object('vbox').pack_start(notebook, True)
>>
>> Should be
>>
>> self.glade.get_object('vbox').pack_start(notebook, True, True, 0)
>>
>> The most problematic to me are the decoding errors. As you see
>>
>>     File "geps029/share/gramps/gen/ggettext.py", line 48, in gettext
>>       return unicode(pgettext.gettext(msgid))
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2:
>>
>> As written in the GEP page, unicode now by default uses ascii. I have no
>> idea why. I fixed most of these things by adding the UTF-8 encoding as
>> option
>>
>> unicode(pgettext.gettext(msgid), 'UTF-8')
>>
>> But I'm afraid there must be a more basic reason for these errors. As a
>> workaround it should work.
>>
>> Benny
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

2012/7/24 Jérôme <romjerome@...>

> Benny,
>
>
>  About your errors in
>> http://www.gramps-project.org/**wiki/index.php?title=Talk:**
>> GEPS_029:_GTK3-GObject_**introspection_Conversion<http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_029:_GTK3-GObject_introspection_Conversion>
>>
>> You can fix most yourself
>>
>
> I made changes on revision 20068
> http://gramps.svn.sourceforge.**net/viewvc/gramps?revision=**
> 20068&view=revision<http://gramps.svn.sourceforge.net/viewvc/gramps?revision=20068&view=revision>
>
> Thanks!
>
>  As written in the GEP page, unicode now by default uses ascii. I have no
>> idea why. I fixed most of these things by adding the UTF-8 encoding as
>> option
>>
>> unicode(, 'UTF-8')
>>
>>
> Overkill for my config...
> Maybe for Windows OS?
>
> Note, it seems we made it wrong on launch (command line)!
>
>  $ PYTHONPATH=/usr/local/lib/**python2.7/site-packages/ python
> src/gramps.py
>
> I will try to describe what I think is maybe wrong for testing gettext
> support with above command line.
>
> I have the feeling that gettext is not passing through python 2.7!
> It is like using python 3.0, which does not need to force unicode any
> more, right?
>
> Testcase: if I only return 'pgettext.gettext(msgid)' # without unicode(),
> then I am passing the first step (but I get error on next python module
> with unicode(): personsidebarfilter).
>
> ie. it should be possible to list all 'exceptions' using unicode(), which
> also need to be reviewed for python3[1] support (gramps 5.0 ???).
>

Hmm, not sure. I think in python 3, unicode command is the new str. Not
sure if one can pass in python 3 then an encoding. I would have to check.
Point is that gettext returns data, so UTF-8. Or in python 3 it still does
that, or it returns 'text'.

Benny

>
>
> [1] http://docs.python.org/**release/3.0.1/whatsnew/3.0.**
> html#text-vs-data-instead-of-**unicode-vs-8-bit<http://docs.python.org/release/3.0.1/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit>
>
>
> Jérôme
>
>
> Le 24/07/2012 09:56, Benny Malengier a écrit :
>
>  Jerome,
>>
>> About your errors in
>> http://www.gramps-project.org/**wiki/index.php?title=Talk:**
>> GEPS_029:_GTK3-GObject_**introspection_Conversion<http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_029:_GTK3-GObject_introspection_Conversion>
>>
>>
>> You can fix most yourself:
>>
>> NameError: global name 'GObject' is not defined
>>
>> Add at import section of the file:
>>
>> from gi.repository import GObject
>>
>> TypeError: pack_start() takes exactly 5 arguments (3 given)
>>
>> Common error, pack_start is now sig
>> pack_start(gtkobj, expandval, fillval, paddingval)
>>
>> So pass True for expandval and fillval, and 0 for paddingval, so the error
>>
>> self.glade.get_object('vbox').**pack_start(notebook, True)
>>
>> Should be
>>
>> self.glade.get_object('vbox').**pack_start(notebook, True, True, 0)
>>
>> The most problematic to me are the decoding errors. As you see
>>
>>    File "geps029/share/gramps/gen/**ggettext.py", line 48, in gettext
>>      return unicode(pgettext.gettext(**msgid))
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2:
>>
>> As written in the GEP page, unicode now by default uses ascii. I have no
>> idea why. I fixed most of these things by adding the UTF-8 encoding as
>> option
>>
>> unicode(pgettext.gettext(**msgid), 'UTF-8')
>>
>> But I'm afraid there must be a more basic reason for these errors. As a
>> workaround it should work.
>>
>> Benny
>>
>>
>>
>>
>