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
https://mail.gnome.org/mailman/listinfo/gtk-dev
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.
https://en.wikipedia.org/wiki/Don't_repeat_yo
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 hackfe
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 h
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 up multiple times, I wanted
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 public struct is an ABI break, so
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
understood this particular point..
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 cla
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, which means that any code po
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
[ 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 out
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 pai
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 type
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". I have searched through this
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 charact
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 "U
19 matches
Mail list logo
