Re: [PATCH] making GtkTextBuffer::set_text() accept single param

Yep, we still need 's'. Let's not mash everything together. -Andrei On Sep 13, 2005, at 12:55 PM, Steph wrote:

OK, I did some experimenting with codepages, 'u', 's' and stuff now. Works fine here - strings that get thrown out when they're 's' are converted nicely when they're 'u'. Of course doze can't then print out the contents of the label correctly for debugging etc, but that's a minor consideration. Wouldn't it make more sense, internally, to have the 's' representation have the functionality of the 'u' representation? Or are there places where we need 's' to mean what it normally means? ----- Original Message ----- From: "Andrei Zmievski" <andrei@gravitonic.com> To: "Steph" <steph@zend.com> Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> Sent: Tuesday, September 13, 2005 5:19 PM Subject: Re: [PHP-GTK-DEV] [PATCH] making GtkTextBuffer::set_text() accept single param

Of course, UTF-8 is compatible with ASCII, so if your string argument happens to contain only chars in the 0-127 range, then it wouldn't be a problem. But we still need to do the conversion in case non-ASCII stuff is passed. -Andrei On Sep 12, 2005, at 3:57 PM, Steph wrote:

I recall issues with this under win32 in GTK 1, it's not an entirely new thing - GTK always did use utf8 strings internally. I haven't had any problems with plain strings on WinXP so far, but then I haven't really pushed the boat out either. Will do some checking when I've more time. ----- Original Message ----- From: "Andrei Zmievski" <andrei@gravitonic.com> To: "Steph" <steph@zend.com> Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> Sent: Monday, September 12, 2005 9:21 PM Subject: Re: [PHP-GTK-DEV] [PATCH] making GtkTextBuffer::set_text() accept single param

Like I said, any text passed to Gtk+ API has to be UTF-8, so we need to use "u". And, when returning a string, we need to convert from UTF-8 to whatever codepage we have. -Andrei On Sep 12, 2005, at 1:13 PM, Steph wrote:

Thanks for that, it's helpful. Question is, should we be making everything 'u' now rather than 's'? ----- Original Message ----- From: "Andrei Zmievski" <andrei@gravitonic.com> To: "Steph" <steph@zend.com> Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> Sent: Monday, September 12, 2005 6:07 PM Subject: Re: [PHP-GTK-DEV] [PATCH] making GtkTextBuffer::set_text() accept single param

Any text passed to Gtk+ should be in UTF-8, so yes, "u" is appropriate. Don't forget to free the converted string, for example: static PHP_METHOD(Gtk, accel_map_add_entry) {

     char *accel_path;
     zend_bool free_accel_path;
     long accel_key;
     GdkModifierType accel_mods;
     zval *php_accel_mods = NULL;

     if (!php_gtk_parse_args(ZEND_NUM_ARGS(), "uiV", &accel_path,

&free_accel_path, &accel_key, &php_accel_mods))

         return;

     if (php_accel_mods &&

phpg_gvalue_get_flags(GDK_TYPE_MODIFIER_TYPE, php_accel_mods, (gint *)&accel_mods) == FAILURE) {

         return;
     }

     gtk_accel_map_add_entry(accel_path, (guint)accel_key,

accel_mods);

     if (free_accel_path) g_free(accel_path);

} -Andrei On Sep 12, 2005, at 6:52 AM, Steph wrote:

I don't have a test script for this, I just want to keep it somewhere safe for now (and can't see any reason for it to fail). Compiles OK. GtkImageMenuItem's constructor represents the stock_id parameter as 'u' (encoded string) rather than as 's' (string) - this is the only place in the overrides where stock_id's represented that way. Should the others also accept encoded strings, or is it a typo? - Steph <textbuffer.txt>-- PHP-GTK Development Mailing List (http://gtk.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- PHP-GTK Development Mailing List (http://gtk.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- PHP-GTK Development Mailing List (http://gtk.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- PHP-GTK Development Mailing List (http://gtk.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php