R: [erlang-questions] A future for gs?
Tue Jun 15 12:23:11 CEST 2010
"The problem with GS is that as soon as you want to do something serious you
end up in
bypassing the limited gs API and going directly towards tcl/tk."
But that problem, in turn, is because there has been no further development
of GS to expand the limited Erlang API, right? If so, then what I'm hearing
here is a tautology: "There will be no further development because there
will be no further development."
There has to be more to this issue than that.
What if there *was* further development of GS, to improve the API? Is the
problem simply that nobody has volunteered to do this?
Or is it that there's been some formal, official decision to not accept any
improvements in future releases of Erlang/OTP?
If it's the latter, where was this decision documented and what were the
reasons given? And isn't it the very rock-bottom minimum of courtesy to
point out clearly, at the very beginning of online documentation for a
package, that official support for it has ceased? Had I known that, I might
have bitten the wx bullet, in all its leaden toxicity. As it is, I might
have just wasted about two weeks exploring an all-but-dead graphics API.
Can someone at least tell me how, in Erlang, one goes "directly towards
tcl/tk", if I'm interpreting that phrasing correctly? Meaning, I assume,
that there's some part of the GS API that allows me to send Tcl commands and
get responses back? Or if there is no such way, is there someone here who
knows for a fact that there isn't?
On Tue, Jun 15, 2010 at 4:18 PM, Kenneth Lundin <>wrote:
> gs will not be further developed. We recommend the use of wx.
> If you like the gs type of API it could probably be built on top of wx.
> The problem with GS is that as soon as you want to do something
> serious you end up in
> bypassing the limited gs API and going directly towards tcl/tk.
> /Kenneth, Erlang/OTP Ericsson
> On Tue, Jun 15, 2010 at 8:19 AM, Michael Turner
> <> wrote:
> > I started writing a little diagram editor in gs, but have just run
> > on a limitation: there doesn't seem to be any way to track where you are
> > a canvas when you're scrolling around in one. The scrollbars work, the
> > canvas objects updates canvas object positions appropriately, but it
> seems I
> > can't find out what part of the canvas I've scrolled *to*. Without that,
> > can't convert window coordinates to canvas coordinates and back again.
> > I can't even get scrollbar interaction events. I started looking at the
> > source and found that there's an API-exposed but undocumented
> > And you can ask to have a scrollbar created, returning successfully.
> > you can't do anything with it. You can't even see it.
> > I've also found some code for some dialog boxes, useful (if ugly) for
> > alerts, file selection, etc. The comments describe this module as
> > "internal", but nothing in the gs source directory actually refers to
> > They are clearly not ready for prime-time (and so "widgety" that Steve
> > would vomit). But they do work (sort of.)
> > This package looks like it was dropped mid-stride, even though it seems
> > have started off in a reasonable direction: wrapping Tcl/Tk.
> > Regretfully, I'm starting to look at wx again, but I find it only reminds
> > far too much of what I disliked about GUI programming in C++. If you
> > already know the wxWidgets API from some other language, the very similar
> > Erlang bindings might seem like a Godsend. But if you just want to get a
> > GUI up and out of the way (my goal), and you don't have that wdWidgets
> > background, it all just seems verbose, over-parameterized,
> > overwhelming. (IMAO, anyway -- I've done Mac programming, Windows
> > programming, and hated every minute of GUI programming on both.)
> > Is there a future for gs? I've gotten the impression that the sun is
> > setting on Tcl/Tk. Maybe gs will follow it?
> > -michael turner
More information about the erlang-questions