[cells-devel] Inheritance from model, not model-object?

[Mikko Ahonen]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20080711/38c59a4d/attachment.html>