RunRev Script Editor and Linux

[Richard Gaskin]

Peter Alcibiades wrote:

> I'm not (publicly at least) telling Kevin how to run his business.  I am
> saying to him, I bought it, and I want it to work.  That is an entirely
> legitimate point to make, first privately, then publicly if that has no
> results.

Rev is what it is.  Like all software it has bugs, and most of those 
bugs are not specific to Linux.  In fact, out of 8000+ submissions to 
the RCQQ, only 153 of them turn up in searches for "Linux", and many of 
those are not specific to Linux.  The number of bugs for Mac and Windows 
far exceed the number for Linux.

If Rev doesn't do what you need you may be able to get a refund. 
Whether Rev provides what you're looking for, the world is as full of 
alternatives as it ever was.  There's no need to stay with a tool you 
don't like using.


> Take RealBasic.  You download a package.  From memory, they have deb, rpm
> and universal binary versions.  I picked the universal binary, put it in my
> home directory, fired it up, and it runs.  If its correctly written why
> wouldn't it?  If RealBasic can do it, Rev can do it.

You may want to check your premise.  I stay abreast of my development 
options and so I read the RB list and forum from time to time as I do 
with AIR, PythonCard, and others, so I'm aware of some of the issues RB 
customers have experienced on Linux.

Here are two searches I did this morning:
<http://forums.realsoftware.com/search.php?keywords=linux+printing&terms=all>
<http://forums.realsoftware.com/search.php?keywords=linux>

The noteworthy posts from RB users complaining about their Linux engine 
are too numerous to include here, but I've included a few highlights 
below to clarify the core issue here:  making rich multi-platform 
software of the scope of Rev and RB is difficult work, and not 
everything works out of the box.

    "I just installed RB for Linux, and in the IDE am puzzled by
     the fact that page setup and print do not seem to do anything
     at all."

    "Finally, I agree that printing from RB can be challenging
     regardless of which platform you're on but specifically on LINUX."

    "I can print to my networked printer from that Ubuntu 9.1 virtual
     machine in other applications, but RB program no."

    "I just recently install Ubuntu 9.10 and RB-10.1 only to find
     that the "OpenPrinterDialog" is not supported but nothing in the
     LR mentioned "OpenPrinter()" so I gave that a try and it did not
     work. Both return 'nil' Is there no way that printing can be
     accomplished with RB-Linux?"

    "OpenPrinter() and OpenPrinterDialog() always return NIL, at least
     on my machines.  So I'm guessing that RB on Linux ain't gonna
     print directly, no how, no way."

    "The printersetup dialog is documented not to work in Linux.
     (Its been a while outstanding as an issue…)"

    "I can´t use the new report writer on Linux, too many bugs,
     I´ve tried with Turboreports and Einhugur reports, but both
     fails with use a higuer resolution than 72 dpi. Is Anybody
     printing reports on Linux?, without printing on Linux Realbasic
     isn´t a real multiplatform solution."

    "Just found out that even printing Landscape is not possible, and
     also that the default printer is not detected correctly. All apps
     in Linux can detect my Brother HL2035 as the default printer,
     but not RB."

    "Well it seems I was right. RS does not have any priority on
     improving printer support for Linux. I asked them about it and
     this is what they said:  'Hi Frank,  These are limitations of all
     versions on Linux. Sorry about this. Improving printing on Linux
     is on our to do list for a future release.'"

    "RB is fairly clunky on Linux, as compared to the RB experience
     on Windows or Mac. (Try opening the online Language Reference
     in Windows/Mac, then in Linux. Yep, the LR is missing ALL its CSS
     & graphics. Also IMHO, this is because of the multitude of Linux
     distros which the kind folks at RS are going out of their way to
     support. I suspect printing has a similar thing: it's probably
     being 'held back' so it can be used on most, if not all, Linux
     distros."

    "Hope nobody is on Linux, because they can't have a PageSetup
     dialogue, so their printing is screwed anyway... but that's
     normal, right? (No, it isn't, it's only normal for RB apps)."

    "Conclusion: RB's print support for Linux is poor at best, and to
     be honest I am having a hard time to believe that it cannot be
     improved."

    "Tell Real to fix many of the numerous RBlinux printing  bugs
     that have been around for years."

    "Every time, I have specifically asked that anyone who has ever
     seen text printed properly from Linux contact me and so far no
     one has."

    "Printing, simply just does not work. It does not report an
     on-screen error"

    "RB seems to believe that bugs are natural. They sold me a defective
     product, then repair the defect, but never inform or provide the
     registered users with the bug fix. So, unless you agree to feed
     them money, you never really have any assurance that what you
     bought will ever work the way they advertised."

    "I love RB, don't get me wrong, but this is making me wonder about
     what else they're just ignoring. I can't build an app and claim
     that it works on three platforms, then have all of our customers
     raising immortal hell because it doesn't. "

    "So how about it, REAL? I've already advertised to my customers
     that there's going to be a Linux version of our app, but there's
     absolutely NO way any of my customers will accept the current
     print quality from RB Linux and compiled apps."

    "Then I find that the GUI is unreadable on Linux"

    "The variations in behavior are often attributable to different
     versions of Linux.  If you try 9.04 and then 9.10 you'll find
     many differences simply because of the differences in the Linux
     version. It's equally frustrating for us to try and deal with
     as if we fix it for one versions it's often broken in another."

Sound familiar? :)  (Imagine how much louder that noise would be if RB 
had a publicly-accessible bug database.)

