Q: Does tRev run on Windows XP? If not, why?
A: No, it does not. But some people try to run it on XP in spite of that fact. What can I say? It's a compelling product. There are very real complications involved in getting the Rev IDE to let tRev relaunch it. I am continually trying to work out the kinks and get a version that does well on XP. Until then, I'd rather give up that part of the market than put out crap.
Q: I hear there is a yearly license to tRev. Does it stop working after a year?
A: The yearly fees are for the nearly non-stop upgrades. If you do not renew, it does not stop working unless Revolution changes so much that it will not run. The Revolution language and Rev IDE change a lot and the OS's change a lot. It is a continual job keeping tRev up-to-date. tRev is updated every week with enhancements, new features and optimizations...sometimes more often. It is continually improving and keeping up with Revolution and two of the platforms it runs on: Mac OS X and Windows Vista/7.
If you look at the bottom left of the tRev editor, you will see your name as the owner of this license to tRev. I do this to keep thievery to an acceptable minimum.
When you are within 60 days of expiring, your expiration date and a link will appear to click and renew. When within 30 days of expiration, the date will turn yellow. When 15 days from expiration, it will turn red. There is a convenient link to click so you can quickly renew on our secure PayPal page. Renewals add to the existing license end-date, btw.
Also, it is worth noting that the market for Revolution add-ons is VERY small. The fees we charge don't really cover the time being devoted to the product from our side. It is much more a labor of love than anything. On the upside, I get to use a really great script editor on my other work!
Q: Since Rev already has a script editor, why should we consider tRev?
A: The answer is in tRev's about box:
Q: Can you give us some more details about these features?
A: I'll break up my answer into sections with screenshots.
Object Browser:
tRev is an object browser by default. When you're not editing any objects, or when you create a new tab (cmd+n), you're looking at the Object Browser. There are no blank screens, unless, of course, you have no stacks open. Then you see blank columns in the browser.
Here you see tRev object browser showing all stacks in the Rev IDE. Few developers care about Rev IDE stacks, therefore, 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.
In the browser, 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.
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. If you double-click an object with the shift key down, you'll find yourself in Revolution looking the object's property inspector. Typing return/enter or clicking the Edit Object button at bottom right also edits the selected object.
You'll also notice that comments in the code 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.
You can also use tRev's no-click inspection (cmd+e while pointer is over an object) and option key inspector (detailed later) to open the script of any object. Cmd+e works in Rev or tRev. In Rev you can use any native form of inspection you like as well—like right-clicking on an object with the pointer tool and choosing edit script.
As you can see, we try to make it really easy to edit a script. If you want to edit the script of the owner of an object beneath the pointer, cmd+d will do it. If you hold down shift while doing any of the above, a Rev property inspector for the object opens.
We've got a great video that illustrates inspection, editing, etc. Pretty funny opening, too. You should
click here to watch
tRev - The Movie.
There's a
three-minute video on the Raptor technology used for property inspection in
tRev as well.
Errors:
When you encounter a compile or execution error, the offending line will highlight, and the error pane automatically opens so you can see what went wrong. After you correct the error and compile, the error pane indicates there was no compile error and automatically closes after a second.
Modeless Debugger (Decoder):
Clicking the Decoder button will put tRev into a mode called "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 g
o 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 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, when you buy tRev it's almost like getting a brand new Revolution thrown in—one that will not crash due to debugging, compile errors or execution errors. Those three things are what make 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 function while Decoding. Links make 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 inspection whatsoever. Very handy, that.
Definitions:
tRev also has a Definitions pane that gives full definitions for Revolution tokens instantly when you click on them. Here's the definition of the decorations property:
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.
Q: 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?
A: 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:
Nifty.
About hover-editing:
We have implemented no-click inspection (which you call hover editing) using an idle handler in tRev. Because the app is so simple with no IDE to contend with, it's not a problem. This is the first time I've had the luxury of an idle handler. Something like this is unheard of in the IDE—links would stop working, for instance.
Because of this little idle handler, we are able to sense when the user has the option key down and then put
tRev into a transparent state where the user can inspect objects "behind"
tRev in the Rev environs. Furthermore, we are able to let the user press the command key to add the inspected object's code as a tab to
tRev, etc. This feature is show in
tRev - The Movie and is quite compelling to watch. (Take your meds before watching, we don't want any heart attacks!)
Q: How did you arrive at the decision to make tRev a separate process, rather than simply trap the editScript message within Rev?
A: When Rev 3.5 came out and it broke GLX2's debugger and it's own. Mark Wieder and I worked for a few weeks trying to get the milk back into the bottle with very limited success. So, I put my head down and, using code from two other apps, I wrote a working version of tRev in a couple weeks. It went on sale as a pre-release product. It sold quickly because it solved this problem of IDE contention and recursion. We had no means of providing debug support for over a month, and STILL people bought it. Rev 3.5 users already had no debugging. Might as well code in a friendly environment, right?
We even have folks who are brand new to Revolution who went straight to tRev. They made the decision by UI/design alone. If you had a choice and you were a new user, which would you use?
This:
or this:
Q: How does tRev differ from GLX2?
A: GLX2 suffers from living in the Rev IDE. I think I've made it clear how this impacts performance and stability. GLX2 also has too many features for my taste. I gave into user demand and added too many features and preferences. This is my biggest failing as a developer. I turned 60 this year and resolved to hold the line on values I hold dear.
tRev and
Twhen (a Twitter app we developed) are good examples work where I held the line.
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.
tRev was made with as few features and as little code as possible. And with emphasis on what is important to Revolution coders, not C++ coders. tRev is not derivative of Microsoft Visual Studio. Microsoft does mediocre design. The Revolution development team is foolish to emulate MS products and Visual Studio in particular. RevTalk is not C#, C++ or the like. It's RevTalk. And we're RevTalk coders who have our own needs, different from those in other languages. Don't get me started.
I should also mention that tRev updates without your having to restart it or Rev. It uses lots of small components. The idle handler I mentioned before also checks our server for new components and puts an Update Available link in the lower left of the editor window. You can also check manually for updates via Help menu's Check for Updates.
Q: Why is it called tRev?
A: The t=terse; Rev=Revolution.
Q: I know you are an avid Mac user. How do you use OS X's Spaces with tRev and Rev?
A: One picture is worth a thousand words...
You should click below to...
Comments [0]