Should we update our cursor resource IDs to match the latest engine? Seems we're moving to a world in which is increasingly difficult to have a single IDE that works with multiple engines (consider libURL too), and thus far I think I've been the only one striving for that anyway.
Indeed it seems that RR is sitting this one out, so we can probably assume it ain't gonna change back. Otherwise, they would have corrected it right away. I just think they are hell bound to eliminate the hand cursor.
The only problem I see with fixing this in MC will be backwards compatibility with earlier engines.
I think this is where we have to let the older IDE version sit and move forward if we're to move forward at all. Between these engine issues and libURL the alternative seems more complicated.
"Necessary" is the only question. We can't determine how long this legacy bug with image pasting will remain in place, so if we want improved behavior it seems more productive to do what we can with what's in hand than wait for an unknowable possibility down the road.
So do we really want this behavior? I'd find it useful, but I'm not sure if that's a universal desire; maybe some folks like the current behavior (can't imagine it, but HyperCarders sometimes have the strangest habits and this behavior seems to play into the only-one-bitmap HC paradigm).
Would be it plausible for you as the head of the MC IDE group to inquire with Kevin directly about their policy/plans regarding such engine bugs? Possibly each one should be addressed individually. Then we can make an informed decision.
I'm afraid even a grand a title as "MC Poohbah" carries no more weight than anyone else.
To the best of my knowledge the Bugzilla notes are the most complete record of where things stand on each issue at this time.
I'm not clear on why so many engine issues are addressed only in their IDE scripts, but since I work on the MC IDE and neither the engine nor their IDE it wouldn't be productive for me to conjecture. My job is just to get the best results I can with what I have to work with at the moment, and leave the learnability of the Rev IDE to its keepers.
It may be that they decided to pretty much freeze the engine and fix all that is possible only in IDE from now on.
We can hope, at least as far as behavioral changes go. I read all of the engine reports in BZ quarterly, and I see some action on a few BZ items so I know some are being addressed; I just don't know how many or on what timeline.
I would not want to accuse them of malice and stabbing MC in its back yet, but it surely starts looking like they do little things that will lead to its slow death.
While there have been some annoyances, maybe we should consider ourselves lucky that it's only costing us a few hours rather than introducing show-stoppers.
Once in a while I get the impression from Kev that he actually likes the MC IDE, that he shares a bit of my feeling that having an engine so powerful that it can run a potentially infinite variety of IDEs is kinda cool.
I would be quicker to ascribe the annoyances we've been dealing with to simply not being on their radar than to malice. They have other things tugging at them more urgently than the needs of a few dozen old schoolers.
Personally I believe our perspective as Enterprise customers is useful for supporting professional work, but if we're the only ones who feel that way it doesn't much matter. :)
It sure would be nice if some of the things were finalized and we get the next formal release of MC IDE out of the door.
Agreed. Klaus did some nice work recently in the latest beta, and if we're all on the same page about working within the current constraints we can move forward to correct for the engine changes.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
