Re: gtk_entry and 2k limit: Thoughts, suggestion, complaint

[Owen Taylor <otaylor redhat com>]

Trever Adams <trever_Adams@bigfoot.com> writes:

>    /* 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?

No. Because it wouldn't make sense. No.

Note that with GtkText, the user will at least eventually see
that they entered that much text, so they will get 
retroactive feedback. 
 
> 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?

No. The smallest legible font is about 5 point - maybe 3 pixels
horizontally to be conservative. At that size, a GtkEntry would
have to 6000 pixels wide to reach the 2k character limit.
I've never personally seen a monitor with more than 2000 pixels
horizontal screen real estate.

> 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.

You clearly have a user interface problem. Although GtkEntry
scrolls, it is not suitable for entering large portions of
text.
 
> 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.

The overhead of GtkText is much less than the size of the
text you are trying to enter here. Without doing a careful
check, I'd be pretty sure that it is <0.5k.

> 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.

The limit is a heuristic to deal with an observed problem.  The fact
that the problem can not be dealt with in GtkText does not mean we
should not try to deal with it in GtkEntry, where a limit
on the number of inserted characters does make sense.

Once we make the upcoming switch to Unicode as the internal
representation for GTK+, we should be able to use other
methods that can do the necessary conversions at much
higher speeds, so this (yes, artificial) limit can be
removed. But at the current time, I would be hesitant 
to do so.
 
> 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.

Thanks for the feedback. As mentioned above, I'm quite
hesitant to make this change, especially since expecting
user's to enter that much text in a single-line widget
is horrible user-interface design.

(Not that user-interface design is up to the toolkit,
but I feel more urgency in supporting good design,
than bad design.)

Regards,
                                        Owen