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

[Giorgos Keramidas <keramida hades hell gr>]

On Thu, Jun 24, 1999 at 01:35:57AM -0600, Trever Adams wrote:
|    /* The algorithms here will work as long as, the text size (a

   [snip - code chunk removed]

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

   [snip - rest of posting]

Well, after this mail arrived, I was just plainly curious and executed the
following `interesting' command on my GTK+ sources (I have version 1.0.6 at
home, kind of old I know):

    cd /usr/src/gtk+-1.0.6/
    find . -name '*.[ch]' -print0 |\
	xargs -0 egrep -ni '\<limit\>|\<maximum\>'

which searches the GTK+ sources for exact but case-insensitive matches of
the words `limit' and `maximum'.  Surprisingly enough, here's the output:

    ./glib/gmem.c:58:			      *  must be declared to be the maximum size it
    ./glib/gutils.c:295:    case ELIBMAX: return "attempting to link in more shared libraries than system limit";
    ./glib/gutils.c:634:    case SIGXCPU: return "CPU time limit exceeded";
    ./glib/gutils.c:637:    case SIGXFSZ: return "File size limit exceeded";
    ./gdk/gdk.c:182:						     *  a maximum time to wait for an event
    ./gdk/gdk.c:1115: *   Calls to "gdk_event_get" will last for a maximum
    ./gdk/gdkcc.c:1030:  /* This is the maximum no. of allocated colors.  See also the nopen == 0
    ./gdk/gdkinput.h:76:  /* reported x minimum/maximum values */
    ./gdk/gdkinput.h:83:  /* calibrated minimum/maximum values */
    ./gdk/gdktypes.h:833:  gint max_colors;		/* maximum no. of colors */
    ./gtk/gtkentry.c:1482:   * maximum length so that if the user pastes a very long text, there
    ./gtk/gtkentry.c:1490:  /* Make sure we do not exceed the maximum size of the entry. */
    ./gtk/gtkhruler.c:27:#define MAXIMUM_SUBDIVIDE     5
    ./gtk/gtkhruler.c:28:#define MAXIMUM_SCALES        10
    ./gtk/gtkhruler.c:174:       *   use the maximum extents of the ruler to determine the largest possible
    ./gtk/gtkhruler.c:183:      for (scale = 0; scale < MAXIMUM_SCALES; scale++)
    ./gtk/gtkhruler.c:187:      if (scale == MAXIMUM_SCALES)
    ./gtk/gtkhruler.c:188:	scale = MAXIMUM_SCALES - 1;
    ./gtk/gtkhruler.c:191:      for (i = MAXIMUM_SUBDIVIDE - 1; i >= 0; i--)
    ./gtk/gtkmenufactory.c:223:      g_warning ("gtk_menu_factory_create(): argument `path' exceeds maximum size.");
    ./gtk/gtkmenufactory.c:343:      g_warning ("gtk_menu_factory_remove(): argument `path' exceeds maximum size.");
    ./gtk/gtkmenufactory.c:489:      g_warning ("gtk_menu_factory_find_recurse(): argument `path' exceeds maximum size.");
    ./gtk/gtkobject.c:952:      g_warning ("gtk_object_get_arg_type(): argument `arg_name' exceeds maximum size.");
    ./gtk/gtkselection.c:57:/* Maximum size of a sent chunk, in bytes. Also the default size of
    ./gtk/gtkvruler.c:27:#define MAXIMUM_SUBDIVIDE     5
    ./gtk/gtkvruler.c:28:#define MAXIMUM_SCALES        10
    ./gtk/gtkvruler.c:174:       *   use the maximum extents of the ruler to determine the largest possible
    ./gtk/gtkvruler.c:183:      for (scale = 0; scale < MAXIMUM_SCALES; scale++)
    ./gtk/gtkvruler.c:187:      if (scale == MAXIMUM_SCALES)
    ./gtk/gtkvruler.c:188:	scale = MAXIMUM_SCALES - 1;
    ./gtk/gtkvruler.c:191:      for (i = MAXIMUM_SUBDIVIDE - 1; i >= 0; i--)

That gives only 10 source files and 2 headers that are likely to have such
limits, which after a little more research and grepping around the GTK+
source proves that candidates for such `artificial' limits are:

    SOURCE		LINE	DESCRIPTION

    gdk/gdkcc.c		1030	perhaps I got the color code all wrong
				and this is not a limit?

    gtk/gtkentry.c	1482	this IS a limit, and we need to discuss it

If I have indeed gotten the color allocation code of gdk/gdkcc.c all wrong,
then the only `artificial' limit of GTK seems to be this GtkEntry thing.

Now, let's get rational here.  I know that having this limit might be
annoying in `some' cases.  However, a limit of approx. 2 KB of text in a
single text entry box does not seem that much of a limit if you think of it
a little more.  Well, I know that modern computers have lots of spare MB's
of memory to waste, but what type of application would require you to play
around with GtkEntry's having more than 2 KB of text in a single widget?

Point 1: Down with the Library Limits
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Someone might argue that such limits should be removed from GTK+.  This is
the approach of `we are gonna make this widget set totally bug free' and it
seems quite appealing, at least at first.

Perhaps, we ought to make this configurable at compile or even run-time. 
Another field in `struct _GtkEntry' along with a couple of `wrapper'
functions, like gtk_entry_get_max_length() and gtk_entry_set_max_length()?

Dunno, I need your help here GTK+ gurus...  Gimme an insight, please.

Havvoc? ...    Anyone? ...

Point 2: Design the Code to Overcome the Limits
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Trever, you should ask yourself...

Is the code of your application really in absolute and DESPERATE need of
keeping more than 2 KB of text in a single GtkEntry?  Can the text of the
GtkEntry be split in a `meaningful' way in more than one widgets.  For
instance, instead of keeping "hostname:port" strings, one might prefer to
have two separate GtkEntry's holding the "hostname" and "port" strings...

Can you think of such a way to split the data that is now stored in the
offending GtkEntry's, in order to avoid this limitation of the widget?

Finalle
~~~~~~~

Well, these are just some thoughts that popped up this morning (it seems
that when I sleep less than 4 hours I have all these crazy ideas flowing
around in my brains, I should probably do it a lot more often).

G'day all.

-- 
     ?     | Giorgos Keramidas       < mailto:keramida@ceid.upatras.gr >
  >(o.o)<  | Phone: +30-932-886457   < mailto:keramida@yahoo.com >
     ^     | "Today is not yesterday's tomorrow, but tomorrow's yesterday."