Re: G_UTF8String: Boxed Type Proposal

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 hackfest in June (if there
is sufficient interest) is a general purpose text buffer for Gio.


Some notable things I want to make a modern textview:


  2) Interface implementations that use append only change buffers.


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

-- Christian

Thanks for sharing that, Christian. Sounds interesting to look into!

I do understand what you have been getting at with the "append only" buffers.

What prompted my proposal in the first place was that I find GtkEntry and supporting objects to be rather limiting. I have been working towards developing a general way to extend the features of the single-line entry to include:

1) easily add user-specified formatting and validation

2) affixes which may or may not be selectable

3) rules for how the text is converted and into which MIME when dragging or copying

AND for these to be easily user-defined.

For some exotic example: "76°54′32″N-12°34′56″W"

1) valid only for regex "^\d{1,2}\302\260\d{1,2}\342\200\262\d{1,2}\342\200\263[NSns]-\d{1,2}\302\260\d{1,2}\342\200\262\d{1,2}\342\200\263[EWew]$"

2) Tags for text containing the digits and cardinal directions specified as editable. Tags containing other symbols - uneditable.

3) drags as struct coord_struct {enum_t COORDS_POLAR, double 76.908889, double 12.582222} to a map widget with "coords" property set to enum_t COORDS_MERCATOR which then calls coord_struct_convert (struct coord_struct *dst, struct coord_struct *src); etc. ... in order to locate the pixel on the map.

Eventually, I could see something like the introduction of GtkEntryMark and GtkEntryTag as aiding (2).

Before embarking further however, I felt that the establishment of the "length-aware UTF-8 string boxed type" could greatly reduce the overhead of redundant code. Perhaps what is called for instead is an Entry Buffer and Widget which use segments and append-only-buffers as GtkTextBuffer and GtkTextView do?

I will be on the lookout for more news about your vision!


gtk-devel-list mailing list
gtk-devel-list gnome org

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