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
I think these are the most important modules. libgnome* is getting
slowly deprecated, so we probably shouldn't demonstrate it. We also
want full i18n setup.
The example program will be gradually polished over time, of course,
so don't expect everything to come up right.
>
> > 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.
OK. So core application writers need to be careful with 3rd party
modules... that's fair.
>
> > 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.
OK. I'll write desktop-devel-list soon, then.
Regards.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
