CLIM mail archive
[Prev][Next][Index][Thread]

Request for spreadsheet example

(I'm using Allegro CLIM 2.0Beta2 on Sparc, but this should be general)

I've come full circle - after two years, I've returned to a problem
which has been annoying us since clim 0.9 days: How does one use CLIM
to implement a spreadsheet-like application for anything beyond a toy
situation which runs and updates acceptably quickly?

Situation:

(defclass foo ()
  ((yesp :type 'boolean)
   (name :type 'string)
   (height :type 'number)
   (where :type 'pathname)))

I've got a list SET-OF-FOO (SoF) of instances of class FOO.  

How do I write a CLIM application which allows me to edit the contents
of SoF given:
1. The application should show me the information in spreadsheet form:

	-NAME-	-YESP-	-HEIGHT-	-WHERE-
	foo1	yes	32		/usr/local/foo1
	foo2	no	47		/net/metheglin/u0/foo2
	...

2. Each cell should be edittable.

3. There should be a scrollbar which lets me browse through the set.
  
Seems pretty straightforward, no?  Well, here's some things that make
it hard.  Lets say I've got 100 elements in SoF... heck, let's say
I've got 10000 elements... let's say that I want my booleans to appear
as gadget checkboxes...  Lets say I have a button that sorts the list
into a different order.  Again, the main problem is one of scale, made
worse by a bunch of factors which tend to be rather slow in most
implementations anyway (but usually aren't a problem because they're
rarely used so much).

Clearly the naive implementation (accepting-values pane with a scroll-
bar) will Lose Big, consing its way to oblivion just laying out the
table, let alone recomputing updating-output after changing a cell.

Now, I'm not completely unreasonable... I'm perfectly happy
implementing my own scroll bar (I've done so, eliminating the overhead
of at looking at non-displayed elements) so that only what you see is
actually displayed... this helps.  I'm also perfectly willing to
accept fixed-size cells, thus eliminating table layout.  But I'm still
unhappy with update speed.

I clearly don't understand enough about the interaction between
updating-output and accepting-values because every time I try giving
my cells U-O hints, I end up with severely broken behavior - usually
either blindingly fast redisplay of wrong data or even slower than the
default.  BTW - Why can't I supply updating-output "hint" arguments to
accept within the the body of an accepting-values?  It would be real
nice to be able to specify :fixed-position t, or various :cache-test
values. 

should I stop using accepting-values and roll my own utility which
lets me say that all cells are completely independant and will never
change position?  Can I tell accepting-values and updating-output the
same things?

Any help gratefully accepted... & thanks,
	-Michael Thome (mthome@bbn.com)
Main Index | Thread Index