RunRev Script Editor and Linux

Richard Gaskin ambassador at fourthworld.com
Fri Jul 16 09:58:22 EDT 2010


Peter Alcibiades wrote:

> The way to look at this thing is to figure out what Rev is doing differently
> from other apps.

Yes! Thank you for writing that.  It seems self-evident, but is so often 
forgotten: the way to solve any problem is to identify the differences 
between the working and non-working states.  Once you do that the world 
is your oyster.

Although there isn't anything else quite like Rev in this world, there 
are enough other apps that solve similar problems that we can use those 
good examples to help identify what they're doing right, and what can be 
changed in Rev.

The MC IDE may be especially useful here because it's a much simpler 
architecture, and is frequently invaluable in determining whether a 
given problem stems from the IDE or the engine.

This is a good example:

> What exactly is Rev doing with its editor, which is not a terribly
> complicated sort of functionality, which makes this editor, unlike
> any other, slowdown and freeze?

At its core, a script editor in Rev is nothing more than a field to 
display and edit the text, and two lines of code:

    put the script of tObject into fld "editor"

...and:

    set the script of tObject to fld "editor"

But having used such a bare-bones editor myself once, I can tell you 
it's not very productive. ;)

So a good editor adds things, and Rev has added a lot:  custom tabbed 
panels, cached scripts, dynamic colorization, syntax guidance and 
checking, integrated dictionary, and a lot more.  All that stuff adds 
complexity, and in complexity dragons lie.

In fact, as I write this something occurs to me:  Could it be the 
integrated dictionary slowing things down?   We know using the 
dictionary directly is often a bottleneck on Linux, so it may not be 
surprising to find if that's the cause of this issue.

My ROSE editor isn't quite compatible with Rev yet so it's not a good 
alternate for testing, but perhaps you could try the MC IDE for a test 
to see how it holds up.

You can use Jacque's ultra-handy MC Setup util, available in the MC IDE 
group at Yahoo (see "metacard_setup102.zip" in the Files section):
<http://tech.groups.yahoo.com/group/MC_IDE/>

MC is a bit spartan in ways and I'm not recommending it for general use 
(unless you like it, of course).  But it is by far a much simpler code 
base, so if nothing else it may help us pin down the source of this 
script editing issue.


> How exactly has Rev implemented the IDE so that you can't put the property
> inspector on one desktop and the editor on another?

That one I think is an engine issue and not governed by the IDE stacks 
per se.

I verified this hunch using (you guessed it) MC:  moving a window to 
another desktop seems to move it okay at first, but going to that 
desktop puts the window back among the others.

Interestingly, I find that if I move the main IDE toolbar in Rev or MC 
to another desktop, then all windows go to that desktop.

I'm not sure exactly what the rule is, but it would seem that the 
toolbar governs which desktop is in use.

I just ran another test and found something VERY interesting:  if you 
close MC's toolbar you can move windows independently across different 
desktops!  Success!

So now one of us needs to try to pin down exactly what the difference is 
between the working and non-working states here:  is it the order in 
which windows are opened?  Their mode?

If you have time to make a standalone to experiment with this the 
results will likely be invaluable for fixing it.

I generally keep all my Rev windows in one desktop, so this isn't a big 
issue for me, but if you have time to help diagnose this the success I 
found with MC's toolbar closed suggests we might be able to find a 
relatively simple fix for this.



> How is Rev relating to the system print functionality that makes
> revPrintField not work?

What does revPrintField do that isn't correct?
More specifically, how does it differ from "print this card"?


> Where is it getting its font lists from?  Its not
> the same place as every other app gets them.

That's a darn good question, though FWIW if you prowl around various 
discussion boards on the web you'll find Rev isn't alone here; a few 
other programs also display incomplete lists of installed fonts.

I was thinking about this yesterday, and I have a question for you or 
Richmond:

When you set the textfont of a field to a font name not included in 
Rev's fontNames function, does the field use that font?

If so, we may be able to come up with a scripted workaround to replace 
the fontNames function, something like linFontNames which would poke 
around to find what it needs to return a complete list.

Not only would that solve the problem for us, but may also be helpful 
for the Rev engine team to find a good solution.


> Rev's problem is not that it is being installed with deep system
> functionality into a complex multifarious environment, and some of this deep
> functionality is understandably failing to work.  Rev's problem is that in
> very simple functions, not deep at all,  it is not relating to identical and
> unchanging features of the OS functionality in the same way that all the
> other apps do.
>
> As an analogy, it would be like writing your app so its installer failed to
> put a starter icon on the desktop in Windows, and then saying, Oh Well, the
> problem is no app store, people just install whatever they want on Windows,
> so its an unpredictable environment.  Yes, it is, but that is not the
> problem, the problem is how you wrote your installer to do something very
> simple and access very basic functionality.

Here's the big question:  Who among us has the time to turn the Rev zip 
archive for Linux into a Debian package?

Andre? :)


> We need to stop making excuses!

Exactly. Let's instead roll up our sleeves and get this thing rolling.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv



More information about the use-livecode mailing list