[gtk-server] Re: performance and safety of Trim_String

  • From: Peter van Eerten <administrator@xxxxxxxxxxxxxx>
  • To: gtk-server@xxxxxxxxxxxxx
  • Date: Wed, 1 Dec 2004 18:51:34 +0100

Hi Jim,

Thanks a lot you for your feedback!

Indeed the GTK-server is a proposition; every improvement is welcome, and I will
test your submitted code asap. Note that it also should work with MinGW.

> I was originally looking through the source to see how
> escaping is handled, e.g. for setting the contents of
> a textarea to something with brackets, commas, and
> newlines. The newline doesn't seem to be possible, and
> the scheme for brackets and commas just pushes the
> problem onto other characters of your choice rather
> than solving the issue.

The newline *is* possible. Please consult the demo applications on the
GTK-server website, especially the e-text reader.

The comma's and brackets however indeed have a problem. This has to do with the
way the incoming GTK strings are being parsed; the C-function "strtok" is used
for it, which cannot decide whether a comma or bracket is part of a user-defined
string. E.g. parsing this with "strtok":

gtk_text_buffer_insert(txtbuf, myendit, "Hello, world :-)", -1)

...cannot see if the comma or the bracket in the string "Hello, world :-)"
actually are argument separators or not. Writing a complete parser is too much
work, compared to the benefit you would gain; there are *only* 2 symbols for
which an alternate character have to be defined. That is why I have implemented
it the way it is now.

Ultimately, the configuration options for the comma (GTK_SERVER_COMMA) and
brackets (GTK_SERVER_BRACKET) indeed are a workaround, and not a structural
solution, that is true.

> Maybe it would be worth while to come up with another
> syntax like substituting commas with ?, brackets with
> ?) newlines with ?n and ? with ?? (i am deliberately
> avoiding \ as it is used too much by every other
> language). Would any of the client languages have
> trouble escaping/unescaping that? Of course the exact
> escape character could be definable...

Indeed this might be a good idea; passing the gtk-functions and arguments
directly without any comma's or brackets would even be nicer, then the client
language does not need any string functions to accomplish the catting of
arguments, and the client code looks much better!

> Not that I am too bothered, for the moment I find it
> is easier to use gtk2 directly from clisp so don't
> have a need for gtk-server, but there have been (and
> will be) plenty of times when it would have extremely
> useful to me. Great idea, please keep up the good
> work.

Well, I think the CLisp community would be more than happy to know how you bind
with GTK2 using CLisp. The only binding I am aware of is mentioned at
http://tenkan.org/clgtk/, which still is beta stage.

Thanks again, and if you have more ideas, comments, code improvements etc. do
not hesitate to contribute them to the mailinglist!



Other related posts: