So these days the main question is (at least for me) : is it worth adding about 1,2 Mb (the Transcript engine) to a standalone, just to handle mouse events ? IOW, is it worth keeping Rev as the central dev. tool for an app, and why not used C librairies instead, and code the whole thing in C ?
Trivializing what the engine delivers as "just to handle mouse events" seems unfair, overlooking the majority of what it does.
Exercise for the reader:
1. Boot your favorite C compiler and make button to select a folder, filter out every file in that folder that isn't a Qucktime file, and then display those QT file names in a scrolling list and have them play when clicked on.
2. Then do that in Transcript.
I'd wager you'd save at least two orders of magnitude of your time doing it in Transcript over your C version, with no perceived difference in runtime performance.
3. Then make another version for another operating system -- the benefits multiply.
:)
Sure, there are a good many specialized, computationally-intensive tasks for which Transcript is not ideal, like modifying large binary data sets such as audio files. For such vertical needs an externals API is provided, so you can use Rev to handle the other 90% of your application and spend your time on the things unique to your application.
Take a skim through the Transcript Dictionary and in addition to mouse events you'll find:
- Extensive file I/O with binary and text modes, overwriting or appending, and automatic conversion of line-endings to and from platform-specific formats
- Windows Registry manipulation
- Mac AppleScript support
- Mac resource fork manipulation
- Built-in gzip compression and decompresion
- Built-in Base64 and MD5
- Image import, export, scaling, cropping, and rotation in most popular formats, with options for controlling image compression format and quality
- Automatic appearance changes for platforms (even better in v2.2; rather beautiful in the new version)
- Robust omni-platform drag-and-drop support
- Automatic menu initialization and event handling, with automatic changes in menu item placement appropriate to each target platform
- Robust QuickTime playback support, all the way down to QTVR node handling
- Audio recording and playback, with control over options for source, codec, and quality settings
- Automatic conversion of a useful subset of HTML and RTF formats for styled text manipulation, import, and export
- Command-line access
- Ability to launch external applications and other processes
- Built-in socket support, with library for handling FTP and HTTP both synchronously and asynchronously -- with many operations just one-liners
- One-line DNS lookups
- One-line access to OS file, folder, and color selector dialogs
- Robust and efficient hierarchically-structured arbitrary data storage of both text and binary data in custom property sets
- XML parsing
- Text searching and substring manipulation
- Built-in color table selector objects and eye-dropper tool
- Automatic layout printing, and library for automatic paginated text printing with header and footer
- One-line alias/shortcut creation
- Simple, robust, and flexible date and time manipulation, with options for localized date formats, month names, etc.
- Robust omni-platform vector objects tools, with arrow heads and markers provided automatically for easy chart-making and more
- Robust omni-platform paint tools, with magnify and more
- Built-in transition effects, and flexible access to QT's transition effects
- Animation commands
- Automatic memory management, going far beyond mere garbage collection
- And more....
Most of these are available with equal ease on all supported platforms, a significant feat in itself.
All this for just 2MBs in a single, self-contained executable file with no army of DLLs strewn all over the hard drive?
Seems like a bargain to me.
Sure, there is no button in the Rev IDE named "Design and Create Application", so I still need to roll up my sleeves and cut some code.
But it's a nearly indescribably joy for me to focus on the people side of software design, leaving the bit-counting for the VM, so I'm happy for the relatively tiny fraction of my apps that I need to code myself.
But really, for the last 12 or 18 months, I got the feeling that the market of multimedia developpement (and mostly the requests from
> clients for much more sophisticated functions) has evolved in huge > proportions...
In the same way, my own projects (for personal needs) can't be built anymore with Rev only...
That can happen, from time to time you may need things that are best done in C. In many cases the optimal use of one's time will be letting Rev handle the UI, file I/O, and other things it does well and easily, and focus your efforts on the components unique to your application.
And therefore I'm wondering whether Rev has (or can) evolved in the same proportions... Could it be that a peak could be reached (in the number of built-in features that could be added to the engine) in a
> more or less near future, and that we'd witness constant evolution > in the market (and clients') needs, while we would be able to satisfy > less and less requests with Rev alone ?
The biggest shift I've seen in the market in recent years is toward Internet-savvy applications, at which Rev excels with nearly unequaled grace.
This month's example: I'm working on an app for a client that needs to allow a team of 20 medical professionals to edit multimedia content from three continents. The system inolves both client and server components, with an administration tool for the project managers to create and modify user accounts, review status and changes, etc. The client needs to run on both Win 2K, XP and OS X, while the server is running Linux.
Given the highly specialized audience, the UI had to be ultra-simple; no off-the-shelf solution like WebDAV would have been unacceptable.
Moreover, the nature of the content editing tasks themselves needs to support specific activities far beyond the scope of WebDAV, and be integrated into a change-tracking system that allows the project managers to identify and review changes easily (including a markup mode that shows text revisions with strikethroughs and color to make deleted and added content readily identified at a glace).
Given the multi-platform nature of the system C would have been much more expensive than Java, and even crafting such a system in Java would have been cost-prohibitive. While the product we're working on has a proven track record and is quite profitable, the additional time needed to support a Java-based workflow would have eaten at least two years' gross margins, possibly more, requiring outside investment, killing any amibitions for expanded marketing activities, and radically slowing time-to-market.
Using Rev the entire system is funded out of existing sales, with the company remaining in the black throughout the development of this new system.
That's the sort of value proposition inherent in the Rev workflow that I just don't see matched with other methods. And I see it again and again with every product I work on.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