Both Rev and RB have issues with Linux (well, all platforms really), and 
both sets of customers have been waiting a long time for fixes on some 
of them, including printing which has been noted here many times.

Of course this is not optimal, and in each community there are many who 
are working with the vendor in productive ways to address these as 
quickly as possible within the ordinary business constraints that drive 
any vendor's priorities.

Even with the comments above and the others I've read there, RB seems 
like a fine tool well worth considering if you have a project where it 
will do what Rev won't.  Geoff Perlman and his team have done a good job 
enhancing the product through the years, and I disagree with the posters 
quoted above who suggest otherwise.  Like Kevin, Mr. Perlman seems an 
earnest person doing the best he can in balancing the various priorities 
needed to fulfill the challenging mission his company set out to accomplish.


> It is not about whether Linux is suitable for the desktop.

Agreed.  Pierre walks on water in my book and I'm usually quick to defer 
to his broad experience and excellent judgment, but on this he and I 
have different opinions.

I wouldn't suggest Linux is for everyone, any more than I'd tell a Mac 
user to use Windows or a Windows user to use Mac.  People choose what 
they use for a good many reasons, and I don't think any single OS is the 
ultimate answer for everyone.

But I'm using Ubuntu more and more every week, and having a good time 
with it.  Others are as well.  It's good today, and with its strong 
community led by Shuttleworth's bold stewardship it's on it's way to 
becoming truly great.



> Should we use workarounds?
>
> In a way yes, that was a route I took in the beginning.  The editor crashes,
> use Geany.  The fonts don't show, use the few ones that do.  Printing?  Use
> awk to reformat, or output to a handwritten .rtf file and pipe it into
> OpenOffice.  Of course, all this is the reverse of write once and run
> everywhere, but still.  The screen?  Reset the resolution every time you use
> Rev?  This is where I draw the line.  No, I'm not doing that.  As a
> customer, I won't be treated like this by any company.

Workaround can be useful for getting an immediate solution, which is why 
I like to try to find them where practical.  But it's still worth 
pursuing solutions directly in the engine or IDE where possible.

The Rev team is investing a disproportionately favorable percentage of 
resources into their Linux engine, and I see no sign of this slowing 
down.  Their goal is the same as ours:  the best engine possible on all 
platforms.

Here your focus is especially helpful in making this happen:

> What should we do for Rev?  It seems to me that the best thing we could do
> for them is, stop making excuses for them.  Python, RealBasic, PyQT, PyGTK,
> Perl, Lua.... they all run on Linux without all this stuff.  There is no
> reason Rev cannot too.  It must, if its to have a future on the platform.

Agreed:  simply excusing bugs without any effort to address them would 
be counter-productive.  Fortunately, I've not seen anyone here doing that.

Solving any problem of any kind requires identifying the differences 
between the working and non-working states.  In software, this process 
begins with recipes for reproducing the problem.

Once the source of a problem has been isolated, the next step is to 
allocate the resources to fix it.  Rev is already putting in more 
resources to their Linux engine than direct ROI warrants, so while not 
everything will be fixed as quickly as we might prefer we can at least 
rest assured that issues for which the cause has been identified will be 
addressed as quickly as budget permits.

We can reduce the cost of fixing bugs - and thereby speed up the rate at 
which they're fixed - by finding relevant APIs and other useful 
information to help point the team to a solution.

Years ago I found an issue with the Mac engine for which Scott Raney was 
having a tough time finding the API to address, so I spent some time 
with Apple's API docs and found the call he needed, emailed it to him, 
and the issue was resolved in the next build a few days later.

Those who use Linux are ostensibly more motivated for this sort of 
community involvement than others since they've chosen an OS built 
around that sort of thing.

So even though Rev is closed-source, there are still opportunities for 
those of us in the community to work with the team in a manner similar 
to an open source process.

Whether it's scripting fixes in the IDE or finding APIs for GTK, there 
are ways to contribute for those in a position to do so.

I've already demonstrated my willingness to dive in and help with 
solutions, and will continue doing so:

For Linux issues I'll do what I can to try to help find reproducible 
recipes, and time permitting will even look into scripting fixes if needed.

I would encourage any interested Rev developers to consider such 
involvement to the degree it benefits their work.  I have a lot riding 
on Rev and an increasing commitment to Ubuntu, so I'm quite motivated to 
help when I can.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com