Re: G_UTF8String: Boxed Type Proposal

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 envision it - the entirety of struct
_GtkEntryBuffer IS a GUString - and all of the procedures which operate
upon instances of that structure could be performed by g_ustring_*()

It's possible you are focusing on implementation before measuring the
problem. DRY alone is not a sufficient argument.

The emergence of such a structure may, IMHO, facilitate more rapid
development of future structures and objects which could also benefit
from having such a length-aware string object. That's all.

One topic I'm interested in covering at the hackfest in June (if there
is sufficient interest) is a general purpose text buffer for Gio.

While not a particular goal, it would allow us to pass content between
gtk and pango without requiring contiguous strings. But that is an awful
lot of pango work and Behdad is probably in the best situation to say if
it would even help. I suspect on *really* long lines it might, but
otherwise not.

Some notable things I want to make a modern textview:

 1) Interface that makes it possible to mmap() source contents
    and/or a page cache for large file support. Being limited to
    virtual address space like we are today is non-ideal.
    (SQL dumps, log viewers, IRC backlog come to mind).
    - another interface implementation could be a contiguous string,
      but i expect the same append only structure is still faster
      once you start editing.
 2) Interface implementations that use append only change buffers.
 3) Unlimited Undo/Redo tracking
 4) Ability to get a snapshot of the buffer for off-thread processing.
    (Highlighting, glyph sizing, etc).
    a. ability to do this without doing copies in most cases
 5) Ability to attach indexes to "GTextBuffer"
    a. Number of code points could be one such line-based index
    b. Line height calculations another
    c. highlighting tags, completion word indexes, etc
    d. index merging to merge off-thread calculations
    e. This gets a little tricky when you want multiple views with
       different font sizes (like we do in Builder and Gedit)
 6) efficient slices for copy/paste

One thing you'll notice when you combine the above is that you've
basically written a database.

-- Christian

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]