LiveCodeJournal: Can you give us some more details about these features?

Daniels:

Object Browser:

tRev is an object browser by default—when you're not editing a script or if you create a new tab (cmd+n). There are no blank screens, unless, of course, you have no stacks open.

Here you see it browsing all stacks in the Rev IDE. Few developers care about Rev IDE stacks, so, as a rule tRev shows only non-IDE stacks. To toggle back and forth between IDE and non-IDE views, you just shift-click the tab.

When you click on a stack, it's cards show. When you click on a card, it's controls show. When you click on a control, only the titlebar changes—as it does with stacks and cards. You may notice two things: there are numbers to the right of every object name. These are the number of lines in the object's code. Some objects are grayed. These are invisible. These are plain Rev fields, btw, and not datagrids. You'll notice I get the numbers to right justify. This is done by padding the numbers with zeros and then coloring the zeros to match the background or highlight color.

Code Editor:

If you double-click the object name, you'll find yourself looking at the object's code—colorized with links to handlers and special handlers called Raptor handlers which are block comments whose links work as property inspectors. You'll also notice that comments preceded by "--> " become folders in the handler list. If you only have one such comment (or none), tRev gives you a flat handler list. Both flat and folderized handler lists can be sorted or not via the little buttons below the list.

Errors:
When you encounter a compile or execution error, the offending line will highlight and you can then click the button for the error pane to see what went wrong.

Modeless Debugger (Decoder):
Clicking the Decoder button will put tRev into a mode we call "decode mode" where you will be able to see breakpoints that record your code's context (what's in vars, etc.) at that moment in the code's execution. This context is stored in a local data base using our Datababies technology, which is blindingly fast. So you can go back and look at your context at any time. You can also step forward or backward through your breakpoints.

When you set a breakpoint, initially it is in lower case and has a unique record id after it. Once the code executes and the breakpoint picks up data, it changes to upper case as you see above. The big arrows, when clicked, take you from one tRev breakpoint to another in the Decoder. You can also do all this with arrow keys: shift+arrow takes you to prev or next breakpoint; arrow by itself just takes you next line.

You can double-click a line to set a breakpoint or type return or click Set Break button at lower right. Same goes for clearing a breakpoint. This is MODELESS debugging. In truth, there is no such thing as a debugger. The developer is the debugger. Calling it a debugger not only sets unrealistic expectations, but is not accurate. We let the developer de-construct his/her code, so that they can fix (or debug) it.

This scheme of debugging (which we will now call decoding), cannot trip up Revolution. It is both modeless and asynchronous. The Rev IDE encounters tRev breakpoints and just fires off a message to tRev via sockets with some context info and then continues to execute. Rev's modal debugger can easily lock up, gets confused with step-overs/throughs, etc. When Rev debugger encounters its breakpoints, it must stop all execution and then use "debugDo" to evaluate a statement. In this situation, it is very easy for Revolution to go into endless recursion. It is a flawed approach.

tRev, on the other hand, does almost everything (script editing, property inspection) separate, in its own app space and does not interfere with Revolution. The decoder never goes into recursion as noted above. As a result, getting tRev is like getting a brand new Revolution—one that will not crash due to debugging, compile errors or execution errors. Those three things are what makes developers tear out their hair with Rev 3.5. You will not find that happening with tRev and Rev together. Rev becomes much healthier through its association with tRev.

It should be noted that the Decode mode is global to tRev, not just the current tab or object. As such, links to handlers and property inspection still works while in Decoder. This makes jumping to a handler being called (in order set a breakpoint) very easy. The Raptor handlers also tell you the properties of your object without any inspectin whatsoever.

Documentation:

tRev also has a Docs pane that gives very terse definitions for Revolution tokens when you click on them. Here's the definition of "mouseDown":

Behaviors:
tRev also has excellent support for behaviors, or parentscripts. When you are editing the script of an object that has a parentscript, you'll see a little link to the left of the Compile Me button. Clicking on this link will take you to the script of the object that is the parentscript of the current edited object.

LiveCodeJournal: Can you share some tips on some of the nifty scripting you've done with tRev?  For example, how do you do your hover editing?  Since Rev doesn't send mouseWithin unless it's explicitly handled, do you use polling?

Daniels: There is no nifty scripting in tRev. There is only a nifty design. If the design is good, you don't need nifty scripting. For example, the architecture for inter-application communication between tRev and Rev is very nifty. It's called Stateless Double Agency (SDA). But the code that does it is dirt simple—beginner stuff. 

