I'm having GUI troubles, and I thought i'd see what everyone else is doing...<br>
<br>
I'm having GUI troubles.&nbsp; Right now i'm using drscheme, which has
unicode, a gui, and a builder.&nbsp; However, the gui is insanely
slow.&nbsp; I do lots of complicated nested panels, and a screen
refresh is taking over 15 seconds right now&nbsp; (it's getting too
slow even for development work now).&nbsp; 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 &quot;thin gui client&quot;, 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 &quot;event X
happened&quot;.&nbsp; <br>
<br>
I tried writing the interface originally in java, but java seemed to
freak on recursions.&nbsp; 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.&nbsp; (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 &quot;thin-ness&quot;.&nbsp; i'm defining these
as: if it's a scheme implementation that I can just cut and paste to
the server code it's &quot;portable&quot;, if its written in assembly but just
passes events back and fourth, maintaining no real state, then it's
&quot;thin&quot;.<br>
<br>
<br>
How is everyone else solving this?<br>
<br>
<br>
Corey<br>