So i would wait for performance to become a problem. If/when it does, you can probably uses synaptic Cells to minimize recomputation, or perhaps the application will suggest a new cells trick -- recent work on a Cells-ODE had me implement user control over propagation so one could do a bunch of state changes and propagate just once. ie, where the user knows multiple state changes can safely be treated as one, they can now get that by wrapping them in with-user-propagation (or whatever I called it).
Great. Luckily, the performance will probably not be a problem in this project.
Welcome to the club. Feels like a free lunch, eh? :)
Yes. when I saw Cells, I immediately also figured that if I had been more experienced, this kind of approach would have helped me with the nastiest programming challenge I have ever encountered: state management of database hot-standby feature. There, each instance is independent, but they must also keep track of each others (assumed) state. And there are both asynchronous and synchronous events coming in. Doing everything manually really sucked big time.
Do you know about the Tile package? I believe they are trying to be more native on the widgets. There is Tile support in Celtk, just not sure how robust it is -- I make all my own widgets using OpenGL.
I briefly looked at Tile. Looks like it could do the trick, but some stuff I get free.
Does your designer need "native", or do they just need "beautiful"? Perhaps they would get off on designing their own widgets.
The requirement is "beautiful". I just see "native" as the trade-off between effort and beautifulness which everybody can agree on for this version of the end-product. If the project succeeds we will go to self-designed widgets.
As for getting more people interested: Cells picks up one new user every
year, and it looks like you are the one for 2008 -- I have six months before I have to worry about finding another user.
:)
Talk to your designer, and check out my beach rants on Google video. What I
am sensing is that widget sets are terribly constraining when it comes to building fluent GUI experiences for users.
Heh, I checked the beach rants. The math learning application seemed really cool.
Does your designer also have an interest in the user experience, as well as the visual quality? In cello I have core classes like view and control and then i just make up an interactive screen element as i need it, with whatever rendering and event handling I have in mind. Instead of forcing my design into the pigeonholes determined by a fixed widget set, I just follow the application and the GUI elements follow me. :)
True, we are mostly interested in the user experience, eye-candy is secondary. Our needs are actually not very complicated, widget-wise. Drag and drop is the most complex feature we need. Otherwise, it is just data entry.
My approach is basically the same as yours. I created class for the preview etc. I just probably use little bit higher level widgets as building blocks. Minimally, clickable image with coordinate information is sufficient to create a buttons etc.
LispWorks seems to be perfect fit for this first project. Building the UI is really hassle-free, and end-result seems reasonably good.
I remember someone mentioning that a big problem in tall buildings was the
amount of
business logic hidden in spreadsheets. I have this dream fantasy of
getting rich just by writing
a parser that would convert a spreadsheet to the equivalent Lisp/Cells
application where they
could see the rules anyway.
If you want to become filthy rich, write a FileMaker to Lisp/Cells/Postgres converter with royalty-free deployment. Right now, each deployed application instance costs $$$. Application would actually be quite straightforward, as you can already copy-paste FileMaker views as XML. Of course, you would bankrupt billion-dollar business as a side-effect, so beware for the sunglassed men in black helicopters.
Best regards,
Mikko Ahonen