PyGtk and gtk-3.0 compatibility

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

PyGtk and gtk-3.0 compatibility

John Stowers
Hi,

First of all, PyGI and GObject introspection is the way forward.

Now, that being said, it seems a little silly to spend all this effort
porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
back in the gtk-2.0 libraries with "import gtk".

So I spent a little time trying to get PyGtk to build with GSEAL. Turns
out it wasn't that hard [1][2].

Only a few accessors were missing
  * GtkWindow.has_user_ref_count
  * GtkInvisible.has_user_ref_count
    These both are used in the sink funcs, and seem to be a synonym
    for checking the object has not been destroyed.
  * gtk_menu_get_position_func{,_data}

So, what is the opinion on this? Is it worth me continuing? My idea
would be to make *only one* PyGtk release that builds against gtk-3.0,
it would see no new features.

John

[1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
[2] http://github.com/nzjrs/pygobject/tree/gtk-3.0

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Tomeu Vizoso-3
On Mon, Jul 5, 2010 at 15:48, John Stowers <[hidden email]> wrote:

> Hi,
>
> First of all, PyGI and GObject introspection is the way forward.
>
> Now, that being said, it seems a little silly to spend all this effort
> porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
> back in the gtk-2.0 libraries with "import gtk".
>
> So I spent a little time trying to get PyGtk to build with GSEAL. Turns
> out it wasn't that hard [1][2].
>
> Only a few accessors were missing
>  * GtkWindow.has_user_ref_count
>  * GtkInvisible.has_user_ref_count
>    These both are used in the sink funcs, and seem to be a synonym
>    for checking the object has not been destroyed.
>  * gtk_menu_get_position_func{,_data}
>
> So, what is the opinion on this? Is it worth me continuing? My idea
> would be to make *only one* PyGtk release that builds against gtk-3.0,
> it would see no new features.

Sounds like a good idea to me, given how much PyGTK application
authors seem to lag behind platform changes.

That said, I think distros should focus on moving to introspection
because it allows them to drop maintenance of a lot of packages. But
anything that makes this move easier for people is important.

Regards,

Tomeu

> John
>
> [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
> [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
>
> _______________________________________________
> pygtk mailing list   [hidden email]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
>
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Gerald Britton-2
On Thu, Jul 8, 2010 at 4:03 AM, Tomeu Vizoso <[hidden email]> wrote:

> On Mon, Jul 5, 2010 at 15:48, John Stowers <[hidden email]> wrote:
>> Hi,
>>
>> First of all, PyGI and GObject introspection is the way forward.
>>
>> Now, that being said, it seems a little silly to spend all this effort
>> porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
>> back in the gtk-2.0 libraries with "import gtk".
>>
>> So I spent a little time trying to get PyGtk to build with GSEAL. Turns
>> out it wasn't that hard [1][2].
>>
>> Only a few accessors were missing
>>  * GtkWindow.has_user_ref_count
>>  * GtkInvisible.has_user_ref_count
>>    These both are used in the sink funcs, and seem to be a synonym
>>    for checking the object has not been destroyed.
>>  * gtk_menu_get_position_func{,_data}
>>
>> So, what is the opinion on this? Is it worth me continuing? My idea
>> would be to make *only one* PyGtk release that builds against gtk-3.0,
>> it would see no new features.
>
> Sounds like a good idea to me, given how much PyGTK application
> authors seem to lag behind platform changes.
>
> That said, I think distros should focus on moving to introspection
> because it allows them to drop maintenance of a lot of packages. But
> anything that makes this move easier for people is important.

I've trying to get a handle on PyGI for a while now, but I'm still in
a bit of a fog.  I've worked on some PyGTK apps so understand that OK,
but what I'm really looking for are answers to questions like:

1. What problem is PyGI trying to solve?
2. What advantage will I see by using PyGI over PyGTK?
3. How do I port my application from PyGTK to PyGI?

>
> Regards,
>
> Tomeu
>
>> John
>>
>> [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
>> [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
>>
>> _______________________________________________
>> pygtk mailing list   [hidden email]
>> http://www.daa.com.au/mailman/listinfo/pygtk
>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>
> _______________________________________________
> pygtk mailing list   [hidden email]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
>



--
Gerald Britton
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Tomeu Vizoso-3
On Thu, Jul 8, 2010 at 16:19, Gerald Britton <[hidden email]> wrote:

> On Thu, Jul 8, 2010 at 4:03 AM, Tomeu Vizoso <[hidden email]> wrote:
>> On Mon, Jul 5, 2010 at 15:48, John Stowers <[hidden email]> wrote:
>>> Hi,
>>>
>>> First of all, PyGI and GObject introspection is the way forward.
>>>
>>> Now, that being said, it seems a little silly to spend all this effort
>>> porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
>>> back in the gtk-2.0 libraries with "import gtk".
>>>
>>> So I spent a little time trying to get PyGtk to build with GSEAL. Turns
>>> out it wasn't that hard [1][2].
>>>
>>> Only a few accessors were missing
>>>  * GtkWindow.has_user_ref_count
>>>  * GtkInvisible.has_user_ref_count
>>>    These both are used in the sink funcs, and seem to be a synonym
>>>    for checking the object has not been destroyed.
>>>  * gtk_menu_get_position_func{,_data}
>>>
>>> So, what is the opinion on this? Is it worth me continuing? My idea
>>> would be to make *only one* PyGtk release that builds against gtk-3.0,
>>> it would see no new features.
>>
>> Sounds like a good idea to me, given how much PyGTK application
>> authors seem to lag behind platform changes.
>>
>> That said, I think distros should focus on moving to introspection
>> because it allows them to drop maintenance of a lot of packages. But
>> anything that makes this move easier for people is important.
>
> I've trying to get a handle on PyGI for a while now, but I'm still in
> a bit of a fog.

First of all, sorry about the confusion, help is needed in properly
explaining the situation, so if someone reading this is able to go
through http://live.gnome.org and make it a bit more coherent, it will
be a great contribution.

Second, PyGI has ceased to exist after it was merged into PyGObject so
it may be better to only refer to it for historical purposes. In
practical terms, PyGObject has gained support for using gobject-based
libraries through introspection.

> I've worked on some PyGTK apps so understand that OK,
> but what I'm really looking for are answers to questions like:
>
> 1. What problem is PyGI trying to solve?

It adds the possibility to call gobject-based libraries without having
to generate/write, build, package, maintain and install specific
bindings for that library.

> 2. What advantage will I see by using PyGI over PyGTK?

You are able to use API that nobody has bothered to write bindings
for, such as GSettings. Incidentally, your application will use less
memory and will start up faster because the class wrappers are loaded
lazily.

One more consequence is that in order to port your application to
Python 3.x or another Python implementation such as Jython you will
only need to port your application code and PyGObject, and not the
thousands of lines in static bindings.

Last, is that the Python GNOME community can focus on improving and
completing a much smaller codebase if we don't need to maintain static
bindings for each library out there. We also pool resources with the
other GNOME teams maintaining bindings for other languages. This has
its importance because as we know critical components of Python in
GNOME were having just minimal maintenance, when any at all.

> 3. How do I port my application from PyGTK to PyGI?

Right now, you need to change the way modules are imported (s/import
gtk/from gi.repository import Gtk/) and mostly adapt to the API
provided by the C libraries you use. This example script may give an
idea of the transformations required:

http://git.gnome.org/browse/pygobject/tree/pygi-convert.sh

That said, PyGObject provides a mechanism for overriding the C API and
is being used to provide an API more compatible with PyGTK. There's
also the possibility to simulate the old way of importing modules with
some import hook magic. As people start porting their applications,
we'll know better how to make it easier.

There exists the possibility that applications can be made to use
introspected libraries instead of static bindings without changes, but
it requires someone doing the work upstream.

Note that by integrating PyGI into PyGObject we don't force you to use
introspection instead of static bindings. It just gives the community
a way forward that could work, given the current resources available.

Hope it clarifies a bit,

Tomeu

>>
>> Regards,
>>
>> Tomeu
>>
>>> John
>>>
>>> [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
>>> [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
>>>
>>> _______________________________________________
>>> pygtk mailing list   [hidden email]
>>> http://www.daa.com.au/mailman/listinfo/pygtk
>>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>>
>> _______________________________________________
>> pygtk mailing list   [hidden email]
>> http://www.daa.com.au/mailman/listinfo/pygtk
>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>
>
>
>
> --
> Gerald Britton
>
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Alberto Ruiz-4
Hey Tomeu,

Is there a plan to update the reference documentation for PyGtk 3.0?

I see this as a major problem at the moment as anyone googling is
gonna hit the 2.0 reference and end up in a pretty strange situation
of stuff just not working for no apparent reason.

2010/7/8 Tomeu Vizoso <[hidden email]>:

> On Thu, Jul 8, 2010 at 16:19, Gerald Britton <[hidden email]> wrote:
>> On Thu, Jul 8, 2010 at 4:03 AM, Tomeu Vizoso <[hidden email]> wrote:
>>> On Mon, Jul 5, 2010 at 15:48, John Stowers <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> First of all, PyGI and GObject introspection is the way forward.
>>>>
>>>> Now, that being said, it seems a little silly to spend all this effort
>>>> porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
>>>> back in the gtk-2.0 libraries with "import gtk".
>>>>
>>>> So I spent a little time trying to get PyGtk to build with GSEAL. Turns
>>>> out it wasn't that hard [1][2].
>>>>
>>>> Only a few accessors were missing
>>>>  * GtkWindow.has_user_ref_count
>>>>  * GtkInvisible.has_user_ref_count
>>>>    These both are used in the sink funcs, and seem to be a synonym
>>>>    for checking the object has not been destroyed.
>>>>  * gtk_menu_get_position_func{,_data}
>>>>
>>>> So, what is the opinion on this? Is it worth me continuing? My idea
>>>> would be to make *only one* PyGtk release that builds against gtk-3.0,
>>>> it would see no new features.
>>>
>>> Sounds like a good idea to me, given how much PyGTK application
>>> authors seem to lag behind platform changes.
>>>
>>> That said, I think distros should focus on moving to introspection
>>> because it allows them to drop maintenance of a lot of packages. But
>>> anything that makes this move easier for people is important.
>>
>> I've trying to get a handle on PyGI for a while now, but I'm still in
>> a bit of a fog.
>
> First of all, sorry about the confusion, help is needed in properly
> explaining the situation, so if someone reading this is able to go
> through http://live.gnome.org and make it a bit more coherent, it will
> be a great contribution.
>
> Second, PyGI has ceased to exist after it was merged into PyGObject so
> it may be better to only refer to it for historical purposes. In
> practical terms, PyGObject has gained support for using gobject-based
> libraries through introspection.
>
>> I've worked on some PyGTK apps so understand that OK,
>> but what I'm really looking for are answers to questions like:
>>
>> 1. What problem is PyGI trying to solve?
>
> It adds the possibility to call gobject-based libraries without having
> to generate/write, build, package, maintain and install specific
> bindings for that library.
>
>> 2. What advantage will I see by using PyGI over PyGTK?
>
> You are able to use API that nobody has bothered to write bindings
> for, such as GSettings. Incidentally, your application will use less
> memory and will start up faster because the class wrappers are loaded
> lazily.
>
> One more consequence is that in order to port your application to
> Python 3.x or another Python implementation such as Jython you will
> only need to port your application code and PyGObject, and not the
> thousands of lines in static bindings.
>
> Last, is that the Python GNOME community can focus on improving and
> completing a much smaller codebase if we don't need to maintain static
> bindings for each library out there. We also pool resources with the
> other GNOME teams maintaining bindings for other languages. This has
> its importance because as we know critical components of Python in
> GNOME were having just minimal maintenance, when any at all.
>
>> 3. How do I port my application from PyGTK to PyGI?
>
> Right now, you need to change the way modules are imported (s/import
> gtk/from gi.repository import Gtk/) and mostly adapt to the API
> provided by the C libraries you use. This example script may give an
> idea of the transformations required:
>
> http://git.gnome.org/browse/pygobject/tree/pygi-convert.sh
>
> That said, PyGObject provides a mechanism for overriding the C API and
> is being used to provide an API more compatible with PyGTK. There's
> also the possibility to simulate the old way of importing modules with
> some import hook magic. As people start porting their applications,
> we'll know better how to make it easier.
>
> There exists the possibility that applications can be made to use
> introspected libraries instead of static bindings without changes, but
> it requires someone doing the work upstream.
>
> Note that by integrating PyGI into PyGObject we don't force you to use
> introspection instead of static bindings. It just gives the community
> a way forward that could work, given the current resources available.
>
> Hope it clarifies a bit,
>
> Tomeu
>
>>>
>>> Regards,
>>>
>>> Tomeu
>>>
>>>> John
>>>>
>>>> [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
>>>> [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
>>>>
>>>> _______________________________________________
>>>> pygtk mailing list   [hidden email]
>>>> http://www.daa.com.au/mailman/listinfo/pygtk
>>>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>>>
>>> _______________________________________________
>>> pygtk mailing list   [hidden email]
>>> http://www.daa.com.au/mailman/listinfo/pygtk
>>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>>
>>
>>
>>
>> --
>> Gerald Britton
>>
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



--
Un saludo,
Alberto Ruiz
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Tomeu Vizoso-3
On Thu, Jul 8, 2010 at 18:22, Alberto Ruiz <[hidden email]> wrote:
> Hey Tomeu,
>
> Is there a plan to update the reference documentation for PyGtk 3.0?
>
> I see this as a major problem at the moment as anyone googling is
> gonna hit the 2.0 reference and end up in a pretty strange situation
> of stuff just not working for no apparent reason.

On the introspection side of things, work is going on in g-i to
generate a single set of documentation that will include the calling
conventions for C, JS, Python, Vala, etc.

As hinted in an earlier message, pygobject includes a set of
"overrides" that expand the API provided by g-i for compatibility with
the static bindings. The idea is that this will make easier to port
existing software and will make existing documentation useful for a
longer time.

Regards,

Tomeu

> 2010/7/8 Tomeu Vizoso <[hidden email]>:
>> On Thu, Jul 8, 2010 at 16:19, Gerald Britton <[hidden email]> wrote:
>>> On Thu, Jul 8, 2010 at 4:03 AM, Tomeu Vizoso <[hidden email]> wrote:
>>>> On Mon, Jul 5, 2010 at 15:48, John Stowers <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> First of all, PyGI and GObject introspection is the way forward.
>>>>>
>>>>> Now, that being said, it seems a little silly to spend all this effort
>>>>> porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
>>>>> back in the gtk-2.0 libraries with "import gtk".
>>>>>
>>>>> So I spent a little time trying to get PyGtk to build with GSEAL. Turns
>>>>> out it wasn't that hard [1][2].
>>>>>
>>>>> Only a few accessors were missing
>>>>>  * GtkWindow.has_user_ref_count
>>>>>  * GtkInvisible.has_user_ref_count
>>>>>    These both are used in the sink funcs, and seem to be a synonym
>>>>>    for checking the object has not been destroyed.
>>>>>  * gtk_menu_get_position_func{,_data}
>>>>>
>>>>> So, what is the opinion on this? Is it worth me continuing? My idea
>>>>> would be to make *only one* PyGtk release that builds against gtk-3.0,
>>>>> it would see no new features.
>>>>
>>>> Sounds like a good idea to me, given how much PyGTK application
>>>> authors seem to lag behind platform changes.
>>>>
>>>> That said, I think distros should focus on moving to introspection
>>>> because it allows them to drop maintenance of a lot of packages. But
>>>> anything that makes this move easier for people is important.
>>>
>>> I've trying to get a handle on PyGI for a while now, but I'm still in
>>> a bit of a fog.
>>
>> First of all, sorry about the confusion, help is needed in properly
>> explaining the situation, so if someone reading this is able to go
>> through http://live.gnome.org and make it a bit more coherent, it will
>> be a great contribution.
>>
>> Second, PyGI has ceased to exist after it was merged into PyGObject so
>> it may be better to only refer to it for historical purposes. In
>> practical terms, PyGObject has gained support for using gobject-based
>> libraries through introspection.
>>
>>> I've worked on some PyGTK apps so understand that OK,
>>> but what I'm really looking for are answers to questions like:
>>>
>>> 1. What problem is PyGI trying to solve?
>>
>> It adds the possibility to call gobject-based libraries without having
>> to generate/write, build, package, maintain and install specific
>> bindings for that library.
>>
>>> 2. What advantage will I see by using PyGI over PyGTK?
>>
>> You are able to use API that nobody has bothered to write bindings
>> for, such as GSettings. Incidentally, your application will use less
>> memory and will start up faster because the class wrappers are loaded
>> lazily.
>>
>> One more consequence is that in order to port your application to
>> Python 3.x or another Python implementation such as Jython you will
>> only need to port your application code and PyGObject, and not the
>> thousands of lines in static bindings.
>>
>> Last, is that the Python GNOME community can focus on improving and
>> completing a much smaller codebase if we don't need to maintain static
>> bindings for each library out there. We also pool resources with the
>> other GNOME teams maintaining bindings for other languages. This has
>> its importance because as we know critical components of Python in
>> GNOME were having just minimal maintenance, when any at all.
>>
>>> 3. How do I port my application from PyGTK to PyGI?
>>
>> Right now, you need to change the way modules are imported (s/import
>> gtk/from gi.repository import Gtk/) and mostly adapt to the API
>> provided by the C libraries you use. This example script may give an
>> idea of the transformations required:
>>
>> http://git.gnome.org/browse/pygobject/tree/pygi-convert.sh
>>
>> That said, PyGObject provides a mechanism for overriding the C API and
>> is being used to provide an API more compatible with PyGTK. There's
>> also the possibility to simulate the old way of importing modules with
>> some import hook magic. As people start porting their applications,
>> we'll know better how to make it easier.
>>
>> There exists the possibility that applications can be made to use
>> introspected libraries instead of static bindings without changes, but
>> it requires someone doing the work upstream.
>>
>> Note that by integrating PyGI into PyGObject we don't force you to use
>> introspection instead of static bindings. It just gives the community
>> a way forward that could work, given the current resources available.
>>
>> Hope it clarifies a bit,
>>
>> Tomeu
>>
>>>>
>>>> Regards,
>>>>
>>>> Tomeu
>>>>
>>>>> John
>>>>>
>>>>> [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
>>>>> [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
>>>>>
>>>>> _______________________________________________
>>>>> pygtk mailing list   [hidden email]
>>>>> http://www.daa.com.au/mailman/listinfo/pygtk
>>>>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>>>>
>>>> _______________________________________________
>>>> pygtk mailing list   [hidden email]
>>>> http://www.daa.com.au/mailman/listinfo/pygtk
>>>> Read the PyGTK FAQ: http://faq.pygtk.org/
>>>>
>>>
>>>
>>>
>>> --
>>> Gerald Britton
>>>
>> _______________________________________________
>> gtk-devel-list mailing list
>> [hidden email]
>> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>
>
>
> --
> Un saludo,
> Alberto Ruiz
>
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

John Stowers
In reply to this post by John Stowers
On Tue, 2010-07-06 at 01:48 +1200, John Stowers wrote:

> Hi,
>
> First of all, PyGI and GObject introspection is the way forward.
>
> Now, that being said, it seems a little silly to spend all this effort
> porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
> back in the gtk-2.0 libraries with "import gtk".
>
> So I spent a little time trying to get PyGtk to build with GSEAL. Turns
> out it wasn't that hard [1][2].

This has reached a reasonable state of working, I have run the same
python applications against a GSEALED G_DISABLE_DEPRECATED branch of
2.21 and against master (although for that you will also need this
branch [0])

If you are interested in playing
 * Check out the gtk-3.0 branches of PyGObject and PyGtk [1][2]
 * Build against a Gtk 2.21.x release with the appropriate GSEAL and
DISABLE_DEPRECATED CFLAGS

The remaining work is
 * When needed, fix the override files to not call deprecated functions
 * If an object has beer wrapped with the (fields (...)) attribute
   then you need to either
   1) Add a (getter-funcname "foo") or (getter-propname "bar")
      attribute to he appropriate defs file
   2) Remove the field wrapping (or possible override), which
      will break compatibility

Behind the scenes, a modified PyGObject codegen is needed because of how
field access on GObjects (ie GtkWidget.window) is now handled. Access is
now delegated to either a getter function (ie gtk_widget_get_window) or
to a GObject property (ie g_object_get(widget, "window", &window))
depending on whether you added the getter-funcname of getter-propname to
the defs file. To see remaining fields that need to be emulated grep for
FIXME-FIELD in the generated code, or watch for DepreciationError
runtime warnings.

So depending on how many fields can be annotated in this way, and how
the GDK sealing / GDKDevice cleanup goes, I am confident that with a
little luck and some work, that PyGtk apps should be able to run against
gtk-3.0 with no code changes (providing you were not using very old
deprecated stuff, and that fields are now accessible with accessor
functions).

John

[0] http://github.com/nzjrs/pygtk/tree/build-against-gtk-3.0
[1] http://git.gnome.org/browse/pygobject/log/?h=gtk-3.0
[2] http://git.gnome.org/browse/pygtk/log/?h=gtk-3.0

p.s. Branches will likely be rebased in future

>
> Only a few accessors were missing
>   * GtkWindow.has_user_ref_count
>   * GtkInvisible.has_user_ref_count
>     These both are used in the sink funcs, and seem to be a synonym
>     for checking the object has not been destroyed.
>   * gtk_menu_get_position_func{,_data}
>
> So, what is the opinion on this? Is it worth me continuing? My idea
> would be to make *only one* PyGtk release that builds against gtk-3.0,
> it would see no new features.
>
> John
>
> [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
> [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
>


_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Rafael Villar Burke (Pachi)
  This is really great, John. Thank you very much for doing this work!

Rafael
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Murray Cumming-5
In reply to this post by John Stowers
On Sat, 2010-07-17 at 12:50 +1200, John Stowers wrote:

> On Tue, 2010-07-06 at 01:48 +1200, John Stowers wrote:
> > Hi,
> >
> > First of all, PyGI and GObject introspection is the way forward.
> >
> > Now, that being said, it seems a little silly to spend all this effort
> > porting C apps in GNOME to gtk-3.0 only to see the first PyGtk app drag
> > back in the gtk-2.0 libraries with "import gtk".
> >
> > So I spent a little time trying to get PyGtk to build with GSEAL. Turns
> > out it wasn't that hard [1][2].
>
> This has reached a reasonable state of working, I have run the same
> python applications against a GSEALED G_DISABLE_DEPRECATED branch of
> 2.21 and against master (although for that you will also need this
> branch [0])
>
> If you are interested in playing
>  * Check out the gtk-3.0 branches of PyGObject and PyGtk [1][2]
>  * Build against a Gtk 2.21.x release with the appropriate GSEAL and
> DISABLE_DEPRECATED CFLAGS
>
> The remaining work is
>  * When needed, fix the override files to not call deprecated functions
>  * If an object has beer wrapped with the (fields (...)) attribute
>    then you need to either
>    1) Add a (getter-funcname "foo") or (getter-propname "bar")
>       attribute to he appropriate defs file
>    2) Remove the field wrapping (or possible override), which
>       will break compatibility
>
> Behind the scenes, a modified PyGObject codegen is needed because of how
> field access on GObjects (ie GtkWidget.window) is now handled. Access is
> now delegated to either a getter function (ie gtk_widget_get_window) or
> to a GObject property (ie g_object_get(widget, "window", &window))
> depending on whether you added the getter-funcname of getter-propname to
> the defs file. To see remaining fields that need to be emulated grep for
> FIXME-FIELD in the generated code, or watch for DepreciationError
> runtime warnings.
>
> So depending on how many fields can be annotated in this way, and how
> the GDK sealing / GDKDevice cleanup goes, I am confident that with a
> little luck and some work, that PyGtk apps should be able to run against
> gtk-3.0 with no code changes (providing you were not using very old
> deprecated stuff, and that fields are now accessible with accessor
> functions).
>
> John
>
> [0] http://github.com/nzjrs/pygtk/tree/build-against-gtk-3.0
> [1] http://git.gnome.org/browse/pygobject/log/?h=gtk-3.0
> [2] http://git.gnome.org/browse/pygtk/log/?h=gtk-3.0
>
> p.s. Branches will likely be rebased in future
>
> >
> > Only a few accessors were missing
> >   * GtkWindow.has_user_ref_count
> >   * GtkInvisible.has_user_ref_count
> >     These both are used in the sink funcs, and seem to be a synonym
> >     for checking the object has not been destroyed.
> >   * gtk_menu_get_position_func{,_data}
> >
> > So, what is the opinion on this? Is it worth me continuing? My idea
> > would be to make *only one* PyGtk release that builds against gtk-3.0,
> > it would see no new features.
> >
> > John
> >
> > [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
> > [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0

What's the status of this now? Is there every likely to be a pygtk
release for GTK+ 3?

--
[hidden email]
www.murrayc.com
www.openismus.com

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

John Stowers

> > >
> > > John
> > >
> > > [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
> > > [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
>
> What's the status of this now? Is there every likely to be a pygtk
> release for GTK+ 3?
>

I suspended the work during the large round of gtk+ breakage (rendering
cleanup mainly) and have not had the time to return to it.

My original goal was to do this in a backwards compatible way. With the
recent API changes to gtk+-3.0 this is no longer possible, things like
the expose/draw transition will be too hard to manage in PyGtk.
GtkApplication making use of GVariant are also going to be difficult to
wrap, minimally, the old way.

That said, I did receive some negative feedback about the idea.
PyGObject is the recommended way in future, and keeping PyGtk alive
might actually hold the platform back. There is certainly some truth in
that argument. In short, I am not sure what do do.

I suspect the whole job will be in the order of a full week of work, and
pragmatically I think this is actually a worthwhile week, given the
*huge* amount of PyGtk applications out there. Of course this argument
is a little weaker now that any PyGtk-3.0 port won't be backwards
compatible anymore.

I don't know what I plan to do. Thoughts appreciated.

Regards,

John

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Tshepang Lekhonkhobe
On Sun, Nov 7, 2010 at 23:24, John Stowers <[hidden email]> wrote:

>
>> > >
>> > > John
>> > >
>> > > [1] http://github.com/nzjrs/pygtk/commits/gtk-3.0
>> > > [2] http://github.com/nzjrs/pygobject/tree/gtk-3.0
>>
>> What's the status of this now? Is there every likely to be a pygtk
>> release for GTK+ 3?
>>
>
> I suspended the work during the large round of gtk+ breakage (rendering
> cleanup mainly) and have not had the time to return to it.
>
> My original goal was to do this in a backwards compatible way. With the
> recent API changes to gtk+-3.0 this is no longer possible, things like
> the expose/draw transition will be too hard to manage in PyGtk.
> GtkApplication making use of GVariant are also going to be difficult to
> wrap, minimally, the old way.
>
> That said, I did receive some negative feedback about the idea.
> PyGObject is the recommended way in future, and keeping PyGtk alive
> might actually hold the platform back. There is certainly some truth in
> that argument. In short, I am not sure what do do.

Don't bother adding 3.x support to PyGTK. Let it remain at current
released version forever, and give it only security/critical fixes. A
good migration (to PyGobject) guide should do, at least for the most
popular tasks.


--
blog: http://tshepang.tumblr.com
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Robert Park
In reply to this post by John Stowers
On Sun, Nov 7, 2010 at 2:24 PM, John Stowers
<[hidden email]> wrote:
> I don't know what I plan to do. Thoughts appreciated.

This seems like a fairly cut-and-dry situation to me. PyGTK is
officially considered "legacy support" only, all efforts should be
placed on making PyGObject as good as it can possibly be.

The idea of a backwards-compatible PyGTK-3 was noble, but if it's not
possible to maintain compatibility, then don't waste your time.

Just consider the most likely use-case for a backwards-incompatible PyGTK3:

Alice is an application developer who has written a non-trivial PyGTK2
application. She is informed that PyGTK2 is no longer supported and
that she'll need to port her app to stay current. She looks at the
available options and sees that she can either port to PyGTK3 or
PyGObject. She doesn't really know what PyGObject is, but based on the
name alone determines that PyGTK3 is the successor to PyGTK2. She
begins porting her app to PyGTK3 and eventually completes her port
successfully. Now what? She just spent a bunch of time porting to an
evolutionary dead-end and is left with something that is still old,
broken, and unsupported. Now she has to spend a bunch MORE effort
porting to PyGObject.

I think the community as a whole would be FAR better served by having
not just better PyGObject code, but better documentation for PyGObject
(including porting HOWTOs).

In my humble opinion, that is ;-)

--
http://exolucere.ca
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Stephen Langer-2

On Nov 8, 2010, at 11:15 AM, Robert Park wrote:

> Alice is an application developer who has written a non-trivial PyGTK2
> application. She is informed that PyGTK2 is no longer supported and
> that she'll need to port her app to stay current. She looks at the
> available options and sees that she can either port to PyGTK3 or
> PyGObject. She doesn't really know what PyGObject is, but based on the
> name alone determines that PyGTK3 is the successor to PyGTK2. She
> begins porting her app to PyGTK3 and eventually completes her port
> successfully. Now what? She just spent a bunch of time porting to an
> evolutionary dead-end and is left with something that is still old,
> broken, and unsupported. Now she has to spend a bunch MORE effort
> porting to PyGObject.

Hi.  I'm Alice, and I have no idea what you're talking about.  I'm heavily invested in PyGTK2 in a long-term project.  As far as I can tell, PyGObject is a low level library that doesn't serve the same purpose as PyGTK at all.  What's the relationship between the new PyGObject and the old?  What kind of porting do I have to look forward to, and on what time scale?

> I think the community as a whole would be FAR better served by having
> not just better PyGObject code, but better documentation for PyGObject
> (including porting HOWTOs).

Yes, please.

Thanks,
   Steve (not really Alice)

--
-- [hidden email]                    Tel: (301) 975-5423 --
-- http://math.nist.gov/mcsd/Staff/SLanger/   Fax: (301) 975-3553 --
-- NIST, 100 Bureau Drive, Stop 8910, Gaithersburg, Md 20899-8910 --

-- "I don't think this will work.  That's why it's science."      --
--                     Naomi Langer (age 6),  17 Feb 2003         --





_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Javier Jardón-2
2010/11/8 Stephen Langer <[hidden email]>:

> Hi.  I'm Alice, and I have no idea what you're talking about.  I'm heavily invested in PyGTK2 in a long-term project.  As far as I can tell, PyGObject is a low level library that doesn't serve the same purpose as PyGTK at all.  What's the relationship between the new PyGObject and the old?  What kind of porting do I have to look forward to, and on what time scale?
>

With PyGObject (since version 2.26) you can access any library with
GObject Introspection support, for example GTK+. A complete list here:
[1]
More info in the project home page: [2]


>> I think the community as a whole would be FAR better served by having
>> not just better PyGObject code, but better documentation for PyGObject
>> (including porting HOWTOs).
>
> Yes, please.
>

There are some tips here: [3]
Also, there is a GnomeGoal to port applications from PyGTK to
PyGObject here: [4]

> Thanks,
>   Steve (not really Alice)

Regards

[1] http://live.gnome.org/GnomeGoals/AddGObjectIntrospectionSupport
[2] http://live.gnome.org/PyGObject
[3] http://live.gnome.org/PyGObject/IntrospectionPorting
[4] http://live.gnome.org/GnomeGoals/PythonIntrospectionPorting
--
Javier Jardón Cabezas
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Robert Park
2010/11/8 Javier Jardón <[hidden email]>:
> [3] http://live.gnome.org/PyGObject/IntrospectionPorting

Hey, my edits are still there. I hope somebody finds that information useful ;-)

--
http://exolucere.ca
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

M3nt0r3
Il 09/11/2010 03:47, Robert Park ha scritto:
> 2010/11/8 Javier Jardón<[hidden email]>:
>> [3] http://live.gnome.org/PyGObject/IntrospectionPorting
> Hey, my edits are still there. I hope somebody finds that information useful ;-)
>
Any luck on windows ? And Mac os ?
My app needs to be portable.

Thanks
F.
--

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|

Re: PyGtk and gtk-3.0 compatibility

Robert Park
On Mon, Nov 8, 2010 at 8:23 PM, [hidden email]
<[hidden email]> wrote:
> Any luck on windows ? And Mac os ?
> My app needs to be portable.

I haven't attempted any other platforms, sorry.

--
http://exolucere.ca
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/