> I once considered writing a Rev plugin called GhostCard, which
> would emulate
> the UI of the dead HyperCard:
>
> When activated, the Rev IDE is suspended and replaced with a
> black-and-white
> UI that emulates the Hypercard expoerience. You could only work with one
> image, only select on
Ben Rubinstein wrote:
> Maybe that is the way forward for those who will want to continue to upgrade
> to new engines etc, benefit from the additional libraries, but use their own
> or the "classic" MetaCard UI. It might even be possible to formalise this
> in a future version of Rev - eg have pr
Not that I'm here to speak for RunRev or anything (and for all I know
those
folks may know of a reason why this suggestion is a very bad idea);
but if
you're interested in things like the database support, but find the
interface too rcih/in your face, have you tried the "Suspend
Development
Tool
on 7/21/03 3:10 PM, Simon lord wrote
> Maybe Kevin will add a pref dialog that allows us to decide what
> palettes and menus we want to see in our work environment. That would
> help considerably and I don't see it as being that difficult to provide.
[...snip...]
> On Monday, July 21, 2003, at 09
Agreed. I tried to give Rev an honest chance this weekend and got
totally frustrated with all the palettes. I was genuinely happy to see
support for MySQL and other items I need but the interface simply
turned me off and I had to use MC in the end. It's not that I didn't
understand the palet
On Friday, July 11, 2003, at 11:42 AM, Richard Gaskin wrote:
So putting it just as bluntly, that there is a perception of MC's value is
reason enough. If that perception changes over time the MC engine will
whither away naturally. There should be no need to force change, and doing
so would not
I have a library of custom handlers that I load at startup in both
MC and Rev. One of my handlers reports the mainstacks that are
currently loaded in memory. When I run this handler in MC, there are
at most only a couple of stacks from the IDE listed, but in Rev, it
is difficult to find my own
On Sat, 2003-07-12 at 20:04, J. Landman Gay wrote:
> On 7/12/03 10:02 AM, Geoff Canyon wrote:
>
-- snip --
>
> For those who prefer MC's simplicity, I don't see any harm in continuing
> to assure it is compatible with the most current Rev engine. People will
> still have to purchase Revolution
On 7/12/03 10:02 AM, Geoff Canyon wrote:
Then I don't understand all the talk of customizing MC. If it's near
perfect (for those who like simplicity) the way it is, let it stay that
way. It won't take a team effort to keep it compatible with any
foreseeable changes to the engine.
I don't recall
On Friday, July 11, 2003, at 11:42 AM, Richard Gaskin wrote:
So putting it just as bluntly, that there is a perception of MC's
value is
reason enough. If that perception changes over time the MC engine will
whither away naturally. There should be no need to force change, and
doing
so would no
On Friday, July 11, 2003, at 10:32 AM, J. Landman Gay wrote:
These are very minor examples, none of which are crucial or
insurmountable. I can customize my way out of the first two of them
easily. But the lean IDE in MC has its appeal -- precisely because I
*don't* have to customize it. It j
On 7/11/03 1:01 PM, Shari wrote:
This brings up a question. I remember when I initially tested Rev vs.
MC, Rev required a LOT more memory. Now if I have a project, and
compile it in Rev, and MC, will it require more memory in Rev?
The extra RAM is mostly for the IDE. Once your stacks become
s
Geoff Canyon wrote:
> In short, (putting it bluntly) why would anyone want to spend effort
> maintaining/updating MetaCard's development environment when the
> Revolution environment is also customizable?
Very different levels of customizability. For example the Rev license
expressly forbids mod
But for those who have been using MC for a long time, the extra
palettes, libraries, and interface elements can get in the way.
Someone mentioned speed, and that's a consideration too; it does
take somewhat longer for Rev's palettes to load and display their
data -- noticeably more time than th
On 7/11/03 12:03 AM, Geoff Canyon wrote:
Out of curiosity, what is it that the MetaCard development environment
has that the Revolution environment doesn't?
Or, what is it that MetaCard _doesn't_ have that can't be hidden or
> done away with in Revolution?
The second statement is more likely on
Taking as a given the fact that the MetaCard development environment is
much more static than the Revolution development environment, and
therefore has had more of the bugs ironed out of it:
Out of curiosity, what is it that the MetaCard development environment
has that the Revolution environme
MCers,
I vote keep this a general discussion list, until the MC-to-Rev
transition has been accomplished.
Create a new MC/Rev open source list. Those of us who are not that
familiar with Rev (do REVers refer to it as Rev or RR?) will become
better suited to the new environment...
The Rev team w
On Wed, 2003-07-09 at 22:34, Mark Talluto wrote:
> On Wednesday, July 9, 2003, at 01:23 PM, Richard Gaskin wrote:
>
> > Tereza Snyder wrote:
> >
> >> on 07.09.03 1:20 PM, Richard Gaskin wrote:
> >>
> >>> Things we need to decide:
> >>>
> >>> - Is Yahoo Groups acceptable as a groupware solution for
Hi MetaCarders,
Recently, "Mark Talluto" wrote:
I am just curious to know how many people are planning on staying with
MC and being active in maintaining its IDE?
I can't say how long we'll stay with the MC IDE (can anyone really?),
but I
can say we're willing to contribute to its development n
On 7/9/03 3:34 PM, Mark Talluto wrote:
I am just curious to know how many people are planning on staying with
MC and being active in maintaining its IDE?
Don't know what the future may bring, but I'd like to remain involved
with the MC IDE regardless.
--
Jacqueline Landman Gay | [EM
Recently, "Richard Gaskin" wrote:
> I would be happy to contribute to the maintenance of the IDE going forward,
> and would like to see simpler extensibility as a first step (after we get a
> list set up to make it happen, of course).
Great suggestion!
I think Richard won't mind me mentioning t
Recently, "Mark Talluto" wrote:
> I am just curious to know how many people are planning on staying with
> MC and being active in maintaining its IDE?
I can't say how long we'll stay with the MC IDE (can anyone really?), but I
can say we're willing to contribute to its development now.
Regards,
Mark Talluto wrote:
> I am just curious to know how many people are planning on staying with
> MC and being active in maintaining its IDE?
That's a good question. I'm well invested in a nice workflow with nifty
quick tools I've added, so I'm inclined to keep that workflow in place for
the forese
On Wednesday, July 9, 2003, at 01:23 PM, Richard Gaskin wrote:
Tereza Snyder wrote:
on 07.09.03 1:20 PM, Richard Gaskin wrote:
Things we need to decide:
- Is Yahoo Groups acceptable as a groupware solution for this
project?
With its discussion list, file repository, calendar, and links it
gets
Tereza Snyder wrote:
> on 07.09.03 1:20 PM, Richard Gaskin wrote:
>
>> Things we need to decide:
>>
>> - Is Yahoo Groups acceptable as a groupware solution for this project?
>> With its discussion list, file repository, calendar, and links it
>> gets my vote, but there may be things I'm overlook
on 07.09.03 1:20 PM, Richard Gaskin wrote:
> Things we need to decide:
>
> - Is Yahoo Groups acceptable as a groupware solution for this project?
> With its discussion list, file repository, calendar, and links it
> gets my vote, but there may be things I'm overlooking.
>
> - If so, is it simple
With the announcement yesterday, as Scott suggested the next step for the
evolution of MetaCard's IDE is to form a discussion list to focus on IDE
development. There's a lot to discuss so we should get that going soon.
I'm a big fan of Yahoo Groups, and one of the readers here suggested turning
27 matches
Mail list logo