Pasting images: purity or usability?
There's an outstanding request to fix an issue in the engine with regard to pasting images: Currently, pasting an image from the Clipboard causes one of two things to happen: either the image is pasted into the bottom-most image object, or if there are no image objects it creates a new image sized to match the entire card. It's rarely the case in my own work that either is what I want. :) http://support.runrev.com/bugdatabase/show_bug.cgi?id=2473 While RunRev hasn't taken the time to address this in the engine, they did take the time to implement a workaround in their IDE's Edit menu: if the clipBoard is image and the selectedImage is empty then lock messages lock screen create image put the clipBoardData[image] into last image unlock messages unlock screen put true into tObjects choose pointer tool select last image So at least their IDE works, even if users will be confused when their standalone behaves differently. The question for us is whether we should maintain the purity of the MC IDE by using the engine's Paste command as it does now, or favor usability by implementing the workaround script from RR. I'd like to say be able to report that we can expect a fix on this soon, but it's been outstanding for half a year so I think if we want this it it may not be productive to wait for the engine to catch up with us. -- 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
Re: Pasting images: purity or usability?
Hi Richard, There's an outstanding request to fix an issue in the engine with regard to pasting images: Currently, pasting an image from the Clipboard causes one of two things to happen: either the image is pasted into the bottom-most image object, or if there are no image objects it creates a new image sized to match the entire card. It's rarely the case in my own work that either is what I want. :) http://support.runrev.com/bugdatabase/show_bug.cgi?id=2473 While RunRev hasn't taken the time to address this in the engine, they did take the time to implement a workaround in their IDE's Edit menu: if the clipBoard is image and the selectedImage is empty then lock messages lock screen create image put the clipBoardData[image] into last image unlock messages unlock screen put true into tObjects choose pointer tool select last image So at least their IDE works, even if users will be confused when their standalone behaves differently. The question for us is whether we should maintain the purity of the MC IDE by using the engine's Paste command as it does now, or favor usability by implementing the workaround script from RR. I'd like to say be able to report that we can expect a fix on this soon, but it's been outstanding for half a year so I think if we want this it it may not be productive to wait for the engine to catch up with us. OK, this is now (obvious) engine bug nr. 2 (besides set cursor to hand, and maybe more...) I don't think that we should workaround this in our beloved lean IDE... We CAN of course, if necessary. ;-) Mr. Miller once promised (yes, he did!) to NOT touch anything in the engine, so we friends of Carlotta er Metacard will not experience any incoveniences... But it looks like that his memory i fading... :-/ Yes, they lack resources (actullay i heard this one much too often and cannot stand this argument any longer!!!) but WE cannot tell this to our customers, i think... So the question is will Rev support the engine fully or not resp. tweak its IDE to balance out some engine inconsistencies? Yes, i AM a bit upset :-) Especially if there are so many serious(!) and pending bugs and we have to hear something like ...upcoming features/news that will change the way of using Rev completely, as Mr. Miller stated in the chat last week, then i DO feel a bit pissed... :-) Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Klaus Major wrote: There's an outstanding request to fix an issue in the engine with regard to pasting images: Currently, pasting an image from the Clipboard causes one of two things to happen: either the image is pasted into the bottom-most image object, or if there are no image objects it creates a new image sized to match the entire card. It's rarely the case in my own work that either is what I want. :) http://support.runrev.com/bugdatabase/show_bug.cgi?id=2473 While RunRev hasn't taken the time to address this in the engine, they did take the time to implement a workaround in their IDE's Edit menu: if the clipBoard is image and the selectedImage is empty then lock messages lock screen create image put the clipBoardData[image] into last image unlock messages unlock screen put true into tObjects choose pointer tool select last image The question for us is whether we should maintain the purity of the MC IDE by using the engine's Paste command as it does now, or favor usability by implementing the workaround script from RR. OK, this is now (obvious) engine bug nr. 2 (besides set cursor to hand, and maybe more...) I don't think that we should workaround this in our beloved lean IDE... Ah yes, the cursor ID issue. I had held out hope for apparently too long that backward compatibility would ultimately become the higher priority, and that they'd adopt the principle of introducing new cursor images with new IDs in a quick bug-fix release. But it's been long enough that it seems perhaps time that we all consider updating all of our software to correct for that anomaly, and that would include the MC IDE. 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. I don't mind updating those resources if the general mood here is that it's time to do it. We CAN of course, if necessary. ;-) 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). Mr. Miller once promised (yes, he did!) to NOT touch anything in the engine, so we friends of Carlotta er Metacard will not experience any incoveniences... But it looks like that his memory i fading... :-/ On the contrary, with this specific issue he's fulfilling that promise to a fault: the engine's always had this anomaly, and RunRev has thus far preserved the behavior perfectly. :) Yes, they lack resources (actullay i heard this one much too often and cannot stand this argument any longer!!!) but WE cannot tell this to our customers, i think... I've sent some of my customers to the Apple feedback page for bugs in OS X that affect WebMerge. But Kevin's a much nicer person than Jobs, so I wouldn't do the same with RR. So the question is will Rev support the engine fully or not resp. tweak its IDE to balance out some engine inconsistencies? 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. Yes, i AM a bit upset :-) Especially if there are so many serious(!) and pending bugs and we have to hear something like ...upcoming features/news that will change the way of using Rev completely, as Mr. Miller stated in the chat last week, then i DO feel a bit pissed... :-) I don't think things are quite so dire. Consider how long this behavior has been in place, and that the BZ request to update it was posted only in December '04. I have no doubt that there may be some nifty things in the works, and I understand how they can be useful in driving new sales. But I also agree with the pervasive feeling expressed in all corners of RunRev's community that cleaning up language orthogonality and tightening up some behavioral loose ends will do more for their conversion rate than anything else. But their conversion rate doesn't line my pocket so my time is best spent focused on the task at hand: Should we consider this proposed script change, or let the old behavior stand? And Klaus, relax. If you let other people's performance affect
Re: Pasting images: purity or usability?
Especially if there are so many serious(!) and pending bugs and we have to hearsomething like "...upcoming features/news that will change the way of using Rev completely",as Mr. Miller stated in the chat last week, then i DO feel a bit pissed... :-)I feel I must point out that Kevin did not actually say this - it was said by Ro Nagey - Kevin and Ro are two quite distinct entities I can assure you.Kevin was quite clear that the next few versions of Revolution would build on what we currently have - and you can read that as meaning that we will do our best to balance the introduction of new features as the market demands, and addressing the current issues that the present technology has.Warmest Regards,Mark. -- Mark Waddingham ~ [EMAIL PROTECTED] ~ http://www.runrev.com Runtime Revolution ~ User-Centric Development Tools___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Richard, On 17.05.2005 13:33:23 metacard-bounces wrote: Klaus Major wrote: [snip] And Klaus, relax. If you let other people's performance affect yours you'll become grouchier than a barking Texan. :) or Belgian barking... ;) Klaus knows what im talking about... IF Rev fixed the image and other Engine issues that lurk on MC since 4 years or more, fixed the lousy cursor support, im sure the number of complains and rants would disminish by 5% on this list... Maybe less but while introducing object oriented variables is useful and welcome, the remaining problems only keep incrementing the aggravation of those who are affected. Day after day, these issues pile up as a lot of time-resource waste for the RunRev client which so far have not been addressed. I know it's harder to fix an engine bug that a GUI bug but still, showing a color cursor in any programming is very 101 class programming. The image ID and stack name conflict issues (to name 2 similar issues) are continually creating issues that could have been resolved YEARS ago... While i've tried and tried to tell Kevin and Scott about this, it's only too funny to see the issues come back over and over... And i thought i was a lousy programmer! Now, im only refering to Engine issues not GUI... Now, I know which way is best for long term programming efficiency and 10X more time resources to get back some spare life-time for myself ;) Cheers Xavier Visit us at http://www.clearstream.com IMPORTANT MESSAGEInternet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.END OF DISCLAIMER ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Ah yes, the cursor ID issue. I had held out hope for apparently too long that backward compatibility would ultimately become the higher priority, and that they'd adopt the principle of introducing new cursor images with new IDs in a quick bug-fix release. But it's been long enough that it seems perhaps time that we all consider updating all of our software to correct for that anomaly, and that would include the MC IDE. 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. I don't mind updating those resources if the general mood here is that it's time to do it. 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. 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 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. It probably simplifies their development cycle. 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. 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. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Mark, Does this mean that some features that are apparently 1980's technology will be migrated to modern standards without our having to suggest it or do we still have to suggest them for you to notice that some things still are not as standard/enterprise as they should be? Some of the suggestions i made to Scott 4 years ago are still impacting me here and still unimplemented... Cheers Xavier On 17.05.2005 14:08:54 metacard-bounces wrote: Especially if there are so many serious(!) and pending bugs and we have to hear something like ...upcoming features/news that will change the way of using Rev completely, as Mr. Miller stated in the chat last week, then i DO feel a bit pissed... :-) I feel I must point out that Kevin did not actually say this - it was said by Ro Nagey - Kevin and Ro are two quite distinct entities I can assure you. Kevin was quite clear that the next few versions of Revolution would build on what we currently have - and you can read that as meaning that we will do our best to balance the introduction of new features as the market demands, and addressing the current issues that the present technology has. Warmest Regards, Mark. -- Mark Waddingham ~ [EMAIL PROTECTED] ~ http://www.runrev.com Runtime Revolution ~ User-Centric Development Tools___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard Visit us at http://www.clearstream.com IMPORTANT MESSAGEInternet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.END OF DISCLAIMER ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Hi Richard and all, Klaus Major wrote: There's an outstanding request to fix an issue in the engine with regard to pasting images: Currently, pasting an image from the Clipboard causes one ... The question for us is whether we should maintain the purity of the MC IDE by using the engine's Paste command as it does now, or favor usability by implementing the workaround script from RR. ... We CAN of course, if necessary. ;-) 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; Same for me... 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). Mr. Miller once promised (yes, he did!) to NOT touch anything in the engine, so we friends of Carlotta er Metacard will not experience any incoveniences... But it looks like that his memory i fading... :-/ On the contrary, with this specific issue he's fulfilling that promise to a fault: the engine's always had this anomaly, and RunRev has thus far preserved the behavior perfectly. :) Ooops, sorry, did not know this, apologies to Kevin (in regards of the image part)! Yes, they lack resources (actullay i heard this one much too often and cannot stand this argument any longer!!!) but WE cannot tell this to our customers, i think... I've sent some of my customers to the Apple feedback page for bugs in OS X that affect WebMerge. But Kevin's a much nicer person than Jobs, so I wouldn't do the same with RR. Sure, but a fact is a fact... So the question is will Rev support the engine fully or not resp. tweak its IDE to balance out some engine inconsistencies? 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. Yes, i AM a bit upset :-) Especially if there are so many serious(!) and pending bugs and we have to hear something like ...upcoming features/news that will change the way of using Rev completely, as Mr. Miller stated in the chat last week, then i DO feel a bit pissed... :-) I don't think things are quite so dire. Consider how long this behavior has been in place, and that the BZ request to update it was posted only in December '04. I felt a bit pissed in general ;-) And please take my little cursing not too serious (see the little smilies?) It is just that i feel better immeadiately once i wrote it down! :-) I have no doubt that there may be some nifty things in the works, and I understand how they can be useful in driving new sales. But I also agree with the pervasive feeling expressed in all corners of RunRev's community that cleaning up language orthogonality and tightening up some behavioral loose ends will do more for their conversion rate than anything else. At least you know what i mean :-) But their conversion rate doesn't line my pocket so my time is best spent focused on the task at hand: Should we consider this proposed script change, or let the old behavior stand? For me: leave as is... And Klaus, relax. If you let other people's performance affect yours you'll become grouchier than a barking Texan. :) I am relaxed, see above, just saving the money for an analyst... ;-) PS: I saw a documentary recently on Klaus Nomi, and while I realize you have nothing in common but the first name EXACTLY, i don't sing soprano nor am i an uomo extravaganzo :-) (At least not in public :-D if you're old enough to remember Nomi Yep ;-) it's a wonderfully nostalgic film: http://thenomisong.com -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com Relaxed greetings from (still cold) germany Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Robert Brenstein wrote: 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
Re: Pasting images: purity or usability?
I am not sufficiently competent to discuss etherial purity, so shall restrict my response to pragmatic needs. When I paste an image, I would expect the image to arrive WISIWIG. The fact that the dimensions match the top window make it unusable as things stand (I have 'imported' images for so long now that I don't even try to 'paste' any more). It may be an engine bug (and there are darn few of 'em), but Richard's proposal solves the problem and would be backwards compatible if/when the bug does get fixed. Stop wittering, Hugh... I vote "yes, please". /H ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Any chance that this issue is related to bugzilla http://support.runrev.com/bugdatabase/show_bug.cgi?id=2353 Tuv couldn't reproduce it and i keep having the problem anytime i try. Seems engine related more than GUI... cheers Xavier On 17.05.2005 11:38:34 metacard-bounces wrote: There's an outstanding request to fix an issue in the engine with regard to pasting images: Currently, pasting an image from the Clipboard causes one of two things to happen: either the image is pasted into the bottom-most image object, or if there are no image objects it creates a new image sized to match the entire card. It's rarely the case in my own work that either is what I want. :) http://support.runrev.com/bugdatabase/show_bug.cgi?id=2473 While RunRev hasn't taken the time to address this in the engine, they did take the time to implement a workaround in their IDE's Edit menu: if the clipBoard is image and the selectedImage is empty then lock messages lock screen create image put the clipBoardData[image] into last image unlock messages unlock screen put true into tObjects choose pointer tool select last image So at least their IDE works, even if users will be confused when their standalone behaves differently. The question for us is whether we should maintain the purity of the MC IDE by using the engine's Paste command as it does now, or favor usability by implementing the workaround script from RR. I'd like to say be able to report that we can expect a fix on this soon, but it's been outstanding for half a year so I think if we want this it it may not be productive to wait for the engine to catch up with us. Visit us at http://www.clearstream.com IMPORTANT MESSAGEInternet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.END OF DISCLAIMER ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Hi Xavier, Any chance that this issue is related to bugzilla http://support.runrev.com/bugdatabase/show_bug.cgi?id=2353 Tuv couldn't reproduce it and i keep having the problem anytime i try. Seems engine related more than GUI... Just tested it and found that this is NOT engine related! I created an 8*7 Gif... Metacard: Set the filename, no problem... Import, no problem... Script: answer file yadda; import paint from it, no problem Rev: Set the filename, no problem... Import as control, - 120*120 pixel Script: answer file yadda; import paint from it, - 120*120 pixel cheers Xavier Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
On 5/17/05 4:38 AM, Richard Gaskin wrote: The question for us is whether we should maintain the purity of the MC IDE by using the engine's Paste command as it does now, or favor usability by implementing the workaround script from RR. This is very low on my priority list, so I am neutral. I virtually never paste in images, and the one time I tried it, the defalt behavior didn't bother me. Leave it alone, or update it, doesn't matter. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
J. Landman Gay wrote: On 5/17/05 4:38 AM, Richard Gaskin wrote: The question for us is whether we should maintain the purity of the MC IDE by using the engine's Paste command as it does now, or favor usability by implementing the workaround script from RR. This is very low on my priority list, so I am neutral. I virtually never paste in images, and the one time I tried it, the defalt behavior didn't bother me. Leave it alone, or update it, doesn't matter. Thanks for the input. Do you feel we should update the cursor IDs to account for the engine change in v2.5? -- 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
Re: Pasting images: purity or usability?
Richard Gaskin wrote: And Klaus, relax. If you let other people's performance affect yours you'll become grouchier than a barking Texan. :) Hey, be nice to your brethren in the south. Some of us have an even worse bite than bark! -Cowboy Chipp ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
The question for us is whether we should maintain the purity of the MC IDE by using the engine's Paste command as it does now, or favor usability by implementing the workaround script from RR. I personally would welcome inclusion of the workaround. Since it's a scripted solution, it would be easy enough to comment out if (when?) Rev updates the engine. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
On 5/17/05 12:44 PM, Richard Gaskin wrote: Do you feel we should update the cursor IDs to account for the engine change in v2.5? Yeah, I suppose. If it means I can use set cursor to hand successfully again, I'm for it. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
