From: Stephen W. <st...@ke...> - 2007-05-03 17:15:24
|
A little while back I said I was going to start the release process for ROX-Lib 2.0.4, but then I got distracted by various things. This is another attempt to get things rolling... -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. The past is a different country, 1987's just the Isle of Wight. |
From: Stephen W. <st...@ke...> - 2007-05-07 09:54:27
|
Stephen Watson <st...@ke...> wrote: > A little while back I said I was going to start the release process for > ROX-Lib 2.0.4, but then I got distracted by various things. This is another > attempt to get things rolling... Draft of the change notes: (I note there haven't been many updates to the translations!) Release 2.0.4: General: - Fix unit tests to use correct path (Thomas Leonard). - Removed a load of unused imports spotted by PyFlakes (Thomas Leonard). - ROX base platform is now Python 2.3, so run unit tests against that by default (Thomas Leonard). - Bugfix: Must use '..' in interface for backwards compat (Thomas Leonard). - Removed some more deprecation warnings. Do not run testsu as part of testall as it is interactive (Thomas Leonard). - Ensure window response codes are treated as int(), required for python 2.5 and pygtk 2.6 (Stephen Watson). - Drag-and-drop didn't work if the hostname contained '-', due to an error in a regular expression (Thomas Leonard, reported by Lennon Cook). - Function to fetch an appropriate icon for a file (Lennon Cook). Changed to return a Pixbuf instead of an Image, to use the existing icon theme lookup and to first check for a .DirIcon for directories (Stephen Watson). Translations: - Update Chinese Translations (Babyfai Cheung). debug: - Exception handler now copes with old-style non-class exceptions and with missing tracebacks (Thomas Leonard). mime: - Added xattr support including test for user set MIME types (Stephen Watson). OptionsBox: - When there is only one section in the options box, don't show a frame (Thomas Leonard). - Added note about size-groups(Thomas Leonard). - Added <filechooser> widget to OptionsBox, which lets the user choose a file using a GtkFileChooser or by drag-and-drop (Jim Ramsay). Requires GTK >= 2.6. - Added Clear button to filename options (Jim Ramsay and Thomas Leonard). saving: - Lookup icons from /rox.sourceforge.net/MIME-icons before /MIME-ICONS (Stephen Watson) session: - Prefered launcher for a URL scheme now part of uri_handler (Stephen Watson). settings: - Prefered launcher for a URL scheme now part of uri_handler (Stephen Watson). tasks: - Fixed some deprecation warnings (Thomas Leonard). - Bugfix: InputBlocker and OutputBlocker now trigger on IO_HUP too (Thomas Leonard). - Added Task.finished blocker, which is triggered when the task finishes, successfully or by throwing an exception (Thomas Leonard; suggested by Ken Hayber). templates: *NEW* - Added templates module as an interface to glade (Stephen Watson). - Templates now has full dict behaviour and derives from glade.XML. Method names have therefore changed to be the same used by glade.XML (Stephen Watson). thumbnail: *NEW* - Added thumbnail module to access thumbnail images of files and also to generate them (Stephen Watson). uri_handler: *NEW* - Suppor shared configuration for launching URIs (Stephen Watson). xattr: *NEW* - Added xattr support including test for user set MIME types (Stephen Watson). -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. Strange as I seem I'm getting stranger by the minute |
From: Lars H. <lar...@un...> - 2007-05-07 10:40:11
|
Stephen Watson wrote: > - Added <filechooser> widget to OptionsBox, which lets the user choose a > file > using a GtkFileChooser or by drag-and-drop (Jim Ramsay). Requires GTK >= > 2.6. > While it's nice to have a filechooser widget this one is very "unrox-ish". Wouldnt it be better to have a button that launches the Filer to the directory in the option value instead of using GtkFileChooser? --- Lars Hansson |
From: Stephen W. <st...@ke...> - 2007-05-20 10:00:28
|
Vincent Lefevre <vin...@vi...> wrote: > On 2007-05-19 21:04:39 +0100, Stephen Watson wrote: > > Vincent Lefevre <vin...@vi...> wrote: > > > There's still a problem: the (translated) message is output in UTF-8 > > > on stderr, even if the locale is ISO-8859-1 (`locale charmap`). The > > > script should convert the string into the current charmap, at least > > > if stderr is attached to a terminal. > > > > Doesn't this happen with all the other warnings that ROX-Lib can > > generate on stderr? > > I don't know. But note that ROX-Filer doesn't have this problem. Try r5026 -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. "Bad dog!" "Affirmative!" |
From: Vincent L. <vin...@vi...> - 2007-05-20 11:04:55
|
On 2007-05-20 11:00:24 +0100, Stephen Watson wrote: > Vincent Lefevre <vin...@vi...> wrote: > > > On 2007-05-19 21:04:39 +0100, Stephen Watson wrote: > > > Vincent Lefevre <vin...@vi...> wrote: > > > > There's still a problem: the (translated) message is output in UTF-8 > > > > on stderr, even if the locale is ISO-8859-1 (`locale charmap`). The > > > > script should convert the string into the current charmap, at least > > > > if stderr is attached to a terminal. > > > > > > Doesn't this happen with all the other warnings that ROX-Lib can > > > generate on stderr? > > > > I don't know. But note that ROX-Filer doesn't have this problem. > > Try r5026 There's still the same problem. -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Jim R. <i....@ji...> - 2007-05-07 14:43:19
Attachments:
signature.asc
|
Lars Hansson wrote: > Stephen Watson wrote: > > - Added <filechooser> widget to OptionsBox, which lets the user > > choose a file > > using a GtkFileChooser or by drag-and-drop (Jim Ramsay). Requires > > GTK >=3D 2.6. > > =20 >=20 > While it's nice to have a filechooser widget this one is very > "unrox-ish". Wouldnt it be better to have a button that launches the > Filer to the directory > in the option value instead of using GtkFileChooser? You can already drag a file from Filer onto the GtkFileChooser button in the options pane, which is quite rox-y. I agree that clicking on the button could do something more rox-like, but the GtkFileChooser button was very easy to implement and it does the job. Of course there is no reason this couldn't be changed in a later version of the library. --=20 Jim Ramsay "Me fail English? That's unpossible!" |
From: Stephen W. <st...@ke...> - 2007-05-19 10:27:58
|
Are there any objections to me going ahead with a release this weekend? -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. "Bad dog!" "Affirmative!" |
From: Vincent L. <vin...@vi...> - 2007-05-19 11:01:34
|
On 2007-05-19 11:27:52 +0100, Stephen Watson wrote: > Are there any objections to me going ahead with a release this weekend? I've tried it without DISPLAY set (mainly to see if there was anything to compile), and I got a segmentation fault instead of an error message. vin:.../rox-lib/ROX-Lib2> AppRun /var/lib/python-support/python2.4/gtk-2.0/gtk/__init__.py:69: GtkWarning: could not open display warnings.warn(str(e), _gtk.Warning) AppRun:13: Warning: invalid (NULL) pointer instance rox._("ROX-Lib2 contains code that is useful to newer ROX applications. \ AppRun:13: Warning: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed rox._("ROX-Lib2 contains code that is useful to newer ROX applications. \ AppRun:13: GtkWarning: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed rox._("ROX-Lib2 contains code that is useful to newer ROX applications. \ AppRun:13: Warning: g_object_get: assertion `G_IS_OBJECT (object)' failed rox._("ROX-Lib2 contains code that is useful to newer ROX applications. \ AppRun:13: Warning: value "TRUE" of type `gboolean' is invalid or out of range for property `visible' of type `gboolean' rox._("ROX-Lib2 contains code that is useful to newer ROX applications. \ AppRun:21: GtkWarning: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed box.add_button(g.STOCK_HELP, g.RESPONSE_HELP) AppRun:21: Warning: g_object_get: assertion `G_IS_OBJECT (object)' failed box.add_button(g.STOCK_HELP, g.RESPONSE_HELP) AppRun:21: Warning: value "TRUE" of type `gboolean' is invalid or out of range for property `visible' of type `gboolean' box.add_button(g.STOCK_HELP, g.RESPONSE_HELP) AppRun:26: GtkWarning: Screen for GtkWindow not set; you must always set a screen for a GtkWindow before using the window if box.run() == int(g.RESPONSE_HELP): AppRun:26: GtkWarning: gdk_pango_context_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_context_set_font_description: assertion `context != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_context_set_base_dir: assertion `context != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_context_set_language: assertion `context != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_layout_new: assertion `context != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_layout_set_text: assertion `layout != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_layout_set_attributes: assertion `layout != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_layout_set_alignment: assertion `layout != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_layout_set_ellipsize: assertion `PANGO_IS_LAYOUT (layout)' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_layout_set_single_paragraph_mode: assertion `PANGO_IS_LAYOUT (layout)' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_layout_set_width: assertion `layout != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: PangoWarning: pango_layout_get_extents: assertion `layout != NULL' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: GtkWarning: gtk_icon_theme_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: GtkWarning: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: GtkWarning: gtk_icon_size_lookup_for_settings: assertion `GTK_IS_SETTINGS (settings)' failed if box.run() == int(g.RESPONSE_HELP): AppRun:26: GtkWarning: Invalid icon size 6 if box.run() == int(g.RESPONSE_HELP): AppRun:26: GtkWarning: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed if box.run() == int(g.RESPONSE_HELP): zsh: segmentation fault (core dumped) AppRun -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Thomas L. <ta...@gm...> - 2007-05-19 11:14:28
|
On 5/19/07, Vincent Lefevre <vin...@vi...> wrote: > On 2007-05-19 11:27:52 +0100, Stephen Watson wrote: > > Are there any objections to me going ahead with a release this weekend? None from me :-) > I've tried it without DISPLAY set (mainly to see if there was anything > to compile), and I got a segmentation fault instead of an error message. Yes, all python-gtk programs do that :-( -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Stephen W. <st...@ke...> - 2007-05-23 19:19:57
|
Vincent Lefevre <vin...@vi...> wrote: > On 2007-05-20 11:00:24 +0100, Stephen Watson wrote: > > Try r5026 > > There's still the same problem. Try this mod: Index: AppRun =================================================================== --- AppRun (revision 5028) +++ AppRun (working copy) @@ -30,5 +30,5 @@ filer.open_dir(os.path.join(app_dir, "Help")) else: - stderr.write(message+'\n') + stderr.write(message.encode()+'\n') -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. The past is a different country, 1987's just the Isle of Wight. |
From: Vincent L. <vin...@vi...> - 2007-05-24 11:28:36
|
On 2007-05-23 20:19:52 +0100, Stephen Watson wrote: > Index: AppRun > =================================================================== > --- AppRun (revision 5028) > +++ AppRun (working copy) > @@ -30,5 +30,5 @@ > filer.open_dir(os.path.join(app_dir, "Help")) > > else: > - stderr.write(message+'\n') > + stderr.write(message.encode()+'\n') > Still the same problem. Even with: stderr.write(message.encode("latin-1")+'\n') Isn't the encoding attached to stderr? http://docs.python.org/lib/bltin-file-objects.html mentions an "encoding" attribute. -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Stephen W. <st...@ke...> - 2007-05-19 11:17:23
|
Vincent Lefevre <vin...@vi...> wrote: > On 2007-05-19 11:27:52 +0100, Stephen Watson wrote: > > Are there any objections to me going ahead with a release this weekend? > > I've tried it without DISPLAY set (mainly to see if there was anything > to compile), and I got a segmentation fault instead of an error message. This happens when using gtk without rox: stephen@kerofin:~/lib/ROX-Lib2> DISPLAY= python Python 2.5 (r25:51908, Jan 9 2007, 16:59:32) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import gtk as g /usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:69: GtkWarning: could not open display warnings.warn(str(e), _gtk.Warning) >>> g.gtk_version (2, 10, 6) >>> box=g.MessageDialog(None, g.MESSAGE_QUESTION, 0, g.BUTTONS_OK, 'test') /etc/pythonstart:1: Warning: invalid (NULL) pointer instance # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: Warning: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: GtkWarning: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: Warning: g_object_get: assertion `G_IS_OBJECT (object)' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: Warning: value "TRUE" of type `gboolean' is invalid or out of range for property `visible' of type `gboolean' # startup script for python to enable saving of interpreter history and >>> box.run() /etc/pythonstart:1: GtkWarning: Screen for GtkWindow not set; you must always set a screen for a GtkWindow before using the window # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: GtkWarning: gdk_pango_context_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_context_set_font_description: assertion `context != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_context_set_base_dir: assertion `context != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_context_set_language: assertion `context != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_layout_new: assertion `context != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_layout_set_text: assertion `layout != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_layout_set_attributes: assertion `layout != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_layout_set_alignment: assertion `layout != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_layout_set_ellipsize: assertion `PANGO_IS_LAYOUT (layout)' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_layout_set_single_paragraph_mode: assertion `PANGO_IS_LAYOUT (layout)' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_layout_set_width: assertion `layout != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: PangoWarning: pango_layout_get_extents: assertion `layout != NULL' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: GtkWarning: gtk_icon_theme_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: GtkWarning: gtk_icon_size_lookup_for_settings: assertion `GTK_IS_SETTINGS (settings)' failed # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: GtkWarning: Invalid icon size 6 # startup script for python to enable saving of interpreter history and /etc/pythonstart:1: GtkWarning: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed # startup script for python to enable saving of interpreter history and Segmentation fault (core dumped) We could either put assert g.gdk.get_display() in rox/__init__.py or have AppRun print the message if rox.g.gdk.get_display() returns None. Which do people favour? -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. That's wierd, new teeth! |
From: Vincent L. <vin...@vi...> - 2007-05-19 11:28:29
|
On 2007-05-19 12:17:08 +0100, Stephen Watson wrote: > We could either put > > assert g.gdk.get_display() > > in rox/__init__.py or have AppRun print the message if > rox.g.gdk.get_display() returns None. Which do people favour? IMHO, there should be a user-friendly message on stderr (translatable, if possible). -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Stephen W. <st...@ke...> - 2007-05-24 17:09:12
|
Vincent Lefevre <vin...@vi...> wrote: > On 2007-05-23 20:19:52 +0100, Stephen Watson wrote: > > Index: AppRun > > =================================================================== > > --- AppRun (revision 5028) > > +++ AppRun (working copy) > > @@ -30,5 +30,5 @@ > > filer.open_dir(os.path.join(app_dir, "Help")) > > > > else: > > - stderr.write(message+'\n') > > + stderr.write(message.encode()+'\n') > > > > Still the same problem. Even with: > > stderr.write(message.encode("latin-1")+'\n') > > Isn't the encoding attached to stderr? > > http://docs.python.org/lib/bltin-file-objects.html mentions an > "encoding" attribute. which is set by Python on start up. It also says: "when the file is connected to a terminal, the attribute gives the encoding that the terminal is likely to use (that information might be incorrect if the user has misconfigured the terminal)" I get these results: stephen@kerofin:~/lib/ROX-Lib2> python -c 'import sys; print sys.stderr.encoding' UTF-8 stephen@kerofin:~/lib/ROX-Lib2> LANG=fr python -c 'import sys; print sys.stderr.encoding' ANSI_X3.4-1968 stephen@kerofin:~/lib/ROX-Lib2> LANG=C python -c 'import sys; print sys.stderr.encoding' ANSI_X3.4-1968 -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. "Daleks have no concept of elegance!" "That is obvious." |
From: Stephen W. <st...@ke...> - 2007-05-19 11:58:58
|
Vincent Lefevre <vin...@vi...> wrote: > On 2007-05-19 12:17:08 +0100, Stephen Watson wrote: > > We could either put > > > > assert g.gdk.get_display() > > > > in rox/__init__.py or have AppRun print the message if > > rox.g.gdk.get_display() returns None. Which do people favour? > > IMHO, there should be a user-friendly message on stderr (translatable, > if possible). Updated, please check. -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. My bleeding heart does not extend to charity |
From: Vincent L. <vin...@vi...> - 2007-05-24 21:32:25
|
On 2007-05-24 18:09:03 +0100, Stephen Watson wrote: > which is set by Python on start up. It also says: > "when the file is connected to a terminal, the attribute gives the encoding > that the terminal is likely to use (that information might be incorrect if > the user has misconfigured the terminal)" My terminal is correctly configured, but... > I get these results: > stephen@kerofin:~/lib/ROX-Lib2> python -c 'import sys; print > sys.stderr.encoding' > UTF-8 Under Debian/unstable: vin:~> python -c 'import sys; print sys.stderr.encoding' None vin:~> locale charmap ISO-8859-1 vin:~> locale LANG=POSIX LC_CTYPE=en_US.ISO8859-1 LC_NUMERIC="POSIX" LC_TIME=en_DK LC_COLLATE=POSIX LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= vin:~> LC_ALL=en_US.UTF-8 locale charmap UTF-8 vin:~> LC_ALL=en_US.UTF-8 python -c 'import sys; print sys.stderr.encoding' None vin:~> python -V Python 2.4.4 Same problem under Mac OS X with python 2.4.3. However... vin:~> python -c 'import sys; print sys.stdout.encoding' ISO-8859-1 vin:~> LC_ALL=en_US.UTF-8 python -c 'import sys; print sys.stdout.encoding' UTF-8 -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Vincent L. <vin...@vi...> - 2007-05-24 21:46:31
|
On 2007-05-24 23:32:05 +0200, Vincent Lefevre wrote: [...] > vin:~> python -c 'import sys; print sys.stdout.encoding' > ISO-8859-1 > vin:~> LC_ALL=en_US.UTF-8 python -c 'import sys; print sys.stdout.encoding' > UTF-8 On <http://www.python.org/download/releases/2.5/NEWS.txt>: What's New in Python 2.5 alpha 1? [...] - Bug #1421664: sys.stderr.encoding is now set to the same value as sys.stdout.encoding. So, until Python 2.5+ is used everywhere, python scripts should change sys.stderr.encoding. -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Vincent L. <vin...@vi...> - 2007-05-19 12:40:51
|
On 2007-05-19 12:58:48 +0100, Stephen Watson wrote: > Vincent Lefevre <vin...@vi...> wrote: > > IMHO, there should be a user-friendly message on stderr > > (translatable, if possible). > > Updated, please check. There's still a problem: the (translated) message is output in UTF-8 on stderr, even if the locale is ISO-8859-1 (`locale charmap`). The script should convert the string into the current charmap, at least if stderr is attached to a terminal. -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Stephen W. <st...@ke...> - 2007-05-19 20:04:56
|
Vincent Lefevre <vin...@vi...> wrote: > On 2007-05-19 12:58:48 +0100, Stephen Watson wrote: > > Vincent Lefevre <vin...@vi...> wrote: > > > IMHO, there should be a user-friendly message on stderr > > > (translatable, if possible). > > > > Updated, please check. > > There's still a problem: the (translated) message is output in UTF-8 > on stderr, even if the locale is ISO-8859-1 (`locale charmap`). The > script should convert the string into the current charmap, at least > if stderr is attached to a terminal. Doesn't this happen with all the other warnings that ROX-Lib can generate on stderr? -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. Forget the shooty dog thing. |
From: Stephen W. <st...@ke...> - 2007-05-25 13:02:25
|
Vincent Lefevre <vin...@vi...> wrote: > On 2007-05-24 23:32:05 +0200, Vincent Lefevre wrote: > [...] > > vin:~> python -c 'import sys; print sys.stdout.encoding' > > ISO-8859-1 > > vin:~> LC_ALL=en_US.UTF-8 python -c 'import sys; print sys.stdout.encoding' > > UTF-8 > > On <http://www.python.org/download/releases/2.5/NEWS.txt>: > > What's New in Python 2.5 alpha 1? > [...] > - Bug #1421664: sys.stderr.encoding is now set to the same value as > sys.stdout.encoding. > > So, until Python 2.5+ is used everywhere, python scripts should change > sys.stderr.encoding. > They can't. It's a read-only attribute and set by the python run-time during initialization. So this is a python bug which we only noticed because we tried to warn about a much more serious pygtk bug. I'm inclined to ignore it and release ROX-Lib as it stands. -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. Strange as I seem I'm getting stranger by the minute |
From: Vincent L. <vin...@vi...> - 2007-05-25 13:12:32
|
On 2007-05-25 14:02:19 +0100, Stephen Watson wrote: > Vincent Lefevre <vin...@vi...> wrote: > > So, until Python 2.5+ is used everywhere, python scripts should > > change sys.stderr.encoding. > > They can't. It's a read-only attribute and set by the python > run-time during initialization. > > So this is a python bug which we only noticed because we tried to > warn about a much more serious pygtk bug. I'm inclined to ignore it > and release ROX-Lib as it stands. Can't the encoding be fixed by reopening stderr with the right codec? -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Vincent L. <vin...@vi...> - 2007-05-19 21:45:43
|
On 2007-05-19 21:04:39 +0100, Stephen Watson wrote: > Vincent Lefevre <vin...@vi...> wrote: > > There's still a problem: the (translated) message is output in UTF-8 > > on stderr, even if the locale is ISO-8859-1 (`locale charmap`). The > > script should convert the string into the current charmap, at least > > if stderr is attached to a terminal. > > Doesn't this happen with all the other warnings that ROX-Lib can > generate on stderr? I don't know. But note that ROX-Filer doesn't have this problem. -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) |
From: Lars H. <lar...@un...> - 2007-05-21 03:47:14
|
Stephen Watson wrote: > Are there any objections to me going ahead with a release this weekend? > The documentation for the new template functions would have you believe that you don't need to use the "root" argument when using the load() function. Maybe I'm doing something wrong but unless I set the "root" to the window I am interested in glade will bomb: code: self.widgets = rox.templates.load() ProxyWindow.__init__(self, self.widgets.getWindow('main')) Error: (Manny:18684): libglade-CRITICAL **: glade_xml_build_interface: assertion `wid != NULL' failed Traceback (most recent call last): File "./AppRun", line 35, in ? w = Win() File "./AppRun", line 15, in __init__ ProxyWindow.__init__(self, self.widgets.getWindow('main')) File "./rox/templates.py", line 121, in getWindow File "./rox/templates.py", line 142, in __init__ AssertionError If i use load(root='main') everything works fine. --- Lars Hansson |
From: Stephen W. <st...@ke...> - 2007-05-21 06:12:05
|
Lars Hansson <lar...@un...> wrote: > Stephen Watson wrote: > > Are there any objections to me going ahead with a release this weekend? > > > > The documentation for the new template functions would have you believe > that you don't need to use the "root" argument when using the load() > function. Maybe I'm doing something wrong but unless I set the "root" to > the window I am interested in glade will bomb: The root argument hasn't been optional since r4995, but the initial doc string hadn't been updated. -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. Lots of planets have a north |