gtk_entry and 2k limit: Thoughts, suggestion, complaint

[Trever Adams <trever_Adams bigfoot com>]

   /* The algorithms here will work as long as, the text size (a
   * multiple of 2), fits into a guint16 but we specify a shorter
   * maximum length so that if the user pastes a very long text, there
   * is not a long hang from the slow X_LOCALE functions.  */
 
  if (entry->text_max_length == 0)
    max_length = 2047;
  else
    max_length = MIN (2047, entry->text_max_length);


Ok, I have issue here.

1) Does GtkText have this same limit for the same reason?  If not, WHY? 
Was a way around this slowness "hang" found?

2) Is it not possible that in some projects the overhead (And multiline
capability, even if enters are present) are not wanted nor needed where
size exceeds 2k?



The chase:  Would it be too much for me to ask that that limit be
removed or made compile time or run time choosable?  I am working on NUE
Order (http://nueorder.netpedia.net) and I have such a problem.  It
seems some of what (yes, this is being used somewhat already at my work)
we entered when we used it with gtk 1.0 can no longer be edited because
of this limit, we also have another place where we just crossed the
limit.

We would rather not go back to 1.0.x since we have things that need
1.2.x and it is shared object hell with gtk because of the configuration
issues.  We would also rather not got to gtk_text_xxxx if at all
possible because of the overhead.

Reasons to remove limit:

1) GTKTEXT should have the same limit for the same technical reason, if
it is indeed valid.
2) Many projects won't like the overhead of gtktext.
3) We are lazy and don't know entirely how to mix and match entry/text
in our app right now.  Eventually we may do just that... right now we
don't have time, we want to get this project out for people to use and
us to use.  (It would be VERY incorrect for us to make all the entry
widgets text widgets).

I am sure I am not giving this request justice, I am a bit tired and my
mind is on other problems (personal as I am not at work).  Please allow
this to be discussed, with me or without, so that we can reach a good
technical decisions.  Again some of my problem with this issue is it is
an ARTIFICIAL limit that seems to make sense for GTKTEXT if it makes
sense for GTKENTRY... I personally don't believe it makes sense in
either case.  I am a purest in many ways, so if it is definitely
technically accurate as is, and again that consensus is reached, I will
gladly take the changes to my code instead of asking you all to make
changes to the library.

If this change is made, I believe it is small enough to be considered a
bug fix to the 1.2.x series.  Also note, this limit should be WELL
documented.  I saw no documentation on www.gtk.org, and I believe I did
search at least some, if not all of the docs that came with the library
and saw no such comment either.

Thank you for considering my change request and for a great library to
write to.

Trever Adams

Please note, I didn't originally write this app... but I am changing it
to stay in sync with the rest of N.U.E. Order and it is taking me time
to understand how it completely works.