SDA architecture:

The code for an agent looks like this:

The environment for creating a build of tRev or updating any one of it's 25 components, looks like this:

About hover-editing:

We even have folks who are brand new to Revolution who went straight to tRev. They made the decision by design alone. If you had a choice and you were a new user, which would you use:
This:

or this:

There are some specialized things that GLX2 does that are very handy. But tRev does more with less and has its independence from the IDE. And look at those screens. Only the important things appear on its single window. And of those, only the tab, handler list and script fields come forward. It was made with as few features and as little code as possible.
tRev also updates without your having to restart it or Rev. It uses lots of small components. My idle handler also checks my server for new components and puts an Update Available link in the lower left of the editor window. You can also check manually for update via Help menu's Check for Updates.

LiveCodeJournal: Now that tRev is out, what's the future for GLX?  Anything about a GLX3 you can share?

Daniels: No GLX3. No more IDE for me. I like living outside the IDE. I will be focusing on a product that builds internet apps using a lot of tRev technology, our Datababies stuff and the CGI work I've been doing.

LiveCodeJournal: At some of the Rev conferences you've done some well-received sessions on printing, which is often a difficult area for new scripters.  What advice can you share for folks getting started with printing in Rev?

Daniels: Avoid it, if you can! I would say it's mostly a trial and error process. As with all coding, if you have a strong conceptual model, then the job becomes easier. My conceptual model begins with sketches on paper. Not unlike the SDA diagram. I might do this for a week in the background while I'm coding something else. Then I name everything. Names are the single most important piece of the coding puzzle. If you're good at naming variables, you'll do fine as a coder. My names support my conceptual model so that when I am coding, I don't get lost in the task and can keep things simple—and supportable.
My failings as a coder come when I have let clients or customers shoot themselves in the foot with crazy request to which I accede. Too often people are solving a problem that is not worth solving because they are too complacent to really think through the problem. Time spent thinking and designing generally offset hours of coding and re-coding.
Here's a good example: in tRev I save information about each object that it edits. Mostly it's scroll position and the selectedchunk. This is so that when you edit an object a week later, you are right where you left off. Nice feature, but how to save this data? I use Datababies to create a record for each object. What should I use for a record id? At first I thought I had to create one. Then I remembered that Revolution has a unique id for every object stored as a custom property. I use that. Why re-invent?

LiveCodeJournal: Rev 4.0's new web plugin seems to be getting a lot of attention, even at this early alpha stage.  Have you used it much?  What do you like most about it?

Daniels: I have tried it repeatedly, but I'm not much of a web guy. I'm a desktop app guy who does n-tier internet apps and development tools. Not much attraction there for me. I am interested in it on behalf of several of the folks that I mentor through our Rev Mentor program. I think once the bugs get worked out, it will be great. I will definitely use it.

LiveCodeJournal: With your focus on n-tier architectures I'll bet you write a lot of Rev-based CGIs.  What are you looking forward to most about the new server-side engine?
Daniels: Debugging tools for non-web CGIs would be most interesting to me. I love On-Rev. I use it in several projects. I was able to do spotlight-style searches using data on On-Rev and a Rev CGI. I used our Datababies for the database layer. One of these days, we're going to release Datababies. It's an entire interview, in and of itself.

LiveCodeJournal: While some folks think of you as That Rev Guy, I've known you since back when Allegiant owned SuperCard, and you've been in the biz even longer than that. Can you tell us a bit about the history of Daniels and Mara?  How did you start, and what sort of projects have you done over the years?

Daniels: We (Mary Jane Mara, my wife, and I) started Daniels & Mara when we moved to Austin in 1987. We had other business ventures, commercial software and consulting work before that, but Daniels & Mara began at that time and place. Our biggest projects have been front-ends to mammoth back-ends. We've done them for GE Aerospace, Apple, Maritz, University of Texas...blah, blah, blah. We are much more focused on strategic consulting and mentoring, these days when it comes to project work. When it comes to product, we provide design, architecture support at a hefty fee. We really enjoy building and promoting our own software.

LiveCodeJournal: This is ancient history, but it was an intriguing notion I've been meaning to ask you about:  many years ago, back when CompileIt! was still a quite popular tool for making externals, you had envisioned a development system built around externals, going far beyond HyperCard into a more open, deeper programming experience.  What inspired that, and how far did you get with implementing it?

