Ruby 1.9 compatibility for GtkFileChooser (String encodings)

This is to propose a patch to correctly handle filenames to/from rg2
with ruby 1.9, in GtkFileChooser.

It is stated in GtkFileChooser documentation that “filenames are
always returned in the character set specified by the
G_FILENAME_ENCODING environment variable”. Also, “while you can pass
the result of gtk_file_chooser_get_filename() to open(2) or fopen(3),
you may not be able to directly set it as the text of a GtkLabel
widget unless you convert it first to UTF-8, which all GTK+ widgets
expect. You should use g_filename_to_utf8() to convert filenames into
strings that can be passed to GTK+ widgets.”

Also, I wasn’t sure what is the behaviour of File methods in Ruby 1.9.
My experimentation shows that the bytes from the encoding of the
String passed are used, e.g. without converting. For example in a
UTF-8 system, File.new(“mémé”) isn’t the same as
File.new(“mémé”.encode(“ISO-8859-1”)) (the last one gives ENOENT).

So, I think Strings representing files got from GTK+ in rg2 should:

1- have an associated encoding, so that they can be displayed in GTK+
without the programmer needing to do conversions (because my new
RVAL2CSTR will send UTF-8 char* to GtkLabel etc)
2- use the encoding expected by the operating system so that File.new
will work

First step is to use g_filename_to_utf8(), so that we are 100%
confident we can create a correct String (by using these bytes in Ruby
UTF-8 encoding).

Second step is to change the encoding of the String for realizing the
(2) item above. After looking at Glib documentation, I think that
using the first item from g_get_filename_charsets() should be fine.

I have made a patch for doing this. I have tested in a UTF-8 system
with a file with an accent, with default settings and also by forcing
filename encoding to ISO-8859-1 (by launching the program with
LC_ALL=en_US in parameter), all works great! Here’s my little test
program:

-=-=—=-=—=-=—=-=–
#! /usr/bin/ruby

require ‘gtk2’

Gtk.init

fc = Gtk::FileChooserDialog.new(“Foo”,
nil,
Gtk::FileChooser::ACTION_OPEN,
nil,
[Gtk::Stock::OK,
Gtk::Dialog::RESPONSE_ACCEPT], [Gtk::Stock::CANCEL,
Gtk::Dialog::RESPONSE_CANCEL])
if fc.run == Gtk::Dialog::RESPONSE_ACCEPT
puts fc.filename
puts fc.filename.encoding
puts File.exists?(fc.filename)
end
-=-=—=-=—=-=—=-=–

The patch is pretty much complete for rbgtkfilechooser.c, however it
might be necessary
to deploy a similar approach for other places in rg2 dealing with
filenames.

What do you think?

Hi,

In [email protected]
“[ruby-gnome2-devel-en] Ruby 1.9 compatibility for GtkFileChooser
(String encodings)” on Fri, 1 Oct 2010 16:36:57 +0200,
Guillaume C. [email protected] wrote:

This is to propose a patch to correctly handle filenames to/from rg2
with ruby 1.9, in GtkFileChooser.

The patch is pretty much complete for rbgtkfilechooser.c, however it
might be necessary
to deploy a similar approach for other places in rg2 dealing with filenames.

What do you think?

THanks!
It looks almost good to me. Could you commit the patch after
appling some my comments?

I think that other places should be handled in other patch.

— gtk2/ext/gtk2/extconf.rb (revision 3938)
+++ gtk2/ext/gtk2/extconf.rb (working copy)
@@ -51,6 +51,8 @@
end
raise “can’t find gdkkeysyms.h” if gdkincl.nil?

+ruby_header = “ruby.h”
+have_func(“rb_str_encode”, ruby_header)

You can use HAVE_RUBY_ENCODING_H macro defined in ruby.h of
1.9. You don’t need to call the have_func().

