On Thu, Mar 17, 2016 at 2:26 PM, Jasper St. Pierre
wrote:
> I'll also ask what "character" means in this case, even though I know
> glib also has the same confusion. Are you talking about the number of
> Unicode code points in the string, or the number of grapheme
I'll also ask what "character" means in this case, even though I know
glib also has the same confusion. Are you talking about the number of
Unicode code points in the string, or the number of grapheme clusters,
as defined by Unicode TR29 [0]? The number of code points isn't useful
for editing in
The major issue is that "Unicode character" doesn't have a good
definition. The most likely definition is a "Unicode code point",
however, Windows uses "Unicode character" to mean a UTF-16 byte
sequence, which means that any code point above the Basic Multilingual
Plane is really composed of two
Just to add my two cents worth as a user of glibmm.
Glib::usting uses g_utf8_pointer_to_offset() to obtain the length of
the string in characters in the method Glib::ustring::length. The
method Glib::ustring::bytes returns the length in bytes;
At no point does it store the number of UTF-8
On Wed, Mar 16, 2016 at 6:58 PM, Randall Sawyer
wrote:
> I have a question at the end of this! Please answer if you think it will
> help.
Hi Randall,
thanks for contributing!
>
> I propose the development of a new boxed type for the Glib API named
> "G_UTF8String".
On 03/19/2016 03:41 AM, Errol van de l'Isle wrote:
Just to add my two cents worth as a user of glibmm.
Glib::usting uses g_utf8_pointer_to_offset() to obtain the length of
the string in characters in the method Glib::ustring::length. The
method Glib::ustring::bytes returns the length in bytes;
On 03/17/2016 09:30 AM, Matthias Clasen wrote:
Hi Randall,
thanks for contributing!
Pleased to be of service! Looking forward to learning how folks work
together in this community.
I believe that you haven't found such a proposal because most people
don't see much use in a separate boxed
On 03/19/2016 12:25 PM, Randall Sawyer wrote:
>
> If there already were such a structure, then it could already have been
> employed by existing objects and structures such as GtkEntryBuffer and
> PangoLayout - to name two - eliminating the need for extra lines of
> redundant code. In fact - as I
On 03/19/2016 02:57 PM, Emmanuele Bassi wrote:
Hi;
On 19 March 2016 at 18:03, Randall Sawyer
wrote:
The concision of "GUString" over "G_UTF8String" reflects the
concision of my
thoughts over what they were at the beginning of this thread.
Since you've brought it
On 03/19/2016 02:04 PM, Randall Sawyer wrote:
>> It's possible you are focusing on implementation before measuring the
>> problem. DRY alone is not a sufficient argument.
>
> "DRY" is not a term I know - or at least in the way you are using it
> here.
I have a question at the end of this! Please answer if you think it will
help.
The following is the result of my efforts to develop widgets derived
from GtkEntry and GtkEntryBuffer. Specifically, I want to have the
ability to easily develop entries which validate their content and which
may
On 03/19/2016 04:09 PM, Christian Hergert wrote:
It's possible you are focusing on implementation before measuring the
problem. DRY alone is not a sufficient argument.
"DRY" is not a term I know - or at least in the way you are using it here.
One topic I'm interested in covering at the
[ Replying a little randomly to this message. ]
Randall Sawyer:
> 3) Wouldn't it be helpful to keep track of how many code points
> ("characters")are stored in the GString - a number which may be less than
> the value of GString.len - without needing to call g_utf8_strlen() each time
> to find
On 17/03/16 20:29, Matthias Clasen wrote:
> Terminology can certainly be confusing at times, but I think that a
> Unicode character is a perfectly well-defined entity, non-withstanding
> the fact that it can be represented in various encodings (a utf8
> sequence, a ucs4 word, a utf-16 surrogate
I'm writing a C++ application and I want it to provide a generic UI
interface, which under the hood might be using GTK, Win32, etc. The goal is
that the app can be compiled with support for one or more UI backends and
the user can choose one at runtime, or at least that one backend can be
selected
Sure, code point works too. Anyway, enough with the ontology, we're
not a standards body
I still don't think that we need a utf8-string datatype.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On Thu, Mar 17, 2016 at 4:09 PM, Jasper St. Pierre
wrote:
> The major issue is that "Unicode character" doesn't have a good
> definition. The most likely definition is a "Unicode code point",
> however, Windows uses "Unicode character" to mean a UTF-16 byte
> sequence,
On 03/19/2016 01:38 PM, Christian Hergert wrote:
On 03/19/2016 06:57 AM, Randall Sawyer wrote:
Some object classes - such as GtkEntryBuffer - store this value and
update it as text is inserted or deleted. That is efficient. The fact
that developers need to write equivalent code for each such
On 03/19/2016 06:57 AM, Randall Sawyer wrote:
>
> Some object classes - such as GtkEntryBuffer - store this value and
> update it as text is inserted or deleted. That is efficient. The fact
> that developers need to write equivalent code for each such class is
> inefficient.
A string abstraction
Hi;
On 19 March 2016 at 18:03, Randall Sawyer wrote:
> The concision of "GUString" over "G_UTF8String" reflects the concision of my
> thoughts over what they were at the beginning of this thread.
Since you've brought it up multiple times, I wanted to ensure you
On Fri, Mar 18, 2016 at 2:57 PM Randall Sawyer
wrote:
> how about the following modifications?
> Change "gstring.h":
> ...
> struct _GString
> {
>gchar *str;
>gsize len;
>gsize allocated_len;
>gsize utf8_len;
> };
> ...
>
Changing the size of a
21 matches
Mail list logo