New MC Standalone Builder?
I remember we had a beta version of a MC Standalone Builder in June 2011. Is there any new or final version and I did miss it? Best wishes for the New Year! Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: mcStandaloneBuilder b1 posted
On Sun, 03 Jul 2011, Ken Ray wrote:
Sorry Wilhelm, misread your post - ignore what I said in my previous
post to
the list.
Not at all, Ken. Your hint to the Livecode tab in the new "preferences"
was new information for me, as it places the path to the preferred
Livecode version then automatically into the field "LiveCode
Folder/Bundle" of the SB.
> My proposal is to allow to point to the "runtime" folder only, which
> could be copied into the Metacard folder. This would mean that you need
> not have both the full Metacard and Livecode installations on the same
> computer (for example on a laptop).
That's the rub... even if the LC SB worked perfectly, it would still be a
pain to develop in the MC IDE and then have to switch out to LC in
order to
build a standalone.
We're trying to accommodate those that use MC *and* LC as well as those
using MC only, so we should come up with a good way to do that;
pointing to
only the Runtime folder might be a way to do it...
Thanks for agreeing here, and maybe we could have both options.
Ken Ray
I want come back to my question about "required" and "optional" fields
in the SB (in my last post):
The SB of our old MC IDE 3.0.0b has a impressing simplicity:
To successfully build a standalone only *three* selections have to be
made. You have to select the source stack ("Stack name"), then the
"Metacard engine" (which two years ago was already the path to this
single file "standalone" (on Windows)), and finally a "Standalone file
name" for the new standalone to be built.
Then you press button "Build" and get the message "Standalone built
successfully"
Especially for quick builds in between during a development such a
simple procedure (only on the surface of course) is important and
useful, more detailed information about a standalone can then be entered
under "Set Windows Version Info.." and "OSX settings" (with "file
version", "OriginalFilename" etc. etc.)
Our new SB could maybe be considered to possess a similar simplicity,
but it is surely not obvious, unless of course you know which entries
are required.
After a lot of trial and error - yesterday and today - I think I found
out the minimal requirements to build a standalone (I am though not
sure, whether I am 100% exact here, but they seem to work; ten minutes
ago I have been finally able to build my first working standalone, but
we do not get a concluding message after an achieved build like with MC
SB 3.0.0b):
- select "Source Stack"
- "Save Stack" is *not* needed for the build, probably only useful for
storing the new custom properties in the source stack, but for that
purpose *after* the build process.
-select "destination Folder"
- select "LiveCode Folder/Bundle"
In the "General" Tab
- enter "App Name" (name of the new standalone)
- enter "Version"
- enter "Builder Number" (really reqired?)
In the "Windows" tab
- add "File Version"
- add "Product Version".
As a result of all my endeavours I have now got two extra folders in my
destination directory, namely "Version" and "Version 1". Folder
"Version" is empty, "Version 1" contains two subfolders "Build" and
"Build 1". "Build" also is empty, "Build 1" eventually contains folder
"Windows" with the three standalone files I managed to create in these
two days. All indeed bear their "App Names" I had chosen in the
"General" tab, but two of them refuse to run and throw an error
"Standalone origin mismatch". -
I am wondering what the meaning of this message could be. As I had
already reported yesterday, one of the non-running standalones has
deviating entries in its ""cRevStandaloneSettings" that are created
during the build process
"Livecode 4.6.1" for "_GEN_EngineFolder"
but "Livecode 4.6" for "defaultBuildFolder"
It seems to me that "Livecode 4.6" is a remnant of an earlier build
inside Livecode. But that does not explain, why and how the standalone
was created nevertheless and why it doesn't run?
I recommend to use something like "cMCStandaloneSettings" in the future
to avoid such conflicts.
The second non-running standalone, which throws the same error message,
does *not* have such conflicting "cRevStandaloneSettings", in fact,
there are none at all, having seemingly disappeared later somehow.
To sum it up: About four hours for the first two explorations of our new
Standalone Builder, some insights - including looks at the structure of
the scripts - and at least one really working standalone.
All in all a positive achievement.
Best regards,
Wilhelm Sanke
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Re: mcStandaloneBuilder b1 posted
Many thanks to Richard and Ken for the release of the new Standalone Builder and the 4.1 IDE, not to forget the new Metacard Setup 2.01 by Jacqueline - and I assume that the preparations by Klaus were helpful for the developments of these tools.. The releases coincided with a palpable improvement of my health after four months of fighting with a nasty gastritis that caused a lot of enforced inactivity and reduced my energy and productivity to a large extent. But last week I have even resumed training with my tennis team, hopefully to prepare for the second half of the summer series in August (usually it is colder here than elsewhere). Although the new releases are actually not the direct cause of my relatively improved health (as you would also guess from my first report below), I think that working with the shortly following versions of Standalone Bulder and the IDE will help me to recover completely in the near future with an enhanced motivation. In his release mail Richard wrote: "In the meantime, feel free to post any bug reports you have either here to or me personally at b...@fourthworld.com I wouldn't want to overload this list with bug reports, but it may be helpful to discuss them here where we can all keep apprised of what's working, what's not, and future directions. Your call." With his "beta 1"-version Richard has given a differentiated answer to a situation that has become at least slightly more complex than before with the required new directory structure for a Metacard folder and the new license-binding procedures for a standalone two years ago. Before Rev version 4.0, all I needed to set up a Metacard folder was to drop a new Revolution engine into the MC IDE and possibly rename the engine, at least on Windows. To build a standalone, in the Metacard Standalone Builder I had to find a single file "standalone" (without extension) instead of the former "MC.exe" - and to prepare for such standalone building I had copied this single "standalone" file into my Metacard folder before. I just checked this again inside my Metacard folder 3.5 gm1 with the MC IDE 3.0.. Here are some results and added comments of my first unsystematic exploration of the B1 version: I succeeded to build two standalones from my stacks on Windows XP and in my Metacard folder 4.6.1, but after the succesful build they refuse to run and only throw an error message "Standalone origin mismatch". After these two non-running builds I was somehow unable to build more standalones. There is for example no indication in the Windows pane which fields are required ones and which optional. One of the questions here: Should not field "Original Filename" in the Windows tab be automatically filled from the chosen "Source Stack" selection? For "LiveCode Folder/Bundle" - in the upper region of the Standalone Builder - I had first chosen the Livecode "runtime" folder" where the "standalone" files reside - following in essence the procedure I had used before in the 3.0 MC IDE, namely locating the necessary file "standalone". Instead we apparently need to choose the complete Livecode folder, but I cannot replicate this now as the Standalone Builder at the moment refuses to build any stacks, there is even no error message when I press button "Build". My proposal is to allow to point to the "runtime" folder only, which could be copied into the Metacard folder. This would mean that you need not have both the full Metacard and Livecode installations on the same computer (for example on a laptop). If the presence of a complete Livecode folder would be needed, why should we use an extra MC Standalone Builder?, provided of course the Livecode SB would function as expected without such peculiarities as it had often shown in the past like endless build times etc.. I see that "cRevStandaloneSettings" are attached to the source stack during the build procedure. Looking at them in one of the source stacks that were built, but refuse to run, I find (without the full path before): "Meta-Livecode 4.6.1" for "_GEN_DestinationFolder" "Livecode 4.6.1" for "_GEN_EngineFolder" but "Livecode 4.6" for "defaultBuildFolder" i.e. "4.6" instead of "4.6.1". Should this be the cause for the above quoted error message "Standalone origin mismatch"? This is all I can report at the moment. I will continue to look more closely into the matter, but it seems to me we need a first update. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: New MC-standalone builder
From the traffic on the livecode lists I see that Richard Gaskin, who apparently did not notice my post on the Metacard list, is back. Richard, could you shed some light on my question below? Thanks in advance! Wilhelm Sanke I had written on June 10: On March 29, 2011, Richard Gaskin had written (in thread "Re: LC/MC StandAlone Builder"): On 3/29/11 10:09 AM, FlexibleLearning wrote: Thank you, Richard. The LC builder does a fine job so far as I can see, but if an MC solution is available it could be a lot more convenient. Hugh Senior FLCo Thanks for the kind words, Hugh. I should note that with my current schedule I probably won't be able to get back to the Standalone Builder until after the conference, but here are some highlights which will hopefully make it worth waiting for: Hello Richard, Is it still too early to ask or could you tell us when the new standalone builder could be released? We are thankful for your commitment to manage this task. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
New MC-standalone builder?
On March 29, 2011, Richard Gaskin had written (in thread "Re: LC/MC StandAlone Builder"): On 3/29/11 10:09 AM, FlexibleLearning wrote: Thank you, Richard. The LC builder does a fine job so far as I can see, but if an MC solution is available it could be a lot more convenient. Hugh Senior FLCo Thanks for the kind words, Hugh. I should note that with my current schedule I probably won't be able to get back to the Standalone Builder until after the conference, but here are some highlights which will hopefully make it worth waiting for: Hello Richard, Is it still too early to ask or could you tell us when the new standalone builder could be released? We are thankful for your commitment to manage this task. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Statements from Kevin in 2003
On Mon, 11 Apr 2011 05:54:53 -0700, Kevin Miller wrote My offer was to continue to support your capability to keep your IDE up to date by making it possible to continue to integrate engines and new features if you chose to do so. To that end we provided complete details of what is required to update your standalone builder to the keeper of your IDE when last requested a long, long time ago (over a year at least). I did not offer to write the MC IDE for you and such an offer would not have been welcome, we already maintain an IDE, this is your IDE which is open source. It is down to those that maintain MetaCard to keep it up to date. I'm sure the current keeper of your IDE can verify this, and that consequently your statements are quite unfounded. Kind regards, Kevin Kevin Miller ~ ke...@runrev.com ~ http://www.runrev.com/ LiveCode: Compile-free coding, the faster path to better apps Hi Kevin, I certainly did not request nor expect you to write or maintain the MC IDE for us. I think the group of MC IDE users is aware that maintaining and adapting the MC IDE is our responsibility alone. Richard has made that especially clear again in a recent post, but it has been our understanding ever since. What I was referring to were the changes made not long ago, which now require a slightly different way of integrating a new Rev/Livecode engine. Until then, we just could take a new engine, possibly needed to rename it, and simply drop it into the folder of the MC IDE and it would work immediately. Now we need to prepare a specific folder structure before a Livecode engine will be accepted as a working part inside the MC IDE. It took some trial-and-error and some members of our group to figure out how to do this. The routine is now more or less established and can be looked up in writing for reference when it needs to be applied with a new engine. No big deal, of course, a minor nuisance only - and once you got the changed folder structure it may be as easy as before to simply drag a new engine into the MC folder - unless of course another change for the necessary folder structure takes place. What I was thinking of was that it may be not a big deal for you, too, to return to a simpler way of just dropping the engine into the IDE (possibly by leaving out specific folder structure references in the Livecode engine?) or an otherwise simpler procedure. Concerning the new MC standalone builder the issues will have been solved with the new version. I think - in this sense - my statement was not quite unfounded when I asked you Could you possibly do something about this and facilitate these processes of integration for future versions of Livecode? This must not be too difficult. I ventured to ask this question as I thought that it would require only really minor efforts from your side to accomplish this. Kind regards, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Statements from Kevin in 2003
On Mon, 11 Apr 2011 05:53:58 -0700, Klaus on-rev wrote: > and that we needed one and a half year to build a new MC standalone builder. I don't think that I am talking/writing chinese, do I, Wilhelm? For the last time: 1. It was not too difficult to create the standalone builder. 2. RunRev supplied all neccesary info to do this. 3. It were MY PERSONAL PROBLEMS that hindered me to do so in that time! 4. We have been talking about this several times in the last weeks here on the list and I pointed this 3) out also several times very clearly! Klaus Sorry Klaus, You were definitely not talking Chinese to me, but the receiver of a message must still actively construe the meaning for himself, which then may come out even wrong or deviate from the intended original meaning. Among other things, my interpretation was influenced also by the longer discussion between Sept 3 and Oct 7 2009 in threads "Metacard 4" and "Standalone Building" on this list. Looking over this discussion again later led me apparently to overestimate the difficulties posed by the new way of standalone building. My impression was indeed that the new standalone building design, although a minor factor compared to you special situation, nevertheless caused at least some substantial difficulties for adapting the MC standalone builder. So, sorry again, receive my apologies. By the way, I like Chinese. I wrote a Metacard stack some time ago introducing about 200 basic Kanji characters in different learning modes. The incentive for this was a longer East-Asian working experience in South Korea, where they use - similar to Japan - a limited set of Kanji characters as part of their written language. Best, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Statements from Kevin in 2003
On Mon, 11 Apr 2011 04:00:15 -0700, Kevin Miller wrote: On 11/04/2011 10:46, "Wilhelm Sanke" wrote: > So much for the - hopefully lifelong - relationship between Livecode > engines and the MC IDE. Well I certainly never said lifelong :) But hey, we've kept up our bargain for 8 years now and still intend to continue to do so. I have absolutely no idea what you might not be happy about... Kind regards, Kevin Kevin Miller ~ ke...@runrev.com ~ http://www.runrev.com/ LiveCode: Compile-free coding, the faster path to better apps Kevin, you are welcome. Thank you for the almost instant reply. What we were somewhat unhappy about (see some of the posts in the recent thread "[MC_IDE] Quick Poll") was that it had become more difficult than before to integrate the new Livecode engines into the MC IDE and that we needed one and a half year to build a new MC standalone builder. Richard Gaskin is going to deliver that new one during the next weeks. Could you possibly do something about this and facilitate these processes of integration for future versions of Livecode? This must not be too difficult. Many thanks in advance and best regards, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Statements from Kevin in 2003
Unfortunately, the Livecode-dev archives available on the web (the former improve-revolution archives) reach back only until October 2003 and the earliest entry on the present Metacard list archives is from Nov 11, 2004. Can someone of you point me to the complete improve-revolution and metacard-list archives for the year 2003? They must be stored somewhere. I made a search on some of my older computers - such running Windows 98 - and was confronted with difficulties when trying to transfer the data , because file structure and necessary transfer media were not fully compatible (When using Iomega-Zip disks this worked in the direction Win 98 to Win XP, but only once, and then the Zip disks needed to be reformatted on Win 98, which however wasn't possible with most of the Zip disks.). Another problem for me was that I had been using computers both in my university office and at home, which had their preferences set in such a way that when you downloaded from your mail lists on one computer, the same mails were no longer accessible from another computer, which surely was an unwise setting of preferences. The older computers from my office have long been trashed, so a number of these old mails have been lost. Nevertheless, I found some statements by Kevin from around the time when Revolution had acquired the Metacard engine On Thu, 14 Aug 2003, Kevin Miller had written - commenting on and verifying his own earlier statement: > This is in writing; Rev has stated that publicly that they will continue > to allow the MC IDE to continue to work with the new Rev engine. Yes. And I'll state it again here in case there is any confusion. I think this is the most important statement from Kevin's side. On the same date Kevin continues with: > it's the *same engine*, just > given a new name. When they add features to it for the benefit of Rev > users, MC users who wish to continue with the MC IDE can just drop in > the new engine and go. Right. So this acquisition means we can, over a period of time, gradually integrate the various language extensions that Revolution has got, and make that available to people who are still using MetaCard. Thus, you can look forward to database access, text to speech, XML, and all the other stuff getting integrated neatly into the language. An really interesting statement, even indicating that possibly Metacard IDE users would, although gradually, get the benefit of of new Revolution features. And another finding in line with the above quotes: On Mon, 8 Dec 2003 06:17:37 -0800 (PST) Alejandro Tejada thanks Kevin for being able to continue to use the MC IDE , which only makes sense of course when you have a compatibility of newer engines and the MC IDE in mind and not just the possibility to continue to use the Metacard engine and IDE of that time (which would be trivial and not worth mentioning): >And you are quite free to go on using the MC IDE if >you wish. Thanks Kevin, you really understand this need. So much for the - hopefully lifelong - relationship between Livecode engines and the MC IDE. Kind regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Second thoughts
After Jacqueline had helped me to understand the basic constellation of the interplay between engine and standalone builder to secure the license binding by encryption, it occurred to me that there is still the question which parts of the standalone builder really must to be encrypted to achieve that goal. The Rev standalone builder is a multi-purpose animal, attaching all kinds of stacks and libraries and also removing all kinds of garbage put in by the Rev IDE, but not needed for the standalone. Especially these processes and when they had been scripted inadequately - which was the case rather often - caused the difficulties for building standalones from certain types of stacks (with build times of more than an hour etc.). These parts of the standalone builder need not and should not be encrypted, only the very small part where the license binding takes place. Looking through the archives (the present "Livecode-dev" archives, formerly the "improve-revolution" archives) I came across a post from Richard (Nov 11, 2003) in response to one of my messages about "Building standalones of larger stacks". Interestingly, Richard here presents arguments for an *unencrypted* standalone builder - "Distro Builder" at that time - when he says "locking..prevents real and sometimes critical problems from being addressed more quickly". This statement is exactly in the line of arguments I presented in our recent discussion in thread "[MC_IDE] Quick Poll". Here is the text of Richard's historic message from the Livecode-dev archives: Building standalones of larger stacks Richard Gaskin ambassador at fourthworld.com Tue Nov 11 11:41:22 CST 2003 Wilhelm Sanke wrote: > As I have stated earlier in this thread, "We would need to compare size, > number of controls and probably other structural elements of a stack to > find out why the Rev IDE is so very slow in some constellations, and > then find out how to remedy this." > > And indeed the Distribution Builder needs 43 minutes for my 10 MB stack > - I am repeating myself here - (and only 3 seconds in the Metacard > IDE), so <3 seconds for your rather small 116 K stack does not > contradict that. It's too bad Rev's Distribution Builder is locked up. If it were as open as MetaCard's we could compare the scripts, fix the issue, and deliver it to RunRev, as we have with MC annoyances in the past. I can appreciate the reasoning behind locking it up, but MetaCard's long and profitable history suggests that locking it may be a solution in search of a problem, sadly one that prevents real and sometimes critical problems from being addressed more quickly. Should unlocking the Distro Builder be an enhancement request? -- Richard Gaskin Fourth World Media Corporation == I think the consequences of these insights could be: - Richard should as far as possible leave the new MC standalone builder unencrypted, save for the tiny part of the license binding. - Richard could renew his intended enhancement request from 2003 and ask Kevin to create the next Livecode standalone builder along the same lines. And more, if we could persuade Kevin to facilitate the process of putting new Livecode engines into the MC IDE , this would in effect indeed turn out as a "win-win-win-situation" - a triple gain for the Livecode team, for MC IDE users, and for Livecode users. Irrespective of the legal and other terms laid down at the time of the acquisition of the Metacard engine by Kevin, such improvements would surely enhance trust and the motivation to continue to actively support the further development of Livecode. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
On Thu, 31 Mar 2011, J. Landman Gay wrote On 3/31/11 12:12 PM, Wilhelm Sanke wrote: Didn't you just state that the build process has been moved into the engine, so - again - why maintain the protection of the Rev standalone builder? The actual building is done in the engine, but the *ability* to build is in the IDE and is protected. Without that protection, anyone with a current LiveCode license could create a competing product. I know you yourself wouldn't do that, but others might. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com Thank you Jacqueline, this makes sense to me, point taken. And as I assured not to develop a competing product and can be relied on that assurance, Kevin maybe may allow me to have a look at that priviledged info needed to build a MC standalone. Best regards, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
One addendum to what Richard delineated about the transition from Metacard to Revolution after Kevin bought the Metacard engine from Scott Raney: The agreement between Scott Raney and Kevin and its details is one matter, the commitment made by Kevin to members of the Metacard user group is another. I had a discussion with Kevin at that time about the future relation of Metacard and Revolution. Among other things I had proposed to keep and maintain Metacard as a sort of "Revolution lite" that would have of course less features than were planned for Revolution. Kevin disagreed to this proposal, probably fearing a competition in his own house then, also in financial terms. I do not remember exactly what he said concerning this point. But he assured me that the compatibility of all future Revolution engines with the Metacard IDE would be guaranteed. I do not know which other members got similar messages, but that is what he promised to me at least. We might find these messages in the old archives. Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
both in maintaining the MC IDE and in further developing Livecode, and I have supported these processes actively for many years. My main platform for development at present is the MC IDE along with a number of add-ons I have developed myself. Here I am in a similar situation as Richard, whose main platform is also not Livecode, but a development of his own on the basis of the MC IDE (Is that correct?). The reasons for that are many - and I will not elaborate them here again. I will not rule out that at some point in the future I could switch over to Livecode altogether, when a level of maturity has been reached that will make working with Livecode comfortable for me. Best regards, Wilhelm Sanke Prof. emeritus Educational Technology University of Kassel ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
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, bu
Re: [MC_IDE] Quick Poll
On Tue, 29 Mar 2011, Richard Gaskin wrote: In keeping with RunRev's commitment to the MC IDE, Oliver Kenyon provided the necessary info to allow us to use the new engine-based standalone building process in v4.0 and later. I checked my mails to the Metacard list and found that I had sent 6 mails on the subject of standalone building between Sept 7 to 9, 2009, referring among other things to comments made by Oliver Canyon concerning bug #2217 and a patched Rev stack also concerning standalone building. Klaus Major and you participated in that discussion as did others. But this information from Oliver Canyon was apparently not sufficient, why else had Klaus encountered so many difficulties in writing a standalone builder? 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 As I noted earlier, I've been using this info to make a new standalone builder, which I'll donate to the MC IDE project. Richard, this is really great news. Many, many thanks to you for this "donation"! I should note that mine only builds desktop standalones, and does not support RevWeb or mobile at this time. I'll probably get around to adding mobile support, but RevWeb is of no interest to me so if anyone wants that they'll have to add it to the donated stack once it's available. I think a desktop standalone builder is a giant step forward at the moment. Add-ons for web and mobile development could follow later if really needed. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Again, thank you Richard and best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [MC_IDE] Quick Poll
I am somewhat late in answering the poll and will post it both to the
Yahoo-MC list and the Runrev Metacard list.
Ken Ray schrieb:
I'd like to take an informal poll to get an idea of how many people are
using the MC IDE, and to what extent. So if you could just reply to this
email with your answers to the 6 questions below, that would be great.
Thanks!
Ken
METACARD IDE POLL ---
Development (up to, but not including standalone/web/mobile deployment)
===
1) What percent of the time do you use the MC IDE for LiveCode
development,
and what percent do you use the LiveCode IDE?
About 90 percent MC IDE, that makes a maximum of 10 percent for Livecode.
2) If you use the LiveCode IDE at all, what do you use it for, and why?
For special features not yet available in the MC IDE, e.g. manually
resetting the points of a polygon.
Deployment
==
I'm aware that the current standalone builder in the MC IDE doesn't work
with the latest engines. With that in mind:
First a remark: The Livecode standalone builder surely has improved over
time. We have had situations where it was nearly or altogether
impossible to build standalones of specific stacks, for instance such
that contained a greater number of controls.
And I do not like the interfering of the Livecode standalone builder
with the building process, e.g. putting into the stack a number of
unwanted front- and backscripts or unnecessary code of the cRevGeneral
kind. I want my standalone to contain what I think it should contain.
Also there were problems with the Livecode standalone builder (did not
yet test if this issue has been resolved with the last build 4.6) when
you had embedded your own partially costumized answer dialogs with the
possibility to set the exact loc of the dialog, like we can do with the
Metacard dialogs.-
1) Do you build standalones with the MC IDE at all (either because you're
using an older version of MC or because you made your own standalone
builder)?
If the necessity arises of course I have to use an appropriate version
of the MC IDE.
I would very much like a new MC IDE standalone builder with the
simplicity of the earlier MC IDE versions.
There must be a way to achieve this, Klaus Major had been working on it,
but the difficulties he encountered apparently were too great and his
time budget he could allot to the task were insufficient.
When Revolution had been launched as a separate product; Kevin Miller
had promised that MC compatibility would be fully preserved. I see this
new structure of the Livecode standalone builder as a definite step away
from this promise. Kevin himself should have supplied us with the means
to program a new MC IDE standalone builder.
I hope there can be a cooperative enterprise of MC IDE users to
eventually produce a MC standalone builder.
I suppose, Richard Gaskin has found solutions to all this? Would it be
possible that he could share his version of a standalone builder - or
offer it as a starting point for a new MC version?
2) Do you build standalones with the LiveCode IDE? If so, is it
because you
can't with the MC IDE or because you prefer the LiveCode IDE? If you
prefer
it, then why do you prefer it?
As I already have stated, I do not prefer the Livecode IDE. There quite
a number of reasons, which would take long to elaborate.
I am rather forced sometimes to use the Livecode standalone builder in
the temporary absence of a MC version.
3) What percent of your projects are to be deployed to the web plugin?
At present none.
4) What percent of your projects are to be deployed to a mobile device?
At present none, too. I haven't bought any of the mobile add-ons for two
reasons:
- they are still in a initial phase of development, and
- the changed pricing and licensing conditions indeed do not appeal to me.
As a commercial license holder until 2013 - a license I bought out of
solidarity with RunRev, prompted by a cry for financial support some of
us did receive some time ago - I have just had a short discussion with
Heather and Kevin about the pricing and licensing terms for mobile
add-ons. I am still not quite clear about the terms and I have to
continue this discussion, but I see for instance that the licensing
period is determined solely by RunRev ("until the next paid update"),
which could be considerably shorter than a year. I would appreciate a
licensing period of at least one year or - if there is no paid update
within that year - until the the next paid update.
What is more, I cannot find information about how much updates woukl
cost - usually update prices have been considerably less than the full
price for a version. And there seems to be no possibility to get a trial
version of a mobile add-on
END POLL ---
Thanks for your answers! It will help drive the direction of the IDE...
__._,_.___
___
metacard mail
Re: MC IDE 4
Hi Klaus, I am sorry to hear about your troubles and your personal situation and wish to express my sympathy to you and for your valuable work for the Metacard and Rev community during many years. Given your innate strength and resilience, I hope and think that you will soon recover and reach a new state of normality and success. Best, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Control browser
"J. Landman Gay" wrote: Anyone else having trouble with the control browser when trying to edit objects in a background? Frequently I click on an object and it immediately unselects. I can change the object via the message box (i.e., set its color or layer, etc.) and I can select it manually with the edit tool. It may be because I'm working on so many HC conversions. I've set the HCAddressing to false but it doesn't help. The same behavior occurs in Rev sometimes, so it may be HC-related. Thought I'd check. Does not happen here. If I click on an object in a group, the Control Browser immediately switches to display all group objects and the selected object stays selected (WindowsXP, Metacard/Rev version 3.5). Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Standalone Building
Klaus wrote: Still unsure what "RevStandaloneSetting" has got ot do with MC? Stack "RevStandaloneSettings" with its substack "RevSaveAsStandalone" of the Rev IDE is the equivalent (and something more) of our Metacard "Standalone Builder". I tried to explain in my last post how Oliver Kenyon's solution to bug 2217 might work with the patched stack "RevStandaloneSettings" and the new custom property (introduced as a workaround by Oliver), namely "cREVKeepDevelopmentProperties". If this property is *not* set to true, the present standalone building in the Rev IDE will even proceed to remove development properties when there are none - as in stacks produced in th MC IDE, and this will lead to these everlasting standalone building processes of possibly several hours.. And: the present file "Standalone" of the Rev IDE which we presently use als in our standalone building - instead of formerly "MC.exe - can no longer used for standalone building neither in the MC nor in the Rev IDE. Meaning, if this - although maybe temporary - present workaround or proposal of Oliver is to be transferred into our IDE, we need to set the property "cREVKeepDevelopmentProperties" in our equivalent of stack "RevstandaloneSettings" namely in our "Standalone Builder". Unless, of course, the whole thing will be resolved by the Rev team in a different way other than Oliver's workaround. Everything's clear? Best, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Standalone Building
From: Klaus on-rev : I can add as many checkboxes as you like :-) , but what exactly should this one be good for? This property "cREVKeepDevelopmentProperties" has no meaning in MC, but maybe I am misunderstanding you? Klaus, It could have meaning for us in the future. The present procedure in Rev 4.0-dp4 with Oliver Kenyon's patched stack "RevStandaloneSettings" - as I assume - is now like this: 1. You create a custom property "cREVKeepDevelopmentProperties" in the stack that shall become a standalone and set it to "true" 2. The patched stack "RevStandaloneSetting" checks this custom property, and if "true", it tells the "engine" not to remove the development properties 3. The file "Standalone" - in the case of Windows - in folder "Runtime/Windows/x86-32/Standalone" is no longer needed or used. The command "Save as Standalone Application" in Menu "File" of the Rev IDE is then sent directly to the Rev engine to build the standalone - without using the file "Standalone" as it was necessary before When you remove file "Standalone" from the "Runtime" folder - or delete it completely - this has no longer an effect on standalone building. Hope this is correct and helps? Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Standalone Building
Richard wrote: For lazy people like myself, the link to that report is: <http://quality.runrev.com/qacenter/show_bug.cgi?id=2217> The full sentence in which RunRev's Oliver Kenyon suggested the need for an engine change is worth noting: To fix the issue, we will need to make an engine change, possibly the addition of a "repeat for each control" loop form. So rather than something irritating, it's actually quite cool: imagine if we had the ease of iterating through controls so simply. Nice stuff - glad to see they're thinking along those lines. I did not grasp the meaning of this "engine change" at first, I had been too afraid that we could run into troubles when trying to cope with an engine change. In the meantime I have used the patched stack "RevStandaloneSettings" along with the additional command "set the cREVKeepDevelopmentProperties of this stack to true". Standalone building in the Rev IDE with these changes is now nearly as fast as in the MC IDE. The option of decreasing stack size by removing development properties added by the Rev IDE could and should IMO be implemented in the form of a tool separate from the standalone-building process. For the Metacard IDE this could mean that we integrate command "set the cREVKeepDevelopmentProperties of this stack to true" into our Standalone Builder - possibly in form of a checkbox button - with the default setting to true. I have responded to Oliver Kenyon's comments directly and as a newly added comment to bug report #2217. See the address Richard provided above- Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Standalone Building
There has been movement from the side of the Rev team concerning this issue. Read comment #10 that has been added to my bug report #2217 today. They confirm that the problem is indeed removing the "development properties". What irritates me is that they speak of a necessary change to the *engine*, which kind of engine is involved her? What does "(ide) engine" mean, which - according to the engine-change log - will implement the standalone building in dp4 and in the future. If this engine is identical to the Revolution engine, then we - as MC-IDE users - could possibly get problems? How must standalone building with the new "engine" be configured to work in the MC IDE? In the attachment of Comment 11 to bug report # 2217 you find a patched Rev stack for standalone building to be used with the command (in Comment 10) "set the cREVKeepDevelopmentProperties of this stack to true".- I will respond to the comments of Oliver Kenyon, and I like to notice that our present discussion has now produced first results. Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Standalone Building
Another additional remark: I just looked at Bug report 2217 which I sent on Sept 20, 2004, five years ago. Report #2217 "New troubles with standalone building and players for multi-fields stacks" is still labeled as "new" A last commentary from my side had been added two years later "Comment #8 From Wilhelm Sanke 2006-04-01 03:41:37 [reply] ---" Nothing has been resolved up to now. Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Standalone Building
An addition to my last post: I found more detailed data about the creative involvement of Monte Goulding in 2004 in the "Read about "Standalone Builder" bug (Bugzilla 2217)"-text where I quote from a post of mine to the improve-revolution list on Sept 20th, 2004 (See stack "Testcolors 1600" in file <http://www.sanke.org/Software/RevTestStacks.zip>: Subject: New troubles with standalone building and players for multi-fields stacks The tests described below were conducted on a Windows XP machine with 2.5 GHz. The standalone build time for my 3300-fields teststack was down to 20 seconds when Monte Goulding had modified the standalone builder of version 2.2B1 on March 5. With version 2.5R2 build time has again reached an extreme length of 40 (forty) minutes. CPU use during the build time is 100%. Build time with the Metacard Standalone Builder is 1 second! Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Standalone Building
ot; by front or backscripts) seem to play a role in other IDE processes, too. Example: Deleting the ten thousand fields using the MC IDE takes 6 seconds, deleting them in the Rev IDE takes 7 minutes, meaning this process is 70 times slower in the Rev IDE. Interestingly, these results are independent of the fact whether the ten-thousands field had been created in MC or Rev. It seems that the Rev IDE looks for "development properties" even in the case that none are existent.-- I sincerely hope that the Rev developers will resolve such problems in the near future, and I also hope very much that standalone building with the Metacard IDE will not be effected by the new procedures announced for Rev version 4. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Metacard 4
This may have been already noticed here, I just want to make sure: The Rev "Standalone" files - necessary to build standalones - of versions 4 dp3 and dp4 do not work with the Metacard Standalone Builder. Version 3.5 does. I experience this on Windows, but did not test on MacOS. We need to make sure (Klaus?) that the final version 4.0 *will* be compatible with our Standalone Builder. Concerning Richmond's assessment of Metacard: Metacard is not going forwards; it is now just an old, passé user interface jammed onto an engine that deserves and requires something a lot better; and that something is already well developed: Runtime Revolution. Please, take look at my two contributions to the recent thread "Practical limits on object counts" on the use-revolution list. For a number of - maybe very personal - reasons I do roughly 95 % percent of my development in the Metacard IDE. Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
RE: Still here
Just to repeat here what I have already stated several times: I use the MC-IDE for about 95% of my programming. The reasons for that are many. One feature I like and use very much is the "Control Browser", which guarantees quick access to all the objects on a card. My sincere thanks first to Richard Gaskin and now to Klaus Major for their commitment to preserve and further develop the MC-IDE. Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Gradient tool?
On Mon, 16 Feb 2009, Klaus Major wrote: Hi Richard, Anyone make a gradient tool for MC 3.0? Not that I knew. If not I'll see what I can whip up, but it sure would be handy if it were available right now. :) Feel free to create one :-) -- Richard Gaskin Fourth World Media Corporation ___ Best Klaus Depends what you mean by "gradient tools". Bernd Niggemann and myself we have integrated the Rev. 3 gradient tools into the sample stack "More about Mask Rev3" <http://www.sanke.org/Software/MoreAboutMasksRev3.zip> which uses some possibilities of the gradient tools to create gradient masks. See card "using gradient tools" of this stack.. But there are several other stacks and tools to be found in our Metacard/Rev community which deal with gradients in different ways. For my part, I might mention various algorithms contained in my "Imagedata Toolkits" that either transform photos into gradient patterns with varying widths and heights of the gradient elements inside a picture or where uni- and -bi-directional gradients are created from scratch. These latter "gradient tools" do not rely on the new Rev 3 features, but can be used with any version of Metacard. Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MC IDE 3.0
Many thanks to Klaus and Jacqueline for fixing the Font Chooser bug and other problems so quickly. As I also continue to work with engine 2.9, I have transferred the new Font Chooser and also substack "Importer" to the 2.9-IDE. The previous "Importer" stack opened with tab "Image" as activated, but with the text of tab "Snapshot". Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Engine 3.0 gm3 unable to open legacy stacks on MacOS?
Klaus Major wrote: Another question: Is there a way to start the 3.0 engine inside the MC IDE and coming up as "Metacard" (like it was possible with earlier versions)? After I rename the "Revolution" file deep down in the OS bundle it refuses to start. You will also have to change some strings in the "info.plist" inside the app bundle! I can send you an "empty" app bundle without the actual engine, if you like. Then you will only have to put the Rev engine into it, rename it to "MetaCard" as you did and that will do the trick. Thank you, Klaus! Works like a charm. As I not a permanent and exclusive user of MacOS I need to learn a lot about the new structural elements and especially about "plists". Putting the Rev engine into the contents/MacOS folder of the bundle you sent me first produced an error message (in German on my machine) stating that this program is not supported by the architecture. But as you indicated, the engine has to be renamed to "MetaCard" and then all is fine, even a Metacard icon shows. But apparently there are more ways to do this. Again following your advice above about changes to the plist file, I tried that before your bundle arrived here, i.e. I did just that in the folder into which I had put the complete Rev bundle along with the MC IDE. Here engine and MC IDE are started, only the tool bar shows "Revolution" as the program. I edited the plist in only two places and renamed from Revolution to MetaCard - CFBundleExecutable and - CFBundleName and now "Metacard" is displayed in the tool bar - *without* having changed the name of the engine from Revolution to MetaCard. If I rename the engine to "MetaCard" then the program does not start in this case. The only thing that differs from your bundle solution is that with my "plist-changes only" the Metacard bundle shows a generic application icon with an "A" in the icon. Once again, thanks for your help. Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Engine 3.0 gm3 unable to open legacy stacks on MacOS?
Klaus Major <[EMAIL PROTECTED]> wrote: What errors/warnings do you get? But I will also take a look a the appropriate "open" scripts i Not necessary anymore! I found out that the legacy stacks got corrupted (that was one of the error messages) while I transferred them with a firewire connection from my G4 MacBook (OS 10.3.9) to my newer MacBook Pro - or maybe when transferring via an USB stick from Windows. Don't know exactly what was the cause, but will find out soon. Legacy stacks created with Metacard 2.6.5 on my Macbook Pro *can* be opened with later engines and 3.0 in both IDEs. Another question: Is there a way to start the 3.0 engine inside the MC IDE and coming up as "Metacard" (like it was possible with earlier versions)? After I rename the "Revolution" file deep down in the OS bundle it refuses to start. You will also have to change some strings in the "info.plist" inside the app bundle! I can send you an "empty" app bundle without the actual engine, if you like. I would appreciate that very much. Thanks in advance! Best regards, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Engine 3.0 gm3 unable to open legacy stacks on MacOS?
I am in the course of updating my old "MC-Player" (for mc and rev files) using the 3.0. engine. One incentive to do this was to provide users of some of my stacks with embedded dialogs a possibility to open them without being annoyed by warnings and error messages in the Rev IDE. On Windows (XP) this works fine, I can open stacks of all stackfileversions, pre-2.7 and >2.7 (and I have included the option to save 2.7-stacks as legacy stacks like in our MC IDE). However, on my MacBook Pro the MC-Player only is able to open stacks with stackfileversion 2.7. The mc- and re-extensions do not matter here. I have now tried to open legacy stacks on MacOS with engine 3 both in the Rev IDE and the Metacard IDE; all I get is either nothing or error messages. What are your experiences? Could this be somehow related to the problems I described in my post to this list "Strange change of file associations with Rev 3-gm-3" on Sept 20?- = Another question: Is there a way to start the 3.0 engine inside the MC IDE and coming up as "Metacard" (like it was possible with earlier versions)? After I rename the "Revolution" file deep down in the OS bundle it refuses to start. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Font Chooser in MC-IDE 2.9 and 3.0b
Jacqueline wrote: Good point, this has bothered me for a long time but I've been too busy to look at it. I just tried a simple fix which seems to work, but it needs testing. In the stack script of the Font Chooser, there is a "mouseup" handler. It has a switch structure. If you add the "refresh" command after the switch is done, it seems to work: on mouseUp if the selobj is empty then exit to MetaCard end if switch the short name of the owner of the target -- SWITCH STUFF HERE end switch refresh -- ADD THIS end mouseUp Thanks Jacqueline for the hint, but that does not work for me here on Windows XP. I looked through the various scripts of the Font Chooser and tried variations, but no luck so far. Even reactivating the bug fix in switch the short name of the owner of the target case "Textfont" ## -- bug fix 6/25/07 JLG ## Not a bug really, just calling the wrong command ;-) ## if it = "none" then get empty ## end bug fix ## February 2008 KM ## This way ALL selectedobjects get their textfont set! made no difference.-- Have to return now to browsing through a 150-pages master's thesis about bilingual education at schools in Oregon, which is surely interesting, but very much lacks a sytematic scientific structure. Hope I can reach an appropriate evaluation that satisfies all people involved. Best regards, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Font Chooser in MC-IDE 2.9 and 3.0b
If the font of a button is empty and you open the font chooser it displays "none" as the font name as it should. Then after having chosen a font, e.g. "Arial", nothing is visible in the "Size" and "Height" fields as a default. Using the scrollbar of the "size" does not display any option, nor is it possible to type anything into the "size" field. The necessary workaround seems to be - maybe there are more possibilities - to check the "Bold" button. After checking "bold" you can now type a value into the "Size" field and then you also can use the size scrollbar to display other values. Likewise the "Height" field now contains values. When you have saved the "New Button" and reopen the Font Chooser "@Arial Unicode MS" is now hilited instead of the originally selected and saved "Arial". Seems we need an overhaul of the Font Chooser. Sorry to cause extra work for the authors of the Font Chooser, who have devoted so much of their valuable time to produce a modern IDE. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Strange change of file associations with Rev 3-gm-3 engine
Rev engine 3-gm-2 displays both *.rev and *.mc-files in the "open stack" dialog as "Revolution stacks". Engine 3-gm-3 restricts the displayed stacks to files with the "*.rev" extension; even when you choose "All files" the display of mc-files is suppressed, but other files like dlls and txt files are shown. It is even impossible to enforce the display of mc-files by typing "*.mc" into the file name box of the open stack dialog. Putting the Revolution.exe engine 3-gm-3 into the Metacard IDE shows the same restrictions: No mc-files are displayed. However, when you rename "Revolution.exe" to "MC.exe", both "Revolution stack"-files "rev" and "mc" are displayed in the "open stack" dialog - like before in gm-2 with "Revolution.exe". This holds for both IDEs, the Revolution and the Metacard IDE. The consequence for users that primarily work with the Rev IDE - but wish to access Metacard files once in a while - would be to rename their Rev engine to "MC.exe". This works fine within the Rev IDE. Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: setting up mc from scratch
metacard wrote on Fri, 01 Aug 2008 05:03:50 -0700: Hi, i´ve just tried the setup-stack with Rev 2.9 studio. Worked without problems. I can start and use the Metacard ide. Only building a standalone results in an error, that the Metacard.exe is not a MetaCard engine. Does this result from my studio license? Regards, Matthias What you need is a file named "Standalone" which is used instead of the MC engine to build standalones. You can find that file in the "Runtime" folder (at least of the Rev Enterprise version, but maybe with "Studio", too?) Best regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: 2.9.0-dp-4
When the 2.9.0-dp-4 engine is used within the Metacard IDE, the Property Inspector and Script Editor are not accessible with right-click, but only through menu button Edit and Object Properties. Imagedata handling - tested with the various scripts used in the teststack attached to bug # 5113 <http://www.sanke.org/Software/TestStackPaintcompression.zip> - is now overall 10% slower with dp-4 compared to the performance of the 2.9.0-dp-3 engine. The speed of dp-3 had nearly reached the performance of engine 2.6.1, which seems to have been the fastest engine concerning imagedata processing so far. Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: BvG Docu and home stack in Metacard
On Thu, 07 Jun 2007, Ken Ray wrote: 3) Add a substack to your main stack window called something like "BVGExternals" and a custom property to your main stack window to hold a path to the revXML external. When you launch check to see if you're in MC. If you are, check the custom property to see if it has a value. If it doesn't, ask the user to locate the revXML external and store the path in the custom property. If it *does* have a value, verify there's a file at that path. Once you're sure you have the external available, dynamically "set the externals" of stack "BVGExternals" to the revXML external path, and then bring the BVGExternals stack into use with "start using stack 'BVGExternals'". This will load the revXML external on the fly and make it available to your main stack window. Another way to do this: put "revxml.dll" and the Rev folder "documentation" into your MC folder (you can delete most of it afterwards). Open "BvG_docu" stack and add "revxml.dll" under "components, externals". Do the same for substack "docsLib" after topleveling it. Save "BvG_docu" and quit Metacard. Start MC again and stack "BvG_docu" and follow Björnkes procedures. Folder "documents" now contains an additional subfolder "BvG_docu". This is the only thing you need to run the dictionary, You can throw out folders and files "packaged_XML", "rev", "pdf" (unless you intend to use these special rev-files or the PDF user documentation), "glos.index", "glos.rsindex", and "dict.index". The remaining "BvG_docu" folder thus adds 5.3 MB to your Metacard folder, instead of the 24.6 MB of the complete Rev documentation.-- I notice some differences of Björnke's stack to my old "searchdocsXML2.61" stack (which was based on the Rev help files of version 2.6.1), among them: - Björnke concentrates on the dictionary, and is more or less forced to do this because the former "Topics" as XML-files have now been replaced by a PDF "User Guide". My searchstack could search through all XML help stacks at once (if selected) as the former Rev documentation was less fragmented. - Björnke searches on a one-word basis and filters out the relevant dictionary entries, the first one as the full article, the others with their listed names which can then bring up the respective entries. My searchstack allows to search with any string length and number of words, and then lists all found lines (with the searchstring colored) along with their entry addresses, of which the first is displayed as a complete help entry. Thus cross-references could be detected that possibly were not envisaged by the authors of the help files. I mention this only to point out different possible search approaches. I think Björnke's stack is a long-needed and valuable contribution especially for the MC community. Best regards, -- Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] "Thumbs and Slides"
I have "revved up" an older "thumbs" stack since we started the discussion about creation and modification dates of images and have added a "slides page" to the stack where the images can be displayed full-screen either step-by-step or as a slide show. (<http://www.sanke.org/Software/ThumbsAndSlides.zip> or from the "Samples" page of my website) Although there are a number of slide stacks around in the Rev community and elsewhere, I offer this stack for public use and for those that would be interested to test yet another variant. I find it satisfactory and in some respects better than the image and slide tool supplied with WindowsXP. The layout of the controls on the "slides page" adapts to any screensize and the height of the stack is chosen to enable the use of the stack even on most modern laptop screens with a size of 1280x800. With most controls turned off on he slides page (using the "hide controls" button) the slide show offers an almost undisturbed view of screensize images, whose display tempo can be adjusted any time even during a slide show. From the "Introduction": Thumbs page: The first 12 JPG images from the chosen folder are displayed as proportionally resized to fit into the maximal width and height of the 240X180-pixels thumbs. The total number of images is shown in the field above image one. You can choose a different image to begin with using button "choose start image" The date shown after the image names is the "modification date", which is in most cases identical with the creation date of the image. Clicking on "next images" or "previous images" will load the next or previous 12 images from the folder. Clicking on one of the thumbs will display the chosen image in full-screen view on the "Slides page". Slides page: Left-clicking on the full-screen image returns to the "Thumbs Page". Button "controls" shows or hides the controls for setting the image dimensions, to expand or shrink the image, and to start and stop a slide show beginning with the actually displayed image. The options to be chosen from the grouped radio buttons in the topleft corner are: - "screen size": the image will be resized to the screensize irrespective of its own dimensions. - "real screen size": the image will be resized proportionally to fit into the rect of the screen. - "real size": the image is displayed in its proper size, meaning that when the image is larger than the screen rect it is displayed enlarged and mid-centered (which is a tolerable and nice enlargement effect possibly up to image sizes 284x2136, depending of course on the screen size and the fact that essential image information is contained in the middle of the image. Button "enlarge" enlarges the image proportionally in subsequent steps. Button "shrink" does just the opposite. Right-clicking with mousedown on the image and dragging moves the image around on the screen, which may be useful for inspecting details of an enlarged picture. Buttons "next slide" and "previous slide" (or the arrow buttons when they are hiddden) navigate to the next or previous image. If the last or first image of the folder is reached, "next" or "previous" are continued nevertheless according to the image order in the folder. Button "start show" starts a continuous and possibly endless slide show, button "stop" stops the show - as does using any of the buttons "next slide", "previous slide", or the arrow buttons (or returning to the Thumbs Page by clicking on the image). During a slide show the dimensions of the displayed image (sreen size, real screen size, real size) can be changed any time - or "hide controls" and "show controls" can be applied - without interrupting the show. It is also possible to change the "display time" of the image during a slide show by adjusting the slider control in the bottomright corner. --Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Test stack "speed of imagedata processing and paintcompression"
On Mon, 04 Jun 2007, Richard Gaskin wrote: I had thought that you'd earlier discovered the difference between MC and Rev to be simply that Rev's boot script changes the default compression. This would imply that anyone who uses MC or any other collection of stacks as their IDE could bring the same performance in any other IDE by simply changing the paintCompression back to the engine's default. What am I missing? -- Richard Gaskin Fourth World Media Corporation Concerning your statement and question, nothing. I submitted the bug report after a longer discussion on the improvement list and had been asked by Mark Waddingham to present a test stack. The discussion also revealed that the Rev team was apparently unaware of these issues. What astonished me in my tests was the fact that under specific circumstances the slowing down of imagedata under PNG compression was far greater than expected, namely 12 times compared to RLE when retrieving imagedate out of a custom property. I thought it useful to share my findings with the Metacard list, too, and - although the basic fact about the boot script has been mentioned before on this list - as memory usually is short, I think it would not hurt to mention this fact again. Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Test stack "speed of imagedata processing and paintcompression"
I have submitted a bug report to the "Revolution Quality Control Center" (what a modern neoliberal term) to which number 5113 was assigned. I post the report to this list, too, because those Metacard users that intend to make a transition to the Revolution IDE may run into unexpected difficulties when they deal with imagedata processing in their stacks. The default setting for the paintcompression in all engines is RLE. The Revolution IDE changes that setting to PNG, which is then transferred even into Rev standalones via an encorporated script. Rev users would be well advised to set the paintcompression to RLE (or at least to JPEG, which is only slightly slower) in their openstack handlers. Here is the text of my report: "There is a test stack with test and result pages that demonstrate the reported effects (you need of course to launch the stack with the different engines). <http://www.sanke.org/Software/TestStackPaintcompression.zip> Because of the included test images and a possible "full-screen" view the stack has a zipped size of 14 MB. I stripped my emerging Photo Tool down to four filters and three images, the first with 5 different sizes, the other two with a size of 2048x1536. Derek Bump's "convolve.dll" is included. Apart from the individual structure of the respective script, the speed of imagedata processing depends on two additional factors: - to some extent on the engine version (and IDE), - as a more important factor on the paintcompression. The fastest engine is version 2.6.1 (Metacard 2.6.6). The speed difference to engine version 2.8.1 - while using the same paintcompression - can reach 33% (compare the results for the "scripted-matrix-version filter"). Concerning the factor paintcompression, the most extreme results of the tests demonstrate that using PNG paintcompression can be up to *twelve times* slower than wih RLE. The speed difference extends to 400% when looking at the results for applying the DLL, PNG paintcompression is here four times slower than RLE, JPEG is somewhat slower than RLE. One test concerned the retrieval of image contents - size 2046x1536 - from imagedata and compressed imagedata stored in custom properties. With the paintcompression set to PNG, image retrieval is up to twelve times slower than with RLE. In this case, there seem to be only minor engine influences. " An addendum I sent today to the improve list: "Contrary to the fact that PNG paintcompression may slow down the speed of imagedata processing considerably, "text-of-image" data are apparently not affected, as you can see when you use button "sample image - five sizes" of the test stack, which stores the image contents as text-of -image data." --Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: The Aborted Plunge (Metacard to Revolution)
On Tue, 29 May 2007, Tariel Gogoberidze wrote: 1) Wilhelm Sanke wrote excellent stack "SearchDocs XML 2.6.1.mc" a while ago. http://www.sanke.org/MetaMedia/Screenshots.htm Unfortunately it can process only pre vs 7.x Rev documentation (in operates on vs 2.6.1 to be precise) but it covers almost all my needs and the great strength of this solution is that it finds all instances of the search word, even in descriptions and comments. In a way it makes instant cross indexing of the whole documentation (Dictionary + FAQ + Topics) by given search word. After the change of the file format of the Rev documentation I was busy with other things and not sure whether the Rev team would not change the format again in the near future. Therefore I personally continued to use my last "Searchdocs" stack, which I still use rather frequently, and discontinued any effforts to adapt the SearchDocs tools. I will take a look ar Björnke's stack. 2) For the latest docs (Rev 2.8.1) I use a stack from Björnke http://bjoernke.com/runrev/stacks.php Best regards Tariel As a fast script-search tool I have used my private "MCBrowser", which I did not offer as a public tool as there were other similar or equivalent tools around (e.g. Klaus Major, Richard Gaskin). I have now put it on my website for download, inspection, and possible improvement. The stack is from 2001 with minor bug fixes later and is a really very fast script-search tool. There maybe some bugs in it, which did not hurt me much as I used the stack only as a personal tool. It think it could be easily enhanced to include substacks, but my present work demands prevent any further development at the moment. From the description on my website: "The Metacard version of the above "RevBrowser". It is basically an enhanced and refined Metacard "Control Browser" with an added fast-search function that lets you search all scripts of a stack. The search tool lists all found scripts lines - with the searchstring colored - along with the addresses of the objects. Clicking on the object address enables you to edit the respective script. (Stack is from 2001, may have some bugs, and especially is unable to deal with "unplaced" groups)." You can get the stack from here: <http://www.sanke.org/Software/MCBrowser.zip> or from page "Tools and Samples for Development" <http://www.sanke.org/MetaMedia/SamplesTools.htm> Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] Preview Gallery for "Imagedate Toolkit 3"
I have uploaded a preview gallery for the forthcoming "Imagedata Toolkit 3" at <http://www.sanke.org/MetaMedia/PreviewToolkit3.htm> An interim version of toolkit 3 will be released during the next week. What's new in interim version 3? While the focus of the "imagedata toolkit 2" was on "hues", toolkit 3 concentrates both on median-despeckle filters and the distortion and deformation of images to achieve various kinds of "painting" effects. Both filter categories have to be used in conjunction to produce such effects. There are 12 such median-despeckle filters, the most powerful of them is "despeckle extreme", which does not only remove noise, but also minor details, thus achieving larger color areas in an image. I have discarded the "Kuwahara" filter of "Imagedata Toolkit 2". While it was a fine exercise to port this known filter to Revolution, it was really the slowest of my adapted scripted filters and much less powerful than my "despeckle extreme" filter, which is also 3 times faster. The distortion/deformation filters comprise: - various kinds of multi-pixel noise - solid and blended rects of different sizes - the dissolution of images by shapes of various sizes (ovals, rectangles, regular polynoms - triangles, rectangles, pentagons -, and the application of this dissolution either at random or in a systematic fashion - dissolving the image with vertical columns of shapes. Other improvements of interim version 3: - the slight color shift when using the "jitter" filter has been fixed (there was a one-char typo) - a "wet paint" filter has been added to "jitter and noise" - the scripted "blur" filters (as opposed to matrix filters) now comprise "progressive blurs" with pixel distances vertically and horizontally from 2 to 8 and for "extreme blurs" with pixel distances from 10 to 60. These blur filters with their precise and powerful effects are genuinely new and nowhere else to be found. - a "venetian mirror" option has been added under "mirrors": reflections of any size can be added inside the images horizontally and/or vertically, which also provides the possibility to produce kaleidoskop-like pictures. - special "max" and "min" effects have been added as a variation of the despeckle-median filters (using the median algorithms, but substituting the median function by minimum and maximum), which then need another - despeckle or lithography - filter to achieve worth-while effects. - images can be exported both as JPEG and PNG.-- The final "Imagedata Toolkit 3", which probably will be released in a month, will also have the following additional features: - adding horizontal, vertical, and diagonal "gradient noise" - replacing colors: selecting a color-to-be-replaced by clicking on the image and choosing a replace-color by either also clicking on the image or a color wheel. This color replacement can be implemented for a specific color or a selected color range with the additional option to choose a computed gray-average as the basis for replacement - simplifying colors: similar procedure as above: the selected color will replace a defined color range ´ - adding transparency to selected areas of an image, implemented also in a similar fashion as with replacing and simplifying colors (see above). As the one of the main features of the Imagedata Toolkit are two superimposed images, the underlying image will appear in the transparent areas, thus producing a new image that can then be saved or exported as a new non-transparent image.- The current "Imagedata Toolkit 2" is still available - for those interested to experiment with structures and colors in images and photos in the meantime until Imagedata Toolkit 3 will be released - at <http://www.sanke.org/Software/ImagedataToolkit.zip> Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Making a pasted image opaque
Postscript: One problem of my proposed script is that restoring the original opaque colors of the image is only possible if the alphadata values are above 0. If the transparency was set to 0, resetting the values to 255 will result in dark or black color values for all alphadata chars with 0. In the forthcoming version of my Imagedata Toolkit the transparency effects have "1" as the value for the greatest transparency, which preserves the original colors when you change the transparency level. So indeed, the safest way is to follow Scott Rossi's proposal to take a snapshot of the rect of the image against a white background. Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Making a pasted image opaque
On Thu, 01 Mar 2007, Scott Rossi and David Epstein wrote: Recently, David Epstein wrote: > When I use Command-control-shift-4 and drag, Mac OSX copies part of > the screen to the clipboard. When I put that into a MC image, the > "white" part of the image is transparent. Both for appearance's sake, > and because I want the image to receive mouseDown messages even when a > white area is clicked, I'd like to make the image I've pasted fully > "opaque". Is there a way to script this transformation? One way is create an entirely new image by importing a snapshot of the image against the white of the card. You can then delete the original image if you wish. Regards, Scott Rossi One way to script this is like below: "on mouseUp put 0 into Counter put the alphadata of img x into adata repeat for each char C in adata add 1 to counter put numtochar(255) into char counter of adata end repeat set the alphadata of img x to adata end mouseUp" Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Vanishing substacks
I ran the stack again in Rev 2.7.4. Nothing unusual happened, so the Rev
Ide is not the culprit.
Seems to be a rare instance of a "spontaneous creationist phenomenon"
that according to philosophers like Schopenhauern and others ("no effect
without a cause" and " even no real *free will* , but all human actions
triggered by stimuli and motivations") cannot really happen.
-Wilhelm
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Re: Vanishing substacks
On Fri, 19 Jan 2007, Chipp Walters wrote: All I can think of is you're using 'delete stack' somewhere. As you know, it closes a mainstack, but really deletes substacks. -Chipp Thanks for the response. The matter remains as mysterious as before. I checked all control, card, and stack scripts.There are 26 instances of "delete", but only concerning items, chars, lines etc. - nowhere concerning stacks. Also, I am 100% sure that I did not use any "delete stack" commands during the last session (via msg) after which the substacks had disappeared. Probably this is not an item for Bugzilla, but rather for category "There are more things between heaven and earth than you can imagine." I also checked for viruses and found none. It just comes to my mind that I opened the stack in question once with Rev 2.7.4 during the last session to test the speed in the Rev IDE. I will look into this as there are customized answer and ask dialogs as substacks in my stack that maybe somehow conflicted with the controlling superpower of the Rev IDE? But such a conflict would not explain the vanishing of all 6 substacks, of which four are unique without conflict potential. Regards, -Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Vanishing substacks
After reading the discussion about "OT: lost everything, macbook and its HD broken. (Andre Garzia)" on the use-revolution list I had reverted to the somewhat neglected habit to make backups of essential stacks now and then. This morning I found that a stack, which had worked alright last night, had lost all of its 6 substacks, one of them containing a very long script library. Happily, I had made a backup of that stack two days ago and was able to copy the newly added scripts to the backup stack. I cannot remember having done anything unusual when working with the stack, the only thing that was deviating from my usual routine was that I accelerated the Windows shutting down process by cutting the power yesterday. At that point of time, however, Metacard (2.6.6) had already been safely closed. Has anybody seen such vanishing substacks? What could be the possible cause of it? This is on Windows XP. Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] "Imagedata Toolkit 2" released.
Although much more still needs to be improved, I have uploaded the present version of the "Imagedata Toolkit" as an interim release. Any feedback could be addressed to me after the holidays, which I will spend with relatives. For adequate performance you need a 2 GHz computer. The majority of the filters and algorithms need less than two seconds, and a number of them only about 400 milliseconds. Derek Bump's included Windows DLL takes about 180 milliseconds to execute, processing time for non-Windows computers and using the Rev-scripted 3X3-matrix-filters versions is down to 7.5 seconds. The external must be placed as usual in the engine folder from where the stack is opened. The toolkit can be downloaded (8 MB) from <http://www.sanke.org/MetaMedia/Samples.htm>. What has changed in version 2? - The paintcompression is set to RLE in an openstack handler to guarantee the same speed for imagedata processing in the Rev IDE as in the faster Metacard IDE. - The inks for the graphics used to select an image area for duplicating or mirroring (used with buttons "mirrored segments" and "multiply segments") is set to "admin" on MacOS to make the borders of the graphic visible. Other changes: 1. Matrix filters The "external.dll" has been replaced by Derek Bump's "convolve.dll" resulting in a much faster execution - about 180 milliseconds on the average - because no workaround is necessary to resolve the Endian issue of the "external.dll". A "remove borders" command has been added to the script calling the "convolve.dll" to remove the black borders caused by the DLL. A number of matrix filters has been added and the possibilities to create random matrices have been enhanced, e.g. there is even the option to choose decimal numbers for the matrix. 2. "Balance" filters a) "White balance": You can set the white level by clicking on the image or choosing a dialog. There is also an "auto white balance" that searches for the brightest pixel of the image and then sets this value as the new white. b) "Mid balance": This is a gamma-correction feature. The chosen middle value (clicking on the image first or setting a slider) will move the existing 128 level up or down without changing the extreme white and black values. Choosing a value less than 128 will result in a brighter image, choosing a higher value will darken the image. c) "Black balance": Brighten the picture by shifting all color values higher from the new black level. 3. Brighten/Darken A very efficient algorithm has been added here with "proportionally" changing the brightness. 4. Temperature A "temperature" (colder - warmer) option has been added to button "Saturation et.al.". 5. Hues a) "fine tuning": This group at the bottomright corner of the stack is unchanged. Adding and subtracting RGB values "separately" can produce an unlimited number of hues. b) The number of "sepia" options has been increased. c) "Quick hues" (red, yellow, green, blue, cyan) produces quick hues - 400 milliseconds on the average - with fixed added values and can be applied repeatedly. d) "Shift mid hues": This works along the lines of "mid balance". First, click on the image to choose a darker or brighter area. Then choose one of the 5 color-pairs options "red - bluegreen, blue - yellow, lightblue - red, yellow - dark blue, cyan - green". Selecting a pixel with a value below 128 will produce a hue with the quality of the first member of each pair, a value above 128 will result in a hue with the color of the second member. e) "Hues (click first)": The chosen average value by clicking into the image is used to calculate a factor by which the hue (red, green, or blue) will be increased proportionally. f) "Hues dialog": This brings up group "Set Hues" with RGB and HSV sliders (h = hue, s = saturation, v = value/brightness). Changing a RGB value automatically resets the HSV values and the other way round. The color shown in the field at the top of the group is then transferred as a hue to the image using 7 different algorithms producing monochrome, multichrome, or negative hues. This is certainly an over-abundance of hues, but having experimented with a number of interesting approaches to produce hues I have left them all in the stack for the time being. 6. "Fun-tastic colors": This works best with images that contain larger areas of "equal colors", e.g. take the sample image "Red Square Moscow". First click into the image to choose a color value, then apply one of the three fun-tastic options. These options can be applied repeatedly. "Fun-tastic colors" are a variation of
Re: image compression default
Richard Gaskin <[EMAIL PROTECTED]> wrote: That's exactly it: That handler isn't a native message -- what calls it? And once we find that culprit, it may be worth discovering what else it changes from natural engine behaviors. The "revlibrary" stack is loaded together with the Rev IDE and then sends "revloadlibraries" from its preopenstack and preropencard handlers (which are located in group "revlibraries") Besides other things and setting the paintcompression, "revloadlibraries" also inserts front and back scripts. Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: image compression default
On Mon, 27 Nov 2006, Richard Gaskin wrote: Did we ever figure out how RunRev's revGeneral was able to alter the default image compression method when its script contains only handlers that must be explicitly called? -- Richard Gaskin Fourth World Media Corporation What kind of image compression are you asking about? The default of the "JPEGQuality" seems to be set by the engine, at least there is no mentioning of JPEGQuality in stack "revlibrary". The "paintcompression" default set by the engine is RLE, which is then overruled by the Rev IDE from stack "revlibrary" in folder "toolset" in the script of group "revlibraries" and its handler "revLoadLibraries": "on revLoadLibraries global gRevSmallAppIcon,gRevAppIcon local tBtn,tLine set the paintCompression to "png" -- match the engine This handler is also added to each standalone. (see my post from Thu, 02 Nov 2006 to this list). Other kinds of compression pertaining to images are not mentioned in the docs. Best, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: (Not) deleting identical substacks - solved.
I noticed that if you delete a substack - using stack "stack components" that is launched from the properties palette - from a stack "mystack" that has a name (like "color chooser" or "answer dialog") identical to one of the substacks of stack "mctools", both substacks are being deleted! The essential script line in button "delete" of group "substacks" of stack "stack components" is "delete stack cname of stack the label of button "Stack Name"" Button "Stack Name" showed stack "mystack" at the time of the deletion. - Using the message box with "delete stack "mysubstack" of stack "mystack"" works - only the substack in "mystack" is deleted, but deleting with button "delete" of group "substacks" of stack "stack components" actually deletes both substacks in "mystack" and "mctools", although the contents of "delete stack cname of stack the label of button "Stack Name"" (button "delete") and "delete stack "mysubstack" of stack "mystack"" (message box) should be the same. I tried a number of variation with ID, the long ID, the owner, the effective filename, but none of these properties or other prevarications helped. Apparently the "cohesion" or "binding" between stack "mysubstack" of stack "mystack" is not strong enough and we would maybe need a new syntax like "delete substack "x" of stack "y". Stack "stack components" that contains the delete button is itself a substack of "mctools" and therefore at first comes across the identical substack in "mctools" and then deletes both identical substacks. The only solution I have found is to move stack "stack components" out of "mctools" and transform it to become an individual mainstack. Now only the intended substack is being deleted and the identical substack in "mctools" remains untouched. The reason why the message box is also a possibility like I reported above - although it is also a substack of "mctools" - seems to be that "stack components" is opened as a palette, whereas msg is opened as "modeless"(?). -- Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
(Not) deleting identical substacks - continued
More findings: - The IDs of the two substacks - one in stack "mystack", the other in stack "mctools" are also identical, as is the ID of the substack-as-a-mainstack in my special repository folder. So ID cannot be used to distinguish between these "identical" substacks. - Using "owner" does distinguish, at least using the message box, like "put the owner of stack "mysubstack" of stack "mystack"" - Using the message box with "delete stack "mysubstack" of stack "mystack"" works - only the substack in "mystack" is deleted, but deleting with button "delete" of group "substacks" of stack "stack components" actually deletes both substacks in "mystack" and "mctools", although the contents of "delete stack cname of stack the label of button "Stack Name"" (button "delete") and "delete stack "mysubstack" of stack "mystack"" (message box) should be the same. Question: Should we try to remove the ambiguity of the "delete" button in stack "stack components" or is the problem perhaps of such a special and rare kind that is not worth spending any effort to fix it? -- Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
(Not) deleting identical substacks
I noticed that if you delete a substack - using stack "stack components" that is launched from the properties palette - from a stack "mystack" that has a name (like "color chooser" or "answer dialog") identical to one of the substacks of stack "mctools", both substacks are being deleted! The essential script line in button "delete" of group "substacks" of stack "stack components" is "delete stack cname of stack the label of button "Stack Name"" Button "Stack Name" showed stack "mystack" at the time of the deletion. Has anybody seen this? Should the script line be changed, maybe including something like "target" or the ID of the stack, to make sure only the intended deletion takes place (not yet tested)? This is on Windows XP with MC 2.6.6. with IDE version 2.6b 11. I looked also at the 2.7.1 IDE: The script of button "delete" is the same as in 2.6b11. Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Another MC-Rev anomaly: "text of image" property
On Tue, 07 Nov 2006, Chipp Walters wrote:
Hi Wilhelm,
Then, if I am correct, setting the global paintcompression to RLE then
'touching' a PNG image (getting and setting both the imageData and
alphaData) will now set the image to RLE instead of the original PNG. Is
this your understanding as well?
Yes.
===
Another interesting difference between imagedata and text of image:
As we know, getting and setting the imagedata will result in a new
formattedwidth and - height defined by the size of the current rect of
the image, meaning at least two things:
- if you change the size of the rect after you have retrieved the
imagedata, then when you set the resized image to the retrieved
imagedata you will get a distorted image at best,
- if you get and set the imagedata without changing the rect, this image
size is now defined as having the optimal quality, i.e. when you now
change the rect you will loose quality when you enlarge the image.
This is apparently not the case with text-of-image. The retrieved
text-of-image data will fit into any rect without loss of quality,
unless of course you expand the image beyond its original size
("original" at the time the image was imported).
Regards,
Wilhelm Sanke
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Re: Another MC-Rev anomaly: "text of image" property
Other details about imagedata, text of image, and paintcompression:
Saving the imagedata will not save the paintcompression format at the
same time. Resetting the image from the saved imagedata will change the
paintcompression of the image to the default global paintcompression.
Contrariwise, saving the imagetext ("text of image") *will* indeed save
the paintcompression format. No matter which global paintcompression
format is set afterwards, when the image is restored from its saved
imagetext, it will possess its original paintcompression.
Unfortunately, the text-of-image data cannot be manipulated in any
consistent way like the imagedata. At least, I did not find a way to do
that.
This means that the only possible use of text-of-image could be storing
and restoring images (when RLE is *not* set as the paintcompression).-
As I already reported, when the paintcompression is set to "RLE" and you
save the imagetext and then restore the image from the imagetext two
things happen:
1. The alphadata are set to 0; the image becomes invisible
2. The image is still there, but its imagedata colors are reduced to one
monochrome color, which you can see when you change the alphadata back
to 255 - opaque.
I tested this also using a MC/Rev-scripted histogram function.
Maybe this feature - getting an invisible monochrome image when
imagetext is saved and reset with "RLE" - should be reported as a bug?.-
It would also constitute a valuable contribution to our discussion, when
someone from the Rev team would enlighten us, why they have chosen PNG
paintcompression as the default format for the Rev IDE and Rev
standalones - especially in the light of the fact that all imagedata
manipulation is slowed down considerably with the PNG format.
Regards,
Wilhelm Sanke
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Re: Another MC-Rev anomaly: "text of image" property
Chipp Walters wrote; (snip) Perhaps if I tweak the imageData on the PNG with paintCompression set to RLE, it will keep it from showing the gamma change? and Tereza Snyder wrote: For me, using PNG images has a positive consequenceetc. The global default setting of the paintcompression can be different from the paintcompression of an image. An image has the paintcompression of the image format that it possessed when it was imported, i.e. fully imported (like with "put URL "binfile:filename" into img x), whereas a referenced image will have he default paintcompression setting. This is probably what the docs want to state: "If the image was created with the import command, its paintcompression is set to the format of the imported picture file." So you can have all he advantages of the PNG format, although the global paintcompression should be set to RLE. However, the moment you change the imagedata of that image, the paintcompression will be the global one. And, you can reset the global paintcompression any time you wish, for example via MSG. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Another MC-Rev anomaly: "text of image" property
On Wed, 01 Nov 2006, J. Landman Gay wrote: (snip) I take back what I said about the paintcompression being in revCommon. It isn't, it is in the library the IDE loads. It's got to be somewhere else in standalones, since that's what is obviously happening. -- Jacqueline Landman Gay Once we know what to look for it is easier to locate. I made a search with my "revbrowser" which contains a fast script browser. In Rev 2.7.4 the paintcompression is set from stack "revlibrary" in folder "toolset" in the script of group "revlibraries" and its handler "revLoadLibraries": "on revLoadLibraries global gRevSmallAppIcon,gRevAppIcon local tBtn,tLine set the paintCompression to "png" -- match the engine ... ..." This handler is also added to each standalone. Best, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Another MC-Rev anomaly: "text of image" property
On Tue, 31 Oct 2006, J. Landman Gay wrote:
Wilhelm Sanke wrote:
For the above points there are no differences between Rev and MC, but
- The format of the "text of image" property is different in Rev
and MC - tested both in stacks and standalones.
Rev sets the default paintCompression to PNG and MC sets it to RLE. I
suspect this is done in the RevCommon library, but I haven't actually
looked. To test equivalencies, it would be good if you set the the
paintCompression to PNG in MC too.
Thanks, Jacqueline, this was the most important hint for me in the last
weeks, because it also solves the mystery of the slow imagedata handling
in Rev, which we dicussed at length in thread "MC-Rev speed differences.."
A related problem and also involving "paintcompression" had been
dicussed between Dar Scott and Wouter in January 2004.---
The format of paintcompression affects both properties "text of image"
and "imagedata".
How the properties are affected seems to be a can of worms and the Rev
docs are incomplete/ambiguous here and even wrong for some details:
Rev docs: "By default, the global paintcompression property is set to
"rle" in standalones and "png" in the development environment."
This is not true: By default, in Rev paintcompression is set to PNG in
the environment *and* standalones. If this would not be the case then
we would not get the speed differences in imagedata handling between
Metacard and Revolution.
Rev docs: "If the image was created with the import command, its
paintcompression is set to the format of the imported picture file."
This is only true if the image was fully imported. For a "referenced"
image the paintcompression format is that of the environment, PNG for
Rev and RLE ("Windows run-length encoded") for Metacard, and - a
referenced image does not contain any "text of image" data, but contains
"imagedata". A referenced image will acquire "text of image" data only
after you have edited it.
Rev docs: "To change an image's compression format, first set the
paintcompression to the desired value, then paint in the image. Then
either go to another card and return, or close and re-open the stack."
This is only partially true: Besides painting in the image you can apply
other possibilities of editing like changing the imagedata with filters
etc. Also it is not necessary to go to another card and return.
The short entry 707 of the Metacard docs is more precise here:
"This property sets the compression format used when an image is
recompressed after it has been edited."---
When you get the "text of image" data while paintcompression if set to
RLE (and the image had been edited), resetting the image to its own
"text of image" data will make it totally transparent as all chars of
its alphadata are set to 0. I suppose this is a bug, as I cannot see a
sound reason for this transparency.
Resetting the alphadata of the transparent image to 255 will not reset
the image, but produce a monochrome rectangle.
The "text of image" data can be retrieved and reset with the other
paintcompression formats PNG, JPEG, and GIF.
If the paintcompression is set to GIF (and the image had been edited)
and you restore an image with "imagedata" retrieved with
paintcompression set to RLE or PNG the resulting image may be distorted
or incomplete.
For my imagedata-handling stacks "Seamless Tiles" and "Imagedata
Toolkit" I added an open-stack handler with "set the paintcompression to
RLE". The described and discussed speed differences between MC and Rev
are no longer there.
At least one question remains, where is the default paintcompression
set? I made a script search in the MC home and tools stacks and did not
find "paintcompression"?? -
I have added a comment to my Bugzilla entry 3938 stating that the issue
has been resolved.
Best regards,
Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Another MC-Rev anomaly: "text of image" property
First: The imagedata speed problem has been added to Bugzilla as bug 3938.-- I took a look at the "text of image" property to see what is different from imagedata (tested for Windows XP). Results: - The number of chars of the text of an image is about 50% smaller than for imagedata, meaning that storing the "text of an image" needs less space. - Other than with imagedata, restoring an image with the stored text of the image shows no speed differences between Rev and MC. Resetting the text of a larger image is about 10 milliseconds slower (180 vs 190 for an image 1600X1200) for both Rev and MC 2.7.4 compared to MC 2.6.6 and Rev 2.6.1. - For referenced images no "text of image" data are available, the retrieved imagetext is then empty (imagedata are *not* empty in this case). You have either to import the image (or take a snapshot) or first to manipulate the imagedata to get any "text of the image" - Manipulating the "text of an image" apparently is not possible like with imagedata. If you reset an image to its changed text, you will get a blank image. Has anybody succeeded or tried to change the "text of an image"? For the above points there are no differences between Rev and MC, but - The format of the "text of image" property is different in Rev and MC - tested both in stacks and standalones. Resetting an image to its previously stored text in MC and the MC IDE results in a blank image (unless the text was stored using Rev and the stack after that opened in MC). This means that you cannot use the text property to store and retrieve images in MC. The different format of the text of image property in Rev can be seen when you put the retrieved text into a field: The first line of the image text in Rev always contains "‰PNG", which is missing in MC.-- The big question - similar to the one about imagedata, but this time to the disadvantage of MC - is (as both IDEs and standalones use the same engine) what is being added to the Rev standalone that allows proper handling of the "text of an image"? Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving to MC 2.7
The test stack for measuring speed differences in imagedata handling between Rev and MC I uploaded yesterday contains an 640X480-pixels image. The differences are distinctly apparent here, but of course somewhat smaller than with larger pictures. I have now added a test stack that contains a 1600X1200 image and also - in the text field - part of the detailed results of testing Rev against MC as stacks and standalones of engine versions 2.66/2.6.1 and 2.7.4. <http://www.sanke.org/Software/MC-Rev-SpeedTest-BZ-Large.zip> (9 MB). Of course I recommend to integrate the new 2.7.4 engine into the MC IDE because of the new features. However some of the new bugs that have been reported on the use list for the Rev IDE are apparent in the MC IDE, too, as they are engine-related, like the coming to the front of an underlying opened folder that hides the stack you are working on when you have looked at the card or stack script and then hide the script editor. Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Moving to MC 2.7
On Sat, 21 Oct 2006, "J. Landman Gay" <[EMAIL PROTECTED]> in response to Tariel Gogoberidze wrote: >> OK, thanks for this info. It's probably more convenient to just build >> standalone in Rev but I wanted to avoid "Rev Junk" placed in my >> standalone. Some of my stacks are "image intensive" and this 200 - 1000 >> millisecond speed difference that Wilhelm discovered would matter. I think Wilhelm was doing some very intensive tests. I haven't noticed any speed difference at all wiwth standalones built in Rev. And while I don't disagree he got different timings in his tests, I haven't had any problem with speed. If you can't get the MC builder to work, you could try Rev. I've had good luck with it. -- Jacqueline Landman Gay | [EMAIL PROTECTED] Thanks, Jacqueline, for "not disagreeing" with me, but the problems you do *not* have with such speed differences may be problems for others, surely for me and maybe for Tariel. I see no reason why we should tolerate sloppy programming and accept this as a "revolution". Using the "reset image" button in my test stack (of script "set the imagedata of img 1 to decompress(the Bilddaten of me)") is 10 times (ten times) slower in Rev than in Metacard, both in stacks and standalones. For the "duplicate color" buttons and images 1600 X 1200 Rev is three seconds slower. I refer to the detailed results of my last post of thread "Speed differences between MC and Rev (problem area nearly found)". You can test this in both IDEs for yourself using stack <http://www.sanke.org/Software/MC-Rev SpeedTest-BZ.zip>. The ending "BZ" denotes that I am going to use this stack as an attachment to my Bugzilla entry. Best regards - no offense intended, but I was not quite sure what you were going to convey. Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Subject: [ANN] "Seamless Tiles Generator" released
This stack - produced in the alternative Metacard IDE - was intended to
be part of the enhancements of my "Imagedata Toolkit", but is now
available as a separate application. It should run on all platforms
(tested on Windows and Mac OS X). On Mac OS X it needs at least an
Revolution engine version from 2.7 up to work properly because of the
restrictions as to image size and divisibility for backpatterns in
earlier versions.
The stack contains its own "Answer Dialog" as a substack, because I need
the functionality to place the dialog close to the buttons that use the
dialog. This dialog should cause no problems with newer versions of
Revolution. If you get a warning because of a "duplicate stack", simply
disregard this.
You can download the zipped stack (6 MB) directly from
<http://www.sanke.org/Software/SeamlessTiles.zip> or
from page "Sample Stacks" of my website <http://www.sanke.org/MetaMedia>
where you also find a short description.-
===
What the "Seamless Tiles Generator" does:
A few sample images are embedded. You can import your own JPG and PNG
files, which will be resized to 640 X 480 pixels.
From this basic image you select a rectangle for further processing.
You can select
- the whole image (not very useful as a tile)
- predefined large and small rectangles: You use a draggable graphic to
select a segment from the basic image.
- segments of a customized size: The height and width of the selecting
graphic can be adjusted using sliders right and below of the basic
image, and then also be dragged within the rect of the basic image.
The selected rectangle of the image is then transferred to page "create
seamless tile" using the button on the upper left of the card.
On card "create seamless tile" you can choose between three options to
create a tile:
- "Overlay mirrored" mirrors the "overlapping" parts of the tile borders
with an optimized transition blending
- "Overlay stretched" stretches a selected border region into both
directions
- "Overlay cropped" produces a blended overlay of the border regions and
crops the resulting tile to provide exact tile borders (This is - to my
experience - the most often used variant of producing seamless tiles
(Photoshop, PainShopPro etc.))
For all three options you can determine five sizes of the "transition
width" of the overlapping areas, from "wide" to "very small".
Of course, it depends very much on the nature and structure of the image
segment used for producing the seamless tile which "option" and
"transition width" is most suited for your purposes.
The produced tile can be tested immediately as a screen-size pattern.
The tile can be modified (before and after producing the "seamless" tile):
- proportional resizing
- simplifying colors (brighten, gray scale, three-threshold gray,
"reduce colors" to 8, 27, 64, and 125 colors)
- changing colors ("complementary" negative colors, "rotate colors"
successively red, green, and blue, "sepia", and "duplicate colors")
- matrix filters (7 filters are provided which could be useful for
background patterns: "fine emboss", "contours", three variants of
"lithography", "gray relief", and "red tint"). An external is not needed
here.
All modifying effects can be used successively, e.g. you could "rotate"
the "red tint" to green, or "brighten" the "contours" filter effect
until you have got an unobtrusive background etc..
Finally the tile can be exported in PNG format for further use.-
Enjoy and experiment in case you like this sort of stuff.
-- Wilhelm Sanke
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev (problem area nearly found)
ng, but must be caused by other interfering scripts in the Rev IDE. Overall conclusion: Rev is generally 3 seconds slower (33 %) when the imagedata handling is included in the measurement. There is also an additional interference from the Rev IDE. Best regards ( see you again next Monday after a longer weekend), Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev (problem area nearly found)
Richard Gaskin wrote:
Confirmed in the IDEs -- 5740ms/avg in MC, 6830ms/avg in Rev (I have a
1GHz PB G4).
I haven't built standalones, though, which would be good to test.
In the meantime I did further tests and built standalones for MC 2.6.5,
2.73, 2.74 and Rev 2.6.1, 2.73, 2.74. I tested 3 more scripts and also
tested all scripts with a much larger image of 1600 X 1200.
As before, no significant differences between stacks and standalones in
MC and - also as before - a slight improvement for the Rev standalones
compared to the Rev stacks, but a remaining difference to the MC
equivalents of up to four seconds, and even one script where Rev runs
*eleven* times slower than MC! See below.
Given this speed loss I'm confident the folks at RunRev will take a keen
interest to determine what's eating performance.
Offhand I can't imagine how the execution of a single handler with no
breaks, pauses, or sends is in any way affected by any outside script,
but it does indeed appear to be the case.
Have you BZ'd this? It would be good to include that file as an
attachment to the report.
I might do this after some more research
-- Richard Gaskin Fourth World Media Corporation
and Chipp Walters (on Wed, 11 Oct 2006) wrote:
Wilhelm,
Just wondering, did you 'lock messages' before and 'unlock messages'
after when running the script? If not, you might want to try it and
see if it doesn't speed things up.
Inserting "lock messages" etc. does not change the results.
But thanks for the hint, because the fact that adding "lock messages"
does not change the speed means that the long
"setProp cREVGeneral [pwhichProp] pWhichProfile" handler
(which belongs to the scripts added by the Rev Standalone Builder)
cannot be the culprit.
Unfortunately, all these extra scripts apparently are added by the
script-protected revsaveasstandalone substack. I searched the scripts of
the "StandaloneSettings" stacks and so far found nothing there that
could be related to the speed difference problems.
Also, you probably want to make sure 'Variable Checking by Default" is
turned OFF in the prefs pane for RR.
Same as above, does not make any difference.
best, Chipp
Here are some results for filters applied to the larger 1600 X 1200
image (again: Windows computer with 2 GHz):
- "duplicate colors": Rev is * three seconds* slower in all the 3 stacks
and standalones ( 9 vs. 12 and 10 vs. 13 seconds with different engine
versions)
- "max dots" (this is a modified version of the Gimp "despeckle"-median
filter, where I exchanged the median for the max values. The button is
to be found in my Imagedata Toolkit below the "despeckle" filter).
Rev is about 4 seconds slower here, the results being 34 seconds for MC
and 38.5 for Rev on the average.
I then happened to notice that the reset button worked considerably
slower in Rev, eleven times slower, and I measured this.
The script of the reset button is a one-liner
"set the imagedata of img 1 to decompress(the Bilddaten of me)" --
("Bilddaten" being a translation of imagedata).
This takes 270 milliseconds in MC and 3000 milliseconds in Rev with all
engine versions and identical in stacks and standalones.
I removed "compress" for setting the custom property and "decompress"
then in the reset handler, which didn't make much of a difference: Rev
is now only 10 times slower.--
Anyway, after the "compress-decompress-reset" tests, I made some
progress in detecting what is involved in producing the speed-difference
problems. Instead of the image I placed a field with a longer text on
the card, which then was saved as a custom property of the reset button.
Resetting the text of the field is indeed identical in all Rev and MC
stacks and standalones, meaning
that the speed differences between MC and Rev are caused by a different
handling of "imagedata"!
It now remains to be found out which script is responsible for this
abject treatment of imagedata in Revolution, where this script is
located, and how we can prevent its interference.
Best regards,
Wilhelm Sanke
<http://www.sanke.org/MetaMedia>
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev
I resend my post of last Friday, hoping the server is up again: On Sun, 24 Sep 2006 Richard Gaskin wrote: I notice no difference in the execution speed. So far this is consistent with all data except Wilhelm's. Neither logically nor empirically have we yet found a way that simply adding a library can affect execution speed. We'll have to wait for Wilhelm to provide more data. (snip) If instead there does seem to be some difference in the way standalones are made (though after building my own standalone maker I can honestly report that I can't imagine what that could be) it's also worthwhile determining where the performance goes. Ideally Wilhelm will be able to come up with a stack that presents an isolated recipe for this problem. It's my understanding that at the moment the tests are being run within a very complex collection of scripts, making it difficult to produce a generalized recipe for others to run. Without such an isolated example of this reported issue, I can't think of any way it could be reasonably addressed further beyond what's already be done. If he's able to deliver an isolated example I'm sure RunRev will jump at the chance to optimize based on it reveals. -- Richard Gaskin Back again to resume the discussion. I have produced this isolated example. Apart from the one-line script of the "reset" button, it contains only a 13-line script of the test button "duplicate colors". Only the MC cursors stack is included as a substack, otherwise nothing is included, not even an "answer dialog". The performance differences are as reported about 600 milliseconds between MC and Rev on a Windows 2 GHz machine, tested with Metacard and Rev using the same 2.7.3 engine. No differences come up for the stacks compared with standalones. A test with 2.7.4 today shows an overall performance improvement for both IDEs of about 200 milliseconds, but the speed difference between MC and Rev of now about 500 milliseconds remains. Stack and standalone with MC show an identical performance - around 1550 and always below 1600 milliseconds. For Rev - 1935 to 2083 milliseconds for the standalone - there is an additional difference between standalone and stack of 100 milliseconds, the stack running in the IDE with a peak of 2165 milliseconds being the slower one. You can download the test stack from here (2 MB because of the embedded picture and the compressed imagedata to enable reset): or type go URL "http:/www.sanke.org/Software/mc-rev_speed_test.rev" in your message box. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On Fri, 22 Sep 2006, Richard Gaskin wrote:
It might be helpful to de-standalone it to take a look at exactly
what's been included.
Once upon a time someone posted the info needed to strip the
executable from the stack -- anyone make a utility for that?
In my own collected archives I found this script:
"on mouseUp
answer file "Standalone"
if it is "cancel" then exit to top
put url ("binfile:"&it) into tStack
repeat forever
-- there's more than one stackfile in there which isinteresting
put offset("#!/bin/sh",char 10 to -1 of tStack) into tOff
if tOff = 0 then exit repeat
put char tOff+9 to -1 of tStack into tStack
end repeat
ask file "Stack"
if it is "cancel" then exit to top
set the fileType to "RevoRSTK"
put tStack into url ("binfile:"&it)
answer "conversion finished" with "OK"
end mouseUp"
This, however, (on Windows) provides me with an extracted stack that is
flagged as "corrupted", even if I comment out the line about the
filetype which is probably meant only for MacOS(?)
A simpler diagnostic might be to have your app spit out a list of
frontScripts, backScripts, and libraries, something like this:
on LogScripts
put the frontScripts &cr& the stacksInUse &cr& the backScripts \
in url ("file:ScriptList.txt")
end LogScripts
Applying this I get 13 front and back scripts running in the stack and
nothing of this in the standalone (in the standalone only my script
library "clib" and the calling button for listing the back and
frontscripts are listed).
When I remove these backscripts and frontscripts in the stack no change
of the slower Rev-IDE speed is effected. So the slower performance in
Rev must be caused by other scripts.-
Unfortunately I cannot follow your other suggestions at the moment
(startloggingMessages etc.) because I really need to concentrate on
other things at the moment (and not only, but also, because of that
voluminous doctoral dissertation on my desk).
I will continue the discussion in about a week and thank all of you in
the meantime for your interest in this thread.
Best regards,
Wilhelm Sanke
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On Thu, 21 Sep 2006, Richard Gaskin wrote: That leaves us with the possibility that Rev is including some of its scripts even when you tell it not to. When you pour through the standalone with a raw editor do you see any Rev scripts in there? and Jacqueline had confirmed in the meantime: I believe the revGeneral library is always included. Yes, I do see that in the Windows standalone built with Rev 2.7.3 -gm1. Apart from the parts of my own scripts that are unprotected I see a lot of extra code, some of which may belong to CRevGeneral, but other scripts certainly could not belong there, like: "set the mainStack of the topStack to "Home" modal "Stack Properties" if it is not empty then set the cursor to watch topLevel it end ifgo to prev card ùA ûA ÖA üA ïA‘? AB B" etc. The above is definitely not *my* code - and why should anybody refer to stack "home" in a standalone? Other functions seem to belong to CRevGeneral like - "function revPoints pGraphic" - "function revApplescriptFull pfunction,pSrc,pDest" Why should this be included in a Windows standalone? - "on revMail pTo, pCC, pSubject, pBody" - "setProp cREVGeneral[pWhichProp] pWhichProfile put the long id of the target into tTarget put tTarget into tTargetLongID if pWhichProp is not "profile" and pWhichProp is not "inLineImages" and pWhichProp is not "virtualWidth" and pWhichProp is not "virtualHeight" and pWhichProp is not "breakPoints" then pass cREVGeneral" etc. Maybe the last example could be one of the culprits that slow down execution (?) and such as "on mouseDoubleUp pButtonNo, pTarget --not been handled --pTarget set in suppress messages frontscript if pTarget is empty then put the long id of the target into pTarget put revTargetStack(pTarget) into tStack put the defaultStack into tDefaultStack set the defaultStack to tStack if the mode of stack tStack is not 0 then click at the clickLoc set the defaultStack to tDefaultStack end mouseDoubleUp" Best regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev and the origin of the English language
On Fri, 22 Sep 2006, Dave Cragg <[EMAIL PROTECTED]>, wrote: The people of Edinburgh and the area to the south east did fight with the Angles of Northumbria. But these were neither Picts nor Scots. They were Britons who spoke what today would be recognised as Welsh. Interestingly, these battles are more remembered in Welsh history than in Scottish history. (Also, some people think Arthur was the leader of a tribe of Scottish Britons, and that he fought against both Angles and Picts.) Eventually, the Angles dominated south east Scotland and the Scots and Picts dominated the remainder of the country. The use of "Welsh" in Scotland died out. The database I based my judgment on was small, and I had warned you that only about 99% of my story was true. There were so many different kingdoms or territories governed by warlords at that time that one can easily become confused. But I think the general picture is true. It is rumoured that there are many missing libraries of that period, thought to be hidden in southern Scotland somewhere. It may be that one of these libraries has got buried in the Rev IDE. (Some of those scripts look like Welsh to me.) I also read somehwere that the Romans introduced the bagpipes to Scotland, but left before they taught people how to tune them. Cheers Dave It could well be that the Romans instroduced the instrument to Scotland, but did not particularly like the sounds coming out of it. A quote from Wikipedia: "Nero is reported to have said he would play them (bagpipe is plural in Latin) in public as a penance for not winning a poetry contest".- In case my comments were felt to be offensive, I apologize to the Scottish branch of my family, who are however living more near Glasgow. Cheers, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Speed differences between MC and Rev and the origin of the English language
Home again and back to work as I announced 11 days ago. There is a 350-pages doctoral dissertation on my desk - a study about internet use in schools - which I need to assess and grade during the next two weeks, but I resume paying some attention to my imagedata stuff and MC. My two vacations this summer were spent in parts of Germany where language minorities still fight against assimilation. Last week I visited the Sorbian area near Poland where a small number of people still speak their old Slavonic language which is also still used in schools. In July I spent a quiet time in the northernmost county of Germany, called "land Angeln" since 2000 years - South of the Danish border - from where the English language and especially the name for the "English" language originated. I had taken my laptop with me to the land "Angeln" to work on my "imagedate toolkit", but in the first night the harddisk crashed and I had two weeks time to attend to other matters and study the local culture and what had remained from old times; additionaly I consulted my memory and later Wikipedia and my old textbooks. As you all on this list are more or less familiar with the English language it will not hurt to share my collected insights about its origin: The short story of the development - and about 99% of this is true - runs like this (and the Scots are also instrumental here, if only in a somewhat negative way): The Roman emperor Hadrian had built his Hadrian's wall across England from Newcastle to Carlisle because he did not like bagpipe music and kilts. When the Roman empire broke down in the 4th century, the revolutionaries from Edinburgh again annoyed the Celtic population South of the Hadrian's wall. Then the British Celts asked two former Roman mercenaries, namely Hengist and Horsa, to help them against the Scots. Hengist and Horsa happened to belong to the Anglian tribe in the land "Angeln" and asked their relatives and more tribesmen over to Britain. The Saxons - South of the land "Angeln" - and the Jutes to the North joined them and established their kingdoms (and languages) in the new country. The last Celtic king to fight against this invasion was the legendary King Arthur from Tintagel in Cornwall. Later other waves of immigrants came over to England from the same places where the Anglians, the Saxons, and the Jutes originally lived. From the eight century on the Vikings made frequents inroads and then settled in England (the famous "Hägar" was one of them). In about 10 miles distance from where I spent my July vacation is "Haithabu", the former trade center of the Vikings in the land "Angeln" (a place similar to Sutton Hoo in England, where big Viking ships have also been found). In the 11th century after Hastings the Normans, which were originally Vikings, too, came over who had made a detour through the Normandy in France, got civilized there and had learned some French and French cuisine in the meantime. Then even later more Northern Germanic tribes invaded, especially Jutes (Danes) who established the "Danelag" in England. Knud the Great was at the same time King of England and Angeln/Denmark/Norway. All these Germanic tribes spoke closely related Germanic dialects very similar to the language documented in "Beowulf", the oldest extant example of poetic "Old-English" language. Interestingly, the venue of the saga told in Beowulf, this center piece of Old-English literature, is the Southern area of Scandinavia. By the time of Chaucer the Anglian/English language had evolved as the widely spoken and officially used means of communication in the new "England". It is an astonishing fact of language development that the term "Anglian/English" , derived from the small land-Angeln region of continental Europe, finally prevailed as the name for one the most important languages and the "lingua franca" for international communication of today. At least the Saxon part of this language development is honored when we sometimes also speak of Anglo-Saxons and Anglo-Saxon languages.-- == Now to the speed differences: On Sat, 09 Sep 2006, Richard Gaskin <[EMAIL PROTECTED]> had written (Subject: Re: [ANN]: Imagedata Toolkit (beta) released): Wilhelm Sanke wrote: >> (Remark for Metacard list members only: >> For optimal performance use the Metacard IDE. When run in the Revolution >> IDE some filters need up to 45% more processing time than in MC. This >> also holds when you create a standalone.) How could that be possible when they both use the same engine? The Rev IDE is a slowly evolving environment with about 20 times more code than in the MC IDE. Given the additional intricacy and interrelatedness of this code it is quite natural that
[ANN]: Imagedata Toolkit (beta) released
y seeming loss of sharpness (see above). 4. Immediate Filters. The majority of these filters (182 in all - with additional variations for most of them) are one-step filters (as opposed to the two steps "select" and "apply" of the matrix filters) and are usually very much faster - less than 2 and even less than 1 second for many of them. A few are slower, the slowest being the "Kuwahara full" filter with 27 seconds. Many of these filters are adaptations from my "Colorpattern Toolkit" which used chars in fields instead of imagedata, others are newly developed, and some are reprogrammed-in-Revolution versions of findings from the net. In the last category belong filters like "jitter" (button "add noise"), "b-contrast" (the variation "spread low tones" is especially useful to brighten dark parts of an image), "thresholds", and the area-filters "despeckle" and "Kuwahara". The codes for these filters were written in languages like Java and "Gluas"; there is an interesting "Gluas Gallery". I have added the original scripts of Gluas solutions in some of the button scripts. Gluas is used to write filters for "Gimp" and is a derivation of the programming language "Lua". Especially the Kuwahara filter, which produces painting-like images, is an example for the possibilities and the limitations of the Revolution language at the same time because the execution of the script for some million of imagedata chars takes its time. I have provided an option "Kuwahara light", which is much faster, but which needs to be applied togeher with the "despeckle" filter to achieve good results. Maybe the Gluas language could be used to develop externals for Revolution, too? One type of filters, the 15 "stretch", "multiply segments", and "mirrored segment" filters, uses a transparent graphic that can be dragged within the rect of the image to select a part of the image for processing. I especially like the "mirrored segments" filter that produces interesting and unpredictable "seamless within" pictures from any image. Some of the remaining filters: "gray values", several "sepia" filters, adding "gradient overlays" of selected colors, "saturation", "pastellizing", "brighten/darken", "reduce colors" to 4096, 512, 125, 64, 27, and 8 colors, various kinds of "swap colors" (negative, rotating, substituting etc.), "max-med-min" experiments, a number of horizontal, vertical, and diagonal mirrors, "flip and turn" flipping and turning the image horizontally, vertically, and 90 degrees, "skew", "shift", and "shrink" for other spatial deformations, "refractions" to produce a series of decreasing images inside the image, "glassy reflections" with various density options, "gradients", "plain transition", and "random" transitions as producing various kinds of transitions - with variable gradient segments appearing in the picture at the same time when "random" is used here. Also a number of buttons to create "primary color patterns" for further manipulation by the described "secondary filters, and "finetuning" colors by influencing the color values of an image either separately for the RGB portions or combined. And last but not least, there is an option to produce "picture borders" of variable sizes where the frame colors are selected from within the picture with a draggable graphic.- Seven sample images are provided that are of different color and structure and which react differently especially when matrix filters are applied. Enjoy! --Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Metacard does not start on a second Mac
Jacqueline Landman Gay wrote: The only thing I can think of is that Rev now requires a registered and licensed version on the drive before the engine will run. If you haven't installed Revolution and licensed it first, other IDEs may not work. Now technically, the MC IDE (or any other) is supposed to ask for your license code if it hasn't already been recorded on the machine, but this may not have happened for some reason. You might try installing Revolution, licensing it, then quitting and launching the MC IDE. That may fix it. It's all I can think of right now, anyway. -- Further testing revealed that the no-start problem accompanied by a short flashing of the Metacard icon in the dock seems to be restricted to version 2.6.5 of the MC IDE (maybe others near to 2.6.5, too? I did not test that). 2.5 opens on the other Mac without problems, with 2.7 I am asked to enter my Revolution license key, and then it works of course. Thanks for the responses.- Today I am leaving for a two-weeks vacation at a somewhat remote place without internet access, but accompanied by my Windows laptop. I hope to be able to add a number of finishing touches to my Imagedate Toolkit. In the meantime I have added and adapted another number of matrix and also scripted filters (filters not based on a matrix), among them two "unmask" filters of really high quality (such as Sivakatirswami wanted to use - in 3X3 and 5X5 matrix format), a "jitter" filter, "glassy reflections" of different solutions, and "filters" that use selected parts of images to produce several kinds of patterns by repeating or mirroring at the same time as an option. . Other features are refined color-tuning options like "increase saturation", "decrease saturation", "produce equal color distances from max or median" etc. or the ability to apply all matrix filters to selected colors or color combinations only, e.g. only to red, to green and blue etc., which leads to interesting results. Another possibility to work with matrix filters is to use 3X3 filters in a "hybrid" fashion as 5X5, 7X7, 9X9, and 11X11 filters: The outer cells of the 3X3 matrix are spread accordingly to a higher level. The effects of these hybrid matrices are different; with contour filters you will get much thicker contour edges. These hybrid filters have a great advantage compared to real 5X5 to 11X11 filters: applying these filters is as fast as with 3X3 filters, meaning that on my 2 GHz computer the execution time will be around 7 seconds in the MC IDE (you cannot apply the DLL of Chipp Walters here, the hybrid solutions have to be entirely scripted) and about 10 seconds in the Rev IDE (same difference holds for MC and Rev standalones), whereas a real "full" 5X5 matrix would need about 25 seconds to execute. There are also "half-tone" filters, i.e. the possibility to produce half-tone images by a combination of filters. For the "full" 3X3 and 5X5 matrix you can either produce and try out new filters using a random function (that also calculates the correct "division" factor for maintaining more or less the origonal color balance) or to create or change new filters manually by entering values into the cells of the matrix. These new filters can be given a name and stored ( and deleted) as user-defined filters for subsequent use.-- Kind regards ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Metacard does not start on a second Mac
J. Landman Gay wrote: Wilhelm Sanke wrote: I tried to transfer the Metacard IDE and a stack from my G4 Powerbook to a second, but very much faster G4 Powerbook to see the speed differences for scripts in the stack. Both Powerbooks run with OS 10.3.9. I used a USB-stick to put the files on the other computer. When I start Metacard on the second Mac, which had neither Metacard nor Revolution installed before, something flashes and the Metacard icon briefly appears in the dock, but it is not started. Clicking on the accompanying file after that results also in nothing. What am I missing? Has this maybe to do with administrator rights for installing new programs? And how could I overcome that? This is the same behavior that is occuring when trying to build a UB standalone, but if you copied the PPC version it should work. Were you logged in as an administrator when you copied the app? That is all that should be required. -- Jacqueline Landman Gay The faster G4 is configured to automatically boot with the administrator keyword, meaning that something else must be required to launch the MC IDE. And: Should there not be a default dialog for such cases in the Mac OS - similar to asking for an administrator keyword when installing new software from a CD? I tried to the same with my wife's iBook - same results: When starting the MC IDE (2.6.5 in this case) the icon briefly flashes in the dock and then nothing. However, a standalone built on my G4 can be started on her machine without problems. Any further ideas? Thanks for the response anyway. -- Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Metacard does not start on a second Mac
I tried to transfer the Metacard IDE and a stack from my G4 Powerbook to a second, but very much faster G4 Powerbook to see the speed differences for scripts in the stack. Both Powerbooks run with OS 10.3.9. I used a USB-stick to put the files on the other computer. When I start Metacard on the second Mac, which had neither Metacard nor Revolution installed before, something flashes and the Metacard icon briefly appears in the dock, but it is not started. Clicking on the accompanying file after that results also in nothing. What am I missing? Has this maybe to do with administrator rights for installing new programs? And how could I overcome that? Any suggestions are appreciated. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
[ANN] ImageData Gallery
I have uploaded a series of images created with the "ImageData Toolkit", which is a modified version of my "Colorpattern Toolkit" (<http://www.sanke.org/ImageDataArt>). Thanks to the information provided by Ken Ray about "imagedata" on his website (<http://www.sonsothunder.com>) I was able to start my quest of the intricacies of this special way to create and manipulate images, which I had not paid much attention to before. I think such information as offered by Ken should be linked in some way to the Rev documentation. The information about imagedata in the documentation alone would not have been sufficient to get me going. I have already rewritten about two-thirds of the 200 algorithms of the Colorpattern Toolkit, but because of other time-consuming tasks I will not be able to offer the new ImageData Toolkit before the beginning of May. The Toolkit now uses 640 X 480 images as the basis, which means that 1.228.000 chars of the imagedata for such a size have to be handled as each pixel of the imagedata is represented by 4 chars, but compared to dealing with the 160 X 120 char resolution of the color field of the Colorpattern Toolkit, the speed for imagedata handling is in many cases even faster - probably due to the binary nature of the imagedata - whereas other special algorithms run at best at a "tolerable" speed. The Imagedata Toolkit will provide the option to import photos as a basis for image manipulation. Experimenting with imagedata I came across a number of new solutions for scripting functions, which I will also use to improve my present Colorpattern Toolkit. Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: (not) Moved icons
On Wed, 08 Mar 2006, Klaus Major wrote: Hi all, did you notice that the "Resource mover" does NOT move ALL MetaCard icons to the target stack? I had to copy the "Icons" stack manually to one of my stacks after i found that e.g. the "white arrow" icons were not displayed in the standalone! That does not affect the "Icons set in script" option. I will try to locate the problem, a short look at the script reveals that not the complete stack "Icons" is copied/cloned to the target stack, instead there is a repeat loop and I will try to find out what exactly is happening inside of it. Regards Klaus Major http://www.major-k.de Hi Klaus, What you already did - copying the whole of stack "icons" as a substack to your standalone -seems to be the exact and only answer, unless we change the relevant scripts of the Resource Mover. I had a look at that "loop", and I have the impression that it copies icons associated with buttons anywhere in a stack that are *not* mentioned in scripts. Additionally the basic icons for answer and ask dialogs seem to be copied. I had come across this problem some time ago (two years or so?) and had reported this on this list. What are the opinions for an optional inclusion of the whole Icon stack? It would add another 500 KB to a standalone. Best regards, Wilhelm Sanke <http://www.sankee.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Some afterthoughts concerning the enigma of "generic players"
if you want to provide the option to save the stack under a different name. Now turn this stack into a standalone. Everybody familiar with the very basics of Metacard/Revolution is able to produce such a player in five minutes. You get an even more basic generic player (I mentioned that in my response to Jacqueline on Feb 17) when you rename file "standalone" - needed to build standalones in versions 2.7 of MC and Rev - to "MyWonderfulGenericPlayer" or whatever and add an ".exe" extension; now you can drag any stack on that filename and it will be opened.- A wide variety of generic players is possible, differing in the amount of resources that are contained in the player itself or - on the other hand - required as embedded resources in the stacks to be launched. Ken's Stackrunner is far more sophisticated in that sense, compared to the old Player on my website, which contains only the answer and ask-dialogs, the Metacard icons, substack "file selector", the cursors, message box, substack "execution error", stack "libURL" (not needed in a non-web application) etc.. The DreamCard Player was clumsy and overloaded - and therefore rather big - when it was released. I criticized that at the time pointing out simpler solutions, and got flamed for that. An "all-purpose" player would need to include all possible resources for any kind of stacks, meaning including all libraries, dlls, i.e. about half or more of the whole IDE and its supplementary stacks. What is certainly important is to strike a sound balance between putting resources into the player or the stacks. Happily, users of the MC IDE can use the "Resource Mover" to put needed resources into a stack, but - as Rev users need to do if they are not building a standalone - there is of course the extra option to manually transfer resources.-- There are a number of situations where some kind of a generic player is indispensable, one reason being the size of MC and Rev standalones. Exe-files in other programming languages contain only the directly required elements. Such files created with Turbo Pascal or Delphi are rather small. Even with one of the other X-Talk languages, e.g. "Toolbook", you can get relatively small executables. We handle this problem for part of our language students as follows: The students get a restricted generic player, capable of running stacks with a specific extension other than "mc" or "rev". Thus we are flexibly able to provide for download and learning stacks of small size that can be easily updated or we can even add new stacks with different filenames.- Coming back to the question of the "enforcement" of a new policy. Let us imagine someone produces a generic player and even sells it as a commercial application you have to pay for. How could that possibly hurt RunRev in any way if they offer an even "free" player? As RunRev does not "sell" their player, how could an alternative player impair them? An alternative player would possibly show the variety of solutions feasable with such wonderful X-talk languages and therefore support and promote the distribution and acceptance of Metacard/Revolution - and not excluding the possibility that the RunRev team may even gain new insights from solutions they could not bring about at the moment, because there are so many tasks at hand to be solved. Every creative effort from other members of the Rev community should be honored and is a possible contribution to improvement.- A last remark: At some place of the discussion I remember the new "Media" brand of Revolution was mentioned as one reason to introduce a restricted player policy(?). We do not yet know much about "Media", as it is not yet released (although you can already pay for it), so I have to reserve judgment here. But if this really is the underlying issue and it is really important to set "Media" definitely apart from "Studio", "Dreamcard" etc. - which I cannot imagine why in terms of running such stacks - then it must be easy to configure "Media" and its player in such a way that other generic players produced with other brands of Revolution cannot open and run Media stacks. Best regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MC 2.7 building standalone
On Sat, 18 Feb 2006, J. Landman Gay wrote (on the Metacard list): >> The licensing agreement for 2.7 has now changed, and custom Players >> are no longer allowed. :( > > > Really? > If we are forced to use the DC Player instead, this is more than > ridiculous! To their credit, the RR team knows that the DC Player has its problems and plans to rewrite it to be a bit more friendly and useful. For one thing, they have assured me they will include all the various libraries so that all stacks will work. :) -- Jacqueline Landman Gay Kevin Miller has commented on this today in so many words on the improvement list of which I allow me to quote a small part for the benefit of our discussion: Just to comment on this thread from the MetaCard list... >> The updated Player for 2.7 stacks was compiled succesfully and works. >>> I will add it to my website. > > The licensing agreement for 2.7 has now changed, and custom Players are > no longer allowed. :( Nothing has changed. Generic players for Dreamcard have never been allowed (please see section 4 c & d of the 2.6 license where it clearly specifies the conditions under which you are allowed to distribute created works). We have turned a blind eye to this in 2.6 because our player had a number of known issues which we didn't have the time to correct. In 2.7, we have clarified the language for this a little in the agreement. We will shortly be shipping a vastly improved Player (snip) However in both cases, being able to shut off the Revolution branding (e.g. splash screen, or anything else we may wish to display) is something you need to upgrade to Studio (and build a standalone) to do. Kind regards, Kevin Am I right if I construe what Kevin says to mean that everybody holding a Studio or Enterprise license is entitled to produce a Player stack to launch rev- or mc-files?- We are encouraged and advised (there are many instances of such recommendations in the list discussions) to use splash-stacks as standalones to launch one or a number of stacks. Such a constellation has at least a twofold benefit: - the whole unit of splash and work stacks is far less in size than when you would produce standalones for each single work stack. - using a splash stack + a work stack makes it possible to save changes to the work stack (which is important in many cases). Customized players/splash stacks would also have the advantage that they can be perfectly tuned to the requirements of the work stacks, meaning including only such components/libraries/icons/dlls that are really needed in a specific situation. A generic Player would never be able to achieve such a directed functionality. In the case of my website, I offer a Player to provide the possibility for visitors to have a look at sample stacks, e.g. at those that are not standalones, which they can view anyway. This is also a good way to reduce the volume of the website. Seen from the marketing angle for RunRev, the possibility to view and test stacks for interested individuals who do not yet use one of the two IDEs could be a starting point for at least some of them to eventually join the community of Revolution and Metacard users. Kind regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MC 2.7 building standalone
On Fri, 17 Feb 2006, Chipp Walters wrote: OK, Now I'm confused. Jacque and Wilhelm, are you saying one can't create an app like Ken Ray's StackRunner in 2.7? Surely not. Perhaps a little more elaboration on what it is you mean by: "Conversely, you can't run any external stacks using a standalone as a >> "player" -Chipp Hi Chipp, given your many time-consuming obligations, you probably glanced too quickly over my post. Here is the portion of my mail addressing your question above: I made a new standalone with 2.7 of my vintage "MC-Player" (something like Ken Ray's "stackrunner" for running MC and Rev stacks, but without net options - available since two years from my website <http://www.sanke.org/MetaMedia>). The updated Player for 2.7 stacks was compiled succesfully and works. I will add it to my website. I am also considering of adding the option to the Player to convert stacks saved in the new 2.7 file format back to the pre-2.7 format - similar in function to your new alt-plugin. In essence, all is needed here is one single extra line of script. I would of course include a warning, should the user choose this option, that he will loose the new functionality of 2.7 with the conversion, in case he should have included some of the new features. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MC 2.7 building standalone
On Thu, 16 Feb 2006, "J. Landman Gay" <[EMAIL PROTECTED]> wrote: (snip) As of version 2.7 it is important to note that you can't build standalones out of the engine that runs the IDE. Conversely, you can't run any external stacks using a standalone as a "player". So it is important to choose the "standalone" version of the app engine when making a standalone, as that is the only one that will work. -- Jacqueline Landman Gay Jacqueline, your second sentence above "Conversely, you can't run any external stacks using a standalone as a "player" could be somewhat misleading. You surely intended to say "using *the* standalone file needed to build standalones". As I was a bit confused at first and to make sure you wanted to express the latter, I made a new standalone with 2.7 of my vintage "MC-Player" (something like Ken Ray's "stackrunner" for running MC and Rev stacks, but without net options - available since two years from my website <http://www.sanke.org/MetaMedia>). The updated Player for 2.7 stacks was compiled succesfully and works. I will add it to my website. But there is more to the 2.7 "standalone file" needed to build standalones, at least on Windows: Rename file "standalone" to "Standalone.exe", and then you can drag-and-drop mc-files on it, which will be opened. You can even again rename "Standalone.exe" to another filename like "Player.exe" and it will work, too. Kind regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
MC Standalones in Rev and MC IDEs (was: MC 2.7)
On Wed, 15 Feb 2006, Klaus Major <[EMAIL PROTECTED]> wrote: Hi friends, when i build a standalone with the new engine I get this error: The file MetaCard.app//.../metacard is no MetaCard engine ??? :-/ any hints are VERY welcome. When i try to build a standalone with Rev, i get, "There was an error building the standalone" which is not very meaningful. NO umlauts in the path! Will the script of the STAB have to be modified to fit the new engine? If yes, any hints how? Regards Klaus Major and "J. Landman Gay" <[EMAIL PROTECTED]> responded: I wonder if we will be able to fix it. The engine has changed completely, and standalones no longer attach the stack to the engine the way it used to (which means the de-compiling script that was just posted to the list doesn't work any more either.) We may need some help from the RR team. I didn't have any trouble building a standalone within Rev 2.7 though. May this is public knowledge in the meantime, I will post it anyway: Building standalones with the 2.7 engine in the Metacard IDE on Windows XP works without problems here. You need to include the file "standalone" in the middle field of the MC Standalone Builder (to be found in the "Runtime/Windows/x86-32" folder of the Revolution files) instead of the engine MC.exe or Revolution.exe. I did not try out for MacOS, but I assume the procedure must be similar with the "Standalone.app" bundle in the neighbouring Revolution folder "Runtime/Mac OS X/PowerPC-32". If a MC stack is used in the Rev IDE, you cannot build a standalone of a stack with a mc-extension, you have to change it to "rev". Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Double tools stack and LookAndFeel
As I temporarily do not access the Metacard list on a regular basis (due to other urgent predelictions) I noticed that a post I sent two weeks ago did not reach the list because of a typo in the address. I will try to change my presents habits. Meanwhile I want to thank Richard Gaskin for the new version of the MC IDE. I hope the list members and especially Jacqueline - to who I refer - will excuse to receive my belated insights only now. On Fri, 30 Dec 2005, "J. Landman Gay" <[EMAIL PROTECTED]> wrote: 1. "Double" mctools stack: >>>> 1. When the MC IDE is started, stack "mctools" appears to have been >>>> loaded twice. This is not limited to just the tools stack, it can happen to any stack. And it's been going on ever since I began using MC. I wrote to Scott Raney about it once, and now I can't find his answer, but basically it is just a cosmetic issue that means nothing. He said to ignore it. The apparent problem is produced by some sort of an inaccuracy of the "stacks()" function: It lists only mainstacks, but for each opened *substack* of a given mainstack - for some reason that escapes me - the full path of the mainstack and the mainstack is listed again. With Message Box, Navigator, and Standalone Builder open the mctools stack is listed four times. The "Windows Task-Manager" shows that only *one* instance of the Metacard Menu Bar is active. Function "mainstacks()" accurately displays a list of all open mainstacks without repetitions. For opened substacks we need "openstacks()" which displays mainstacks *and* substacks side by side without repetitions. Seems to me the "stacks()" function needs some overhauling. 2. LookandFeel: >>>> Which means that the culprit must the new engine! I built a standalone >>>> of the same stack in the Rev IDE with "Windows emulated" checked: Same >>>> result, the produced standalone displays MacOS native features (like >>>> they appear on Windows). It is my understanding that look and feel is a session-specific property that is never built into the standalone or into a stack. (I can't explain why an older version of the engine would retain this property, though.) Look and feel must be set in a preOpenStack handler if you want to implement something different than the native OS appearance. It isn't meant to be a permanent property, so I don't think this is a bug. -- Jacqueline Landman Gay Actually, all engine versions prior to 2.6 (from 2.5 and backwards) preserved the lookandfeel applied or automatically set in the IDE. As I see it, this is the way as it should be when I design the appearance of an application. Why should the engine (or for that matter the Standalone Builder) enforce a different appearance? Of course you can set the lookandfeel in an (pre)openstack handler - this works - , but I would like "to get what I see" when I work in the IDE without the necessity to script what I see all the time when developing. Maybe we could improve the MC Standalone Builder as a workaround (until maybe the engine has reverted to older standards in this case, which however seems rather improbable to me) with a function that looks for the presently applied lookandfeel and sets this as a property of a standalone. Another related issue: We lack an "Appearance Manager" option in the Preferences substack. Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Rev 2.7 engine in MC IDE?
Has anybody succeeded in getting to work the "Rev 2.7 Developer Preview 1" engine in the Metacard IDE (for the time being accessible for Enterprise-license holders) ? All I get here is an error message "Error while initializing development environment". Could this be caused by the new "Development Environment Licensing" - as announced by the "ChangeLog" - or is it just an intermediate bug? There is now a distinction between the engine used by the development environment and the engine used to build standalones - this is to allow one set of licensing functionality across all Revolution-compatible development environments. At present, the pre-2.7 per-Revolution licensing model is still used, but in the next build an IDE engine will not run *unless* it has had a valid license key entered. Best wishes for a productive and Happy New Year, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Issues of MC IDE version 2.6b11
uot; stack. Aren't we just discussing how to "mess around" with the IDE, to really improve it in such a way that "other developers" can benefit from it? The two lines to be added are at the end of the preopenstack handlers: Line 1: "if the NewLoc of this stack is not empty then set the loc of this stack to the NewLoc of this stack" Line 2: "set the NewLoc of this stack to empty ". There is no need to be "skittish" here, because the two lines are encapsulated in a way, they do not interfere with any other parts of the script when no "newLoc" has been set in the calling script.- Two issues concerning the relationship between the MC and Rev IDEs: 8. We cannot display ".rev" files in the dialog for loading stacks, we have to switch to "all files" to find them finally among all other file types in the directory. The Rev IDE displays both Metacard and Rev files in the open dialog. A couple of months ago I had made such a proposal for the MC IDE and had shown how to script this. 9. I found out that it is impossible to build standalones from Metacard stacks (when maintaining their extension "mc") with the Rev standalone builder. Up to now I had assumed that it has something to do with embedded dialogs or other substacks, but that is apparently not the case. The other way round, building standalones in the MC IDE from rev stacks is possible even with maintaining the extension. But when selecting the file in the dialog, Rev files are not displayed (see the related issue 8. above), but you can type the stack name into the dialog, which is however less comfortable than selecting the file directly.--- Could these issues possibly be addressed in a next version of the MC IDE? Best regards to all Metacardians, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Answer Dialog at ScreenLoc?
Scott Rossi and Richard Gaskin wrote: (snip) I had offered a solution that places the ask and answer dialogs anywhere on the screen or relative to a stack. There are sample stacks at . Thanks Wilhelm. I know how to modify the answer/ask dialogs however I was looking for a solution that did not involve modifications to these dialogs. My stack is to be used in the Rev/MC environments and I would prefer to use the available IDE dialogs. I'm a bit skittish about using properties -- how about a global named gMCAlertLoc? When empty it uses the proposed defaults I outlined, and when set it becomes the default location. -- Richard Gaskin To Scott: You can of course use the available IDE dialogs: Just add the two script lines I have proposed (at the right place) to them, this is what I normally do when a new version appears. To Richard, If this achieves the same effect (it should, but would require an appropriate change of the engine), that would be O.K with me. With my custom property - I repeat myself here - you have both default behavior - when it is empty - and "directed" behavior when you set the "NewLoc". The important function of the second added script line is that NewLoc is set to empty immediately *after* the dialog stack has been safely placed; thus default behavior is restored, but the option to place a dialog anywhere the next time remains. Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Answer Dialog at ScreenLoc?
On Wed, 31 Aug 2005 , Scott Rossi <[EMAIL PROTECTED]> wrote: Aside from modifying its code, is there a trick to forcing the answer dialog to appear at the screenLoc? (snip) Scott Rossi Creative Director Tactile Media, Multimedia & Design Naturally, this is a reappearing topic. We have had a similar discussion one year ago on this and the improvement list. I had offered a solution that places the ask and answer dialogs anywhere on the screen or relative to a stack. There are sample stacks at . You determine any location for the stacks by setting a custom property "NewLoc" in the script of the calling handler that triggers the dialog (or not setting the property if you want normal dialog behavior) after having modified the script of the dialogs with only two lines; see below from the information on my website: "Modified answer- and ask-dialogs that can be placed at any location on the screen or relative to a stack. The sample stack contains English and German information how to proceed with the new custom property "NewLoc" or to modify the dialogs in your own Metacard or Revolution IDE. The modified dialogs are contained both as substacks of the sample stack and in a separate folder (to be added to other stacks) All that is needed are two script lines added before the end of the preopenstack handlers: " if the NewLoc of this stack is not empty then set the loc of this stack to the NewLoc of this stack set the NewLoc of this stack to empty " The stacks can be used as usual if no NewLoc property is set. Line 2 of the script makes sure to restore the default behavior of the dialogs the next time they are opened without a specified "NewLoc"." Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> P.S. Just returned home for 48 hours between two assignments and looking through some 150 mails. I regret that presently I cannot devote much time and effort to Metacard and Revolution, but hopefully that will change in about three weeks. W.S. ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: image display
On Tue, 09 Aug 2005, Rick Rice <[EMAIL PROTECTED]> wrote: I am still using Metacard 2.5 On the Mac (OS--X.3) I have images with graphic objects (curve) overlaid. The object appearance is filled so that it will respond to a mouse click. The ink is set to noop. Depending on the student input, I want to outline the location of the object so that the student can see where it is and what it is outlining on the base image. To do this I set, in a script, the ink to admin. This leaves the base image visible with a cell now outlined by the graphic object. Now for the problem. When I move this to Windows XP and older, when I set the ink to admin I get the entire object filled with grey which obscures the underlying cell. I have tried every fill, nothing results in a simple line outlining the object. How can I make the object line visible without filling it. I tried unchecking the "filled" in appearance but then there is no mouse response. Rick Hi Rick, with Windows I use fillcolor 255,204,102 with the ink set to srcAnd (which alternates with "noop" to achieve a flashing effect). You can see the effect in my "Image and Words" stack, which you can get from page "Sample Stacks" of <http://www.sanke.org/MetaMedia> From the description: "Learning words through pictures in five different versions: Wordshow, Move and Click, Test and Learn, Test with Loop, Final Test. Basic part of the stack is an image with polygon overlays corresponding to the outlines of objects. Mode "Test with Loop" is an example for an instructional programs that allows the repetition of unsolved problems." Regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Caching?
On Fri, 22 Jul 2005 Tariel Gogoberidze <[EMAIL PROTECTED]> wrote: I guess, first I should explain why I used the "weird" script below.. It seems engine has a bug or at least inconsistency where Put number of bgs would ignore nested grps but, in "repeat with j= 1 to number of bgs" the count WILL go through nested grps. So, if you have lets's say 4 bgs and bg # 3 has nested grp, above repeat loop would not count bg # 4 and would return bg 1, bg 2, bg3 and sub group of bg3 leaving bg 4 out in cold. Hi Tariel, The docs of Rev are more precise here. From the "comments" of "backgroundnames": "If a group in the stack contains groups, only the top-level groups are reported." I wish we had a function that would return all backgrounds - including nested ones - without scripting a workaround. So, I had to work around this behavior with the following script on mouseUp put the short name of this stack into pSrcStack repeat forever add 1 to count if there is no bg count of stack pSrcStack then exit repeat put word 1 of the owner of bg count of stack pSrcStack into tWhichOwner if tWhichOwner = "Stack" then put the name of bg count of stack pSrcStack & cr after tBgNames end if end repeat answer tBgNames end mouseUp I did something similar (first) when encountering exactly the same problem while I tried to update my MC- and RevBrowsers, see my script farther down. Now the caching? issue that puzzles me If you create stack with 2 cards and 2 grps (I created both groups with background behavior "on") and remove both groups from card 1 and remove grp 1 from card 2 (so, now grp 1 is "unplaced" and grp 2 is only placed on card 2). Note: Stack has "destroy stack" and "destroy window" set to true. With this settings, if you run script above on just launched stack, the script would return group "BG1" group "BG2" But if you go to next card and back and run script again it would return group "BG1" Only. (snip) best regards Tariel I observed the same behavior, i.e. if a card has not yet been opened during a session then "stack" will be returned as the owner - even when the background in question is indeed owned by the card. In the discussion we had on this list (or the Run list) one or two years ago I had proposed to introduce something like "the effective owner of background x". Two solutions to the problem are possible - as far as I know: 1. Loop through (open) all cards of the stack before you run the above script 2. Ask for the "number of cards" a background has (see script below). Someone recommended this to me during the previous discussion., I forget who. Here is the script I used to get placed and unplaced backgrounds of a stack, which I just found in one of my test stacks. I am not sure if it is the latest version - so no guarantee comes with the script "on mouseUp put the name of the topstack into SName put empty into BList put empty into SortList put 0 into counter repeat add 1 to counter if there is a background counter of stack SName then put the name of background counter of stack SName into BName put the owner of background counter of stack SName into item 2 of BName if word 1 of the owner of background counter of stack SName is "group" then put Space before BName #=== if the number of cards of background counter of stack SName = 0 and word 1 of the owner of background counter of stack SName <> "group" then put " (unplaced)" after last char of BName end if #= put BName into line counter of BList put item 1 of BName into line counter of SortList else exit repeat end if end repeat put Blist into fld "Blist" put the number of lines of BList into Zahl repeat with i = 1 to Zahl put line i of BList into Zeile put line i of SortList into SZeile if char 1 of Zeile is " " then put item 2 of Zeile into Eigner put lineoffset(Eigner,BList) into GroupEigner put line Groupeigner of BList into Beigner put empty into pad repeat while char 1 of Beigner is Space put Space after last char of pad delete char 1 of Beigner end repeat put pad&Zeile into line i of BList put pad&SZeile into line i of SortList end if end repeat put SortList into fld "Backgrounds" end mouseUp" Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Deep-mask feature and alwaysbuffer
When trying to use the new deep-mask feature of Rev 2.6 (engine version
2.6.5, build 108) I experienced odd behavior while using the Metacard
IDE (Windows XP)
After setting the windowshape of a new stack to the ID of the imported
semi-transparent PNG, the stack completely vanished. Testing the
visibility of the stack in the message box ("put the vis of this stack")
returned "true". After some experimenting I found out:
- when the windowshape is set, the image disappears
- at the same time a screenshot is taken inside the area of the stack -
with the effect that the stack is no longer visible
- you can test that the stack is there by setting the loc of the stack
to a different point: the stack with the screenshot will now stand out
as visible
- clicking on the stack - in pointer mode - will make the imported image
visible again
- saving the stack now, quitting the Metacard IDE, restarting Metacard
and opening the saved stack: The stack remains invisible.
As a workaround I put into the preopenstack handler:
"lock screen
choose pointer tool
click at the loc of this stack"
This helped.
What helped likewise was the script Scott Rossi used for his
"psychedelic bug", interestingly this made the stack visible again, too.
(Try this on OSX, using a stack with a deep mask applied:
lock screen
unlock screen with visual "dissolve"
See anything unusual?
Regards,
Scott Rossi)
In the Rev IDE, when applying the new deep-mask feature the stack
remains visible, also a stack created and saved in the Rev IDE can be
opened as visible in the Metacard IDE. Hence, as the engine used in both
IDEs is identical (2.6.5, build 108), there had to be some difference in
the IDEs when the stack is created and saved.
Eventually I found out that the culprit is "alwaysbuffer": In the Rev
IDE a newly created stack has the default setting of "alwaysbuffer =
true" ("Buffer display" in the stack inspector is checked) whereas in
the MC IDE the default setting is "false" (mctools-version 2.6B11).
Setting alwaysbuffer to true when creating a new stack In the MC IDE
solves the described problems - and un-checking "Buffer display" for a
new stack in the Rev IDE lets you experience the weird behavior I have
described above.
If these peculiarities are intended, a remark about the necessity to set
the alwaybuffer-property for a stack to true when using the deep-mask
feature should be added to the "windowshape" entry of the documentation.
Regards,
Wilhelm Sanke
<http://www.sanke.org/MetaMedia
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Deep-mask feature and alwaysbuffer
When trying to use the new deep-mask feature of Rev 2.6 (engine version
2.6.5, build 108) I experienced odd behavior while using the Metacard
IDE (Windows XP)
After setting the windowshape of a new stack to the ID of the imported
semi-transparent PNG, the stack completely vanished. Testing the
visibility of the stack in the message box ("put the vis of this stack")
returned "true". After some experimenting I found out:
- when the windowshape is set, the image disappears
- at the same time a screenshot is taken inside the area of the stack -
with the effect that the stack is no longer visible
- you can test that the stack is there by setting the loc of the stack
to a different point: the stack with the screenshot will now stand out
as visible
- clicking on the stack - in pointer mode - will make the imported image
visible again
- saving the stack now, quitting the Metacard IDE, restarting Metacard
and opening the saved stack: The stack remains invisible.
As a workaround I put into the preopenstack handler:
"lock screen
choose pointer tool
click at the loc of this stack"
This helped.
What helped likewise was the script Scott Rossi used for his
"psychedelic bug", interestingly this made the stack visible again, too.
(Try this on OSX, using a stack with a deep mask applied:
lock screen
unlock screen with visual "dissolve"
See anything unusual?
Regards,
Scott Rossi)
In the Rev IDE, when applying the new deep-mask feature the stack
remains visible, also a stack created and saved in the Rev IDE can be
opened as visible in the Metacard IDE. Hence, as the engine used in both
IDEs is identical (2.6.5, build 108), there had to be some difference in
the IDEs when the stack is created and saved.
Eventually I found out that the culprit is "alwaysbuffer": In the Rev
IDE a newly created stack has the default setting of "alwaysbuffer =
true" ("Buffer display" in the stack inspector is checked) whereas in
the MC IDE the default setting is "false" (mctools-version 2.6B11).
Setting alwaysbuffer to true when creating a new stack In the MC IDE
solves the described problems - and un-checking "Buffer display" for a
new stack in the Rev IDE lets you experience the weird behavior I have
described above.
If these peculiarities are intended, a remark about the necessity to set
the alwaybuffer-property for a stack to true when using the deep-mask
feature should be added to the "windowshape" entry of the documentation.
Regards,
Wilhelm Sanke
<http://www.sanke.org/MetaMedia
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
Re: Appearance of menu items in version 2.6.B11 (and earlier)
On Tue, 21 Jun 2005, Richard Gaskin <[EMAIL PROTECTED]> wrote: What happens if you modify the MC IDE's preOpenStack handler to set the mcVersion to the version? -- Richard Gaskin This works, too, if the line is added to the card script. By the way, resetting (back) the mcversion of the mctools stack to a number different from 2.6.5 does not re-create the overlapping and cutting-off. Once modified the overlapping disappears ?? But this can be safely replicated when you delete mctools and unzip stack mctools2.6b11.mc.zip <cid:part1.02020604.02090709@hrz.uni-kassel.de> again. Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> P.S.: Just returned from a stay of several weeks at my second home (as it were) in Surfside, part of North Miami Beach, where my schedule and leisure time distracted me very much from things like Metacard and Revolution. I only cursorily looked through the messages and I now have to try to catch up with what has happened in the meantime. Sitting by the bay in a warm night breeze under huge Australian pine trees, looking at the reflections of the lights from the other side of the bay, drinking a glass of fine Samuel Adams Lager, being surrounded by fireflies (the big "click-beetle" version with two lights) and an occasional pelican, maybe reading - for temperature contrast - a "Cat Who" story by Lilian Jackson-Braun from Northern Wisconsin, all this and more provides a quality of life that can hardly be surpassed. At present I am again sitting on the terrace of my Central European home - not bad either - and try to adjust to normal conditions and to work as usual. ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Appearance of menu items in version 2.6.B11 (and earlier)
On Mon, 20 Jun 2005,Klaus Major <[EMAIL PROTECTED]> wrote: Hi Wilhelm, I have uploaded three screenshots (taken with a camera) that show the overlapping of text in some menu items and also cut-off text: <http://www.sanke.org/MetaMedia/MCTools-B11.htm> Must be an engine issue, since we did not change anything in the menus. Problem solved, cause not fully understood: When I set the "mcversion" of the mctools stack to the engine version (2.6.5) - AND restarted Metacard after saving - the menu items appear without overlapping and cut-off text like in my screenshots. But it escapes me why a non-matching version number should cause such overlapping and cutting-off !? This does not happen with engine versions 2.5 or 2.6.2 (I reset the mcversions of these earlier versions without getting adverse effects). Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Appearance of menu items in version 2.6.B11 (and earlier)
I have uploaded three screenshots (taken with a camera) that show the overlapping of text in some menu items and also cut-off text: <http://www.sanke.org/MetaMedia/MCTools-B11.htm> Regards, Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Setting a buttons icon... update
On Sat, 12 Mar 2005; Shari wrote: Discovered that the images it is using are in other stacks. (Gosh I had images I had no idea existed hiding away) But the question still remains... if I want it to use img "isabella.jpg" of stack someStack, how do I get it to use that specific image if another img exists somewhere with the same id? -- Mac and Windows shareware games http://www.gypsyware.com You can change the ID of an image. Have a look at the "ID property" in the "Metatalk Reference" or the "Transcript Dictionary". --Wilhelm Sanke <http://www.sanke.org/MetaMedia> ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
RE: Fixed bug 2471
On Fri, 11 Mar 2005, Xavier wrote: Wilhelm, It's funny but I dont remember ControlsN2O being impacted! I've been using a custom list and table for my browser since I added that feature 2 or 3 years ago... Also, ControlsN2O is no longuer MetaCard compatible since it depends on the RevGeometry manager. Something I should fix sometime this year but given the nil demand... It might never happen... Although thanks for the mention! And good job getting that fixed... cheers Xavier Xavier, in November I had had a look at your stack "ControlsN2O". As I work with both IDEs, I do not remember if I tested in Metacard or Revolution. Anyway, the bug showed. Here is the relevant part of my post of Nov 15 to this list: "MisterX" <[EMAIL PROTECTED]> wrote: > Oh, about 282 downloads according to my ControlsN2O (controlsbrowser for > runrev) stack downloads! > > But I never got affected by this bug so im wondering about the differences > in the engines or how you induce the bug... > > cheers > Xavier Xavier, I regret to state this, but you *are* affected like all others that use the "pad"-routine in their browsers. I tested this.-- Best regards, Wilhelm ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Fixed bug 2471
The announced buildnumber 77 that contains the fix has been made available with version 2.5.1-2. The affected Metacard Control Browser, as well as Richard's "Devolution", MisterX's "ControlsN20", and my "MCBrowser" and "RevBrowser´" tools thats used similar routines to display groups and nested groups, now again work as they did before August last year. Just tested the new version. Many thanks to Mark Waddingham and others that appear persuaded to include this fix in the first update of the new engine because of the general nature of the bug (after first having voiced some reservations). --Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Fixed bug 2471
Thanks for the fix which you announced to me in the post below. I see that the current release of 2.5.1 is still buildnumber 73. When and where will buildnumber 77 be available? Regards, Wilhelm Sanke http://support.runrev.com/bugdatabase/show_bug.cgi?id=2471 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-10 07:20 --- Fixed. Integrated into 2.5.1 buildnumber 77 ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Id numbers vs names
On Sat, 26 Feb 2005, Shari <[EMAIL PROTECTED]> wrote: No, they don't change by themselves. But if you're changing the program and add/delete objects... To get consecutive ID numbers of a series of controls order their layers in the sequence you wish and copy the card. On the new card you will then have your consecutive ID numbers. Cheers, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
XML Library in the MC IDE?
I resend my post below (addressed to the use-revolution list) to you as "Metacard specialists". Has anybody tried and succeeded to work with the XML library in the MC IDE? Of course one could write one's own routines for processing XML files where needed, but there *is* a XML library and I am wondering how it could be integrated in Metacard as it possible with other Rev-specific libraries or handlers. Regards, Wilhelm Sanke On Sat Jan 22, 2005, Mark Smith mark at maseurope.net wrote: >>> > Could anybody tell me where the "XML library" is located in the Rev >>> > IDE? > >> >> I think it's found as 'revXML.bundle' for MacOS and 'revXML.dll' for >> Windows in the 'components' folder inside the revolution folder... >> >> Is that what you mean? >> >> Cheers, >> >> Mark Thanks for the information. Unfortunately the XML library with 'revXML.dll' does not seem to work in the Metacard IDE. I am updating the search routines of my "Topsearch" stack to include XML-files. This works in the Rev IDE, but not in Metacard, even if I set up an identical directory structure, i.e. putting 'revXML.dll' into folder "components/global environment" like in Rev. Even the engine (version 2.6.2A3) is the same in both environments, only the names "mc.exe" and "revolution.exe" differ. I also tried to transfer the needed MC stacks into the Rev directory (only 3 extra stacks are needed besides the "mc.exe" engine to put up the slim MC IDE), but in spite of that the XML library was not accessible. The usual "transcripted" libraries or handlers defined elsewhere *can* be used in the MC IDE as well (provided the necessary links to other libraries or handlers in the Rev IDE are established in an analogous way in Metacard - which may be complicated in some cases, given the very complex structure of the Rev IDE). Am I missing something or is this an instance of lacking compatability between Revolution and Metacard? I am not familiar with DLLs, but could it be that 'revXML.dll' checks for the engine name (or the other way round) and only cooperates with "Revolution.exe" and not with the same engine named "mc.exe"? If this would be the case the compatability problem could be easily fixed inside the engine - or the DLL? - with an improved "name-calling" routine. Cheers, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MC IDE problem
On Thu, 20 Jan 2005, Richard Gaskin wrote: (snip). I just posted b8 -- please let me know how it works for you. -- Richard Gaskin Fourth World Media Corporation Could you explain what else has changed in this release? You were probably just starting to do that. Also, there is another version of a "mcTranscriptDict" of Jan 10, 2005, in the files section of the Yahoo MC_IDE list. What does it do? It does not have the two options "Scroll to" and "Filter" ( i.e. only the latter) we had added some time ago. Best regards, Wilhelm Sanke ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
