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
___________________________________________________________
[email protected] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
