I'm having GUI troubles, and I thought i'd see what everyone else is doing...<br>
<br>
I'm having GUI troubles.  Right now i'm using drscheme, which has
unicode, a gui, and a builder.  However, the gui is insanely
slow.  I do lots of complicated nested panels, and a screen
refresh is taking over 15 seconds right now  (it's getting too
slow even for development work now).  Gtk objects work much faster
(but aren't stable as the gtk-ffi-lib is't finished)<br>
<br>
Now I have the system split into a client and server, for just this type of problem....<br>
<br>
The system can be interactively tested in the client, which is very helpfull during development.<br>
<br>
Now if the client is written in scheme, then I can abuse the
client/server spec, and add features on the client side... then when
they are working, move them to their proper place on the server....<br>
<br>
My other thoughts were to make a "thin gui client", which just managed
events... so like we could have a client in any language that would
recieve event X from the mouse, and pass to the server "event X
happened".  <br>
<br>
I tried writing the interface originally in java, but java seemed to
freak on recursions.  It's been a while, but if I remember right,
it was like when a type A panel held a type B panel, which held a type
A panel.  (wouldn't even compile)<br>
<br>
So I guess what i'm looking for is:<br>
unicode support<br>
Since it's part of the development cycle (i.e. 90% of the gui objects
are to test things that aren't fully completed features yet), a GUI
builder would be important.<br>
and finally code portability or "thin-ness".  i'm defining these
as: if it's a scheme implementation that I can just cut and paste to
the server code it's "portable", if its written in assembly but just
passes events back and fourth, maintaining no real state, then it's
"thin".<br>
<br>
<br>
How is everyone else solving this?<br>
<br>
<br>
Corey<br>