Problems with the gs library?

[Chris Pressey]

On Thu, 27 Jun 2002 13:54:44 -0500
James Hague <jamesh@REDACTED> wrote:

> I'm happy with Erlang for most general programming tasks, and now I'm in
> need of doing some GUI work.  I've heard criticisms of gs in the past,
> particularly that it's too slow.  I know it takes a few seconds to call
> gs:start(), and that it takes a significant amount of extra time to
> start Erlang with the toolbar (at least under Windows).  Is the problem
> with Tk itself, the communication with Tk, or is it something else? 
> What are the other problems with using gs?  I know it certainly isn't as
> nice as Delphi, but Tk is the standard UI toolkit for Python, so it
> can't be all bad.
> 
> Thanks for any comments.

Hi James,

I think the reason gs is somewhat slow is because there are two levels of
interpretation going on: Erlang and Tcl.  In my experience, erlgtk is
faster, probably because there is no extra interpretation layer.

Another huge drawback of gs is that you cannot react to a window being
closed.  That is, you can react to it, but you cannot do anything to stop
it.  This is the main reason I didn't write a text editor using gs - there
was no way to pop up a dialog box saying "File is not saved, are you sure
you want to exit?"

I've gotten erlgtk to work under FreeBSD and Windows now (using Luke's
build, plus some files from my FreeBSD build) and I like it a lot.

I've put a lot of thought into writing a gs->erlgtk emulation layer,
and I've come to the conclusion that for simple user interfaces (buttons,
entries, and sliders, basically,) it would be quite easy, but for anything
more detailed (grids, canvases, fonts,) it would be quite difficult.

My solution for the time being is to write a new, very abstract user
interface layer, which could use one of any number of backends (erlgtk,
gs, slang, etc.)  This is a *very* abstract interface though, primarily
suited for data entry, and thus probably not everyone's cup of tea.

Hope this helps.
-Chris