— gtk2/ext/gtk2/rbgtkfilechooser.c (revision 3938)
+++ gtk2/ext/gtk2/rbgtkfilechooser.c (working copy)
@@ -22,7 +22,82 @@

static VALUE
+filename_to_ruby_free(filename)

  • gchar* filename;
    +{

Could you use

filename_to_ruby_free(gchar *filename)

style? We want to deprecate legacy ANSI style.

+#ifdef HAVE_RB_STR_ENCODE

  • gchar* filename2;

Please use

gchar *filename_utf8;

instead of it. We want to use meaningful name.

  • GError *err = NULL;

Please use ‘error’ instead of ‘err’. We don’t use
abbreviated name.

  • VALUE s = Qnil;

Please use ‘rb_filename’ or something meaningful name.

+#else

  • return CSTR2RVAL2(filename);
    +#endif

Please use CSTR2RVAL_FREE() because CSTR2RVAL2() is
deprecated. We want to use meaningful name.

Thanks,

kou

1.9. You don’t need to call the have_func().
Why not, but I already used HAVE_RB_STR_ENCODE in revision 3938, and I
got it that way because of your revision 3744.

So revisions 3744 and 3938 should be fixed first with using
HAVE_RUBY_ENCODING_H, right?

filename_to_ruby_free(gchar *filename)

style? We want to deprecate legacy ANSI style.

Ok. Once upon a time, I used this style in a previous patch and you
made me use legacy ANSI style, so that’s now what I do…

Suggestion: if some style rule changes, a script should modify all
source code to match new style, isn’t it? So when we copy-paste
another similar code in the project to try to do a correct patch, we
don’t end up with using old style…

+#ifdef HAVE_RB_STR_ENCODE

  • gchar* filename2;

Please use

gchar *filename_utf8;

instead of it. We want to use meaningful name.

Ok.

  • GError *err = NULL;

Please use ‘error’ instead of ‘err’. We don’t use
abbreviated name.

That was taken from some other code in rg2… but ok.

+#else

  • return CSTR2RVAL2(filename);
    +#endif

Please use CSTR2RVAL_FREE() because CSTR2RVAL2() is
deprecated. We want to use meaningful name.

Oh, that one is really easy: remove CSTR2RVAL2, and perl (err, ruby)
-pi -e all uses to new style. Why not doing that?

Thanks,


Guillaume C. - http://zarb.org/~gc/

2010/10/6 Kouhei S. [email protected]:

Thanks,

kou

Could you explain the use of “ruby -pi -e”. If I found time next week
I will take a look at this point.


Vincent C.

Hi,

2010/10/4 Guillaume C. [email protected]:

You can use HAVE_RUBY_ENCODING_H macro defined in ruby.h of
1.9. You don’t need to call the have_func().

Why not, but I already used HAVE_RB_STR_ENCODE in revision 3938, and I
got it that way because of your revision 3744.

So revisions 3744 and 3938 should be fixed first with using
HAVE_RUBY_ENCODING_H, right?

Yes. Could you fix those changes? We want to use HAVE_RUBY_ENCODING_H
rather tan HAVE_RB_STR_ENCODE.

Could you use

filename_to_ruby_free(gchar *filename)

style? We want to deprecate legacy ANSI style.

Ok. Once upon a time, I used this style in a previous patch and you
made me use legacy ANSI style, so that’s now what I do…

I’m sorry about my inconsistent comments…
We want to drop legacy ANSI style because Ruby itself drops it.

Suggestion: if some style rule changes, a script should modify all
source code to match new style, isn’t it? So when we copy-paste
another similar code in the project to try to do a correct patch, we
don’t end up with using old style…

Yes. You’re right. But we don’t have time to do it…
So we just improve it step by step for now…

Please use ‘error’ instead of ‘err’. We don’t use
abbreviated name.

That was taken from some other code in rg2… but ok.

It also a TODO item…
We want to improve other places.

Please use CSTR2RVAL_FREE() because CSTR2RVAL2() is
deprecated. We want to use meaningful name.

Oh, that one is really easy: remove CSTR2RVAL2, and perl (err, ruby)
-pi -e all uses to new style. Why not doing that?

Just no time for it…

Thanks,

kou

Could you explain the use of “ruby -pi -e”. If I found time next week
I will take a look at this point.

it’s an inplace edit. a bit like “sed -i” but on steroids since you
have the power of ruby (or perl) (personally, I still use perl for
that, because it’s helpful to have more default values etc than ruby
for one liners).

in the last thing we were talking about, you could do:

perl -pi -e ‘s/\bCTR2RVAL2\b/CSTR2RVAL_FREE/’ *.c

it’s kinda trivial, i was about to propose doing it soon. but if you
want to play with it, why not.


Guillaume C. - http://zarb.org/~gc/

Why not, but I already used HAVE_RB_STR_ENCODE in revision 3938, and I
got it that way because of your revision 3744.

So revisions 3744 and 3938 should be fixed first with using
HAVE_RUBY_ENCODING_H, right?

Yes. Could you fix those changes? We want to use HAVE_RUBY_ENCODING_H
rather tan HAVE_RB_STR_ENCODE.

Done.

filename_to_ruby_free(gchar *filename)

style? We want to deprecate legacy ANSI style.

Ok. Once upon a time, I used this style in a previous patch and you
made me use legacy ANSI style, so that’s now what I do…

I’m sorry about my inconsistent comments…

No, it was not inconsistent, it was just changing over time so it was
a surprise for me :slight_smile:

We want to drop legacy ANSI style because Ruby itself drops it.

Suggestion: if some style rule changes, a script should modify all
source code to match new style, isn’t it? So when we copy-paste
another similar code in the project to try to do a correct patch, we
don’t end up with using old style…

Yes. You’re right. But we don’t have time to do it…

I can try to do a script/one liner to fix all this in one step. Are
you ok if I do that and show you the patch, or do you think it’s too
dangerous?

Oh, that one is really easy: remove CSTR2RVAL2, and perl (err, ruby)
-pi -e all uses to new style. Why not doing that?

Just no time for it…

I can do that :slight_smile:


Guillaume C. - http://zarb.org/~gc/

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Ruby 1.9 compatibility for GtkFileChooser
(String encodings)” on Wed, 6 Oct 2010 22:42:17 +0200,
Guillaume C. [email protected] wrote:

Yes. Could you fix those changes? We want to use HAVE_RUBY_ENCODING_H
rather tan HAVE_RB_STR_ENCODE.

Done.

Thanks!

Suggestion: if some style rule changes, a script should modify all
source code to match new style, isn’t it? So when we copy-paste
another similar code in the project to try to do a correct patch, we
don’t end up with using old style…

Yes. You’re right. But we don’t have time to do it…

I can try to do a script/one liner to fix all this in one step. Are
you ok if I do that and show you the patch, or do you think it’s too
dangerous?

Yes please!

Oh, that one is really easy: remove CSTR2RVAL2, and perl (err, ruby)
-pi -e all uses to new style. Why not doing that?

Just no time for it…

I can do that :slight_smile:

Please also do it!


kou

2010/10/6 Guillaume C. [email protected]:

perl -pi -e ‘s/\bCTR2RVAL2\b/CSTR2RVAL_FREE/’ *.c

it’s kinda trivial, i was about to propose doing it soon. but if you
want to play with it, why not.

Not necessary. I was just curious about these options.
It seemed easy to patch this point that why I proposed to do it but If
you have time you can do it. You seem more aware of this process than
me


Vincent C.

On Thu, Oct 7, 2010 at 14:14, Kouhei S. [email protected] wrote:

In [email protected]

I can try to do a script/one liner to fix all this in one step. Are
you ok if I do that and show you the patch, or do you think it’s too
dangerous?

Yes please!

Protoize turns K&R-style declarations to ANSI-style declarations:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Running-Protoize.html

Hi,

In [email protected]
“Re: [ruby-gnome2-devel-en] Ruby 1.9 compatibility for GtkFileChooser
(String encodings)” on Thu, 7 Oct 2010 15:27:56 +0200,
Guillaume C. [email protected] wrote:

So here’s a patch to remove CSTR2RVAL2 and RVAL2CSTR2 and use their
explicit counterpart.

Notice, I’ve also seen that CSTR2RVAL2 properly returns Qnil if the
passed gchar* is NULL, so the patch also simplifies uses like “str ?
CSTR2RVAL2(str) : Qnil” into “CSTR2RVAL_FREE(str)”.

Is the patch looking good?

Yes but don’t remove CSTR2RVAL2 and RVAL2CSTR2.
They are deprecated but we should keep provides them until
Ruby-GNOME2 1.0.0. We should just warn for using them.

Others are OK for me.

Thanks,

kou

Is the patch looking good?

Yes but don’t remove CSTR2RVAL2 and RVAL2CSTR2.
They are deprecated but we should keep provides them until
Ruby-GNOME2 1.0.0. We should just warn for using them.

Why not, but why? Is there external dependencies to them? Since I have
removed them all, they should be useless now. So keeping them would
only let someone forgetting about not using them, to use them…


Guillaume C. - http://zarb.org/~gc/

Oh, that one is really easy: remove CSTR2RVAL2, and perl (err, ruby)
-pi -e all uses to new style. Why not doing that?

Just no time for it…

I can do that :slight_smile:

Please also do it!

So here’s a patch to remove CSTR2RVAL2 and RVAL2CSTR2 and use their
explicit counterpart.

Notice, I’ve also seen that CSTR2RVAL2 properly returns Qnil if the
passed gchar* is NULL, so the patch also simplifies uses like “str ?
CSTR2RVAL2(str) : Qnil” into “CSTR2RVAL_FREE(str)”.

Is the patch looking good?

libraries.)
Ok.

