Table inspector from 4W

Richard Gaskin ambassador at fourthworld.com
Tue Oct 14 22:43:23 EDT 2008


-= JB =- wrote:

 > I am sure the Rev team can speed things up in time.  But many
 > features available are much better than nothing at all.
 >
 > As for the proper spacing when I was using a demo of Rev over a
 > year ago I asked about adding a glyph for justification. Someone
 > suggested make an invisible image for a glyph which would be 1
 > point and you could then enter the amount needed.
 >
 > Things can be improved by the Rev team but many things can be used
 > now.  If it gets so large it is too slow you will have to wait for
 > those options to be improved.
 >
 > Another way to speed it up would do not have a few thousand rows.
 > This could be overcome by using a database and after so many rows
 > were scrolled the database would get the next hundred or so,
 > whatever works.

Both of those are very clever workarounds, but they must be recognized 
for what they are.

The extra characters for the images, while aiding display, complicate 
data retrieval since they must be parsed out.

The buffered display of long lists can work in some cases, but it means 
either accepting a scrollbar whose thumb bears no relationship to the 
field contents, or using a separate scrollbar object and managing it 
yourself.

Sure, it's all doable, but a dozen lines here and a dozen lines there 
and pretty soon you have a rather complex subsystem on your hands -- a 
subsystem that doesn't add innovative features to one's app as much as 
simply compensate for not having basic ones.

For the relative few in the Rev community with the experience to pull 
off such a set of workarounds gracefully, our clients would rather we be 
working on bullet-point features.

And for newcomers, it's quite a lot to ask of them to figure all that out.

Things like this are a lot like chunk expressions:  you can parse text 
in any language, but I hate parsing text in any language that doesn't 
have chunk expressions.  It's so logical, so efficient, so very much the 
right way to handle that task.

Ideally everything in the Rev experience would be as compelling, at 
least the most commonly-used stuff.


That said, here you show yourself to be a man after my own heart:

 > I am not saying it is perfect but if that is what you need it
 > would be better than nothing.

Amen, brother.  I hope my nit-picking over this object doesn't appear 
arbitrary.  In general, I'm right with you on that, and often seek some 
way to get an immediate solution, however imperfect, to get the job done 
and move on to other things.

But there's a delicate balance in the ratio of time spent on a 
workaround relative to its quality and relative to the complexity it 
adds to one's code base.

If you absolutely need a independent column alignment, there are ways to 
do it (I'd probably favor multiple lists with a single list overlaid, 
but that also comes at a price of its own in parsing and reassembling data).

But the cost of doing it is high, the complexity it adds is relatively 
high, and the final result performs slower than even Java.

For highly specialized things that only one or a few people need (for 
example, a sonar dial widget for a Battleship game, or an orthogonal 
grid library for visual simulations), sometimes you just gotta roll up 
your sleeves and cut some code.  I'm okay with that.  Sometimes I even 
enjoy it. :)

But independent column alignment is so very central to so much of what 
so many people want to build in Rev, and have wanted for so long, that I 
believe we're at a point where it can be reasonably said to be expected 
in the engine.  Much of what people need to display are numbers.

It's not just the 261 votes for that request that matter.  Those of us 
using the product now are a small number compared to those we need to 
see using it five years from now.  It's that much-larger audience of 
newcomers who will need it most, so they can just drop it in and move on 
to more interesting things like learning arcane SQL syntax, and along 
the way gain the feeling that they couldn't possibly use anything else 
because anything else would be too much work.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com




More information about the use-livecode mailing list