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