After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740818 - gunichar2 not bound
gunichar2 not bound
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Bindings: GLib
0.34.x
Other Linux
: Normal enhancement
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2014-11-27 17:54 UTC by Christian Persch
Modified: 2016-10-03 19:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glib-2.0: Add UCS-4 and UTF-16 related bindings (3.22 KB, patch)
2016-09-18 11:32 UTC, Rico Tzschichholz
none Details | Review
glib-2.0: Add UCS-4 and UTF-16 related bindings (3.17 KB, patch)
2016-09-25 12:26 UTC, Rico Tzschichholz
none Details | Review
glib-2.0: Add UCS-4 and UTF-16 related bindings (3.16 KB, patch)
2016-09-27 18:03 UTC, Rico Tzschichholz
none Details | Review
glib-2.0: Add UCS-4 and UTF-16 related bindings (3.16 KB, patch)
2016-09-27 19:08 UTC, Rico Tzschichholz
committed Details | Review

Description Christian Persch 2014-11-27 17:54:20 UTC
gunichar has bindings in glib-2.0.vapi, but gunichar2 does not.
Comment 1 Rico Tzschichholz 2016-09-18 11:32:43 UTC
Created attachment 335799 [details] [review]
glib-2.0: Add UCS-4 and UTF-16 related bindings
Comment 2 Rico Tzschichholz 2016-09-19 18:32:52 UTC
@chpe: It this what you would expect to be able to work with.
Comment 3 Christian Persch 2016-09-20 16:17:43 UTC
Hmm. IIRC I filed this when I was working on bindings for PCRE's 16- and 32-bit libraries, so what I had in mind would have been full string16/string32 classes for utf-16/32 like string for utf-8. Since glib doesn't have all the functions for these like for 8-bit strings, I guess only providing the basics and the to/from utf16/32 conversion functions is ok for now. (However I'd name the API utf32 not ucs4, even though the glib functions have ucs4 in the name.)
Comment 4 Rico Tzschichholz 2016-09-25 12:26:29 UTC
Created attachment 336212 [details] [review]
glib-2.0: Add UCS-4 and UTF-16 related bindings
Comment 5 Jürg Billeter 2016-09-25 16:06:53 UTC
The name unistring is misleading, in my opinion, as the string type is a Unicode string as well. Does anything speak against string16/string32? I would also not use ucs4 as name anywhere. As far as I know, the relevance of UCS-4 is only historical and the (permanently unassigned) code points that are not in UTF-32 are not representable in UTF-8 or UTF-16 either.
Comment 6 Rico Tzschichholz 2016-09-27 16:42:27 UTC
I guess I am fine with string16 and string32 while keeping the current method names.
Comment 7 Rico Tzschichholz 2016-09-27 18:03:21 UTC
Created attachment 336380 [details] [review]
glib-2.0: Add UCS-4 and UTF-16 related bindings
Comment 8 Christian Persch 2016-09-27 18:33:02 UTC
(In reply to Jürg Billeter from comment #5)
> The name unistring is misleading, in my opinion, as the string type is a
> Unicode string as well. Does anything speak against string16/string32? 

string16/string32 sound fine to me.

> I would also not use ucs4 as name anywhere. As far as I know, the relevance of
> UCS-4 is only historical and the (permanently unassigned) code points that
> are not in UTF-32 are not representable in UTF-8 or UTF-16 either.

Note that not all of the glib functions do support these codepoints, i.e. g_utf8_to_ucs4_fast() does not (anymore, see bug 738504 comment 10), and the others probably aren't guaranteed to, either. So using utf32 in the names would really be better.
Comment 9 Rico Tzschichholz 2016-09-27 19:08:53 UTC
Created attachment 336382 [details] [review]
glib-2.0: Add UCS-4 and UTF-16 related bindings
Comment 10 Rico Tzschichholz 2016-10-03 19:37:19 UTC
Attachment 336382 [details] pushed as 5c5245d - glib-2.0: Add UCS-4 and UTF-16 related bindings