[pygtk] PrgressBar
Hi, DeprecationWarning: use GtkProgressBar Any idea why I'm getting this warning, i assume that I shall use gtk.ProgressBar? I'm receiving this earing on the following lines in my code: self.progress.set_format_string(%v %%) self.progress.set_show_text(1) self.progress.set_percentage((size/totsize)) In addition to that the set_percentage method is crashing with a lot of debug msg + a x async message. The set_percentage is called within a thread. And yes, I'm using gtk.threads_enter, gtk,threads_leave around it. I've also initialized gtk threads. The same applies for the progress.update and progress.set_fraction. I appreciate very much any ideas regarding this matter. Best regards Øistein Aanensen ___ 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] Compiling PyGTK2
On Mon, 20 Jan 2003 17:47:36 -0200, Christian Reis [EMAIL PROTECTED] wrote: On Mon, Jan 20, 2003 at 02:22:26PM -0500, joehill wrote: AttributeError: Search instance has no attribute 'window' Well, this is a rox problem now, thankfully, not ours. :-) Actually, it might be a PyGTK problem. Looks like the infamous ref-counting bug (this object is only referenced by signal handlers, so I'm going to wipe __dict__): http://bugzilla.gnome.org/show_bug.cgi?id=92955 So, I'm gonna go bug them back at rox. One thing I wanted to clarify (besides what is pygtk.pth, and why do you hate it so?) was about the pygtk.pth is what tells Python to look in the gtk-2.0 or gtk-1.2 directories by default, and I use it as shorthand to refer to the whole pygtk.py debacle. I hate this solution because it is has utterly confusing semantics and has generated about 50% of the list traffic for the last 4 months or so. Indeed. I guess there was a need to be compatible with RedHat 8.0 (where 'import gtk' has to get 2.0 by default) and everyone else (where it has to get 1.2). Perhaps there should be a warning if you forget to import pygtk? [...] There is no need to reinstall Python, and all PyGTK apps will now find pygtk correctly. One thing that many ignore is that the default prefix of /usr/local *MAY NOT BE CORRECT* for your system. If your Python is installed by default to /usr, it definitely isn't - you *must use* --prefix=/usr instead. Just because it's default, in this case, doesn't mean it's correct. Doesn't pygtk.py search sys.path? In that case, it should still find stuff in /usr/local, even if python is in /usr (provided /usr/local is in the default search path). I think there's a problem if you've installed some gtk-2.0 bits to one prefix and some to another, though: http://bugzilla.gnome.org/show_bug.cgi?id=70178 (at the end; I should have opened a separate bug report) -- Thomas Leonard http://rox.sourceforge.net [EMAIL PROTECTED] [EMAIL PROTECTED] GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 ___ 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] Compiling PyGTK2
On Tue, Jan 21, 2003 at 11:06:49AM +, Thomas Leonard wrote: Well, this is a rox problem now, thankfully, not ours. :-) Actually, it might be a PyGTK problem. Looks like the infamous ref-counting bug (this object is only referenced by signal handlers, so I'm going to wipe __dict__): Well, at least not an installation problem ;) but I concede. pygtk.pth is what tells Python to look in the gtk-2.0 or gtk-1.2 directories by default, and I use it as shorthand to refer to the whole pygtk.py debacle. I hate this solution because it is has utterly confusing semantics and has generated about 50% of the list traffic for the last 4 months or so. Indeed. I guess there was a need to be compatible with RedHat 8.0 (where 'import gtk' has to get 2.0 by default) and everyone else (where it has to get 1.2). Perhaps there should be a warning if you forget to import pygtk? Not exactly. The problem is that 'import gtk' now has utterly undefined semantics. If you installed pygtk2 and *then* pygtk0, yes, import gtk gets pygtk0. But if you did it the other way around, you get pygtk2. To complicate matters further, you may have installed into a non-standard directory, used the wrong prefix, etc etc etc. [...] There is no need to reinstall Python, and all PyGTK apps will now find pygtk correctly. One thing that many ignore is that the default prefix of /usr/local *MAY NOT BE CORRECT* for your system. If your Python is installed by default to /usr, it definitely isn't - you *must use* --prefix=/usr instead. Just because it's default, in this case, doesn't mean it's correct. Doesn't pygtk.py search sys.path? In that case, it should still find stuff in /usr/local, even if python is in /usr (provided /usr/local is in the default search path). I think there's a problem if you've installed some But for Python installed by default with prefix /usr, /usr/local is not in sys.path, is never searched, and it won't work. Python only looks in *one* site-packages directory by default, the one inside the default pythonX.X/lib directory. The bottom line is: if you install to a prefix which isn't the default Python prefix, you'll need to hack sys.path manually. Johan, perhaps we can get a ./configure warning that You are installing pygtk into a non-standard directory, and you'll have to fiddle sys.path to make things work properly.? gtk-2.0 bits to one prefix and some to another, though: http://bugzilla.gnome.org/show_bug.cgi?id=70178 (at the end; I should have opened a separate bug report) This is yet another problem, really. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ 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: {SPAM?} Re: [pygtk] Compiling PyGTK2
On Tue, Jan 21, 2003 at 09:43:06AM -0200, Christian Reis wrote: On Tue, Jan 21, 2003 at 11:06:49AM +, Thomas Leonard wrote: Actually, it might be a PyGTK problem. Looks like the infamous ref-counting bug (this object is only referenced by signal handlers, so I'm going to wipe __dict__): Well, at least not an installation problem ;) but I concede. Hmm, actually it *was* my problem. I'm so used to empty __dict__'s being pygtk bugs, but this one really was an uninitialised object ;-) [...] Doesn't pygtk.py search sys.path? In that case, it should still find stuff in /usr/local, even if python is in /usr (provided /usr/local is in the default search path). I think there's a problem if you've installed some But for Python installed by default with prefix /usr, /usr/local is not in sys.path, is never searched, and it won't work. Ah, I guess this is a Debian thing, then. I've added a note to our list of pygtk hints. Thanks, -- Thomas Leonard http://rox.sourceforge.net [EMAIL PROTECTED] [EMAIL PROTECTED] GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 ___ 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] Compiling PyGTK2
Johan, perhaps we can get a ./configure warning that You are installing pygtk into a non-standard directory, and you'll have to fiddle sys.path to make things work properly.? You already get this warning if you're using distutils and i rather not touch the autotools system, instead i encourage the use of distutils, just use: ./setup install Or if you want to install it to a different prefix: ./setup install --prefix /usr/local (Since /usr is default on Red Hat systems for example) -- Johan Dahlin [EMAIL PROTECTED] Async Open Source ___ 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] PrgressBar
DeprecationWarning: use GtkProgressBar Any idea why I'm getting this warning, i assume that I shall use gtk.ProgressBar? I'm receiving this earing on the following lines in my code: Yes, the usage of GtkProgress is deprecated. You can replace it with GtkProgressBar. In addition to that the set_percentage method is crashing with a lot of debug msg + a x async message. The set_percentage is called within a thread. And yes, I'm using gtk.threads_enter, gtk,threads_leave around it. I've also initialized gtk threads. The same applies for the progress.update and progress.set_fraction. Have you tried the latest CVS? A few threading issues has been solved lately. If it still occurs in CVS, please file a bug in bugzilla with an appropriate test case, so i some one who knows about threads can fix it. -- Johan Dahlin [EMAIL PROTECTED] Async Open Source ___ 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] Compiling PyGTK2
[Thomas Leonard - Tue, 21 Jan 2003 05:10:56 AM CST] Actually, it might be a PyGTK problem. Looks like the infamous ref-counting bug (this object is only referenced by signal handlers, so I'm going to wipe __dict__): http://bugzilla.gnome.org/show_bug.cgi?id=92955 I feel silly now. I was looking for pygtk/python-gtk in Gnome's bugzilla page, but not gnome-python, so never found pygtk's list of official bugs, so bothered you all earlier. And neglected to read James' GNOME page. Bah. The one link I didn't click. -- | The bomb will never go off. I speak as an expert in explosives. | -- Admiral William Leahy, U.S. Atomic Bomb Project ___ 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] Compiling PyGTK2
well, I got you beat. I could have read those bug reports and never have known it was related at all. damn newbies... Ava Arachne Jarvis wrote: [Thomas Leonard - Tue, 21 Jan 2003 05:10:56 AM CST] Actually, it might be a PyGTK problem. Looks like the infamous ref-counting bug (this object is only referenced by signal handlers, so I'm going to wipe __dict__): http://bugzilla.gnome.org/show_bug.cgi?id=92955 I feel silly now. I was looking for pygtk/python-gtk in Gnome's bugzilla page, but not gnome-python, so never found pygtk's list of official bugs, so bothered you all earlier. And neglected to read James' GNOME page. Bah. The one link I didn't click. ___ 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 GC (was Re: [pygtk] Compiling PyGTK2)
What is the thinking behind the PyGTK GC mechanism? I've looked at the code but don't think that I understand it. What I see is that PyGTK widgets that are GObjects are viewed as Python containers and the Python GC system is used to track and presumably dispose of them. It seems that PyGTK objects are not GC'd if they have a GTK reference which keeps alive unreferenced (in Python) widgets that are added to a GTK container. What other things am I missing in understanding the PyGTK memory management? As Thomas Leonard points out there is a problem with handling cyclic references involving signal handler closures that reference the Python object. Are there other problems? Thanks 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/
[pygtk] GtkSourceView wrapped
I finally got around to making this work. At the moment syntax highlighting does not work for some reason, but I haven't played with it that much. Line numbering works though.
Attached is a patch to the 1.99.14 tarball, basically modifies the build files (gtk/Makefile.am, configure.in) to build the sourceviewmodule.
Also attached are three source files that go into gtk/ (.override, .defs, .c ) and one test file.
to use:
import gtksourceview
gsv = gtksourceview.SourceView()
Next I will try to get the highlighting to work, otherwise, what's the point eh?
BTW, I'm on RH8, I had to configure with --prefix=/usr and modify Makefile.am, and gtk/Makefile.am to have:
pkgpythondir = $(pythondir)
pkgpyexecdir = $(pyexecdir)
instead of
pkgpythondir = $(pythondir)/gtk-2.0
pkgpyexecdir = $(pyexecdir)/gtk-2.0
It gets very confused otherwise.
I did not modify the .spec file, maybe next time.
Enjoy
- - -- - --- -- - -
Ahmad Baitalmal
BitBuilder
web: http://www.bitbuilder.com
- - -- -- --- -- - -
diff -u pygtk-1.99.14/aclocal.m4 pygtk-1.99.14.orig/aclocal.m4
--- pygtk-1.99.14/aclocal.m4 2003-01-18 14:30:59.0 -0800
+++ pygtk-1.99.14.orig/aclocal.m4 2002-12-27 03:55:44.0 -0800
@@ -1084,6 +1084,8 @@
AC_REQUIRE([AC_PROG_LD])dnl
AC_REQUIRE([AC_PROG_LD_RELOAD_FLAG])dnl
AC_REQUIRE([AC_PROG_NM])dnl
+AC_REQUIRE([LT_AC_PROG_SED])dnl
+
AC_REQUIRE([AC_PROG_LN_S])dnl
AC_REQUIRE([AC_DEPLIBS_CHECK_METHOD])dnl
AC_REQUIRE([AC_OBJEXT])dnl
@@ -1251,9 +1253,12 @@
lt_cv_global_symbol_to_cdecl=sed -n -e 's/^T .* \(.*\)$/extern char \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'
lt_cv_global_symbol_to_c_name_address=sed -n -e 's/^: \([[^ ]]*\) $/ {1\\\, (lt_ptr) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/ {\\2\, (lt_ptr) \\2},/p'
;;
-irix*)
+irix* | nonstopux*)
symcode='[[BCDEGRST]]'
;;
+osf*)
+ symcode='[[BCDEGQRST]]'
+ ;;
solaris* | sysv5*)
symcode='[[BDT]]'
;;
@@ -1350,7 +1355,7 @@
save_CFLAGS=$CFLAGS
LIBS=conftstm.$ac_objext
CFLAGS=$CFLAGS$no_builtin_flag
- if AC_TRY_EVAL(ac_link) test -s conftest; then
+ if AC_TRY_EVAL(ac_link) test -s conftest$ac_exeext; then
pipe_works=yes
fi
LIBS=$save_LIBS
@@ -1894,7 +1899,7 @@
# like `-m68040'.
lt_cv_prog_cc_pic='-m68020 -resident32 -malways-restore-a4'
;;
-beos* | irix5* | irix6* | osf3* | osf4* | osf5*)
+beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
# PIC is the default for these OSes.
;;
darwin* | rhapsody*)
@@ -1937,7 +1942,7 @@
lt_cv_prog_cc_pic='+Z'
;;
-irix5* | irix6*)
+irix5* | irix6* | nonstopux*)
lt_cv_prog_cc_wl='-Wl,'
lt_cv_prog_cc_static='-non_shared'
# PIC (with -KPIC) is the default.
@@ -1981,11 +1986,7 @@
sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
lt_cv_prog_cc_pic='-KPIC'
lt_cv_prog_cc_static='-Bstatic'
- if test x$host_vendor = xsni; then
- lt_cv_prog_cc_wl='-LD'
- else
- lt_cv_prog_cc_wl='-Wl,'
- fi
+ lt_cv_prog_cc_wl='-Wl,'
;;
uts4*)
@@ -2350,7 +2351,7 @@
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is.
# If DATA tags from a recent dlltool are present, honour them!
-archive_expsym_cmds='if test x`head -1 $export_symbols` = xEXPORTS; then
+archive_expsym_cmds='if test x`sed 1q $export_symbols` = xEXPORTS; then
cp $export_symbols $output_objdir/$soname-def;
else
echo EXPORTS $output_objdir/$soname-def;
@@ -2359,6 +2360,7 @@
set dummy \$symbol;
case \[$]# in
2) echo\[$]2 @ \$_lt_hint ; $output_objdir/$soname-def;;
+ 4) echo\[$]2 \[$]3 \[$]4 ; $output_objdir/$soname-def; _lt_hint=`expr \$_lt_hint - 1`;;
*) echo \[$]2 @ \$_lt_hint \[$]3 ; $output_objdir/$soname-def;;
esac;
_lt_hint=`expr 1 + \$_lt_hint`;
@@ -2410,6 +2412,30 @@
hardcode_shlibpath_var=no
;;
+ linux*)
+if $LD --help 21 | egrep ': supported targets:.* elf' /dev/null; then
+ archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+ supports_anon_versioning=no
+ case `$LD -v 2/dev/null` in
+*\ [01].* | *\ 2.[[0-9]].* | *\ 2.10.*) ;; # catch versions 2.11
+*\ 2.11.93.0.2\ *) supports_anon_versioning=yes ;; # RH7.3 ...
+*\ 2.11.92.0.12\ *) supports_anon_versioning=yes ;; # Mandrake 8.2 ...
+*\ 2.11.*) ;; # other 2.11 versions
+*) supports_anon_versioning=yes ;;
+ esac
+ if test $supports_anon_versioning = yes; then
+archive_expsym_cmds='$echo { global: $output_objdir/$libname.ver~
+cat $export_symbols | sed -e s/\(.*\)/\1;/ $output_objdir/$libname.ver~
+$echo local: *; }; $output_objdir/$libname.ver~
+$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script
Re: [pygtk] Can't find gtk.FileSelection.get_selections
On Mon, 2003-01-20 at 07:54, Ahmad Baitalmal wrote: For multiple file selection, gtk.FileSelection.get_selections does not seem to be available in 1.99.14 What am I missing? Attached is my hack to add the missing get_selections functionality to the GtkFileSelector. I was unable to convince my boss to ship a CVS of Python/GTK (which fixes your problem) so I had to add the functionality in Python. It is not the most elegant code you'll ever see, but it seems to work... -- Michael JasonSmith http://www.cosc.canterbury.ac.nz/~mpj17/ import gtk import os, os.path class MultipleFileSelector(gtk.FileSelection): def __init__(self): gtk.FileSelection.__init__(self, 'Select Files') self.hide_fileop_buttons() self.set_select_multiple(1) self.file_list.get_selection().set_mode(gtk.SELECTION_MULTIPLE) self.ok_cb = ok_cb self.cancel_cb = cancel_cb self.show_all() def get_select_multiple(self): dirname = os.path.dirname(self.get_filename()) retval = [] selection = self.file_list.get_selection() store = self.file_list.get_model() iter = store.get_iter_first() while iter != None: if selection.iter_is_selected(iter): filename = %s%s%s % (dirname, os.sep, store.get_value(iter, 0)) retval.append(filename) iter = store.iter_next(iter) return retval
