Open Letter to Rev: Quality Is Job #1

Chipp Walters chipp at
Fri Oct 20 18:29:54 EDT 2006

As a fellow Windows user, I thought I might lend some insight into some of
the issues.

On 10/20/06, Bill Marriott <wjm at> wrote:
> - The installer introduced in 2.7 is horrible. It installs desktop
> shortcuts
> that point nowhere. The file associations are busted. It doesn't perform
> uninstall correctly. The full program directory is present after
> uninstall,
> junk is still sprinkled through the registry, and Rev doesn't remove its
> entries in Add/Remove programs. While the 2.6.1 installer works perfectly
> under Vista, the 2.7.4 installer locks up and has to be forced-quit. Error
> handling within the installer is a joke. Install/Uninstall should be one
> thing that is bulletproof, but these apparently haven't even been "smoke
> tested." Please tell me ... Aside from copying bits to the Program Files
> folder, what does it do RIGHT?

Perhaps correct, though my shortcut works. I know they do go through some
fancy hoops to make sure the shortcut points to the correct "blessed"
version of Rev. Perhaps that's the issue. Regarding uninstalling, you are
probably correct, but ever try to uninstall anything from Microsoft, Apple,
Real Audio, Norton or MacAffee. OMG!  And, I think we can give the small
development team at RR a pass on the Vista stuff at this moment. The fact
is, they were the first RAD tool out there with UB support on Macs and very
much expect they will provide the same level of service with Vista.

- Standalones created with 2.7.x are bigger, slower, consume more resources,
> and are highly unpredictable compared to standalones created with 2.6.1.
> Half the time, quitting the standalone leaves the process running in Task
> Manager -- when the exact same stack under 2.6.1 exits cleanly. We've had
> reports of libraries not being included even when explicitly added. And
> Bill
> V's recent post is not the first report of standalones being built
> incorrectly or bugs returning from the dead.

Not my experience. Yes a bit larger, but not noticably slower. There is an
interesting discussion on speed issues over in the MetaCard forum, if you're
interested. I think the bottom line is there's not a huge drop from 2.6.x to
2.7.x. I haven't had any problems with libraries not installing, on Windows
or Macs. Of course I use a 'splash screen' architecture which IMO seems to

- More often than I'd like, quitting Rev 2.7.x itself results in an
> application error upon exit. And that is if you're lucky and the process
> isn't simply "hidden" as it is in standalones that don't quit properly.
> When
> the Windows Error Reporting dialog comes up I click "Send Report" every
> time... do you guys even receive/read those reports? Because I haven't
> seen
> any decrease in their frequency from one release to the next.

We've already gone over this in previous emails. If you have a stack which
exhibits this behavior and you need some help with it, contact me offlist
and I'll take a peek.

- The IDE is noticeably, painfully slow, and suffers from screen refresh
> problems and on-screen corruption. I've had the 2.7.x IDE (and my work
> product) simply disappear more than once. The sluggishness of the current
> script editor is simply unacceptable (as described previously). It makes
> me
> long for the days of editing on a ZX81 in SLOW mode. This is not "software
> at the speed of thought" -- it's software at the speed of "musing."


- Geometry manager still is hit-or-miss. It works until it doesn't... then
> you have to rebuild everything from scratch. One prominent developer told
> me
> he never uses it, because of the peril to his work product. Just when are
> you going to get around to fixing that?

Like many of us hard-core types, I don't use it. I rolled my own called
altLayout Mgr, and it too has holes in it as well...just I know where they
are! Writing a bug-free complete GeoMgr could be one of the holy-grails out
there. It certainly works for smaller projects, but as Xavier and many
others have pointed out, there is a law of diminishing returns as stacks get
more complicated. Many developers, like Richard, prefer hand-coding their
own resizeStack handlers-- it's really not that hard, and the amount of
control you get can't be matched with generic libraries.

- The XML library under 2.7.x seems to consume much more memory and not
> clean up after itself. Stacks that use XML work fine under 2.6.1, but have
> locked up with 2.7.x.

Wouldn't know. I like using Ken Ray's tools for XML parsing- Or for simpler
stuff, some nifty handlers from Jerry Daniels.

- The Internet library has resulted in lockups in stacks that have run
> without incident under 2.6.1.

That is an interesting one. Of all the scripted stuff in Rev, I've found
Dave Cragg's libURL to be of the highest quality. Plus, he's an easy guy to
get in touch with, answer questions almost immediately and provides patches,
fixes and any help he can. Can't imagine a more helpful individual. I use a
bunch of weird libURL stuff (we have our own authentication dll which works
with it) and haven't seen any problems lately.

In fact, the 2.7.x series is so awfully bug-ridden, its most welcome new
> feature is the ability to save in "legacy" format.

Agreed, that feature should have been in the earlier versions. That said, I
did provide a quick plugin to save in legacy format from the very start of
2.7.x, so, it was available.

Yes, Rev, it's really that bad.
> I wrote a long time ago that I planned to purchase every update to the
> product. That's because I genuinely want to see Rev succeed (not to
> mention
> continue to exist/pay the bills). But I have to take it back. No, not this
> time. Not with 2.7.

Good point. Purchasing the update plan does ALSO help Rev succeed. I would
imagine the more revenue Rev receives, the more resources can be allocated
to finding/fixing bugs. If they were only out to 'rip us off', then I can
certainly understand your point of view. But I really believe they do the
absolute best job with their resources as possible.



More information about the use-livecode mailing list