| Author |
Message |
|
| dae |
 Posted: Sun Oct 07, 2007 7:33 pm |
 |
|
|
Joined: 03 Aug 2007
Posts: 5
|
I have posted a website all about the GS module.
http://erl.dougedmunds.com
Comments welcome.
-dae
------
search keywords:
GS graphic interface tcl/tk window gui visual |
|
|
| Back to top |
 
|
| GLPunzi |
| Posted: Thu Nov 08, 2007 11:45 am |
|
|
|
User
Joined: 08 Nov 2007
Posts: 14
|
I'm new in erlang, and this info could be very helpfull to me.
Thanks for the work  |
|
|
| Back to top |
|
| francesco |
| Posted: Tue Nov 13, 2007 7:47 am |
|
|
|
User
Joined: 07 Jul 2006
Posts: 249
Location: London
|
|
| Back to top |
|
| DoomIhlVaria |
| Posted: Fri May 02, 2008 6:02 pm |
|
|
|
Joined: 02 May 2008
Posts: 1
Location: Sarasota, Florida
|
This is truly a shame. I find the GS library to be wonderfully simplistic. I would love to see the library maintained and to have the existing bugs (particularly Windows-related) resolved.
I have tried to build a simple tile-based mapping program using GS under Windows XP x64 (a user base that some insist doesn't exist) only to run into loads of problems. The reason I chose Erlang for this is that the map data would be fed into a different Erlang program and I figured I could save some time by dealing only in native Erlang data types.
While wxErlang has far more extensive features than GS, I feel we would be losing a lot by scrapping such an easy to use library. A person can read the relevant docs and throw together a simple GUI application in less than an hour using GS.
Further, wxErlang, at first glance, does not handle garbage collection or threading with anywhere near the ease that I have come to expect from Erlang. |
|
|
| Back to top |
|
| steved |
| Posted: Fri May 02, 2008 9:09 pm |
|
|
|
User
Joined: 29 Apr 2008
Posts: 78
|
I too thought GS "had something" particularly with create_tree. That seemed to offer a really simple way to design/build GUIs incredibly quickly - or to offer a decent visual GUI builder for those that prefer that.
From what I read of wxErlang it was originally largely generated erlang code directly off the wxWidgets C++ API... the style of coding against wxErlang reminds me a lot of Swing (Java) - i.e. boringly verbose.
I noticed that Wings3d seems to have implemented its own (and very fast) WM built over esdl.
GUI APIs have always been a pain to learn/use. When I saw GS I had high hopes that it could offer a simple alternative that could mature, but I'd take a bet that the final answer will lie somewhere between the three different approaches. |
|
|
| Back to top |
|
| Matthew Harrison |
| Posted: Wed Jul 23, 2008 9:06 am |
|
|
|
Joined: 23 Jul 2008
Posts: 2
|
steved wrote: I too thought GS "had something" particularly with create_tree. That seemed to offer a really simple way to design/build GUIs incredibly quickly - or to offer a decent visual GUI builder for those that prefer that.
From what I read of wxErlang it was originally largely generated erlang code directly off the wxWidgets C++ API... the style of coding against wxErlang reminds me a lot of Swing (Java) - i.e. boringly verbose.
I noticed that Wings3d seems to have implemented its own (and very fast) WM built over esdl.
GUI APIs have always been a pain to learn/use. When I saw GS I had high hopes that it could offer a simple alternative that could mature, but I'd take a bet that the final answer will lie somewhere between the three different approaches.
I agree, too. I like the GS interface, and the idea in the docs that is has a frontend and multiple backends (although only tk appears to ever have been implemented - and looks like it heavily influenced the design of the GS interface). I've been looking at the mandel contrib, and wondering why it kills my CPU. I came to the conclusion that it was because it writes the results pixel by pixel which is Bad (see Tk Images Dos and Don'ts. Implementing the writing of lines of pixels in gs images would help this enormously, it was taking longer than the calculation!
Tcl/Tk 8.5 has come out recently, and now tk is themable (requires some mods to use new ttk widgets instead, but shouldn't be too much work) This addresses the dated look and feel issues, and could encourage more apps to be written.
The way of constructing widgets with tuples of options really lends itself to configuring from a generated data file, which could be produced by translating output from other gui builders initially.
But I have to admit, Tcl/Tk has languished for ages, although it may make a bit of a comeback with 8.5. But wxerlang looks like being the favoured way, more open, and more people know C++ perhaps than tcl!. I'll have to have a look. I hope the interface will be as nice as gs (or as nice as a completed gs would have been) If what Joe & all are saying about super multi-core systems being the death of the multi-threaded shared data model, eventually Erlang will need to implement more and more features (like GUI toolkits) at as low a level as possible, until we have an entire OS.
Which brings me to how can I contribute? I have many years GUI programming experience (mainly in Java/Swing, but years ago in C++)[/url]
Rgds,
Matthew. |
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
