Re: [pygtk] PyGtk and gtk-3.0 compatibility
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?
--
murr...@murrayc.com
www.murrayc.com
www.openismus.com
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
[pygtk] gnome-python-extras release?
Could we have a new release of gnome-python-extras from svn trunk, please? Or should I do that? I need it for Glom. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
Re: [pygtk] ANNOUNCE: PyGObject 2.15.1
On Wed, 2008-07-16 at 16:22 +0200, Johan Dahlin wrote: > Murray Cumming wrote: > > On Wed, 2008-07-16 at 10:38 +0200, Johan Dahlin wrote: > >> I am pleased to announce version 2.15.1 of the Python bindings for GObject. > >> > >> The new release is available from ftp.gnome.org as and its mirrors > >> as soon as its synced correctly: > >> > >>http://download.gnome.org/sources/pygobject/2.15/ > >> > >> There are two new significant features in this release series, initial > >> bindings for GIO. Note that these are not complete, please report > >> missing API in Bugzilla so we know what people are missing. > > > > Do you have some online documentation for this API? > > A guy showed up and started to write GIO documentation. I have not seen the > initial work which he did, I'll let you know when I get my hands on it. Surely you have some way to at least put the generated reference documentation online, even if there are no human-generated descriptions? > > This was a big job for the C++ bindings due to the strange parameter > > orders, the many optional parameters, and the need to guess sensible > > default paramter values. So I'm interested in how you did it for Python. > > We're not binding the complete API, but from my head these are the > differences between the python and the C api: > * Add default values, NULL/0 etc where it make sense > * Swap argument order for cancellable arguments, so we can have a default > value of NULL. This makes it possible to do things such as: > gfile.read_async(callback) > * gfile.read() uses a return value instead of out parameter, just like > the builtin read method on file. > > The rest is afaicr pretty straight-forward. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] ANNOUNCE: PyGObject 2.15.1
On Wed, 2008-07-16 at 10:38 +0200, Johan Dahlin wrote: > I am pleased to announce version 2.15.1 of the Python bindings for GObject. > > The new release is available from ftp.gnome.org as and its mirrors > as soon as its synced correctly: > >http://download.gnome.org/sources/pygobject/2.15/ > > There are two new significant features in this release series, initial > bindings for GIO. Note that these are not complete, please report > missing API in Bugzilla so we know what people are missing. Do you have some online documentation for this API? This was a big job for the C++ bindings due to the strange parameter orders, the many optional parameters, and the need to guess sensible default paramter values. So I'm interested in how you did it for Python. > Codegen has been moved from PyGTK and can now be used without > depending on GTK+, which should be useful for GObject based libraries. > > What's new since PyGObject 2.15.1? > - Rename pygtk-codegen-2.0 to pygobject-codegen-2.0 to avoid >conflicting with PyGTK (Paul Pogonyshev) > > Blurb: > > GObject is a object system library used by GTK+ and GStreamer. > > PyGObject provides a convenient wrapper for the GObject+ library for use > in Python programs, and takes care of many of the boring details such as > managing memory and type casting. When combined with PyGTK, PyORBit and > gnome-python, it can be used to write full featured Gnome applications. > > Like the GObject library itself PyGObject is licensed under the > GNU LGPL, so is suitable for use in both free software and proprietary > applications. It is already in use in many applications ranging > from small single purpose scripts up to large full > featured applications. > > PyGObject requires glib >= 2.8.0 and Python >= 2.3.5 to build. > GIO bindings require glib >= 2.16.0. > > -- > Johan Dahlin > [EMAIL PROTECTED] > ___ > gnome-announce-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/gnome-announce-list -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Use of C++ "private" keyword in API.
The use of the C++ private keyword is causing a build failure in Glom
with the latest pyobject:
/*< private >*/
/* using union to preserve ABI compatibility (structure size
* must not change) */
union {
GSList *closures; /* stale field; no longer updated DO-NOT-USE!
*/
PyGObjectFlags flags;
} private;
Could this be renamed, please.
--
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] PolicyKit from Python
On Thu, 2008-02-07 at 22:55 +0800, David Zeuthen wrote: > On Wed, 2008-02-06 at 13:32 +0100, Murray Cumming wrote: > > On Tue, 2008-02-05 at 15:58 +0100, Murray Cumming wrote: > > > Does anyone know if there are already PolicyKit (and > > > policykit-gnome) python bindings? > > > > I discovered that I can probably do this with just the D-Bus API. I made > > the attached test case after some googling, but the call to PolicyKit's > > ObtainAuthorization() doesn't seem to have any effect. I'd welcome any > > advice. > > > > I'm on Ubuntu Hardy Heron, where PolicyKit is definitely working, as > > seen when I try to use the Services control panel, for instance, which > > has an Unlock button. > > > > I believe that I need to call ShowDialog() if ObtainAuthorization() > > denies authorization, but I want to understand this first part. > > The names of interfaces and objects changed a bit since 0.6 to 0.7 to > make it desktop agnostic (so in some future if the user is running > non-GNOME he will get a native authentication agent etc.); this is what > you should use > > http://hal.freedesktop.org/docs/PolicyKit/model-authentication-agent.html > http://hal.freedesktop.org/docs/PolicyKit-gnome/ref-auth-daemon.html > > There is no ShowDialog() any more. Does that clear it up? Thanks. I figured out a bit more since I sent the email, but I'm still having no luck. I blogged about it: http://www.murrayc.com/blog/permalink/2008/02/07/gnome-lirc-properties-using-policykit-to-get-sudo-access/ -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com > ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] PolicyKit from Python
On Tue, 2008-02-05 at 15:58 +0100, Murray Cumming wrote:
> Does anyone know if there are already PolicyKit (and
> policykit-gnome) python bindings?
I discovered that I can probably do this with just the D-Bus API. I made
the attached test case after some googling, but the call to PolicyKit's
ObtainAuthorization() doesn't seem to have any effect. I'd welcome any
advice.
I'm on Ubuntu Hardy Heron, where PolicyKit is definitely working, as
seen when I try to use the Services control panel, for instance, which
has an Unlock button.
I believe that I need to call ShowDialog() if ObtainAuthorization()
denies authorization, but I want to understand this first part.
--
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
>
#!/usr/bin/python
import pygtk
pygtk.require('2.0')
import gtk
import dbus
import os
class TestWindow:
def on_button_clicked(self, widget, data=None):
#Call the D-Bus method to request PolicyKit authorization:
session_bus = dbus.SessionBus()
policykit = session_bus.get_object('org.freedesktop.PolicyKit.AuthenticationAgent', '/', "org.gnome.PolicyKit.AuthorizationManager.SingleInstance")
if(policykit == None):
print("Error: Could not get PolicyKit D-Bus Interface\n")
gdkwindow = self.window.window
xid = gdkwindow.xid
print "Calling ObtainAuthorization..."
#This complains that no ObtainAuthorization(ssi) exists:
#granted = policykit.ObtainAuthorization("test_action_id", xid, os.getpid())
#TODO: Neither of the async callbacks are called, and how could the return value be useful if it is async?
granted = policykit.ObtainAuthorization("test_action_id", xid, os.getpid(), reply_handler=self.__handleAuthReply, error_handler=self.__handleAuthError)
print "...Finished."
print "granted=", granted
def __handleAuthReply(self, granted):
print "handleAuthReply: granted\n"
def __handleAuthError(self, exception):
print "handleAuthError: not granted: %s\n" % exception
def on_delete_event(self, widget, event, data=None):
# Close the window:
return False
def on_destroy(self, widget, data=None):
gtk.main_quit()
def show(self):
self.window.show()
def __init__(self):
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.connect("delete_event", self.on_delete_event)
self.window.connect("destroy", self.on_destroy)
self.button = gtk.Button("Obtain Authorization")
self.button.connect("clicked", self.on_button_clicked, None)
self.window.add(self.button)
self.button.show()
window = TestWindow()
window.show()
gtk.main()
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] PolicyKit from Python
Does anyone know if there are already PolicyKit (and policykit-gnome) python bindings? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Does gobject.idle_add guarantee execution order?
On Sat, 2007-12-08 at 08:40 -0600, [EMAIL PROTECTED] wrote: > Christopher> If I do something like > > Christopher> gobject.idle_add(foo) > Christopher> gobject.idle_add(must_run_after_foo) > > Christopher> Then am I guaranteed that these will indeed happen in the > Christopher> expected order? > > If the documentation doesn't state it, I don't think you can assume it. > Yuri showed one way to get the behavior you wanted. I also know that the order is definitely not guaranteed if you use different priorities, so you need to be careful that a progress notifier (sent often) could be called after an end notifier (called once). -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Use of C++ "private" keyword in API.
On Thu, 2007-06-28 at 12:39 +0200, Murray Cumming wrote:
> The use of the C++ private keyword is causing a build failure in Glom
> with the latest pyobject:
>
> /*< private >*/
> /* using union to preserve ABI compatibility (structure size
>* must not change) */
> union {
> GSList *closures; /* stale field; no longer updated DO-NOT-USE!
> */
> PyGObjectFlags flags;
> } private;
>
> Could this be renamed, please.
May I go ahead and fix this in svn?
--
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Use of C++ "private" keyword in API.
The use of the C++ private keyword is causing a build failure in Glom
with the latest pyobject:
/*< private >*/
/* using union to preserve ABI compatibility (structure size
* must not change) */
union {
GSList *closures; /* stale field; no longer updated DO-NOT-USE!
*/
PyGObjectFlags flags;
} private;
Could this be renamed, please.
--
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 11:20 +0200, Tim Janik wrote: > On Fri, 22 Jun 2007, Murray Cumming wrote: > > > On Fri, 2007-06-22 at 11:03 +0200, Tim Janik wrote: > >> On Fri, 22 Jun 2007, Murray Cumming wrote: > >> > >>> On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote: > >>>> On Fri, 22 Jun 2007, Murray Cumming wrote: > >>>> > >>>>> On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: > >>>> > >>>>>> b) GtkTooltips is going to be deprecated in 2.12 anyways, so there > >>>>>> is little use in continuing to use it anyway. > >>>>>> c) note that the actual compilation changes could easily be ironed out > >>>>>> by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was > >>>>>> introduced > >>>>>> deliberately, to catch remaining tips_data_list uses in third-party > >>>>>> code which should be removed now, since tips_data_list became a > >>>>>> mere alias for NULL for future Gtk+ versions. > >>>>> > >>>>> When was GtkTooltips::tips_data_list deprecated, if it was every public > >>>>> API? > >>>> > >>>> reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 > >>>> in favour of GtkTooltip. > >>> > >>> So, this is deprecation with a break. Breaking normally follows > >>> deprecation after a delay. Deprecation with a break is just a break. > >> > >> every change is a "break" in some sense. the question is whether the > >> change actually affect applications badly or not (not what name is given > >> to it). so far, no case has been made for tips_data_list=NULL badly > >> affecting applications or LBs, i'm still waiting. > > > > I was talking about the renaming of the struct field, which breaks > > builds. If the rename is going to be reverted, and the change of > > behavior has no bad effect then that's fine. > > the structure field renaming is there to catch current third-party uses. > that way we can gather feedback on field usage and figure if there are > cases where the behavior change has bad effects. > > as for reverting the structure field rename, i don't think that > is really necessary for 2.12. Gtk+ 2.x stable branches are supposed > to be ABI and API compatible, however not neccessarily source > compatible. This is news to me, though similar things have been done before. I thought we had got better. > when 2.12 deprecates GtkTooltips, the field is not > anymore part of the API, ABI is maintained by its NULL assignment, > and the source incompatibility is covered by README.in (as all > source/API changes have to be). -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 11:03 +0200, Tim Janik wrote: > On Fri, 22 Jun 2007, Murray Cumming wrote: > > > On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote: > >> On Fri, 22 Jun 2007, Murray Cumming wrote: > >> > >>> On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: > >> > >>>> b) GtkTooltips is going to be deprecated in 2.12 anyways, so there > >>>> is little use in continuing to use it anyway. > >>>> c) note that the actual compilation changes could easily be ironed out > >>>> by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced > >>>> deliberately, to catch remaining tips_data_list uses in third-party > >>>> code which should be removed now, since tips_data_list became a > >>>> mere alias for NULL for future Gtk+ versions. > >>> > >>> When was GtkTooltips::tips_data_list deprecated, if it was every public > >>> API? > >> > >> reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 > >> in favour of GtkTooltip. > > > > So, this is deprecation with a break. Breaking normally follows > > deprecation after a delay. Deprecation with a break is just a break. > > every change is a "break" in some sense. the question is whether the > change actually affect applications badly or not (not what name is given > to it). so far, no case has been made for tips_data_list=NULL badly > affecting applications or LBs, i'm still waiting. I was talking about the renaming of the struct field, which breaks builds. If the rename is going to be reverted, and the change of behavior has no bad effect then that's fine. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 10:46 +0200, Tim Janik wrote: > On Fri, 22 Jun 2007, Murray Cumming wrote: > > > On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: > > >> b) GtkTooltips is going to be deprecated in 2.12 anyways, so there > >> is little use in continuing to use it anyway. > >> c) note that the actual compilation changes could easily be ironed out > >> by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced > >> deliberately, to catch remaining tips_data_list uses in third-party > >> code which should be removed now, since tips_data_list became a > >> mere alias for NULL for future Gtk+ versions. > > > > When was GtkTooltips::tips_data_list deprecated, if it was every public > > API? > > reppeating what i wrote above, GtkTooltips will be deprecated in 2.12 > in favour of GtkTooltip. So, this is deprecation with a break. Breaking normally follows deprecation after a delay. Deprecation with a break is just a break. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: > > As noted in bug http://bugzilla.gnome.org/show_bug.cgi?id=449318, > > there was a recent gtk+ API change. jdahlin just barely told me that > > the changed API has existed since 1998, long before gtk+-2.11.x (and > > pointed me to http://bugzilla.gnome.org/show_bug.cgi?id=447214). This > > API change breaks pygtk and means that much of GNOME cannot be > > compiled. But it doesn't seem clear who should fix this. Should gtk+ > > revert it or somehow fix the API break, or is this an API break we > > want and expect pygtk to adapt to? > > so far, my take on the issue is that PyGtk should adapt to that > change by not using tooltips->tips_data_list, because: > a) i haven't seen a single argument yet about why giving up using > tips_data_list would be bad for PyGtk or any other application > for that matter; > b) GtkTooltips is going to be deprecated in 2.12 anyways, so there > is little use in continuing to use it anyway. > c) note that the actual compilation changes could easily be ironed out > by Gtk+ by doing s/_tips_data_list/tips_data_list/ but was introduced > deliberately, to catch remaining tips_data_list uses in third-party > code which should be removed now, since tips_data_list became a > mere alias for NULL for future Gtk+ versions. When was GtkTooltips::tips_data_list deprecated, if it was every public API? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] pygtk svn trunk build broken.
The pygtk build in jhbuild is currently failing with: gtk.c: In function '__GtkNotebook_class_init': gtk.c:62730: warning: assignment from incompatible pointer type gtk.c:62750: warning: assignment from incompatible pointer type gtk.c: In function '__GtkScrolledWindow_class_init': gtk.c:68636: warning: assignment from incompatible pointer type ./gtk.override: In function '_wrap_gtk_tooltips__get_tips_data_list': ./gtk.override:3130: error: 'GtkTooltips' has no member named 'tips_data_list' make[2]: *** [_gtk_la-gtk.lo] Error 1 make[2]: Leaving directory `/home/murrayc/svn/gnome218/pygtk/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/murrayc/svn/gnome218/pygtk' make: *** [all] Error 2 -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Branching gnome-python-extras
On Wed, 2007-05-23 at 12:21 +0200, Murray Cumming wrote: > On Fri, 2007-03-16 at 18:55 +0100, Murray Cumming wrote: > > If there are no objections, I'll branch gnome-python-extras as > > "gnome-2-18", so I can change pygda to use libgda-3.0. > > > > I'll probably also increase its version from 2.14 to 2.19, to be in sync > > with gnome-python's version number. > > Could we have a gnome-python-extras 2.19.x tarball, please, or is there > any objection to me releasing it? OK, so I will release a new tarball. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Branching gnome-python-extras
On Fri, 2007-03-16 at 18:55 +0100, Murray Cumming wrote: > If there are no objections, I'll branch gnome-python-extras as > "gnome-2-18", so I can change pygda to use libgda-3.0. > > I'll probably also increase its version from 2.14 to 2.19, to be in sync > with gnome-python's version number. Could we have a gnome-python-extras 2.19.x tarball, please, or is there any objection to me releasing it? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Branching gnome-python-extras
If there are no objections, I'll branch gnome-python-extras as "gnome-2-18", so I can change pygda to use libgda-3.0. I'll probably also increase its version from 2.14 to 2.19, to be in sync with gnome-python's version number. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Overriding GObject methods in Python
On Fri, 2006-11-24 at 13:44 +, Ed Catmur wrote: > Unfortunately not; the vfunc signatures are only expressed in the > header files. Thus they aren't in the binary and aren't accessible to > GObject introspection. Even the new introspection? That's meant to make extra information available. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Overriding GObject methods in Python
On Fri, 2006-11-24 at 11:29 +0100, Hrvoje Nikšić wrote: > On Fri, 2006-11-24 at 10:33 +0100, Murray Cumming wrote: > > On Thu, 2006-11-23 at 12:27 +0100, Hrvoje Nikšić wrote: > > [snip] > > > The problem is that the fields of XyzClass and its descendants are > > C > > > struct members, as inaccessible to Python code as any field of a C > > > struct, at least without heavy ctypes hackery. > > [snip] > > > > But I guess that pygtk (like other bindings) has a standard way of > > wrapping these, because they are needed in order to implement custom > > GtkTreeModels or GtkCellRenderers, among other things. > > As far as I can tell by looking at gtk/pygtkcellrenderer.c, PyGTK allows > overriding by creating a "stub class" PyGtkGenericCellRenderer that > inherits GtkCellRenderer and overrides its C methods with its own > methods that call into Python. GtkTreeModel is handled exactly the > same. > > While this approach works for a specific class, it requires writing > non-trivial glue code for each class that needs to be subclassed. It > doesn't allow a Python programmer to subclass a given GObject class > directly from Python. If that glue code is hand-coded, I guess it's repetitive and can be generated somehow. In a future pygtk that uses the future introspection features of GObject, it could probably even be done at runtime for arbitrary GObjects. Gtkmm generates the equivalent glue code for this given 1. the desired signature of the C++ virtual function via e.g. _WRAP_VFUNC(void do_something(int thing), do_something) 2. the signature of the C vfunc, in our hand-written libsomethingorother_vfuncs.defs file. 3. Conversions between the C parameters and the C++ parameters. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Overriding GObject methods in Python
On Thu, 2006-11-23 at 12:27 +0100, Hrvoje Nikšić wrote: [snip] > The problem is that the fields of XyzClass and its descendants are C > struct members, as inaccessible to Python code as any field of a C > struct, at least without heavy ctypes hackery. [snip] But I guess that pygtk (like other bindings) has a standard way of wrapping these, because they are needed in order to implement custom GtkTreeModels or GtkCellRenderers, among other things. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Best path to pygtk support in library
On Mon, 2006-10-30 at 08:13 -0500, Samuel Cormier-Iijima wrote: > You might want to look at this FAQ entry as a starting point: > > http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq23.022.htp > > Sorry I can't help you more, just found this looking for some other > PyGTK related stuff and hoped it could help. > > Samuel Cormier-Iijima > > On 10/29/06, Sean Kelley <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I have a collection of Gtkmm widgets that are a part of a library. > > What are my options in providing support for PyGtk? Will I need to > > rewrite those widgets in C as a Gtk+ library? Or is there a way to > > provide Python bindings to a Gtkmm library? Yes, the use of pygobject_new() will allow you to get an object that you can use in Python code. But I guess that just gives you a generic base API for that object, unless you also have a pygtk-style wrapper for an underlying GObject. For instance, pygobject_new() wouldn't normally give you an object with python methods like the C++ object's methods. I'm using pygobject_new() in Glom where I use both C++ and Python bindings for libgda, using both APIs for the same underlying object. I guess it might be worth investigating the use of the Python API (or boost::python) to provide real pygtk/Python bindings for a gtkmm-based class, but it's not something I've tried before. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: Stop a row in a TreeView from being draggable
> Quoting Alan Franzoni: > >> If you want to stop *all rows* from being draggable, here's a quick >> hack: >> >> treeview.drag_source_unset() >> treeview.drag_dest_unset() >> >> Truly speaking, they can be dragged anyway, but they won't drop >> anywhere. >> >> If you wanted to prevent just some rows from being dragged... I don't >> know, >> maybe you could connect a callback to dynamically set/unset >> drag_source , >> but I think there'll be a better way around that. > > Thanx for the reply. I should have mentionned that I need some rows to > be draggable and some not. In a gtkmm example, we do this by deriving from the TreeModel and overriding some of its vfuncs: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch08s06.html As far as I can tell, this is how to do it in C as well. I'm not sure if pygtk offers a way to do this. The gtkmm example: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch08s08.html#id2521693 Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Mentioning gnome-python* more on the web site.
May I suggest that this page http://www.pygtk.org/downloads.html also mention gnome-python, gnome-python-desktop, and gnome-python-extras. At the moment I don't have any definitive web site to point people at when mentioning Glom's pygda dependency (and the brief use of pygtk in Glom's example). Thanks. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pygda build broken: const-GObject
On Sun, 2006-04-23 at 12:20 +0100, Gustavo J. A. M. Carneiro wrote: > On Sáb, 2006-04-22 at 22:07 +0200, Murray Cumming wrote: > > " > > Could not write method GdaValue.get_gobject: No ArgType for 'const > > GObject*' > > " > > > > Has something changed? > > New code was added to pygtk codegen to handle const-SomeObject*, but > we forgot to handle the case when it is used as return type. Fixed in > HEAD now, and gda API has at least one more wrapped method ;-) Many thanks. That's working for me now. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] pygda build broken: const-GObject
The pygda build is currently broken (in gnome-python-extras when libgda
is installed):
"
gda.c: In function '_wrap_gda_value_get_gobject':
gda.c:1689: error: syntax error before '-' token
"
That's because the code generator is generating this:
"
static PyObject *
_wrap_gda_value_get_gobject(PyObject *self)
{
const-GObject *ret;
"
That's probably because the .defs file says
"
(define-method get_gobject
(of-object "GdaValue")
(c-name "gda_value_get_gobject")
(return-type "const-GObject*")
)
"
But I think that's correct, and the hyphen is used elsewhere. If I take
the hyphen away then I get this warning instead:
"
Could not write method GdaValue.get_gobject: No ArgType for 'const
GObject*'
"
Has something changed?
--
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] ANNOUNCE: GnomePythonExtras 2.13.2 (unstable)
On Wed, 2006-01-18 at 20:24 +, Gustavo Carneiro wrote: > On Wed, 2006-01-18 at 16:28 +0100, Murray Cumming wrote: > > On Tue, 2006-01-17 at 00:25 +, Gustavo J. A. M. Carneiro wrote: > > > - Revert back to wrapping pygda 1.2 due to API instability of 2.0 > > > (Murrray Cumming) > > > > I messed up the pkg-config file. It's fixed in CVS. Could we have > > another release please? Sorry for the bother. > > > > Can you wait until next weekend? If so, sure (I can even finish the > g-p-e/g-p-d split), else you'll have to do it for me. It's easy for distros to patch, so don't worry. > Busy work week, > I'm afraid :| Thanks for the effort splitting g-p-e. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: [gnome-db] libgda python bindings
On Wed, 2005-05-25 at 07:44 +0200, Sergio Srdjan Vemic wrote: > Hello, > > is there any progress on python bindings for libgda? You'd have to be more specific. There are python libgda bindings in gnome-python-extras 2.11, and in cvs. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Wrapping Gtksheet
On Wed, 2005-05-18 at 12:07 +, Philippe Collet wrote: > Hi list, > I'm a beginner in the wrapping process. > I'm trying to create a wrapper to use gtksheet with pygtk. This already exists, I believe, at least for the GTK+ 1.2 version: http://sourceforge.net/projects/python-gtkextra/ However, I know from wrapping this for C++ that gtkextra is not particularly good, plus most of it now has better replacements in GTK+ itself. The API is lousy and the behaviour is rather fragile. I am not encouraged by seeing the first and only release of the GTK+ 2 port being called 2.0, as if it could be instantly API stable. For a while, the GtkPlot stuff from gtkextra filled a real need, but I would choose the new gnumeric charting stuff instead now. > I found this faq which is a little bit complicated because we have to modify > the configure.in and to use autogen.sh. > http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq01.011.htp > > Is this faq up to date and is there any other links except: > http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq06.003.htp > http://www-106.ibm.com/developerworks/linux/library/l-wrap/ > > I'm looking for any materials which can explain me the wrapping with pygtk. > Thanks a lot, > Philippe -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: [gnome-db] libgda python bindings
Gustavo, could you please do a gnome-python-extras 2.11.x tarball release? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: [gnome-db] libgda python bindings
On Fri, 2005-04-08 at 16:11 +0200, Murray Cumming wrote: > On Fri, 2005-04-08 at 15:29 +0200, Murray Cumming wrote: > > Is it normal to change the .defs (which should > > describe the C API) to get a different python API? > > On irc, Johan Dahlin also said: > > murrayc> Is there really no way to add API without changing .defs? > jdahlin> murrayc: there is, let me see > jdahlin> murrayc: in foo.override, do % \n define class.method > jdahlin> murrayc: and then _wrap_klass_with_underscore_method_name > > I would prefer that, so that > - The .defs are just a description of the C API. > - We can regenerate the .defs without worrying about redoing our > changes/hacks. Filip, I have added your get_key() method in the .override file, without changing the .defs. I'm not sure if this works. I have not tried it in an example, because I am not sure where this should be used anyway. Maybe you could add an example for it? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: [gnome-db] libgda python bindings
On Fri, 2005-04-08 at 10:48 -0300, Johan Dahlin wrote: > >>I put these in because they came from gda_init() which is never called in > >>the python module. Note that I did had set GETTEXT_PACKAGE to libgda-2, > >>too. The idea obviously was that libgda warnings or errors be localized. > >> > >> > The best approach here is to call gda_init() in your module init > function and then let the library worry about the rest. It's usually a > bad idea to copy code from a library into a wrapper. Thanks. I've done that, by looking at the pygtk/gtk/gtkmodule.c:gtkinit () code. > >Yes, I regenerated the defs file, and added your BoxedTypes definitions > >to it. I don't know what's normal, but I guessed that h2defs.py would > >create correct .defs, and it seems to work. > > > > > h2defs.py is not perfect, it happens from time to time that it does not > pick up stuff from headers properly, especially if you're not using the > gtk+ coding style. OK. Now I understand that the "method" is not meant to be the C function name, but should be the name of the method inside the object, or a global function inside the module. I have rename the gda_config_* methods to config_* in the .defs file, like it was in pygda 0.3.0. However, isn't this possible in python/pygtk? gda.Config.get_key(). instead of gda.config_get_key(). even if there is no GdaConfig object? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: CVS account request
On Fri, 2005-04-08 at 17:51 +0200, Christian Rose wrote: > fre 2005-04-08 klockan 17:31 +0200 skrev Filip Van Raemdonck: > > Hi, > > > > I'd like to request a CVS account on cvs.gnome.org because Murray Cumming > > added libgda python bindings into the gnome-python-extras module and, me > > being the original author for these bindings, he suggested I should continue > > to maintain them. > > Murray, can you confirm, and do you support this CVS account request? Yes. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: [gnome-db] libgda python bindings
On Fri, 2005-04-08 at 15:29 +0200, Murray Cumming wrote: > Is it normal to change the .defs (which should > describe the C API) to get a different python API? On irc, Johan Dahlin also said: murrayc> Is there really no way to add API without changing .defs? jdahlin> murrayc: there is, let me see jdahlin> murrayc: in foo.override, do % \n define class.method jdahlin> murrayc: and then _wrap_klass_with_underscore_method_name I would prefer that, so that - The .defs are just a description of the C API. - We can regenerate the .defs without worrying about redoing our changes/hacks. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: [gnome-db] libgda python bindings
On Fri, 2005-04-08 at 15:00 +0200, Filip Van Raemdonck wrote: > Hi, Please use Reply To All so that the list sees your reply too. > On Thu, Mar 31, 2005 at 03:19:03PM +0200, Murray Cumming wrote: > > On Thu, 2005-03-31 at 13:47 +0100, Gustavo J. A. M. Carneiro wrote: > > > > > > If someone else will supply the patches and I just do > > > maintainer/review/minor-correction work, then definitely yes. I'm all > > > for it, and the "pygtk community" seems to think this a good idea. > > > > I guess that Filip and I can handle this, with some help sometimes. > > Shall I go ahead and add them to cvs? It might take me a couple of days > > to figure everything out. > > > > Filip, do you have a GNOME cvs account? > > No, I haven't. Do I need one? ;) Yes, I think you will. Here are some instructions: http://developer.gnome.org/doc/policies/accounts/requesting.html I am happy to apply patches for you until you get your account. > Anyway: I've dug out the changes I made since that first public release, > been trying to sync them to your checkin from a few days ago but I'm a bit > lost with what you changed in the checkin (or why you changed some > things). Mostly I changed stuff just to make it build and to make the examples work. I don't think that your pygda 0.3 tarball built for me either. I'm not an expert on any of this stuff. > In random order: > > In gdamodule.c there is this: > cut--- > 12 : /* This was in pygda 0.3, but is not in other *module.c files > in gnome-python-extras. murrayc. > 13 : bindtextdomain (GETTEXT_PACKAGE, GDA_LOCALEDIR); > 14 : bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8"); > 15 : */ > cut--- > > I can see why you removed these, but I'm not sure if they should've been. I have no idea. I didn't see them in other parts of gnome-python-extras or gnome-python, but I didn't look everywhere. > I put these in because they came from gda_init() which is never called in > the python module. Note that I did had set GETTEXT_PACKAGE to libgda-2, > too. The idea obviously was that libgda warnings or errors be localized. > > Another thing, in gda.defs all functions have the gda_ prefix. I > specifically left these out as a change in my (prerelease) 0.0.2 bindings, > and I believe other bindings do it the same way. Am I mistaken, has > something changed since I did those bindings, have I simply missed > something? Is there a reason these prefixes are back or is it simply > because you regenerated the .defs file from scratch? (Don't know if you > actually did, I'm just guessing) Yes, I regenerated the defs file, and added your BoxedTypes definitions to it. I don't know what's normal, but I guessed that h2defs.py would create correct .defs, and it seems to work. With your .defs, I got a lot of error messages during generation. Are you using the latest pygtk? > Next, everything from gda-error.h appears to be missing from the .defs > file. Is this on purpose or by accident? No, let's add that back then. > I do have a patch (attached) which was the most important change, against > your checkin. It adds a config_get_key function, and does removes the > config_get_ functions. It doesn't make lot of sense to have various > config_get_ methods in a dynamically type language IMHO :) > I do not know if it works with the CVS code; it did work in my codebase > and I don't see why it shouldn't know. Yes, that looks good. Is it normal to change the .defs (which should describe the C API) to get a different python API? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: [gnome-db] libgda python bindings
On Thu, 2005-03-31 at 15:19 +0200, Murray Cumming wrote: > On Thu, 2005-03-31 at 13:47 +0100, Gustavo J. A. M. Carneiro wrote: > > On Thu, 2005-03-31 at 13:17 +0200, Murray Cumming wrote: > > > So, Gustavo (gnome-python-extras maintainer), may we add this to gnome- > > > python-extras? > > > > OK, if you want me to do most of the work for these bindings, I have > > to think about it. It depends on how much API is there and how much > > bindings-friendly it is. > > > > If someone else will supply the patches and I just do > > maintainer/review/minor-correction work, then definitely yes. I'm all > > for it, and the "pygtk community" seems to think this a good idea. > > I guess that Filip and I can handle this, with some help sometimes. > Shall I go ahead and add them to cvs? It might take me a couple of days > to figure everything out. OK. I have added it now. I had to make some small changes to pygda 0.3.0 to make it build, but not so many. It's still very rough, so any changes are welcome. I'll try to work on it gradually. I added a couple of examples too, which sort of work. > Filip, do you have a GNOME cvs account? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: [gnome-db] libgda python bindings
On Thu, 2005-03-31 at 13:47 +0100, Gustavo J. A. M. Carneiro wrote: > On Thu, 2005-03-31 at 13:17 +0200, Murray Cumming wrote: > > So, Gustavo (gnome-python-extras maintainer), may we add this to gnome- > > python-extras? > > OK, if you want me to do most of the work for these bindings, I have > to think about it. It depends on how much API is there and how much > bindings-friendly it is. > > If someone else will supply the patches and I just do > maintainer/review/minor-correction work, then definitely yes. I'm all > for it, and the "pygtk community" seems to think this a good idea. I guess that Filip and I can handle this, with some help sometimes. Shall I go ahead and add them to cvs? It might take me a couple of days to figure everything out. Filip, do you have a GNOME cvs account? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: [gnome-db] libgda python bindings
So, Gustavo (gnome-python-extras maintainer), may we add this to gnome- python-extras? On Tue, 2005-03-29 at 18:50 +0200, Filip Van Raemdonck wrote: > On Tue, Mar 29, 2005 at 04:24:00PM +0200, Rodrigo Moya wrote: > > On Tue, 2005-03-29 at 13:51 +0200, Murray Cumming wrote: > > > > > > I need some libgda (2.0) python bindings for my Glom project. I notice > > > that a pygda project was started, but has not made much progress: > > > http://mail.gnome.org/archives/gnome-announce-list/2004- > > > January/msg00046.html > > I've made some (not much though) changes after that, but I don't even know > on which harddrive I left them. I'll take a look if I can find them. > > > > Could we put this in GNOME's CVS, maybe in gnome-python-extras? I have > > > CCed the pygda author. > > > > as you want. > > Indeed. I wouldn't mind maintaining these bindings by myself, but they > worked for what I needed and have always had other items higher up on my > todo list so I never got around to do more work on them. > > > Regards, > > Filip > -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] libgda python bindings
I need some libgda (2.0) python bindings for my Glom project. I notice that a pygda project was started, but has not made much progress: http://mail.gnome.org/archives/gnome-announce-list/2004- January/msg00046.html Could we put this in GNOME's CVS, maybe in gnome-python-extras? I have CCed the pygda author. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Where is gnome-python?
On Tue, 2005-03-01 at 13:33 +, Gustavo J. A. M. Carneiro wrote: > On Tue, 2005-03-01 at 14:26 +0100, Murray Cumming wrote: > >On Mon, 2005-02-28 at 21:47 -0700, Elijah Newren wrote: > >> On Tue, 1 Mar 2005 01:31:31 -0300, Eric Jardim <[EMAIL PROTECTED]> wrote: > >> > Why does gnome-python and other specific bindings besides PyGTK do not > >> > appear on this page on the GNOME project? > >> > > >> > http://www.gnome.org/start/2.9/bindings/#python > >> > >> This appears to be an oversight, AFAICT. If anyone would like to make > >> a patch against > >> gnomeweb-wml/www.gnome.org/start/2.9/bindings/index.wml, we should be > >> able to get this straightened out. > > > >I have added that now. > > Thanks! > > BTW, the CVS modules are not correct. It should be gnome-python/pygtk > and gnome-python/gnome-python. Fixed. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Where is gnome-python?
On Mon, 2005-02-28 at 21:47 -0700, Elijah Newren wrote: > On Tue, 1 Mar 2005 01:31:31 -0300, Eric Jardim <[EMAIL PROTECTED]> wrote: > > Why does gnome-python and other specific bindings besides PyGTK do not > > appear on this page on the GNOME project? > > > > http://www.gnome.org/start/2.9/bindings/#python > > This appears to be an oversight, AFAICT. If anyone would like to make > a patch against > gnomeweb-wml/www.gnome.org/start/2.9/bindings/index.wml, we should be > able to get this straightened out. I have added that now. Other bindings are not there because they are not on the release schedule, usually because they do not follow the GNOME Platform Bindings rules. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: API freeze break request
On Fri, 2005-01-14 at 18:08 +, Mark McLoughlin wrote: > > I'm not happy about adding a whole > > class after an API freeze, because we'll have no chance to fix it if > > it's not perfect. > > The python API is a direct mapping of the GConf one - I think it may > even be autogenerated from the headers. I didn't come up with the API > definition, it was already there ... I just implemented it .. OK. I expected that they had to hand-craft their APIs a bit more than that. If this is saving you considerable pain on an important project then I'll give you 1 approval. If it's just nice to have then I still don't feel it's worth the risk. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: API freeze break request
On Fri, 2005-01-14 at 16:12 +, Mark McLoughlin wrote: > Hi, > The python GConf binding is missing a wrapping for GConfEngine, which > isn't used very often but I came across a need for it while writing a > little admin tool for GConf. > > See the patch below. The pygtk maintainers seem to be okay about > including it, so long as the release team approve. > > See: > > http://bugzilla.gnome.org/show_bug.cgi?id=164059 > > for more details. Patch appended. Its pretty straightforward and > shouldn't impact any existing APIs. Can't you work around this in some way? For instance, can't you include your own local wrapper of this class? I'm not happy about adding a whole class after an API freeze, because we'll have no chance to fix it if it's not perfect. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] stock item
> As I want to create a stock item for the button Credits in a gnome about > window, I wounder why there is not stock item gtk-credits or gtk-about > or anything else. There is one in GTK+ 2.5/2.6. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] The Great Master Plan for Python Bindings
One thing that might prove the point and allow a split to actually happen, is people volunteering to maintain the individual packages. It's pretty scary to volunteer to help to maintain all of gnome-python, but it's not so scary to maintain just the gnome-vfs or gconf bindings, for instance. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] The Great Master Plan for Python Bindings
> On Tue, Oct 12, 2004 at 09:28:37PM +0100, Gustavo J. A. M. Carneiro wrote: >> First of all, we have the problem of gnome-python being proposed for >> inclusion in the gnome bindings. Since it contains bindings[1] for libraries that do not belong to the GNOME Developer Platform, they should be split out of gnome-python. I am personally in favour of this approach. > > I am as well if this means something like the pygtk-extras package we had discussed earlier this year. I don't think it's worth the hassle of > splitting everything up -- makes it hard for us, makes it hard for the end-users who just want to pick up an extra package and go. End "users" don't pick gnome-python packages - they pick applications and sane distros do the rest for them. End "developers who use pygtk" don't use the source tarballs - they use the distro packages, which are usually split up completely even if the tarball isn't. For people who actually work on pygtk, there's jhbuild. > Is there a > good argument *for* splitting everything up? I can think of 1. It will be awkward to move something like pygnomeprint from pygtk-extra to gnome-python when (if) libgnomeprint becomes part of the GNOME Platform. 2. Distros must split them up completely, so doing it in the tarball makes different distros do that more consistently. 3. You would be able to release fixes for the gnome-vfs bindings, for instance, even if the bonobo bindings, for instance, are temporarily broken. 4. Distros would be able to ship fixes for the gnome-vfs bindings, for instance, even if you have released, for instance, broken bonobo bindings. 5. It will be easier to share maintenance - in particular, different people can decide when different parts of gnome-python make new releases. The whole thing is a lot of code for one person to maintain. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gnome_authentication_manager_init
> No, because no one warned me this API was missing. Now, as > punishment, you have to wait 6 months for gnome-python 2.10 ;-) Let's not scare people too much. Although you have to wait 6 months for a stable version of gnome-python that has this, you can have it much sooner in an unstable test version, or from cvs, particularly if you submit a patch. > You could also wrap it in a small custom python C module for the time > being.. > > Mental note: need to run h2defs through libgnome* headers and merge in > any API additions in development branch of gnome-python. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Guidelines for pygtk in the GNOME Desktop?
> Qua, 2004-09-29 às 17:45 +0200, Murray Cumming escreveu: >> > I suggest that we come up with a PyGnomeHello sample application in >> > python, but using autotools, gnome autogen, etc. A "Best Current >> > Practices" program, to serve as example. >> >> That would be wonderful. Could someone do that this week, please? > > Between me and Johan Dahlin I think we can come up with a good sample, > but probably more towards the end of the week. > > I assume we want a model application for the future GNOME 2.10 > platform. Also assuming gnome-python would be in such platform. > Therefore I'm thinking of using the following modules: > o gtk > o gnome.vfs > o gconf Don't worry about writing code to actually do stuff. It's just the build system and these guidelines that need to be demonstrated here. Of course, useful code examples are always good, but I think that's a different issue. By all means do this in the same module, but don't let perfectionism delay things. We have a similar thing for gtkmm, even if I don't maintain it as much as I should. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Guidelines for pygtk in the GNOME Desktop?
> I suggest that we come up with a PyGnomeHello sample application in > python, but using autotools, gnome autogen, etc. A "Best Current > Practices" program, to serve as example. That would be wonderful. Could someone do that this week, please? > Probably we can come up with a > document too, explaining how to do python gnome integration. > >> >> I'm not a python coder so feel free to correct me, but I suggest: >> >> 1. GNOME Desktop modules should use the #! technique to specify a >> particular version of python, to avoid breaking the application when a >> new >> incompatible version of python is installed. For instance: >> #!/usr/bin/python-2.3 > > I think it would be more correct: > #! /usr/bin/env python2.3 > > An alternative would be to make configure check AM_PATH_PROG > (python2.3), and sed replace the first line of the program script > frontend with the correct path. So if the user installs python 2.3 > in /usr/local, the installed python program packages still > use /usr/bin/python2.3. > > This sort of decisions should be discussed and standardised. > >> Distributers of binary packages must, of course, adjust the prefix in >> this >> path if necessary. >> >> 2. The GNOME Desktop should use only one major version of python, such >> as >> 2.2 or 2.3, but not both. Which version to use, and when to start using >> a >> newer one, should be agreed among the maintainers. > > Fine. > >> >> 3. The GNOME Desktop should use only python bindings that are in the >> GNOME >> Bindings release, because those bindings offer API stability, and a >> reliable release schedule. There might be exceptions to this [1], but >> this should be avoided for commonly-used bindings, and these extra >> modules >> would then need to be approved as part of the GNOME Desktop instead of >> the >> GNOME Bindings. > > I hope you mean "The GNOME Desktop should use only python bindings _of > GNOME libraries_ that are in the GNOME Bindings release". Yes. But my sentences get long and boring very easily. > Because > applications may wish to use python bindings for external libraries, > just like GNOME C applications are allowed to use non-GNOME libraries > too, as long as there is no GNOME library providing similar > functionality. Yes, though we often have to say that these are part of the Desktop. > Also, I think this places an extra importance on the future inclusion > of gnome-python in the GNOME Bindings. Yes, definitely. > Therefore, I commit myself to > propose its inclusion for GNOME 2.10, when the time comes. Wonderful, and I thank you. That time is now, really. The actual decision comes later. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Guidelines for pygtk in the GNOME Desktop?
So, it looks like the GNOME community would like to allow the use of python and python bindings in GNOME Desktop modules. Well done. But I think there need to be some rules about this. I'm not sure whether these should be part of the GNOME release team documentaton, or part of the pytgtk documenatation that we could link to. I'm not a python coder so feel free to correct me, but I suggest: 1. GNOME Desktop modules should use the #! technique to specify a particular version of python, to avoid breaking the application when a new incompatible version of python is installed. For instance: #!/usr/bin/python-2.3 Distributers of binary packages must, of course, adjust the prefix in this path if necessary. 2. The GNOME Desktop should use only one major version of python, such as 2.2 or 2.3, but not both. Which version to use, and when to start using a newer one, should be agreed among the maintainers. 3. The GNOME Desktop should use only python bindings that are in the GNOME Bindings release, because those bindings offer API stability, and a reliable release schedule. There might be exceptions to this [1], but this should be avoided for commonly-used bindings, and these extra modules would then need to be approved as part of the GNOME Desktop instead of the GNOME Bindings. [1] gst-python has already been suggested. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] pygk 2.4.0?
Presumably pygtk 2.4 is now API stable (as per the schedule), so shouldn't there be a pygtk 2.4.0 release to show that? Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] PyGTK in the standard Library
On Fri, 2004-06-18 at 20:32 -0300, Christian Robottom Reis wrote: > On Fri, Jun 18, 2004 at 10:27:28AM +0100, Matthew Bull wrote: > > There have been several discussions on the list in the last few months > > about trying to get PyGTK into the standard library, and whilst > > attending europython recently I had an opportunity to steer > > conversations in that direction with a lot of people to get a feel for > > the (european at least) communities take on this, most of the people I > > spoke to where non PyGTK folks, and the opinions seemed to be generally > > favourable. > [snip numerous arguments in favor of including pygtk] > > Summarizing the issues presented in this thread, we have the following > topics that want evaluation: > > - Combined Release pygtk is currently on the GNOME 6-monthly time-based release schedule. Unless the Python release schedule is the same as the GNOME release schedule (highly unlikely) then it can't really be on both schedules. I am always against putting things inside other commonly-distributed source tarballs just to get them distributed. pygtk is already quite well packaged on major distros. > > - API Stability > > - Tkinter, KDE and Python advocacy > > - Non-GTK+ packages > > - MacOS functionality > > - Use of Python's development infrastructure > > - Distribution of documentation > > I'm not even going to try fleshing these out, but whoever wants to argue > about inclusion needs to take these into serious consideration. > > One thing that popped up were two potential projects that somebody with > some free time or a lot of love for Python and PyGTK could try tackling: > > - IDLE Port > > - Integrated RAD Tool > > Thanks for chipping in with opinions and proposals, > -- > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 > _______ > pygtk mailing list [EMAIL PROTECTED] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] When will 2.4 be official?
On Wed, 2004-06-16 at 14:59 +0200, Johan Dahlin wrote: > > Well, the pygtk developers/contributors should be working to this plan: > > http://www.gnome.org/start/2.7/ > > Okay, Okay. Before September :-) > > Because assume nothing will stop us to release 2.4.0 earlier. > > I'm not sure how ABI/API & feature freezes applies to modules. The API/ABI freeze applies to Platform Bindings modules just like it applies to Platform modules. The feature freeze really only makes sense for Desktop modules. > But it's > safe to assume that most of the important things should be done before > that. (Meaning everything but bug fixes) Sounds good. Try to make sure people test the new API thoroughly before the freeze. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] When will 2.4 be official?
On Thu, 2004-06-10 at 16:11 +0200, Johan Dahlin wrote: > tor 2004-06-10 klockan 16.02 skrev Jonathon McKitrick: > > I've been using it for a while, and I was wondering when it will be > > announced. > > Lot's of people has asked that recently. I don't consider it stable > enough to replace 2.2.0 yet. > > Maybe 1 month, maybe 3. No definite plan. Well, the pygtk developers/contributors should be working to this plan: http://www.gnome.org/start/2.7/ -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Grand plan for documentation in 2.4
> Okay, maybe not the tutorial then since it's quite big. But I can't > > really see why it's an issue to include another 600-700 k in the > > tarball, the benefits are big. > > Are the benefits so big, though? I don't think it's such a big problem > to include in the doc/ directory a README that points to the > downloadable tarballs and CVS I think it's easier for distros to package your documentation if it's in the source tarball. And you should want your documentation to be installed. The source tarball size should be mostly irrelevant because not many people should be installing from the source tarballs. This works well for gtkmm, which has about 2.5 MB of generated docs in the source tarball. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: New Bindings modules (python)
On Wed, 2004-05-05 at 12:42 +0100, Gustavo J. A. M. Carneiro wrote: > A Qua, 2004-05-05 às 12:12, Johan Dahlin escreveu: > > > Would you like to put pygtk on the schedule? > > > > Sure, but I can only answer for pygtk > > (gobject,atk,pango,gdk/gtk,libglade) and not for gnome-python which is > > Gustavo Carneiros area these days. I've only done the releases. > > Unfortunately I have not enjoyed enough free time to do any > significant work lately, so I cannot in good conscience claim any sort > maintainership status of gnome-python. Hmm, we would need some officially responsible maintainer. If there is no maintainer that says that it should be on the schedule then it would be meaningless to put it on the schedule. That might not be such a big problem though. Now that I see that pygtk wraps libglade, I see that pygtk does provide most of what people want. But it would be a pity if they didn't have easy access to libgnomecanvas, gconf, and gnome-vfs as well. I think now might be the time to call for a new maintainer(s) for gnome-python, to stop it being orphaned. When you give responsibility, people often take responsibility. [snip] > > gnome-python: > > libbonobo > > libbonobouiould > > gconf > > libpanelapplet > > libgnomecanvas > > libgnome > > libgnomeui > > nautilus > > gnome-vfs > > libart_lgpl > > libart_lgpl is not really wrapped. Only a minimal subset of it is > wrapped, for integration of the libgnomeprint bindings. There is no > separate python module that wraps libart_lgpl. > > > libgnomeprint > > libgnomeprintui > > gtkhtml2 > > > > pyorbit: > > ORBit2 > > > > There exists python bindings for libxml2, libxslt and vte, but they are > > included upstream. I think there are bindings for gstreamer and > > gtksourceview but they are available from other places. > > > > I haven't heard of libwnck bindings. > > > > For bonobo API stability issues, please contact Gustavo (putting him on > > CC) > > Gnome-python's API is not 100% stable at the moment. Some API changes > that have been happening lately are: > 1- Addition of functions and methods; > 2- Addition of parameters to existing function and methods, carefully > as to make them optional and not break applications; > 3- Addition of raised exception when checking parameters; > > Of these points, only point 3- can be considered API break. But usually > these exception are raised when otherwise the function would simply > crash, so they can't really be considered API break. > > I imagine that 1- and 2- changes will not be allowed after API > freeze. Yes, not until the GNOME 2.9/2.10 cycle. > I am fine with that. Point 3- may be required, occasionally, > even after API freeze. Is it possible? I'm not a Python expert. Will it break already-installed applications? I guess it will not break already-installed applications if it only deals with situations that cause crashes anyway. Will it break compilation (if there is such a thing?) of already-existing applications? > And, BTW, bonobo API of gnome-python HEAD is stable now. > > > > > > If it's absolutely necessary then we can maybe bend the rules just to > > > get you on board. But I'd need to know what exceptions we are making and > > > why, so that we can communicate that to users of the platform. > > > > I guess including libgnomeprint[ui] in the tarball is still a good idea, > > but I'm all in favour of removing gtkhtml2. > > I don't mind at all removing gtkhtml2 bindings, as long as the code is > moved into libgtkhtml2 itself. Let's not throw it away! Sounds good to me. > In general, for modules not part of the GNOME Development Platform, > these are the things we must _not_ do: > 1- Remove these modules, throwing away the code; (what a waste of > effort) > 2- Move into a standalone package; (who would maintain it?) 2. works for lots of other projects. You don't have to stop maintaining it just because it's not in the same tarball. > And this is what, IMHO, we _may_ do: > 1- Move the code to the respective C library module, though the same > gnome-python developers can keep maintaining this code with the > permission of the C module's maintainer. I think it's much easier for someone to maintain bindings code if it's in one of their own modules than if it's part of the underlying module. And I don't think we want GTK+ (or libxml, nautilus, etc) to ship its bindings along with itself - that would get crazy. > > This is just my opinion, of course, and I'm not really a maintainer, > so... > > Regards. > > -- > Gustavo João Alves Marques Carneiro > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > The universe is always one step beyond logic. > -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: New Bindings modules (python)
On Wed, 2004-05-05 at 13:12 +0200, Johan Dahlin wrote: > > Would you like to put pygtk on the schedule? > > Sure, but I can only answer for pygtk\ [snip] > pygtk: > gobject > atk > pango > gtk > libglade Excellent. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] New Bindings modules (python)
I really hope we can get the python bindings on the schedule this time. It looks like they are already very much on track to wrap GTK+ 2.4 in time. For the purposes of the discussion, I will regard Johan Dahlin as the gnome-python maintainer, because he has been making releases and because I need some point of contact. Of course, James Henstridge can override that anytime. Johan, it looks like the pygtk module is on track and easily meets the existing Bindings rules: http://developer.gnome.org/dotplan/bindings/rules.html and schedule: http://www.gnome.org/start/2.7/ Would you like to put pygtk on the schedule? I am more concerned about the gnome-python tarball, because it seems to wrap gtkhtml2 and libgnomeprint*. which are not part of the GNOME Platform and therefore might not be API stable. I also wonder how API-stable the bonobo stuff is. I thought I saw libwnck bindings as well, but maybe that was just in cvs. Can you give me a full list of the stuff that you do wrap, such as libglade, libgnome, libgnomeui, gconf, etc? If it's absolutely necessary then we can maybe bend the rules just to get you on board. But I'd need to know what exceptions we are making and why, so that we can communicate that to users of the platform. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com On Tue, 2004-05-04 at 20:07 +0000, Murray Cumming wrote: > We are now in sync with the GNOME schedule: > http://www.gnome.org/start/2.7/ > There is no extra, different, GNOME Bindings schedule. > > According to that schedule, the new modules decision is on July 19th, > but modules should make 2.7.x releases before that to show that they can > stick to the schedule, in the hope that they will be approved. That > means that you should make the first 2.7.1 releases on May 10th. Sorry > for the short notice: > http://www.gnome.org/start/2.7/#Hard_API_Freeze > > So, I would like your lists of modules as soon as possible if you would > like to > - add a module to the schedule, to wrap something extra. > - add a whole new Bindings project to the schedule. > > Notice that the same date is being used for the API freeze. So, new > modules won't be approved if they are not already ready for API freeze. > The earlier I know about new modules, the more chance I will have to > assess that. Here is some information about the API Freeze: > http://developer.gnome.org/dotplan/tasks.html#FreezeAPI > > Here are the Platform Bindings rules again: > http://developer.gnome.org/dotplan/bindings/rules.html > > I hope that is clear. Please do ask if it is not. > > Murray Cumming > [EMAIL PROTECTED] > www.murrayc.com > > > On Sat, 2004-04-24 at 13:56 +1000, Jeff Waugh wrote: > > Good morning everyone, > > > > Welcome to GNOME 2.7 - it's fun-crazy-hack-time again! :-) > > > > We're trying something slightly different with the schedule this time, to > > see if we can push back the freezes a little bit while still having a safe > > and stable final release. Given that we've had a good run of high quality, > > timely releases (at least internally), it's worth a try. > > > > Remember that the schedule is *not* final, it's proposed here for your input > > before we lock it down for good. > > > > The Proposed Schedule is up on the 2.7 start page [1], and is accompanied by > > a BRAND NEW webcal version [2] for you to subscribe to in Evolution 1.5 (and > > various other calendar clients). The 2.7 start page also includes links to > > helpful information related to the release, such as module lists for each > > suite, testing guides, how to contact the release team, and so on... > > > > [1] http://www.gnome.org/start/2.7/ > > [2] webcal://www.gnome.org/start/2.7/schedule.ics > > > > > > Proposed Schedule > > - > > > > Here's a cal(1) rendition of the schedule which you can quote in replies. :) > > > >April 2004 > > Su Mo Tu We Th Fr Sa > >1 2 3 > >4 5 6 7 8 9 10 > > 11 12 13 14 15 16 17 .-. > > 18 19 20 21 22 23 24 2.6.1 <--/ YOU ARE HERE / > > 25 26 27 28 29 30 `-' > > > > May 2004 > > Su Mo Tu We Th Fr Sa > > 1 > >2 3 4 5 6 7 8 > >9 10 11 12 13 14 15 2.7.1 > > 16 17 18 19 20 21 22 > > 23 24 25 26 27 28 29 > > 30 31 > > > >June 2004 > > Su Mo Tu We Th Fr Sa > > 1 2 3 4 5 > >6 7 8 9 10 11 12 2.7.2 > > 13 14 15 16 17 18 19 2.6.2 > > 20 21 22 23 24 25 26 > > 27 28 29 3
[pygtk] [Fwd: 2.8 Platform Bindings - invitation]
-- Murray Cumming www.murrayc.com [EMAIL PROTECTED] --- Begin Message --- The 2.5/2.6 GNOME Platform Bindings seem to be a success so far. So I invite new projects to join the GNOME Platform Bindings schedule for the 2.7/2.8 (and future) release cycle, which will last approximately 6 months. First tarballs will probably be due in the middle of April. Bindings maintainers should tell us what source tarballs they plan to put on the schedule. Bindings should follow these rules: http://developer.gnome.org/dotplan/bindings/rules.html Note that those rules do not guarantee 100% API coverage, but they do guarantee API/ABI stability. The 2.7 schedue will be like this http://www.gnome.org/start/2.5/bindings/ but will more closely match the regular 2.7 GNOME schedule. If it's absolutely necessary then I might make small changes to the rules, though we should try not to put the schedule in danger or confuse people too much about what we promise. -- Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ language-bindings mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/language-bindings --- End Message --- ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: GNOME platform bindings (was Re: [pygtk] Release Candidate 1: pygtk-2.2.0-RC1.tar.gz)
On Wed, 2004-03-10 at 07:21, Xavier Ordoquy wrote: > On Wed, 2004-03-10 at 01:27, Graham Ashton wrote: > > Failing that, if there's enough interest in getting pygtk included in > > the release set, what do people think of the second option? > > I see drawbacks (release deadline fixed, Yes, that's an advantage for many people. Your users want to know that you will closely track the APIs that you are wrapping, and your developers need to know when they can help most effectively. And distros need to know when you will release new stable API so that they can depend on it in their scheduled releases. A release schedule makes sure that software gets released. This could clearly help gnome-python. > API coverage has to match the > gtk/gnome version You don't need to wrap 100% of the C API, but you should try. > with no further API addition) but I'm failing to see > the advantages. gnome-python gets released, publicised, distributed, and used. -- Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Release Candidate 1: pygtk-2.2.0-RC1.tar.gz
On Sun, 2004-03-07 at 23:10, Gustavo J. A. M. Carneiro wrote: > A Dom, 2004-03-07 às 19:02, Murray Cumming escreveu: > > On Fri, 2004-03-05 at 16:14, Christian Robottom Reis wrote: > > > Hey there, > > > > > > We're providing a new PyGTK release candidate for testing: > > > > > > http://www.gnome.org/~jdahlin/pygtk-2.2.0-RC1.tar.gz > > > > That's great. Well done, and I hope this means you'll try to put pygtk > > on the GNOME Platform Bindings 2.7/2.8 schedule. > > Not likely happen, I'm afraid. We're not willing to split > gnome-python just to be part of some "meta package". > To justify this position, I can think of at least the following > arguments: > > 1- Distributions can already split gnome-python into individual binary > packages (one per python module) as they want, and many already do just > that, such as Fedora; > > 2- All modules are optional, dependent on the respective C libraries; > > 3- The split between developer and desktop platform is time varying. > For example, I can foresee libgnomeprint* becoming part of developer > platform sooner or later. Perhaps even gtkhtml2, who knows? Are we > going to keep moving bindings from one package to another as modules are > added to devel platform in the future? > > If the GNOME Platform Bindings release team is willing to amend the > rules, we are willing to make an effort to follow release schedule and > maintain API compatibility. Is that the official decision of the gnome-python maintainer? -- Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Release Candidate 1: pygtk-2.2.0-RC1.tar.gz
On Fri, 2004-03-05 at 16:14, Christian Robottom Reis wrote: > Hey there, > > We're providing a new PyGTK release candidate for testing: > > http://www.gnome.org/~jdahlin/pygtk-2.2.0-RC1.tar.gz That's great. Well done, and I hope this means you'll try to put pygtk on the GNOME Platform Bindings 2.7/2.8 schedule. -- Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: python bindings for gtk 2.4 and gnome 2.6
On Wed, 2004-02-18 at 15:03, Xavier Ordoquy wrote: > ## I added pygtk mailing list in CC > > At the moment we will try to flush a bit the bugzilla patch and bugs > pending. > However, it would be a great help if someone could point out missing API > function/widget/modules and enter them in bugzilla. That would be a good > starting point to extend the binding. (Don, since you're gonna to need > things for your application, listing them here would be cool). > After that we'll have a clearer view on the things to do. New 2.2 and 2.4 API is well-marked with "since 2.2" and "2.4" in the API docs (mostly from the C source), so it's worth grepping for that. Also, the gtkmm NEWS file shows new stuff. Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Python in GNOME Platform Bindings 2.7/2.8?
James, I've tried asking before, but I'd still really like to know whether you think gnome-python can be on the GNOME Platform Bindings 2.7/2.8 schedule. I'd rather sort this out sooner rather than later. For instance, is pygtk close to wrapping GTK+ 2.2? How about 2.4? Is there anything in the Bindings rules that is a complete blocker for you? It really does look like gnome-python could use an official co-maintainer. I suspect that we could have got gnome-python into 2.5/2.6 if there had already been one. -- Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
RE: [pygtk] Bugzilla Cleanup Summary
> I just like to mention a small tip to everyone who has a > patch in bugzilla or want a specific patch to be included in > the next version: > > SCREAM OUT LOUD! I can recommend having a list-of-patches link on the website: http://www.gtkmm.org/bugs.shtml Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
RE: [pygtk] Gnome-python and the GNOME Platform Bindings release set
> > * You may not add API in the stable (2.6.x, for instance) > phase. You > > must wait until the next schedule to add API. Remember, it's not a > > problem if you must wait to add API, because you must only wait <6 > > months until the next stable release. For instance, GTK+ > 2.4 adds API > > compared to GTK+ 2.2. > > This could hamper the addition of simple, non-intrusive API > that we receive in the form of patches to Bugzilla. "Remember, it's not a problem if you must wait to add API, because you must only wait <6 months until the next stable release." And, in general, you can tell people to use a workaround in the meantime. This rule works for the GNOME Platform, and for gtkmm. Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
RE: [pygtk] gnome application
> Well, gnome windows are usually avoided by most developpers. > You should consider using bonobo windows instead. In > gnome-python tarball, it's in examples/bonobo/bonoboui No, I think that most people are trying to use BonoboUI as little as possible. The new menu and toolbar APIs in GTK+ 2.4 are meant to replace - The old GTK+ menus and toolbars - The libgnomeui menus and toolbar - The libbonoboui menus and toolbars. This is all my opinion, but I think you should just use libbonoboui if you want to create an embeddable GUI component, or us libbonobo if you want to do some difficult multi-threading interprocess-communication stuff. Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
RE: [pygtk] FW: GNOME Platform Bindings release set
> > > That would seem to be a problem. It is a fairly arbitrary > > > imposition, so an unnecessary use (waste) of time in the > longer term. > > > > I've explained the reasons at length. But to summarise: We > don't put > > unstable stuff in the GNOME Platform so we won't put > unstable stuff in > > the GNOME Platform Bindings. And we won't put stuff in the GNOME > > Platform Bindings if it isn't a binding for the GNOME Platform. > > Help me out here: > > - Does GTK+ constitute a part of the GNOME Platform? If so, then I > assume PyGTK would constitute a part of the Platform Bindings. Yes, of course, if pyGtk wraps GTK+ and not also something that is not part of the GNOME Platform. > - What does "stable" mean? None of the code AFAIK is under heavy > development, so if the only criteria for splitting > packages is not > being "in-development" [which is a bit bogus] then It's about _API_ and _ABI_ stability: http://developer.gnome.org/dotplan/bindings/rules.html#ApiFreezeMeaning > - Is there a requirement of completeness? Must the > bindings cover a > certain minimum percentage of the original platform library? No, but you should _try_. Obviously nobody can enforce how much you try. > - As a summarizing statement, how strict are we going to > be towards > package splits? Do you forsee PyGTK shipping more than two > packages (pygtk and gnome-python) as part of the bindings? Yes. See "What should be wrapped" here: http://developer.gnome.org/dotplan/bindings/rules.html But you might need to do an extra split if gnome-python currently contains anything that has unstable API or that wraps something that is not in the GNOME Platform. > > > My main disappointment in the "proposal" at the moment is > > > that whilst it should still be in proposal status it is being > > > pitched like a done deal. > > > > I have given everybody time to respond, and received the explicit > > blessing of the GNOME Board and release team, but we can't wait > > forever. The schedule > > Why was it not announced here earlier? It was announced on language-bindings. All language bindings maintainers are on that mailing list, and the pygtk maintainer knew about it from the beginning. It was also announced on dekstop-devel and gnomedesktop (and osnews, and my blog, but they are silly). I am chasing you on your own list as a favour to you. > > must start and releases must be made. I have given pygtk > extra time by > > creating a December 22nd deadline for tarball submissions. > > Yes, it gives us just enough time to package the tarballs and > fill the stockings with bug reports Yes, we just need the tarballs that the gnome-python maintainers want to put on the schedule. The more difficult stuff happens later: http://www.gnome.org/start/2.5/bindings/ Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
RE: [pygtk] FW: GNOME Platform Bindings release set
> > I find the fact that we would need to > > break apart > > packages a bit annoying (and potentially a burden for releases and > > etc). > > That would seem to be a problem. It is a fairly arbitrary > imposition, so an unnecessary use (waste) of time in the longer term. I've explained the reasons at length. But to summarise: We don't put unstable stuff in the GNOME Platform so we won't put unstable stuff in the GNOME Platform Bindings. And we won't put stuff in the GNOME Platform Bindings if it isn't a binding for the GNOME Platform. > My main disappointment in the "proposal" at the moment is > that whilst it should still be in proposal status it is being > pitched like a done deal. I have given everybody time to respond, and received the explicit blessing of the GNOME Board and release team, but we can't wait forever. The schedule must start and releases must be made. I have given pygtk extra time by creating a December 22nd deadline for tarball submissions. Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] FW: GNOME Platform Bindings release set
I have not seen any discussion of this here, so I am forwarding this in case any interested people don't know about it. Murray Cumming www.murrayc.com [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cumming Murray (CNET External) Sent: Dienstag, 9. Dezember 2003 11:18 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: GNOME Platform Bindings release set We now have a GNOME Platform Bindings release set. This means that we can give some bindings a schedule and rules to work within, and we can endores those bindings. Rules: http://developer.gnome.org/dotplan/bindings/rules.html Schedule: http://www.gnome.org/start/2.5/bindings/ Note that those rules do not guarantee 100% API coverage, but they do guarantee API/ABI stability. At the moment, it's just gtkmm (C++) and gtk2-perl (Perl): http://www.gnome.org/start/2.5/bindings/modules.html Expect others in the GNOME 2.8 schedule. I really think that Python should be in 2.6 too, and others if they can do it. For 2.6, they have until December 22nd to give us the list of modules that they want to be put in the release set. Gtk# say they will do it unofficially and hope to be in 2.8. If you have questions about the GNOME Platform Bindings release set please send email to [EMAIL PROTECTED] CC [EMAIL PROTECTED] if you want to appeal to a higher power. This might be reorganized a bit in future. Murray Cumming www.murrayc.com [EMAIL PROTECTED] ___ language-bindings mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/language-bindings ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: [orbitcpp-list] ORBit-C++ module in gnome cvs is dead?
On Thu, 2002-09-12 at 09:18, Murray Cumming wrote: > That ORBit-C++ module in gnome cvs also contains some Python stuff. I'm > sending this to the pygtk list so that they can reassure me that they > don't need it either. Ignore that. I think it's just some cvs trickery. There is this line in CVSROOT/modules: ORBit-C++ ORBit-C++ &pyIDL &python-am-changes -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: [orbitcpp-list] ORBit-C++ module in gnome cvs is dead?
That ORBit-C++ module in gnome cvs also contains some Python stuff. I'm sending this to the pygtk list so that they can reassure me that they don't need it either. On Thu, 2002-09-12 at 03:15, Sam Couter wrote: > Murray Cumming <[EMAIL PROTECTED]> wrote: > > There is an ORBit-C++ module in gnome's cvs, but it doesn't appear to > > have been touched since January 2000. And the current ORBit/C++ code for > > ORBit1 is in sourceforge's cvs. > > > > So is it OK to discard that stuff? We need to start a new module for the > > standalone ORBit/C++ for ORBit2 and I'd like to simplify things first. > > As far as I'm concerned, you can discard it. I've never touched it. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: [gtkmm] Any Python experts here?
On Sun, 2001-10-21 at 18:47, Matt Wilson wrote: > OK, should be fixed now. Many thanks. > > Cheers, > > Matt > > On Sun, Oct 21, 2001 at 12:41:59PM -0400, Matt Wilson wrote: > > Oh, you're right. Gimme a sec. > > > > Matt > > > > On Sun, Oct 21, 2001 at 06:40:52PM +0200, Murray Cumming wrote: > > > On Sun, 2001-10-21 at 18:03, Matt Wilson wrote: > > > > I fixed this in CVS last week. Can you try pulling latest from HEAD? > > > > > > It doesn't seem to be fixed: > > -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Re: [gtkmm] Any Python experts here?
On Sun, 2001-10-21 at 18:03, Matt Wilson wrote: > I fixed this in CVS last week. Can you try pulling latest from HEAD? It doesn't seem to be fixed: [root@localhost cvs]# rm -rf pygtk [root@localhost cvs]# cvs -z3 co pygtk ... [root@localhost cvs]# cd pygtk/codegen [root@localhost codegen]# ./h2def.py /gnome/head/cvs/gtk+/gtk/*.h > gtk_defs [root@localhost codegen]# grep -re "gtk_widget_get_name" gtk_defs [root@localhost codegen]# > On Sun, Oct 21, 2001 at 10:16:33AM -0500, Mike DeSimone wrote: > > >On Sun, 2001-10-21 at 01:25, Sebastian Rittau wrote: > > > > > >h2def.py is in the pygtk cvs module, in the codegen directory. It scans > > >.h files and generates interface descriptions in a lisp-like format. > > > > > >It currently ignores function declarations that start with > > >G_CONST_RETURN, because it expects only 1 piece of white space between > > >the return type and the function name, and it can't handle the extra > > >item. > > ___ > to unsubscribe or change your subscription parameters : > https://lists.sourceforge.net/lists/listinfo/gtkmm-main > > -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
