[MC_IDE] Quick Poll
Wilhelm Sanke
sanke at hrz.uni-kassel.de
Wed Mar 30 14:52:39 CDT 2011
Richard wrote:
> On 3/29/11 11:24 AM, Wilhelm Sanke wrote:
> > > Could you possibly point out where we could find this "necessary info"
> > > from Oliver Canyon, if it was available it surely escaped me?.
> This and
> > > the difficulties of Klaus - there are other reasons as I
> understand and
> > > deplore on the side of Klaus - led me to assume that there
> unfortunately
> > > had *not* been sufficient information from the RunRev side to build a
> > > new MC-compatible standalone builder
>
> In all fairness to RunRev, it's not an easy change. And I would even go
> so far as to say it was a useful change, actually necessary as far as
> RevWeb is concerned and also UAC, and also helpful for both RunRev's
> license protection and for the MC IDE, since now the engine does all the
> bit-level stuff (binding the engine, embedding icons, embedding UAC
> info, etc.).
>
> It took a few back-and-forth emails with Oliver to get this down, and a
> fair bit of trial-and-error on my part. Actually, a lot of trial and
> error since any error messages that come back from the engine are rather
> sparse.
>
> It's not a task I'd wish on anyone who has other things to do, but I do
> feel it's fair to say that RunRev, and particularly Kevin, Mark
> Waddingham and Oliver, made themselves available to help with my
> understanding of the initial example that Oliver had sent to Klaus and
> I, and ultimately it was their willingness to help that made the new SB
> possible.
and Klaus wrote:
> I received the neccessary infos from scotland but this is of course
> nothing that should go into a public mailing list, so I did not
> publish this info!
Thanks Richard and Klaus for the feedback, and also to Monte for chiming in.
Richard indeed makes it plausible that Kevin and his team still stick to
their commitment to continue to help to support the MC IDE in its
compatibility with newer engines of Revolution/Livecode.
Though - I say this with a piece of my tongue in cheek - the whole
matter reminds me a bit of the "communication problem" political parties
in Germany recently used as an argument when they had lost elections:
"We stand to our principles and our goals are OK, but unfortunately we
had a communication problem with explaining our goals to the voters."--
Apparently the - somehow privileged - information received from RunRev
was not comprehensive enough to let Richard and Klaus create a new
standalone builder at once. Richard needed several contacts with more
than one person and additionally trial and error processes as he writes.
And we had to wait one and a half year until finally we now got the
prospect to see this new standalone builder soon.
I think such a kind of support from the RunRev side urgently needs to be
improved and accelerated!
There is also the question - having been asked and discussed heatedly on
the RunRev lists time and again - why are things sometimes made so
overly complicated that they affect functionality and user-friendliness
that negatively?
While overall it could be stated that Revolution/Livecode has indeed
improved considerably over time, there are still features that are not
up to par or have even deteriorated, among them the support for the MC
IDE. Aditionally Revolution has had a lot of egregious problem issues
during its development, think of one of the earlier application browsers
that were practically unusable or the Rev standalone builder in 2004,
which needed an hour or more to build standalones from certain types of
stacks.
In my Teststack
<http://www.sanke.org/Software/RevTestStacks.zip>
I had described some of the problems encountered at that time and also
outlined a recipe to fix this particular standalone problem.
At that time - 2004 - RunRev had also given up its principle to allow
the possibility of total customization of the Rev IDE (a principle
introduced and observed by Scott Raney for Metacard) by encrypting the
standalone builder. Fortunately, there occurred a small time window to
look at an inadvertently unencrypted update, which enabled me to make
proposals how to fix the issue.
Shortly after this Monte Goulding was assigned to repair the standalone
builder, which he did with great success - maybe using some of my
recommendations (I do not know) or along his own lines - obvious to his
analytical and practical mind.
Had we had access to the code of Rev standalone builder now, it would
have been much easier for many of the Metacard group members to
understand how the standalone file is being attached to a stack, and
then create our own standalone builder accordingly.
I have never fully understood and accepted the protection of the Rev
Standalone Builder. I know they give reasons pertaining to licensing
procedures, and they want to prevent that someone circumvents the
embedded licensing procedures and builds his own product and then
competes with Revolution, but I believe these fears are unfounded, as
there are surely means to guarantee a proper licensing process without
necessarily encrypting the standalone builder.
Again, had the Rev standalone builder not been protected, its
performance and structure would have been improved by now much more -
and much faster - by interested and competent Revolution and Metacard
users.--
I think, as the RunRev team still upholds a principal support of the MC
IDE (like the German political parties I mentioned above), we should
however appeal to Kevin to improve the support.
One other issue in this context would be to facilitate to embed new
Livecode engines into the MC IDE and give exact directions how to so,
and thus to avoid to force us to quite an amount of trail and error.--
And, would it be possible to get access to the privileged information
Richard and Klaus received for creating the MC standalone builder? I
would really like to know - and I think others, too - how the standalone
file is being attached to a stack. And I assure sincerely that I am not
intending to produce a competing product.
Best regards,
Wilhelm Sanke
More information about the metacard
mailing list