Re: [pygtk] Installation problems win32
At 03:34 AM 6/17/2004, Joel Becker wrote: On Wed, Jun 16, 2004 at 02:14:11PM -0400, John Ehresman wrote: I think this should continue to be an option, but I'd like to see a distutils / py2exe type solution so the 1st 3 steps can be eliminated. I'm not talking about eliminating pygtk / gtk distributions entirely, but rather making it easy for applications to easily include and use a private copy of the libraries. you can py2exe your pygtk application but including the all GTK+ runtime with your application is overkill IMHO (the minimal distribution does not only include a few DLLs but also some configurations files (in the etc subdir) and locales. Welcome to DLL Hell. No Thanks. This discussion is not limited to the Windows world See the post by Havoc on his blog http://log.ometer.com/2004-06.html#16 and the discussion on OSNews http://207.44.212.20/comment.php?news_id=7399 Personally, I'm in favor of a GTK+ framework installer (à la .Net or Java) that only contains the GTK+ runtime as the basic component, with additional components (libraries, headers and development tools: libxml2, libglade, glade, gtkmm,...) available as extra packages (ideally through a net install package manager, something like the cygwin setup). Applications (gimp, gaim,...) would then each have their own installer that checks for the presence of this GTK+ framework. Same for pygtk, through its distutils-generated installer. This of course implies that this GTK+ distribution is stable enough so that developers don't feel the need of embedding their own patched gtk+ runtime in their application installer. This is not a trivial request. For example, gtk+-2.4.3 is not yet available in binary form for win32 on Tor's page (http://www.gimp.org/~tml/gimp/win32/downloads.html). However, the gladewin32 project (http://gladewin32.sourceforge.net) has a all-in-one installer that claims that the Gtk+ runtime is updated to 2.4.3 with unofficial bug fixes. Can we rely on this one and what does unofficial bug fixes mean ? Cedric ___ 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] popt question
This is OK -- I need to do it only once :-) This is fine then - unless getopt behaves differently to popt, or has less/more features that could cause problems. IMHO, it boils down to: do you want/need the gnome/gtk standard command line options, or not? I do. As I understand it, I don't have to do anything about the standard options -- they are taken care of by the gnome libs, right? As far as I can remember yes. You can blame me if this is not correct :) __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail ___ 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] ItemFactory deprecated?!
thanks, guess I should have RTFM! looks very nice maybe it would be an idea to add a link to the the deprecated message in the ItemFactory docs for people as dumb as I am?? On Wed, 2004-06-16 at 17:53, Dennis Craven wrote: On Wed, 2004-06-16 at 11:30, Matthew Bull wrote: Hi, Could someone illuminate me as to why gtk.ItemFactory has been deprecated and more importantly whats the best way to create 'stock' menu items from now on?? I think I can see a way of doing it but it will be hard (and messy) I think the new way to do what the old ItemFactory did is called gtk.UIManager. I've never used an ItemFactory, but from it's description it sounds like did something similar. I've used the UIManager in my code as of just a few days ago, and it is very clean and easily maintainable. Cheers, ~djc ___ 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] g_log_set_handler?
A Qua, 2004-06-16 às 23:32, Tim Newsham escreveu: Hi, Is there any way to set the log handler in pygtk? I couldn't find any. I did notice a previous related thread on turning tk warnings into exceptions. I am interested in altering the default warning logging mechanism. Currently under windows it forces a console window to open up to emit these warnings. I know that ideally the code would be warning free, but I still get occasional harmless warnings from gtk and glade. I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. If you are interested in this, you should open a bug report in bugzilla.gnome.org, product pygtk, type enhancement. A patch will speed up the bug progress, but otherwise I will eventually do this, but it may take some time. Regards. -- Gustavo João Alves Marques 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/
Re: [pygtk] g_log_set_handler?
If you are interested in this, you should open a bug report in bugzilla.gnome.org, product pygtk, type enhancement. A patch will speed up the bug progress, but otherwise I will eventually do this, but it may take some time. John Ehresman already wrote one, it's included in the tarball in the GIOChannel bug (which # I can't remember) -- Johan Dahlin [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] Installation problems win32
Cedric Gustin wrote: you can py2exe your pygtk application but including the all GTK+ runtime with your application is overkill IMHO (the minimal distribution does not only include a few DLLs but also some configurations files (in the etc subdir) and locales. The minimal distribution that we use is 9.5 MB on disk. With disk sizes measured in the GB's these days, I don't think this is huge. What is still worth worrying about is the size of the code pages when the program is running. This of course implies that this GTK+ distribution is stable enough so that developers don't feel the need of embedding their own patched gtk+ runtime in their application installer. This is part of the issue -- gtk on Windows is not as mature as on Linux. Because of this, there is likely to more need to distribute different versions. Cheers, John ___ 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] g_log_set_handler?
Gustavo J. A. M. Carneiro wrote: I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. Interesting idea; I think this should be an option and maybe should be the default behavior. The patch I submitted as part of the patch to create a glib module simply wraps the log_set_handler function so that a Python callable can be used as the handler. John ___ 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] g_log_set_handler?
On Thu, Jun 17, 2004 at 11:52:57AM -0400, John Ehresman wrote: Gustavo J. A. M. Carneiro wrote: I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. Interesting idea; I think this should be an option and maybe should be the default behavior. The patch I submitted as part of the patch to create a glib module simply wraps the log_set_handler function so that a Python callable can be used as the handler. Speaking of this patch, we should start discussion on whether we want it in for 2.4 or not. Johan (and someone else?) has expressed reservations because he feels that most of it duplicates functionality already in the Python standard library. I'm sure you have a good argument against that one already :-) Take care, -- 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/
Re: [pygtk] g_log_set_handler?
Speaking of this patch, we should start discussion on whether we want it in for 2.4 or not. Johan (and someone else?) has expressed reservations because he feels that most of it duplicates functionality already in the Python standard library. I'm sure you have a good argument against that one already :-) Not the g_log_set_handler, I'd like to have them in. It's mostly the GIOChannel I don't want in which I think you're confusing. The patch actually wraps both so I can't blame you for that. -- Johan Dahlin [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] g_log_set_handler?
Christian Robottom Reis wrote: Speaking of this patch, we should start discussion on whether we want it in for 2.4 or not. Johan (and someone else?) has expressed reservations because he feels that most of it duplicates functionality already in the Python standard library. I'm sure you have a good argument against that one already :-) I agree with him :). I think the basic glib patch should go in, without exposing IOChannel's. IOChannel's can be added later if there is a need. John ___ 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] g_log_set_handler?
A Qui, 2004-06-17 às 16:52, John Ehresman escreveu: Gustavo J. A. M. Carneiro wrote: I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. Interesting idea; I think this should be an option and maybe should be the default behavior. The patch I submitted as part of the patch to create a glib module simply wraps the log_set_handler function so that a Python callable can be used as the handler. Right. I was not thinking it even as option. PyGTK would _always_ install a log handler, at startup, that would capture all warning messages and inject them into python's warning module. Then, if the programmer wants to intercept warnings, he would use the standard python API. I think that this way GTK blends better with Python, and the programmer doesn't have to learn two logging APIs. Regards. -- Gustavo João Alves Marques 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/
Re: [pygtk] g_log_set_handler?
I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. I'm not sure why a new mechanism is needed. GLIB already provides a mechanism for intercepting the log messages (g_log_set_handler). If this was exposed in pygtk, then a programmer could intercept the log messages, redirect them as python warnings, or do whatever else they wanted to do with them. Since pygtk is a package that exposes GTK API's to python, this seems like the appropriate thing to do. Gustavo João Alves Marques Carneiro Tim N. ___ 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] g_log_set_handler?
On Thu, Jun 17, 2004 at 03:41:52PM -0400, John Ehresman wrote: Tim Newsham wrote: I'm not sure why a new mechanism is needed. GLIB already provides a mechanism for intercepting the log messages (g_log_set_handler). If this was exposed in pygtk, then a programmer could intercept the log messages, redirect them as python warnings, or do whatever else they wanted to do with them. This is a case where Python and gtk provide similar functionality and it may make sense to route gtk warnings through the Python warning framework because then there would one way to capture all warnings. From the standpoint of Python, the glib logging mechanism is the new mechanism. Another example of duplicate functionality is character set conversion: Python has unicode support so there's no need to expose the equivalent glib functions. Note also that whatever functions we need to expose means more code to maintain and keep up to date as time goes by. It makes a lot of sense to rely on base Python functionality and only wrap or adapt what is actually necessary. I also like gjc's recommendation to route all glib warnings through Python warnings -- it's just so much easier to handle from there. Of course, some people might *want* the original handling, so we'd need a way to turn it off, I guess. Any API suggestions? Take care, -- 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/
[pygtk] Freshmeat Releases?
Hello list, Has this project given up on Freshmeat releases or has it just been overlooked? Since the most recent pygtk release on Freshmeat is 2.0.0, it is difficult (impossible actually) to list the newer versions since as dependancies. My project depends on PyGTK = 2.3, but since only 2.0 can be shown as a dependancy, it's causing some user confusion as you might expect when it the program doesn't work on their PyGTK 2.0.0 installed system. Just wondering if this is an oversight or not. I do realize that you have plenty of places to update when a new release is ready for the masses ;) Cheers, ~djc ___ 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] g_log_set_handler?
Gustavo J. A. M. Carneiro wrote: A Qua, 2004-06-16 às 23:32, Tim Newsham escreveu: Hi, Is there any way to set the log handler in pygtk? I couldn't find any. I did notice a previous related thread on turning tk warnings into exceptions. I am interested in altering the default warning logging mechanism. Currently under windows it forces a console window to open up to emit these warnings. I know that ideally the code would be warning free, but I still get occasional harmless warnings from gtk and glade. I think pygtk should install a log handler to turn all log messages into python warnings. Then, the pygtk programmer may use the standard 'warnings' module to do whatever he wishes to such warnings: hide them, turn them to exceptions, show in a text/list widget, etc. If you are interested in this, you should open a bug report in bugzilla.gnome.org, product pygtk, type enhancement. A patch will speed up the bug progress, but otherwise I will eventually do this, but it may take some time. I think that maybe the Python 'logging' module would be a better choice than Python warnings. http://docs.python.org/lib/module-logging.html The different levels of g_log would be translated into the equivalent Python logging levels as follows: G_LOG_LEVEL_ERROR logging.CRITICAL G_LOG_LEVEL_CRITICAL logging.ERROR G_LOG_LEVEL_WARNINGlogging.WARNING G_LOG_LEVEL_MESSAGE25 (between WARNING and INFO) G_LOG_LEVEL_INFO logging.INFO G_LOG_LEVEL_DEBUG logging.DEBUG The transposition of meanings for critical and error is unfortunate, but I guess we could live with it. Handling fatal G_LOG_LEVEL_ERROR messages may not be useful anyway. A heirachy of loggers would be created, with something like 'glog' at the top, and a child logger for each log domain, i.e.: 'glog.Gtk', 'glog.GLib', 'glog.Pango', etc. We would also need to define a few useful gtk-related logging.Handler classes, such as TextBufferHandler, ListStoreHandler, etc. I think that all of this should go into a module called 'glog'. If anyone else likes this idea I could try putting together an initial version of such a module. -- Tim Evans Applied Research Associates NZ http://www.aranz.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] How to hack gdesklets to work with 2.4
I don't use autoconf, but I'd like to install gdesklets, and it won't let me, since it doesn't find pygtk. I have the 2.4 beta installed. How can I hack the script to get it to work? Sorry if it's a lame question, but I never DID get autoconf... :-\ jm ___ 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] How to hack gdesklets to work with 2.4
On Fri, Jun 18, 2004 at 01:32:05AM +0100, Jonathon McKitrick wrote: I don't use autoconf, but I'd like to install gdesklets, and it won't let me, since it doesn't find pygtk. I have the 2.4 beta installed. How can I hack the script to get it to work? Look at config.log, and see what test is failing. It's probably a matter of setting some configure flags or minor shell script hacking. Take care, -- 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/