What about the following steps?

  1. Don’t remove CSTR2RVAL2 and RVAL2CSTR2.
  2. Release Ruby-GNOME2 with CSTR2RVAL2 and RVAL2CSTR2 are
    deprecated announce.
  3. Remove CSTR2RVAL2 and RVAL2CSTR2.
  4. Release Ruby-GNOME2 with CSTR2RVAL2 and RVAL2CSTR2 are
    removed announce.

Fine with me!


Guillaume C. - http://zarb.org/~gc/

Hi,

In [email protected]omain.invalid
“Re: [ruby-gnome2-devel-en] Ruby 1.9 compatibility for GtkFileChooser
(String encodings)” on Thu, 7 Oct 2010 16:37:02 +0200,
Guillaume C. [email protected] wrote:

Is the patch looking good?

Yes but don’t remove CSTR2RVAL2 and RVAL2CSTR2.
They are deprecated but we should keep provides them until
Ruby-GNOME2 1.0.0. We should just warn for using them.

Why not, but why? Is there external dependencies to them? Since I have
removed them all, they should be useless now. So keeping them would
only let someone forgetting about not using them, to use them…

Maybe yes. There are some programs/libraries that use
Ruby-GNOME2 C API. (e.g. rbclutter. And I have some
libraries.)

What about the following steps?

  1. Don’t remove CSTR2RVAL2 and RVAL2CSTR2.
  2. Release Ruby-GNOME2 with CSTR2RVAL2 and RVAL2CSTR2 are
    deprecated announce.
  3. Remove CSTR2RVAL2 and RVAL2CSTR2.
  4. Release Ruby-GNOME2 with CSTR2RVAL2 and RVAL2CSTR2 are
    removed announce.

(It’s better that warning messages are showen for those
macro use at 2. release.)

Thanks,

kou

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs