Re: G_UTF8String: Boxed Type Proposal
On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer
wrote:
> 2) If the former is true - which it is - then the developer will need to
> call g_utf8_strlen() to determine if there are multi-byte sequences to
> navigate - and if there are - g_utf8_offset_to_pointer() to locate the array
> index. Doesn't this increase processing demand?
It does. But whether that is a problem (in general, or for your
particular use case) can only be answered by profiling. My theory is
that you won't be able to notice this on the profile at all, unless
all your application does is constantly operating on large amounts of
text. In which case, you really shouldn't be using GString to begin
with...
> 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?
> 4) Would my efforts be better spent editing patches of "gstring.h" and
> "gstring.c" - or - to proceed as I am to introduce a parallel alternative?
I think we haven't gotten past the 'what is the problem you are trying
to solve - and is it a problem in the first place ?' part yet.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: G_UTF8String: Boxed Type Proposal
I like to voice my opinion as well:
- Bundling data and its length in a boxed type is useful, but that's
gblob,
- Bundling number-of-Unicode-character is rarely useful indeed,
- A string API that would require any changes to the string content to go
through editing function calls is painful and will remain unused,
I also have a piece of a more personal opinion: Many processes that simply
*reject* invalid Unicode text are useless in many situations. For example,
gedit used to refuse to open a file if it had even a single
invalidly-encoded byte. I find that annoyingly limited. Same thing about
Pango. Fortunately, both have been fixed for many years now.
behdad
On Mon, Mar 21, 2016 at 6:32 AM, Matthias Clasen
wrote:
> On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer
> wrote:
>
>
> > 2) If the former is true - which it is - then the developer will need to
> > call g_utf8_strlen() to determine if there are multi-byte sequences to
> > navigate - and if there are - g_utf8_offset_to_pointer() to locate the
> array
> > index. Doesn't this increase processing demand?
>
> It does. But whether that is a problem (in general, or for your
> particular use case) can only be answered by profiling. My theory is
> that you won't be able to notice this on the profile at all, unless
> all your application does is constantly operating on large amounts of
> text. In which case, you really shouldn't be using GString to begin
> with...
>
> > 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?
> > 4) Would my efforts be better spent editing patches of "gstring.h" and
> > "gstring.c" - or - to proceed as I am to introduce a parallel
> alternative?
>
> I think we haven't gotten past the 'what is the problem you are trying
> to solve - and is it a problem in the first place ?' part yet.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
--
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: G_UTF8String: Boxed Type Proposal
Thank you once again to all who have responded.
I have changed my mind.
I DO grasp the nature of responders' objections.
My understanding has now reached a "tipping point".
What is the tipping point?
On 03/21/2016 04:30 PM, Behdad Esfahbod wrote:
I like to voice my opinion as well:
- Bundling data and its length in a boxed type is useful, but that's
gblob,
- Bundling number-of-Unicode-character is rarely useful indeed,
- A string API that would require any changes to the string content
to go through editing function calls is painful and will remain unused,
I also have a piece of a more personal opinion: Many processes that
simply *reject* invalid Unicode text are useless in many situations.
For example, gedit used to refuse to open a file if it had even a
single invalidly-encoded byte. I find that annoyingly limited. Same
thing about Pango. Fortunately, both have been fixed for many years now.
behdad
On Mon, Mar 21, 2016 at 6:32 AM, Matthias Clasen
mailto:matthias.cla...@gmail.com>> wrote:
On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer
mailto:srandallsaw...@hushmail.me>>
wrote:
> 2) If the former is true - which it is - then the developer will
need to
> call g_utf8_strlen() to determine if there are multi-byte
sequences to
> navigate - and if there are - g_utf8_offset_to_pointer() to
locate the array
> index. Doesn't this increase processing demand?
It does. But whether that is a problem (in general, or for your
particular use case) can only be answered by profiling. My theory is
that you won't be able to notice this on the profile at all, unless
all your application does is constantly operating on large amounts of
text. In which case, you really shouldn't be using GString to begin
with...
Matthias, I comprehend what you are saying here.
As Christian pointed out recently
(https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00037.html),
"DRY alone is not a sufficient argument."
> 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?
> 4) Would my efforts be better spent editing patches of
"gstring.h" and
> "gstring.c" - or - to proceed as I am to introduce a parallel
alternative?
I think we haven't gotten past the 'what is the problem you are trying
to solve - and is it a problem in the first place ?' part yet.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
The tipping point is the function g_utf8_normalize() - which is called
by objects which DO possess a length-of-string in units of UTF
8-code-points ("characters" in Glib parlance).
If my proposed idea were to be adopted in a useful way - then every call
to any g_utf8_*() function would require that it be wrapped in a
g_ustring_*() [previously g_utf8_string_*()] function in order for
GUString [previously G_UTF8String] to be truly useful.
Time to move on.
Along the way - however - I have come up with two functions which I will
be proposing and which may very well be useful in a number of certain cases:
g_utf8_unilen() - which measures the length of string in UTF-8 sequences
("characters") primarily and in non-nul bytes secondarily
g_utf8_offset_to_pointer_sized () - which optimizes its return value by
by first comparing byte length to UTF-8 length [for the cases when these
are both known] - opting for pointer arithmetic when equal - and then
compares UTF-8 offset to UTF-8 length in order to decide whether to
parse the first 3/4 of the last 1/4 when calling g_utf8_offset_to_pointer()
These last two, I will definitely be submitting as a patch.
--
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: G_UTF8String: Boxed Type Proposal
Frankly, the use of the term "character" when referring to a "UTF-8 encoded Unicode code point" was for me a source of confusion when I leapt to the conclusion of the unmet need of a UTF-8-length-aware wrapped string type - be it called "G_UTF8String" or "GUString". I recommend that all Glib documentation be rewritten such that throughout all descriptions of g_utf8_*() functions, the parlance "character" be replaced with "UTF-8 code point sequence" or equivalent terminology. Thank you. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GUString: Boxed Type Proposal
Hi! I keep my word: https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00034.html I have come to a conclusion: https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00042.html I have something to say about that: https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00043.html -Randall ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Branch or Patch?
I am ready in all earnestness to submit the proposal for the conclusion of new UTF-8-length-oriented functions 'g_utf_unilen()' and 'g_pointer_to_offset_sized()' - declared in "gunicode.h" and defined in "gutf8.c" [https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00042.html] I have instructions at https://wiki.gnome.org/Git/Developers#Local_Branches and at https://wiki.gnome.org/Git/Developers#Contributing_patches . Which of these two is the appropriate one to follow? Thank you, Yours, Randall ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Branch or Patch?
On 03/21/2016 07:29 PM, Randall Sawyer wrote: I am ready in all earnestness to submit the proposal for the conclusion of new UTF-8-length-oriented functions 'g_utf_unilen()' and 'g_pointer_to_offset_sized()' - declared in "gunicode.h" and defined in "gutf8.c" [https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00042.html] Oops! Make that 'g_utf8_unilen()' instead of 'g_utf_unilen()' and 'g utf8_offset_to_pointer_sized()' instead of 'g_pointer_to_offset_sized()'. I have instructions at https://wiki.gnome.org/Git/Developers#Local_Branches and at https://wiki.gnome.org/Git/Developers#Contributing_patches . Which of these two is the appropriate one to follow? Thank you, Yours, Randall ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Branch or Patch?
On 03/21/2016 07:42 PM, Randall Sawyer wrote: On 03/21/2016 07:29 PM, Randall Sawyer wrote: I am ready in all earnestness to submit the proposal for the conclusion of new UTF-8-length-oriented functions 'g_utf_unilen()' and Oops - again - for my conflation between intended motivation - 'conclusion' - and requisite process - 'nominal inclusion'. 'g_pointer_to_offset_sized()' - declared in "gunicode.h" and defined in "gutf8.c" [https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00042.html] Oops! Make that 'g_utf8_unilen()' instead of 'g_utf_unilen()' and 'g utf8_offset_to_pointer_sized()' instead of 'g_pointer_to_offset_sized()'. I have instructions at https://wiki.gnome.org/Git/Developers#Local_Branches and at https://wiki.gnome.org/Git/Developers#Contributing_patches Which of these two is the appropriate one to follow? Thank you, Yours, Randall ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 3.20
GTK+ 3.20.0 is now available for download at: http://download.gnome.org/sources/gtk+/3.20/ sha256 sum: 1c3d3a4a6e959ec8636ccb074bcdb8fa25c81ec56fbc70de6a3f5ef83ba6d803 gtk+-3.20.0.tar.xz What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a comprehensive set of widgets as well as facilities for creating your own widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript (especially in combination with gobject-introspection and the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP), GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation of the GNOME desktop. What's new in 3.20 == Major new features include: * The CSS machinery now uses element names for widgets and their components * CSS margins, borders, padding and min-width and min-height are now much more consistently supported * CSS features that have been added: radial gradients, recoloring symbolic icons, image(), calc(), rem * Help overlays to document keyboard shortcuts and gestures * GTK+ now reads .XCompose files * GTK+ can use native file choosers on Windows * A HighContrastInverse theme has been added * The Wayland backend has full support for DND, kinetic scrolling, startup notification, primary selection, presenting windows, bell. * Deprecations and removals: Style properties, testing infrastructure, geometry support in window sizing, GdkDeviceManager, gtk_text_iter_begins_tag, gdk_display_get_screen For more details and lists of fixed bugs, see the NEWS file that is included in the tarball, or see: http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.20.0 For concerns about porting from older GTK+ releases, see the README file that is included in the tarball, or see: http://git.gnome.org/browse/gtk+/plain/README.in?id=3.20.0 Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ is found at: http://library.gnome.org/devel/gtk3/stable/gtk-building.html Common questions: http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. March 21, 2016 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
