Alain Farmer wrote:
Hello Richard and y'all,
... so it would seem there would be room
for an open source alternative -- maybe.
Hear! Hear! ;-))
We are on the same wavelength in this regard. :)
As you all know, I'm making steady progress towards
this goal, e.g. an open-source multi-platform xCard
that takes advantage of all the relevant Web [2.0]
standards, and so on. Yup! I speak of XulCard. :-)
It sounds like maybe we're on different wavelengths, though I admire
your work on XulCard and wish you the best.
I was referring to Rev-based IDEs, like MC. My work involves mostly
desktop apps, so attempting to rework it all into a browser-based object
model seems difficult for many projects.
In the long run I see PythonCard as the logical open source alternative
for desktop RAD, but given its current state it looks like we have a few
good years left focusing on Rev. And as long as Rev maintains a good
price/productivity ratio, PythonCard may coexist with Rev as happily as
Linux with OS X. A little healthy competition keeps everyone performing
their best.
In the here and now, MC is losing users to Rev. Since the Rev IDE comes
free with the package when you license the engine, there's certainly
nothing wrong with that to the degree people are able to maintain, or
even enhance, their productivity.
But the growing interest in Constellation/Galaxy suggests the Rev
community may remain as hungry for others development styles as they
were when Rev itself was born.
Currently, MC appeals only the those who were using it before Rev was
born. It's not simple to set up, and has relatively few features. Of
course those of us who grew up with it like it that way, and I continue
to support its core mandate of minimal change to maintain its simplicity
and freedom.
But on balance, I have to admit that from Day 2 with MC I've been
augmenting it with my own tools. As much as I like being close to the
engine (i.e., close to my user's runtime experience), MC makes very few
tasks particularly convenient, and a lot of things I do commonly aren't
supported in the MC GUI at all (like editing frontScript, backScripts,
and libraries), requiring trips to the Message Box if it weren't for my
tools.
Over the eight years I've been working with MC I've amassed a lot of
tools. Many were one-offs for specialized tasks that aren't worth
sharing, and some of the rest are available for free in my devolution
toolkit. But there's a lot more. A LOT more. It's been difficult
justifying the time to clean them up from tool form to product form,
but they're coming along as time goes by.
I've started forking the MC IDE so I can better integrate these tools
into a cohesive environment. Many of these will still work
independently of any IDE just as the ones in devolution do now, but
sometimes I need an even less intrusive IDE than MC.
For example, I spend a lot of time making drawing apps, and neither MC
nor Rev passes messages well enough to make such work convenient, so
I've already begun taking steps to get MC out of the way, making an
environment that is even closer to the engine while offering many more
conveniences.
In addition to the sort of layout and construction tasks the MC and Rev
IDEs have traditionally focused on, my forked IDE (working name M2)
will also include support for the superset of tasks ranging from project
management to product management. These new areas of support are
largely driven by RIP properties (see
http://groups.yahoo.com/group/revInterop/), so they should be fully
interoperable with any other tools which also follow those open
recommendations.
So if any of you here have opinions about new ways we might expand MC
but have been reluctant to recommend them for that IDE and don't want to
put in the effort to make your own forked project, maybe there's a way
we can divvy up work on this skunkworks version as a playground for
these ideas.
--
Richard Gaskin
Managing Editor, revJournal
___
Rev tips, tutorials and more: http://www.revJournal.com
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