Daniels: HPW, the Hyper Programmer's Workshop was the product. We licensed it for very high dollars to large corporations who where doing HyperCard projects, particularly front-ends to mainframes. Big bucks. I wrote a pre-compiler for that and worked with Bill Woodruff who wrote a nice, small app that did nothing but run XCMDs. It also handled text call-backs and all the HyperCard toolbox calls. It was unbelievably fast. I want to get back into the app-building business again, soon. You might watch for that in the next year.

LiveCodeJournal: You've been using Rev since very early on, perhaps v1.0, yes?  How did you first come across Rev?

Daniels: I was aware of MetaCard from its first days, as a journalist and as a HyperCard developer. I was a consulting manager for a large regional company when I needed to create some prototypes for my teams of programmers. I bought a license to MetaCard in 2000 to do the work. I loved it and heard about Revolution a year or so later. I bought that and like it, too. I was a 1.0 user of Rev, yes. Not sure what version of MC I started with.

LiveCodeJournal: With all the time you spend with Revolution it's clear you have a passion for it.  Yet those of us who make dev tools are picky folks, and with the range of tools you've produced perhaps you're pickier than most. :)  If you woke up tomorrow and found yourself in charge of designing the Rev IDE, what would you change first?
Daniels: I would never do the Rev IDE. It's a road without an end and littered with thorns. It offers to do too much and because of this, it has a low market value. I would create a more specialized toolkit that would be worth more money to its users. Tools like Revolution are traditionally subsidized by a big company. Apple, Microsoft, Sun...these guys subsidize dev toolkits. So the price of Rev is artificially low. The price of my re-write of Rev would be low. So I have no thoughts of re-writing it.

LiveCodeJournal: In addition to Rev, what other tools and languages are you using these days, and what do you like about them?

Daniels: Revolution work keeps me very busy these days, so I haven't ventured outside of it much in the last years. I did work in Forth, Pascal, Basic, Smalltalk and C. Never did much C++. Do a little Javascript and have managed lots of Java projects where I had to help debug code, but that was all in the late 90's and early 2000's.

LiveCodeJournal: What features have you seen in other languages that you'd like to se incorporated into RevTalk?

Daniels: I would like to see more HyperTalk in Revolution. I feel the Rev dev team's penchant for C++ creeping in.

LiveCodeJournal: What are your top three feature requests in the Rev Quality Control Center?

Daniels: I actually have none. I'm too lazy to bother, I guess. I feel certain that the force of my will can be felt from here to Edinburgh. (humor)

LiveCodeJournal: You certainly have the ability to publish your development tool products yourself, yet you're publishing them through RevSelect.  What are the advantages of RevSelect for dev tool authors, and how has your experience been with the program?

Daniels: RevSelect more than doubles our sales of tools. No question about it. And I do enjoy working with Bill, Heather, Robin and Kevin. The financial arrangement gives Runtime Revolution incentives to work with me. Kevin has been really great. He's a good partner. His development team lacks even the most basic communications skills, however. So we were caught flat-footed with the 3.5 debugger re-architecting that broke everything. To be fair, I'm not sure the Rev dev team even knew enough about it to communicate with us about it.
As I have said on the email list, Kevin has a very tough job and we get a great value for our money with Revolution. Huge value. No complaints from me about that. In order to deliver their product, corners have to be cut. I can live with that, even if it breaks my debugger. Something good came out of that, though, didn't it? tRev.

LiveCodeJournal: Everyone knows you're a geek, but I've known you long enough to glimpse a very multi-faceted life beyond your programming work.  What can you tell us about your non-geek life in terms of your hobbies and other interests?  What makes for a great day away from the computer for Jerry Daniels?

Daniels: What do I do when I'm not coding/designing/mentoring? I am very involved with my family. MJ and I are lucky in that our adult, married children live very nearby. We're all here in Southwest Austin area. We're very ready for grandchildren. We read alot. My daughter and I are forming a reading club. We don't watch TV. We rent DVDs from NetFlix when we aren't reading or just talking with each other.
We also have a large extended family that includes people from all over the world. That's because a large part of our extended family is American Indian—Lakota. We work together on an annual family pow-wow held in Potato Creek, South Dakota, and a yearly Sun Dance held in Crockett, Texas. We help people with vision quests, sweat lodges, namings, wiping of the tears, healings...stuff like that. I really love to sing Lakota songs with my kola (friends). It's funny, but people hear this and they say: "Wow, cool. Do you have any peyote?" Traditional Lakota ceremony involves the use of a cannunpa (ceremonial pipe) and precludes the use of alcohol and recreational chemicals or herbs or fungi. So, no peyote. Been clean since '71.