[OT] Jacques teeth (was embedding fonts]
How's the tooth? Did they ever figure out which one it was? No, but I broke one on the other side so they fixed that instead. Sharks grow new teeth as the old ones wear out. We should be so lucky. Jacques, I know it's not funny but... I'm sorry I am laughing! I wish they'd perfect the art of growing new teeth. I'd read somewhere that they had successfully implanted pigs teeth and they grew? Or am I dreaming I read that somewhere? Something about sticking pigs teeth in humans and creating new teeth, filling our holes? I'd give it try, I would I would! Shari -- Dogs and bears, sports and cars, and patriots t-shirts http://www.villagetshirts.com WlND0WS and MAClNT0SH shareware games http://www.gypsyware.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Embedding fonts in Metacard
It's an external, a dll on Windows and a bundle on Macs. You'll need to ship the appropriate external with your app, and set the externals property of your mainstack to point to the file's location. Then you can use revFontLoad and revFontUnload to manage the fonts. Beautiful! Worked like a charm! I put both externals into a folder called Externals that will ship with the game regardless of platform. That way even during development I know it's working properly as I have not set Metacard itself to use the externals. Then on preOpenStack: put fGameFolder Externals/ into loadExtras if the platform is MacOS then put loadExtras revfont.bundle into loadWhat else put loadExtras revfont.dll into loadWhat set the externals of stack nameOfMainStack to loadWhat -- Dogs and bears, sports and cars, and patriots t-shirts http://www.villagetshirts.com WlND0WS and MAClNT0SH shareware games http://www.gypsyware.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Embedding fonts in Metacard
I could swear the answer to this exists somewhere but I've looked high and low to no avail. I know that revLoadFont exists for Revolution. I thought I read where it became part of the engine. I saw the synonym XLOAD_FONT in the Rev docs so I thought perhaps that call would work in Metacard. But apparently not as my result is coming up with errors. So the question is... to load fonts in Metacard, and for distribution with a standalone created in Metacard, what do I need to do? Is there a library in Rev I can copy over? Or is this now a .dll and do I install it in the Metacard external folder? And if so, does it become part of the standalone? :-) Shari -- Dogs and bears, sports and cars, and patriots t-shirts http://www.villagetshirts.com WlND0WS and MAClNT0SH shareware games http://www.gypsyware.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Embedding fonts in Metacard
Shari wrote: I could swear the answer to this exists somewhere but I've looked high and low to no avail. I know that revLoadFont exists for Revolution. I thought I read where it became part of the engine. I saw the synonym XLOAD_FONT in the Rev docs so I thought perhaps that call would work in Metacard. But apparently not as my result is coming up with errors. So the question is... to load fonts in Metacard, and for distribution with a standalone created in Metacard, what do I need to do? Is there a library in Rev I can copy over? Or is this now a .dll and do I install it in the Metacard external folder? And if so, does it become part of the standalone? It's an external, a dll on Windows and a bundle on Macs. You'll need to ship the appropriate external with your app, and set the externals property of your mainstack to point to the file's location. Then you can use revFontLoad and revFontUnload to manage the fonts. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Embedding fonts in Metacard
It's an external, a dll on Windows and a bundle on Macs. You'll need to ship the appropriate external with your app, and set the externals property of your mainstack to point to the file's location. Then you can use revFontLoad and revFontUnload to manage the fonts. Thankee! How's the tooth? Did they ever figure out which one it was? Shari -- Dogs and bears, sports and cars, and patriots t-shirts http://www.villagetshirts.com WlND0WS and MAClNT0SH shareware games http://www.gypsyware.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Embedding fonts in Metacard
Shari wrote: It's an external, a dll on Windows and a bundle on Macs. You'll need to ship the appropriate external with your app, and set the externals property of your mainstack to point to the file's location. Then you can use revFontLoad and revFontUnload to manage the fonts. Thankee! You're welcome. How's the tooth? Did they ever figure out which one it was? No, but I broke one on the other side so they fixed that instead. Sharks grow new teeth as the old ones wear out. We should be so lucky. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Richard Gaskin wrote: I got through the last seven years by maintaining a script called FixMC which wormed through the IDE making minor behavioral and aesthetic tweaks. Is it possible to make latest version available for download? will be very much appreciated. Ideally it should not be needed, as we can fix MC ourselves now. :) What do you like about that script -- anything worth considering for the IDE itself? Just the sum of this tweaks, especially platform specific adjusting of the fonts and button sizes in dialogs and positioning of windows. While we are on this and fully realizing how controversial this issue is, I'm always changing the MouseDown script of button menuButton of stack MetaCard Menu Bar to on mouseDown which if MCcheckEdit() then put edited into stackstatus[MCtargetstack(the long id of the target)] if which is 3 then select the target popup MC SelectedObject Menu end if end if if the commandKey is down and the optionKey is down then edit script of the target else pass mouseDown end mouseDown and adding the following line after MouseUp of the same button on mouseUp which if the commandKey is down and the optionKey is down then exit to MetaCard This allows HyperCard like behavior of editing the script when you option + command click on control in any mode. Additional benefit, at least for me, is that in browse mode command + Option click edits the script of the control inside the group and in Pointer mode edits the script of the group. best regards Tariel ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
On 5/12/04 8:29 PM, Tariel Gogoberidze wrote: While we are on this and fully realizing how controversial this issue is, I'm always changing the MouseDown script of button menuButton of stack MetaCard Menu Bar to on mouseDown which if MCcheckEdit() then put edited into stackstatus[MCtargetstack(the long id of the target)] if which is 3 then select the target popup MC SelectedObject Menu end if end if if the commandKey is down and the optionKey is down then edit script of the target else pass mouseDown end mouseDown and adding the following line after MouseUp of the same button on mouseUp which if the commandKey is down and the optionKey is down then exit to MetaCard This allows HyperCard like behavior of editing the script when you option + command click on control in any mode. Additional benefit, at least for me, is that in browse mode command + Option click edits the script of the control inside the group and in Pointer mode edits the script of the group. I do something similar, but I put it into a frontscript so I don't have to edit the IDE as much. My version doesn't have the neat side-effect of editing objects/groups alternately though. Here's mine: on mouseUp -- in a frontscript if the optionkey is down and the commandKey is down \ and script editor is not in the long name of the target then edit script of the target else pass mouseUp end mouseUp -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Richard Gaskin wrote My interest in maintaining the fewest necessary options in the Plugin Manager was to further this encouragement toward universal deployment of plugins. The more options available in MC that are not in Rev, the more people have to remember if they want to share their work with several thousand people instead of just a few dozen. Personally, I agree with the above completely and hope that plugin manager will be kept simple, with only necessary and Rev compatible options. And the introduction of a non-engine message(s) into the API however harmless it is may create a bad precedent IMHO. Or I can make my own. I got through the last seven years by maintaining a script called FixMC which wormed through the IDE making minor behavioral and aesthetic tweaks. I love this stack and used it to fine tune every new version of MC since you once posted it on your web site. Unfortunately I have the very old version of this stack and some features are not working any more with latest version of MC IDE. Is it possible to make latest version available for download? will be very much appreciated. Thanks in advance Tariel A number of clients and friends have found it useful, and all that was needed to support such personal preferences were a few seconds to run the script each time an IDE was released. If things ever change in a direction I can't work with, I can find a way take care of any of my own needs and those of my clients under nearly any circumstances. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Tariel Gogoberidze wrote: Or I can make my own. I got through the last seven years by maintaining a script called FixMC which wormed through the IDE making minor behavioral and aesthetic tweaks. I love this stack and used it to fine tune every new version of MC since you once posted it on your web site. Unfortunately I have the very old version of this stack and some features are not working any more with latest version of MC IDE. Is it possible to make latest version available for download? will be very much appreciated. Ideally it should not be needed, as we can fix MC ourselves now. :) What do you like about that script -- anything worth considering for the IDE itself? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Scott Rossi wrote: The MC IDE is supposed to be after all open source now, so I think it should be possible to develop new features and then have folks try them out. Richard, is this doable? Yes, and done: Robert Brenstein is a very good scripter, he's been in the community quite a while, and none of the things he needs for his plugin, far as I can tell, will cause harm to the performance or behavior of the IDE. For these reasons I added him to the moderator list a few days ago so he can post his changes in B5. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: Why did you add the library as plugin type? Because two people presented an argument that there may be times when a stack should only be libraried at startup but not when opening the stack. Moreoever, most good libraries are designed to be initialized with start using called from an app, and have no auto-initialization of their own. But this is exactly the same argument for the active plugin type. It's not my argument, so that's as far as I can go in explaining it. As I said, beyond the same auto-launch feature that the other 99% of Transcripters use I have no further needs. Is the fact that I am the only one advocating it the issue? Or is it that I am the only one who sees the utility of it? My own conservative reaction is based on the number of requests for this new mode/type (currently one). But now that it no longer requires me to displace billable time, if it does no harm it's much easier for me to just let it be than to prolong the discussion of its necessity. If it's useful people will use it; if they don't like it they'll speak up. I'd rather let the community speak for themselves. I would, however, encourage other plugin developers to consider using only those IDE features that are also available in the Rev IDE, if for no other reason than to help the larger whole of people who enjoy this language. Since this includes the entire Transcript vocabulary and object model, it leaves things pretty wide open. My interest in maintaining the fewest necessary options in the Plugin Manager was to further this encouragement toward universal deployment of plugins. The more options available in MC that are not in Rev, the more people have to remember if they want to share their work with several thousand people instead of just a few dozen. But the community calls the shots here, and as code monkey I just implement 'em. Perhaps a healthy compromise would be to group Rev-breaking options visually in the PM with a note about their effects, so folks can make informed decisions when using them. But what I do is completely irrelevant here. This project is a community effort, so when a feature is proposed and the majority vote in favor of it, someone must write even if some will never use it. I don't see other open source projects run really so democratically but I have actively participated only in a couple :) There was a brief but interesting thread on these issues on HyperCard list just recently. Background on this is in another thread from today titled A History and Roadmap of the MC IDE Project. Anyway, I think by now I have outlined and argued all changes I envisioned for the next beta. A few people suggested to continue with the workabout solutions using either auto-open or library routes instead of supporting active plugins explicitely. Only Richard discussed the operation of Plugin Manager self. The majority has been quite silent. So, should I bother to post what I suggested as b5? Or should we continue with b4? If everyone is happy with the way b4 works, I will shut up and just make my own version as Richard suggested :) Or I can make my own. I got through the last seven years by maintaining a script called FixMC which wormed through the IDE making minor behavioral and aesthetic tweaks. A number of clients and friends have found it useful, and all that was needed to support such personal preferences were a few seconds to run the script each time an IDE was released. If things ever change in a direction I can't work with, I can find a way take care of any of my own needs and those of my clients under nearly any circumstances. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: But as far as I am concerned it is a kludge and a kludge that anyone writing such plugins must always remember to follow. If I open Plugin Manager and see something marked as a library, it should be a library. May be I am a purist, but since plugins are new to MC, it would be a shame to start with a kludge that is not necessary. Using Transcript is a kludge? I would imagine the audience for such a specific feature would be rather small, possibly more than one but unlikely to be many more given how few people use MC. Why not just encourage ever more effective use of the language, so that the developer can have any behavior she wants wants, get a much larger audience for her effort, and the other 99% of Transcripters have the opportunity to benefit from it? These are MetaCard folks here. Mostly professional developers, they seem accustomed to scripting a line or two as needed. :) So, in my view, the following categories of plugins should be recognized: Passive plugins -- plugins that are opened only manually by the user. Any MetaCard or Revolution stack can be used as a passive plugin. The Plugins menu is basically a launchpad to open them convieniently. Auto-open plugins -- plugins that are opened automatically at startup. Any MetaCard or Revolution stack can be set to be an auto-open plugin. The standard sequence of preOpen and open messages is sent when the stack opens. Library plugins -- plugins that are installed as libraries (through start using) automatically at startup: they are not opened but a 'libraryStack' message is sent to them. They open as a normal stack when selected from the Plugins menu or opened in the Plugin Manager. (new) Active plugins -- plugins that are executed automatically at startup: they are not opened but a 'pluginStack' message is sent to them. Such plugins are meant to perform one-time actions just after the MetaCard IDE loads. They open as normal stacks when selected from the Plugins menu or opened in the Plugin Manager. A given plugin can actually belong to multiple categories. They are not exclusive (except passive of course). Half of these won't work for most Transcripters, but all of them could if they just used preOpenStack as their hook instead of dependency on a new feature in an obscure IDE. I guess it's one of those subjective things. In my own head I just see one type a plugin: a stack file. Driven by an incredibly flexible engine, there's almost no end to the combinations of modes and behaviors one can come up with. For Rev compatibility it's useful to support the auto-open option, and with preOpenStack as a hook the world is the scripter's oyster. But beyond the most basic compatibility with the majority of Transcripters I'm much less excited about plugin features. Most of the handful of people who still use the MC IDE have businesses based around it. They're mostly building applications, not IDE components. The relative few who do make publicly-distributed plugins usually make them for Rev, or at least Rev-compatible. Personally I wouldn't write components for use by other developers that weren't compatible with the current shipping product, and the stuff I write for internal use hasn't been slowed down by anything absent from an IDE. Furthermore, I postulate that the order of events at startup should be to 1. build plugins menu 2. start using all library plugins 3. execute all active plugins 4. open plugins to be opened at startup Holding shift key down, should disable 2, 3, and 4. That the order of things in B4 (with the exception of #3, as active plugins hadn't been discussed here at the time). The extra stuff sounds okay to me, as long as it doesn't break Rev compatibility and I don't have to write it. I'll be the first to admit that it's hard to get me motivated to spend much time on nuances that will be used by so few people. Many of the MC developers I know have been using one form of Plugins folder or another for years, far less feature-rich and with narry a complaint I was hoping to post the B5 build you sent, but it crashes my Stuffit Expander: -- Date/Time: 2004-05-06 18:34:21 -0700 OS Version: 10.3.3 (Build 7F44) Report Version: 2 Command: StuffIt Expander Path:/Applications/Utilities/Stuffit Stuff/StuffIt Expander.app/Contents/MacOS/StuffIt Expander Version: 7.0.3 (7.0.3) PID: 3528 Thread: 2 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0004 I double-checked my Stuffit installation by downloading a fresh copy of B4, which decompressed without error. While I haven't had issues with other attachments I can't rule out a Mozilla email issue (I'm testing last night's build of Mozilla 1.7b). I was going to ask you to resend but it seemed simpler to just add you to the moderator list so I did. You can post b5 directly. You may want to double-check the Stuffit file before posting to
Re: Re: Plugins, fonts
On 07 May 2004, at 08:04, [EMAIL PROTECTED] wrote: Message: 6 Date: Thu, 06 May 2004 23:05:06 -0700 From: Richard Gaskin [EMAIL PROTECTED] Subject: Re: Plugins, fonts To: Discussions on Metacard [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Robert Brenstein wrote: Snip Please review the credit for your contributions that I added in B4 and let me know if you feel it's appropriate (Help-Licensing, Version History tab). Also, please consider updating the Read Me to include a descriptions of this new active plugin feature. That' s what I was looking for, version history, but unfortunately I still can find it. May be an embedded version history in the script of the Home stack or somewhere near would be a nice addition to make sure there always is a guide to what has changed since the previous version. Richard Gaskin Fourth World Media Corporation Nevertheless nice work. Greetings, WA ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Oops typo, can must be can't, sorry... Please review the credit for your contributions that I added in B4 and let me know if you feel it's appropriate (Help-Licensing, Version History tab). Also, please consider updating the Read Me to include a descriptions of this new active plugin feature. That' s what I was looking for, version history, but unfortunately I still can't find it. May be an embedded version history in the script of the Home stack or somewhere near would be a nice addition to make sure there always is a guide to what has changed since the previous version. Richard Gaskin Fourth World Media Corporation Nevertheless nice work. Greetings, WA And double oops because I addressed the wrong list.. Shame on me.. WA ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Plugins, fonts
Auto-open plugins -- plugins that are opened automatically at startup. Any MetaCard or Revolution stack can be set to be an auto-open plugin. The standard sequence of preOpen and open messages is sent when the stack opens. (new) Active plugins -- plugins that are executed automatically at startup: they are not opened but a 'pluginStack' message is sent to them. Such plugins are meant to perform one-time actions just after the MetaCard IDE loads. They open as normal stacks when selected from the Plugins menu or opened in the Plugin Manager. Can you give me an example of an active plugin that wouldn't work properly if it was an auto-open plugin? They look nearly identical... Ken Ray The forementioned setScriptEditorFont plugin is a good example. When I open it as a normal stack, it collects the info and displays a window showing the current selection and allows me to select another font/size. When I make new selection, it saves it and updates the currently open editors. When being closed, it also checks if I changed the selection but forgot to make it the new default. In other words, it functions like a normal stack using a number of standard messages. Upon startup, the stack is supposed to only set the default for the engine. Nothing else. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Plugins, fonts
Could they also be done via the auto-open type: on preOpenStack doMyOneStartupThing close this stack end preOpenStack Cheers Monte Well, Monte, and how do you know whether preOpenStack is to run the doMyOneStartupThing and close or whether to open the stack properly (see the example as I just posted in reply to Ken). I looked at the plugin model used in Rev and found it powerful but overly complicated. I agree with Richard that we should keep things as simple as possible in MC IDE. However, we should still try to make them right. I am not proposing this new type haphazzardly. I have been playing with plugins since b1 and we got as far as b4. In the meantime I have coded a number of plugins of different types and functionality (and envisioned even more). I realized that a) using libraries as non-libraries is a hack b) there is no 100% certain way to distinguish when preopenstack is executed from auto-open and from manual open. Sure, all MC programmers are advanced and we can code hacks in our stacks that do things the way we want them. However, plugin stacks are likely to be shared among other developers, so should be coded more like products. And the framework of the plugin technology we set in place now is not only for today. Note that there no penalty whatsoever to having the new type. It does not complicate things for using plugin manager either (except for having an extra checkbox in the window). One will use it only when needed. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: But as far as I am concerned it is a kludge and a kludge that anyone writing such plugins must always remember to follow. If I open Plugin Manager and see something marked as a library, it should be a library. May be I am a purist, but since plugins are new to MC, it would be a shame to start with a kludge that is not necessary. Using Transcript is a kludge? I would imagine the audience for such a specific feature would be rather small, possibly more than one but unlikely to be many more given how few people use MC. Why not just encourage ever more effective use of the language, so that the developer can have any behavior she wants wants, get a much larger audience for her effort, and the other 99% of Transcripters have the opportunity to benefit from it? These are MetaCard folks here. Mostly professional developers, they seem accustomed to scripting a line or two as needed. :) Come on, Richard. The issue is not in using Transcript or our ability to code. Why did you add the library as plugin type? One could use auto-open with a preOpenStack handler which checks whether it is among the stacksInUse and start using it, then exit. I am now proposing to recognize yet another type which is somewhat similar to library but with different execution characteristics. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
I was hoping to post the B5 build you sent, but it crashes my Stuffit Expander: I double-checked my Stuffit installation by downloading a fresh copy of B4, which decompressed without error. While I haven't had issues with other attachments I can't rule out a Mozilla email issue (I'm testing last night's build of Mozilla 1.7b). This was actually a zip archive produced by DropStuff. My Stuffit Expander unzips it without problems. But I vaguely recall some zip issues on OSX. I was going to ask you to resend but it seemed simpler to just add you to the moderator list so I did. You can post b5 directly. You may want to double-check the Stuffit file before posting to make sure the issue I encountered was just a Mozilla issue. Also, a housekeeping favor if you don't mind: when I post a new build into the Latest Test Version folder I move the last one into Archives/Non-Release Builds/. There's a handy Cut and Paste feature for moving files easily. Okay, I can post it myself. But I need to update the documentation first. While I see no harm in the new IDE message you've added, in the future please post feature requests to the list for discussion before posting a build that contains them. Staying away from IDE messages flying around is one of the reasons we use the MC IDE, and while I'm confident your dilligent style will avoid the pitfalls of other designs, some folks here have strong opinions about such matters and I feel their arguments have merit. The new message will be sent explicitely to a specific stack, only once when starting, and only when the stack was marked accordingly. So there is no danger of messages flying around. Yes, the matter of plugins should have been discussed more on the list. I gather they are very few people truly interested in this, though. B1 through B4 were just minor incremental improvements. The B5 changes a number of things, and thus I brought this up on the list. Above all else this is a community project. The crew here chose the X11 license specifically because it has the fewest hindrances of any GPL-compatible license. Among other things this means there's nothing stopping anyone interested in more adventurous exploration from making their own forked project from any version of the MC IDE from v2.5.1 forward. As Scott Raney says, Let a thousand flowers bloom. But this specific implementation has a narrow mandate from the community: make the fewest changes necessary. Well, yes, I could produce my own version of IDE but I am not sure whether does would be truly beneficial to the MC community. I have may be more vested interested in MC as it is and will for quite a while still be my primary production tool. Please review the credit for your contributions that I added in B4 and let me know if you feel it's appropriate (Help-Licensing, Version History tab). Also, please consider updating the Read Me to include a descriptions of this new active plugin feature. Will do. And as discussed here a couple weeks ago in response to the leftover script editor windows, please send the message mcStripAndShip to the mctools mainstack before posting; that strips any leftover script editors and saves the IDE. Ok. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
I found it at last, I must have been blind. But... (Help-Licensing, Version History tab). I didn't think about the help menu and started with the help button on the home stack. This way you reach a license button which opens the Licensing Metacard stack where no version history button is. May be it is better to make both path converge to the same Licensing stack. Sorry for the fuzz Greetings, WA ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Okay, I promise this to be the last post from me today. I have already used more bandwidth than normal :) I split my reply to Richard's long email to cover different aspects more clearly. For Rev compatibility it's useful to support the auto-open option, and with preOpenStack as a hook the world is the scripter's oyster. But beyond the most basic compatibility with the majority of Transcripters I'm much less excited about plugin features. Actually, if we are talking about Rev compatibility, we should support all its open options, including quit, as well different open modes (modeless, invisible, etc). I think this can be added without much effort. Admittedly though, all Rev plugins I have seen are passive or simple auto-open types. In case of MC, I can envision a number of plugins that expand or supplement its spartan interface. Most of the handful of people who still use the MC IDE have businesses based around it. They're mostly building applications, not IDE components. The relative few who do make publicly-distributed plugins usually make them for Rev, or at least Rev-compatible. I have indeed been using MC for many years and built a business around it so do speak. However, even for my own usage, I see plugins as a big boost, actually extending into my products (and yes, active plugins play a critical role there :). Personally I wouldn't write components for use by other developers that weren't compatible with the current shipping product, and the stuff I write for internal use hasn't been slowed down by anything absent from an IDE. True for commercial or shareware plugins. Not so true for utilities. Even some of us MC diehards may need to dig into modifying home and mctools less and start using plugins instead. Many of the MC developers I know have been using one form of Plugins folder or another for years, far less feature-rich and with narry a complaint But until now there was no way to share any such extensions to IDE. Most are probably hard coded in Home stack. Plugins allow us to share. We will see what happens. Furthermore, I postulate that the order of events at startup should be to 1. build plugins menu 2. start using all library plugins 3. execute all active plugins 4. open plugins to be opened at startup Holding shift key down, should disable 2, 3, and 4. That the order of things in B4 (with the exception of #3, as active plugins hadn't been discussed here at the time). Actually, that was not the order of things in b4. #2 and #4 were executed for each stack alphabetically. It means that if my aXXX auto-open stack needed y library to function, I had to rename it to Za. Also, in b4, shift key disables not only execution but also building the plugin menu. I think that plugins should be always openable in passive mode (that is from menu). Another important change that I made for b5 is that the plugin menu is build only at startup and when plugin manager opens (and when the folder is changed, of course). The execution is done only at startup. In beta b4, any action involving plugin manager, opening it or even changing the display mode of the list, resulted in menu being rebuilt and all stacks opening/executing again. Yes, another change I did is to place all the plugin code inside the plugin manager stack (in b4 most is in the backscript from mctools), so plugin technology is more self-contained rather than spread between mctools and plugin manager stacks. The extra stuff sounds okay to me, as long as it doesn't break Rev compatibility and I don't have to write it. I'll be the first to admit that it's hard to get me motivated to spend much time on nuances that will be used by so few people. Well, I have already coded all this for others to try. I will post a new beta over the weekend. Then anyone can try it out and see whether it is an improvement or anything should be rolled back or improved further. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: Okay, I promise this to be the last post from me today. I have already used more bandwidth than normal :) I split my reply to Richard's long email to cover different aspects more clearly. For Rev compatibility it's useful to support the auto-open option, and with preOpenStack as a hook the world is the scripter's oyster. But beyond the most basic compatibility with the majority of Transcripters I'm much less excited about plugin features. Actually, if we are talking about Rev compatibility, we should support all its open options, including quit, as well different open modes (modeless, invisible, etc). I think this can be added without much effort. If you look at little deeper I don't think you want to employ full Rev compatibility: those extra messages bouncing around are anethema to the MC experience, and the inconsistency of their behavior annoys even die-hard Rev fans. As for modeless, invisible, etc.: those were discussed here, and the general preferences was to just use the built-in properties for those things rather than Rev's custom properties which redundantly mirror the built-in ones. Once upon a time this was all so simple: folks wanted a menu to provide convenient access to extra utilities, and decided it would be useful to also have the option of having some of those automatically opened if they choose. At that point, everything else possible with the engine is available or a plugin's behavior. Why it needs to be any more complicated than that continues to elude my simple mind. Admittedly though, all Rev plugins I have seen are passive or simple auto-open types. In case of MC, I can envision a number of plugins that expand or supplement its spartan interface. Such distinctions are arbitrary. Plugins are just stack files, and using preOpenStack as a hook there is nothing the engine allows that can't be done by a plugin. Rather than two or four types or modes or whatever we call them, I see an infinite variety of possibilities. But I don't see it as the IDE's responsibility to provide point-and-click affordances for all of them. One hook opens the world for a plugin. The number of lines written to justify automatic accomodation of the script font settings plugin easily exceeds the number of lines needed to simply make it do whatever it needs in a simpler Plugins Manager. Personally I wouldn't write components for use by other developers that weren't compatible with the current shipping product, and the stuff I write for internal use hasn't been slowed down by anything absent from an IDE. True for commercial or shareware plugins. Not so true for utilities. Even some of us MC diehards may need to dig into modifying home and mctools less and start using plugins instead. Why, now that there's a plugins menu with auto-open capabilities? And how is it that such a person would be inclined to dive into direct modification of the IDE but be unable/unwilling to write a two-line initialization plugin to coordinate any specialized needs they might have? Many of the MC developers I know have been using one form of Plugins folder or another for years, far less feature-rich and with narry a complaint But until now there was no way to share any such extensions to IDE. Most are probably hard coded in Home stack. Plugins allow us to share. We will see what happens. Indeed they do, which is why I first proposed this last summer. But with a menu for easy access and an auto-open option all possibilities are available without placing finite boundaries on different types of behaviors and teaching people what these modes mean. Furthermore, I postulate that the order of events at startup should be to 1. build plugins menu 2. start using all library plugins 3. execute all active plugins 4. open plugins to be opened at startup Holding shift key down, should disable 2, 3, and 4. That the order of things in B4 (with the exception of #3, as active plugins hadn't been discussed here at the time). Actually, that was not the order of things in b4. #2 and #4 were executed for each stack alphabetically. It means that if my aXXX auto-open stack needed y library to function, I had to rename it to Za. B2 works as you describe, but the code for B4 first builds the menu, then loads libraries, then opens those plugins specified for auto-open. Also, in b4, shift key disables not only execution but also building the plugin menu. I think that plugins should be always openable in passive mode (that is from menu). Yes, it completely bypassed the entire Plugins system. Simply choosing Plugins Manager without the Shift key reactivated it. There's an argument for something more flexible, which is why I agreed with your suggestion as long as you were willing to write it. But the first pass was written only to prevent injury, and among two dozen people I'm not sure how many will be taking advantage of anything more with any
Re: Plugins, fonts
Wouter wrote: I found it at last, I must have been blind. But... (Help-Licensing, Version History tab). I didn't think about the help menu and started with the help button on the home stack. This way you reach a license button which opens the Licensing Metacard stack where no version history button is. May be it is better to make both path converge to the same Licensing stack. Modifying the Home stack is problematic, for reasons I can get into more if needed. The plan for the moment is to update the Home stack when it becomes necessary to do so with the next license change. I think I'll need some code from Dr. Raney for that, and he may be back in Colorado by then. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Wouter wrote: That' s what I was looking for, version history, but unfortunately I still can find it. May be an embedded version history in the script of the Home stack or somewhere near would be a nice addition to make sure there always is a guide to what has changed since the previous version. With the original mandate to make as few changes as possible, a simple Version History seemed sufficient to outline the few bug fixes and the original, simple Plugin Manager spec. But as things have become more complex and there are now additional messages flying around and multiple combinations of point-and-click substitutes for what used to be accomplished with already-documented Transcript, it may make sense to start a separate documentation project. Who wants to head that up? Nevertheless nice work. Thank you. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: Why did you add the library as plugin type? Because two people presented an argument that there may be times when a stack should only be libraried at startup but not when opening the stack. Moreoever, most good libraries are designed to be initialized with start using called from an app, and have no auto-initialization of their own. Here, when I need specialized behavior I just write a simple stack that uses preOpenStack to handle any initialization I need for my own purposes, from librarying stacks to setting IDE properties or anything else. But what I do is completely irrelevant here. This project is a community effort, so when a feature is proposed and the majority vote in favor of it, someone must write even if some will never use it. That's why discussing feature proposals here first is important. The nice thing about the X11 license is that if the community eventually changes to want the IDE to grow in complexity and start behaving like Rev, myself and my clients can always revert to a simpler version to maintain the lean, total-control world we're accustomed to. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
On 07 May 2004, at 18:00, [EMAIL PROTECTED] wrote: Message: 1 Date: Fri, 07 May 2004 08:24:53 -0700 From: Richard Gaskin [EMAIL PROTECTED] Subject: Re: Plugins, fonts To: Discussions on Metacard [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed snip Modifying the Home stack is problematic, for reasons I can get into more if needed. The plan for the moment is to update the Home stack when it becomes necessary to do so with the next license change. I think I'll need some code from Dr. Raney for that, and he may be back in Colorado by then. Oh, but you don't have to really change the home stack. Changing the handler of button Iicensing of stack Help Directory to: on mouseUp go to stack Licensing --Licensing MetaCard end mouseUp Gives no problems here. But may be you see one I don't... -- Richard Gaskin Fourth World Media Corporation Greetings, WA ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Most of the handful of people who still use the MC IDE have businesses based around it. They're mostly building applications, not IDE components. The relative few who do make publicly-distributed plugins usually make them for Rev, or at least Rev-compatible. As one who is still using MC as it was before Rev, I can verify. I did not participate in the poll as I was not a member and didn't have time that day to become one, so my IDE never registered. Been a busy girl, just took two months off to marry my IBM fella :-) I rarely post here anymore as all discussions appear to be geared toward the IDE. But I do read every post. Have not joined the Rev list as my version is from before the marriage of MC and Rev. I prefer the MC IDE, the Rev IDE is too cluttered and makes it harder to work. Too many windows in the way. To me the IDE should be in the background, assisting you quietly. It shouldn't be blowing its horn in your ear distracting you. I've never made a plugin for the IDE, though one of these days I will find the snippet of code that allows a full stackwide script search for a string. I am very grateful to all of you who've kept the MC IDE alive. You are very appreciated! Shari -- --Shareware Games for the Mac-- http://www.gypsyware.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Wouter wrote: Modifying the Home stack is problematic, for reasons I can get into more if needed. The plan for the moment is to update the Home stack when it becomes necessary to do so with the next license change. I think I'll need some code from Dr. Raney for that, and he may be back in Colorado by then. Oh, but you don't have to really change the home stack. Changing the handler of button Iicensing of stack Help Directory to: on mouseUp go to stack Licensing --Licensing MetaCard end mouseUp Good work. On my to-do list for the next build. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Sorry for breaking my promise to keep quiet, but either I presented my case badly or you are misreading my words, Richard. For Rev compatibility it's useful to support the auto-open option, and with preOpenStack as a hook the world is the scripter's oyster. But beyond the most basic compatibility with the majority of Transcripters I'm much less excited about plugin features. Actually, if we are talking about Rev compatibility, we should support all its open options, including quit, as well different open modes (modeless, invisible, etc). I think this can be added without much effort. If you look at little deeper I don't think you want to employ full Rev compatibility: those extra messages bouncing around are anethema to the MC experience, and the inconsistency of their behavior annoys even die-hard Rev fans. I did not say anything about FULL compatibility but about OPEN options. This meant to exclude support for the custom messages. As for modeless, invisible, etc.: those were discussed here, and the general preferences was to just use the built-in properties for those things rather than Rev's custom properties which redundantly mirror the built-in ones. I agree that using built-in properties would really suffice. However, Rev plugins may rely on the setting in the plugin manager since RunRev decided otherwise. The issue is whether we care. Coding to support this and actual execution are insignificant. The only issue is degree of compatibility with Rev. It is also possible to recognize these options as set by Rev but not support for MC stacks. Once upon a time this was all so simple: folks wanted a menu to provide convenient access to extra utilities, and decided it would be useful to also have the option of having some of those automatically opened if they choose. At that point, everything else possible with the engine is available or a plugin's behavior. Well, you know the saying about the finger and the hand. If Plugins menu is used only as a simple launchpad to open stacks, the plugin concept stops short to fullfill its promise IMHO. If we make the next step, we need to recognize that some stacks may have dual functionality when used as plugins. Why it needs to be any more complicated than that continues to elude my simple mind. Well, all this complicated stuff comes into play ONLY when you explicitely ask for it. If you don't, you have your simple world. Admittedly though, all Rev plugins I have seen are passive or simple auto-open types. In case of MC, I can envision a number of plugins that expand or supplement its spartan interface. Such distinctions are arbitrary. Plugins are just stack files, and using preOpenStack as a hook there is nothing the engine allows that can't be done by a plugin. Of course, such distinctions are arbitrary. They just help to keep things apart. Why do we talk about toplevel, modal, modeless etc stacks? They are all still stacks. Rather than two or four types or modes or whatever we call them, I see an infinite variety of possibilities. Apple and oranges. Those four modes define simply their handling by plugin manager. What the plugins do is up to programmers. But I don't see it as the IDE's responsibility to provide point-and-click affordances for all of them. One hook opens the world for a plugin. I don't understand what you mean. The number of lines written to justify automatic accomodation of the script font settings plugin easily exceeds the number of lines needed to simply make it do whatever it needs in a simpler Plugins Manager. Please explain. If I have 5 plugins that are active I need to repeat the same kludge code in each of them. In the plugin manager, it is a few extra lines which work same for any number of such plugins. If there are no such plugins, plugin manager just ignores this code. BTW, it took me longer to debug this kludge code than write and debug those few lines in Plugin manager. Personally I wouldn't write components for use by other developers that weren't compatible with the current shipping product, and the stuff I write for internal use hasn't been slowed down by anything absent from an IDE. True for commercial or shareware plugins. Not so true for utilities. Even some of us MC diehards may need to dig into modifying home and mctools less and start using plugins instead. Why, now that there's a plugins menu with auto-open capabilities? That is what I said, didn't I? And how is it that such a person would be inclined to dive into direct modification of the IDE but be unable/unwilling to write a two-line initialization plugin to coordinate any specialized needs they might have? That is what I said, too, didn't I? Many of the MC developers I know have been using one form of Plugins folder or another for years, far less feature-rich and with narry a complaint But until now there was no way to share any such extensions to IDE. Most are probably hard coded in Home
Re: Plugins, fonts
Shari wrote: Been a busy girl, just took two months off to marry my IBM fella :-) Congratulations. Good to see you back here. You've been missed. Have not joined the Rev list as my version is from before the marriage of MC and Rev. The Rev list is where the meaty language discussion happens these days. It's a much busier list, so digest mode may be useful. -- Richard Gaskin Fourth World Media Corporation ___ Rev tools and more: http://www.fourthworld.com/rev ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: Why did you add the library as plugin type? Because two people presented an argument that there may be times when a stack should only be libraried at startup but not when opening the stack. Moreoever, most good libraries are designed to be initialized with start using called from an app, and have no auto-initialization of their own. But this is exactly the same argument for the active plugin type. Is the fact that I am the only one advocating it the issue? Or is it that I am the only one who sees the utility of it? But what I do is completely irrelevant here. This project is a community effort, so when a feature is proposed and the majority vote in favor of it, someone must write even if some will never use it. I don't see other open source projects run really so democratically but I have actively participated only in a couple :) There was a brief but interesting thread on these issues on HyperCard list just recently. Anyway, I think by now I have outlined and argued all changes I envisioned for the next beta. A few people suggested to continue with the workabout solutions using either auto-open or library routes instead of supporting active plugins explicitely. Only Richard discussed the operation of Plugin Manager self. The majority has been quite silent. So, should I bother to post what I suggested as b5? Or should we continue with b4? If everyone is happy with the way b4 works, I will shut up and just make my own version as Richard suggested :) Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Once upon a time this was all so simple: folks wanted a menu to provide convenient access to extra utilities, and decided it would be useful to also have the option of having some of those automatically opened if they choose. At that point, everything else possible with the engine is available or a plugin's behavior. If Plugins menu is used only as a simple launchpad to open stacks, the plugin concept stops short to fullfill its promise IMHO. If we make the next step, we need to recognize that some stacks may have dual functionality when used as plugins. At the risk of interjecting a small dose of reality here, I hope we all know that the MC IDE is a volunteer project. My understanding is the Rev folks are not obligated to support it, but they must allow for the MC IDE to be compatible with the latest Rev engine. I also don't believe there have been any offers to seriously revamp MC as most folks know how time consuming this would be, especially for something that is not officially supported and used by a handfull of developers. Since Richard Gaskin has graciously offered to act as project manager on a *volunteer* basis, perhaps it would be more effective to go and build whatever enhancement is desired yourself, rather than arguing the merits of the enhancement. The MC IDE is supposed to be after all open source now, so I think it should be possible to develop new features and then have folks try them out. Richard, is this doable? Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
on Fri, 07 May 2004 12:32:28 -0700 Scott Rossi wrote: [snip] The MC IDE is supposed to be after all open source now, so I think it should be possible to develop new features and then have folks try them out. [snip] Does exist a wish list for new features for the mc ide? For example, i've buy the altbrowser dll from Altuit. i'm using this dll as a player for different media, like real audio, mp3 and flash animations... Could it be possible to create a tool in the palette, that lets you draw a rectangle of the size of your player and a mc plug-in automatically install all the scripts to use the dll as player only in that stack? (This means no need to install QuickTime on windows pc) Thanks in advance. al = Visit my site: http://www.geocities.com/capellan2000/ Search the mail list: http://mindlube.com/cgi-bin/search-use-rev.cgi __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: Once upon a time this was all so simple: folks wanted a menu to provide convenient access to extra utilities, and decided it would be useful to also have the option of having some of those automatically opened if they choose. At that point, everything else possible with the engine is available or a plugin's behavior. ... Why it needs to be any more complicated than that continues to elude my simple mind. Well, all this complicated stuff comes into play ONLY when you explicitely ask for it. But I didn't. Like I said, I know you write good code and as long as the features you're adding to support your plugin do no harm and I don't have to write them I have no issue with it. But looking ahead, it's worth noting that the specialized needs of your plugin have introduced a non-engine message into the API for the first time in 14 years. In this specific case I see no harm, but going forward it may be prudent to be mindful of a potential slippery slope. If folks want a Rev-like IDE, there's Rev. If your plugin is now well accomodated then there will be no further need for such things, and the issue goes away. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Plugins, fonts
Good morning On both Mac Classic and Windows XP using engine 2.6 and IDE 2.6.b4: When I open the script editor, see its small indistinct font and want to change it, I select Brensteins SetScriptEditorFont under Plugins and head for the font. However, the pointer tool does not change when over the plugin stack. Would it be possible to make it change automatically to browse tool? And when talking about fonts, on Windows XP all instructions in the Home stack (for instance: File, Edit, Tools etc.) show in a very small and ugly font (1024x756), actually, it is not much better in the Rev environment either. But would it be possible to make it more distinct, use another font or preferably use a bigger size? Regards Signe Marie Sanne 1. amanuensis Signe Marie Sanne e-mail: [EMAIL PROTECTED] Romansk Institutttel: +47 55 58 21 27 Øisteins gt. 1 5007 Bergen http://www.hf.uib.no/hfolk/mlab/hjem/default.html Norway ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Signe Marie Sanne wrote: Good morning On both Mac Classic and Windows XP using engine 2.6 and IDE 2.6.b4: When I open the script editor, see its small indistinct font and want to change it, I select Brensteins SetScriptEditorFont under Plugins and head for the font. However, the pointer tool does not change when over the plugin stack. Would it be possible to make it change automatically to browse tool? If the stack's style property is set to modeless or palette it will behave as though always in browse mode. And when talking about fonts, on Windows XP all instructions in the Home stack (for instance: File, Edit, Tools etc.) show in a very small and ugly font (1024x756), actually, it is not much better in the Rev environment either. But would it be possible to make it more distinct, use another font or preferably use a bigger size? What is the fontsize of those elements, and what is the normal such of such elements on your system? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
At 00:12 06.05.2004 -0700, you wrote: Signe Marie Sanne wrote: Good evening to you, Richard. I see that you still are at work Good morning On both Mac Classic and Windows XP using engine 2.6 and IDE 2.6.b4: When I open the script editor, see its small indistinct font and want to change it, I select Brensteins SetScriptEditorFont under Plugins and head for the font. However, the pointer tool does not change when over the plugin stack. Would it be possible to make it change automatically to browse tool? If the stack's style property is set to modeless or palette it will behave as though always in browse mode. I'll change the stack's style. And when talking about fonts, on Windows XP all instructions in the Home stack (for instance: File, Edit, Tools etc.) show in a very small and ugly font (1024x756), actually, it is not much better in the Rev environment either. But would it be possible to make it more distinct, use another font or preferably use a bigger size? What is the fontsize of those elements, and what is the normal such of such elements on your system? Here I understand that I have revealed my ignorance of the system as such. I now see that the font for the rest of the system is just the same small ugly. (I used to work on Mac for more than 10 years before moved on to Windows XP). I'll look into it. Thanks again. Signe Marie ___ 1. amanuensis Signe Marie Sanne e-mail: [EMAIL PROTECTED] Romansk Institutttel: +47 55 58 21 27 Øisteins gt. 1 5007 Bergen http://www.hf.uib.no/hfolk/mlab/hjem/default.html Norway ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Signe Marie Sanne wrote: Good morning On both Mac Classic and Windows XP using engine 2.6 and IDE 2.6.b4: When I open the script editor, see its small indistinct font and want to change it, I select Brensteins SetScriptEditorFont under Plugins and head for the font. However, the pointer tool does not change when over the plugin stack. Would it be possible to make it change automatically to browse tool? If the stack's style property is set to modeless or palette it will behave as though always in browse mode. Okay, the SetScriptEditorFont plugin now opens as modeless by default. It also forces the font change onto the currently open script editor windows. However, I can't release this version until MC IDE b5 is out because the plugin works now in a mode not supported by b4. And when talking about fonts, on Windows XP all instructions in the Home stack (for instance: File, Edit, Tools etc.) show in a very small and ugly font (1024x756), actually, it is not much better in the Rev environment either. But would it be possible to make it more distinct, use another font or preferably use a bigger size? I guess we should think about SetDefaultIDEfont plugin :) Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
At 11:19 06.05.2004 +0200, you wrote: Signe Marie Sanne wrote: Good morning On both Mac Classic and Windows XP using engine 2.6 and IDE 2.6.b4: When I open the script editor, see its small indistinct font and want to change it, I select Brensteins SetScriptEditorFont under Plugins and head for the font. However, the pointer tool does not change when over the plugin stack. Would it be possible to make it change automatically to browse tool? If the stack's style property is set to modeless or palette it will behave as though always in browse mode. Okay, the SetScriptEditorFont plugin now opens as modeless by default. It also forces the font change onto the currently open script editor windows. However, I can't release this version until MC IDE b5 is out because the plugin works now in a mode not supported by b4. Thanks for the correction, Robert. And when talking about fonts, on Windows XP all instructions in the Home stack (for instance: File, Edit, Tools etc.) show in a very small and ugly font (1024x756), actually, it is not much better in the Rev environment either. But would it be possible to make it more distinct, use another font or preferably use a bigger size? I guess we should think about SetDefaultIDEfont plugin :) Yes, that's an idea I would applaud. Changing the system's text size did not change much text in Home.mc, MetaCardMenuBar.mc etc. Only text on the uppermost line with the close box became bigger, otherwise the text remains as small and illegible as before (at least for my old eyes). Regards Signe Marie Sanne 1. amanuensis Signe Marie Sanne e-mail: [EMAIL PROTECTED] Romansk Institutttel: +47 55 58 21 27 Øisteins gt. 1 5007 Bergen http://www.hf.uib.no/hfolk/mlab/hjem/default.html Norway ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: Okay, the SetScriptEditorFont plugin now opens as modeless by default. It also forces the font change onto the currently open script editor windows. However, I can't release this version until MC IDE b5 is out because the plugin works now in a mode not supported by b4. I'll see if I can get that out today. But what does your plugin need that isn't supported in B4? If it won't run with B4 it won't run with Rev, an undesirable thing for most plugins since that's what the other 99% of Transcripters use. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: Okay, the SetScriptEditorFont plugin now opens as modeless by default. It also forces the font change onto the currently open script editor windows. However, I can't release this version until MC IDE b5 is out because the plugin works now in a mode not supported by b4. I'll see if I can get that out today. But what does your plugin need that isn't supported in B4? If it won't run with B4 it won't run with Rev, an undesirable thing for most plugins since that's what the other 99% of Transcripters use. -- Richard Gaskin Richard, the new version is programmed as an active plugin, which will (hopefully) be supported as of b5. I guess you haven't had time yet to check out the files I sent you. For those listening in and wondering: the stack in question ran under pre-b5 versions pretending to be a library in order to be called but not opened at startup. But it ain't library. All it does is sets the script editor font when the IDE starts. When opened normally, it presents a window to choose the font and size. In other words, it is akin to an extension/control panel combo in Mac OS. Since I can imagine quite a few stacks that function in this manner, I have therefore suggested to recognize a separate plugin category and passed an implementation suggestion to Richard. I call them 'active' plugins since they get activated at startup, but may be someone can suggest a better term. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: But what does your plugin need that isn't supported in B4? Richard, the new version is programmed as an active plugin, which will (hopefully) be supported as of b5. I guess you haven't had time yet to check out the files I sent you. For those listening in and wondering: the stack in question ran under pre-b5 versions pretending to be a library in order to be called but not opened at startup. But it ain't library. All it does is sets the script editor font when the IDE starts. When opened normally, it presents a window to choose the font and size. In other words, it is akin to an extension/control panel combo in Mac OS. B4 added the auto-library option, which takes care of loading the library. As a library it can respond to the libraryStack message to do any faceless operations, and can even stop using itself. For the UI selecting it from the menu opens it. What more is needed for that dual behavior? I may be a little slow, running on only one cup of coffee today -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
For those listening in and wondering: the stack in question ran under pre-b5 versions pretending to be a library in order to be called but not opened at startup. But it ain't library. All it does is sets the script editor font when the IDE starts. When opened normally, it presents a window to choose the font and size. In other words, it is akin to an extension/control panel combo in Mac OS. B4 added the auto-library option, which takes care of loading the library. As a library it can respond to the libraryStack message to do any faceless operations, and can even stop using itself. For the UI selecting it from the menu opens it. What more is needed for that dual behavior? I may be a little slow, running on only one cup of coffee today -- Richard Gaskin This is exactly what I did earlier, as you read in my email. But as far as I am concerned it is a kludge and a kludge that anyone writing such plugins must always remember to follow. If I open Plugin Manager and see something marked as a library, it should be a library. May be I am a purist, but since plugins are new to MC, it would be a shame to start with a kludge that is not necessary. So, in my view, the following categories of plugins should be recognized: Passive plugins -- plugins that are opened only manually by the user. Any MetaCard or Revolution stack can be used as a passive plugin. The Plugins menu is basically a launchpad to open them convieniently. Auto-open plugins -- plugins that are opened automatically at startup. Any MetaCard or Revolution stack can be set to be an auto-open plugin. The standard sequence of preOpen and open messages is sent when the stack opens. Library plugins -- plugins that are installed as libraries (through start using) automatically at startup: they are not opened but a 'libraryStack' message is sent to them. They open as a normal stack when selected from the Plugins menu or opened in the Plugin Manager. (new) Active plugins -- plugins that are executed automatically at startup: they are not opened but a 'pluginStack' message is sent to them. Such plugins are meant to perform one-time actions just after the MetaCard IDE loads. They open as normal stacks when selected from the Plugins menu or opened in the Plugin Manager. A given plugin can actually belong to multiple categories. They are not exclusive (except passive of course). Furthermore, I postulate that the order of events at startup should be to 1. build plugins menu 2. start using all library plugins 3. execute all active plugins 4. open plugins to be opened at startup Holding shift key down, should disable 2, 3, and 4. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
On 5/6/04 7:02 PM, Robert Brenstein wrote: For those listening in and wondering: the stack in question ran under pre-b5 versions pretending to be a library in order to be called but not opened at startup. But it ain't library. All it does is sets the script editor font when the IDE starts. When opened normally, it presents a window to choose the font and size. In other words, it is akin to an extension/control panel combo in Mac OS. B4 added the auto-library option, which takes care of loading the library. As a library it can respond to the libraryStack message to do any faceless operations, and can even stop using itself. For the UI selecting it from the menu opens it. What more is needed for that dual behavior? I may be a little slow, running on only one cup of coffee today -- Richard Gaskin This is exactly what I did earlier, as you read in my email. But as far as I am concerned it is a kludge and a kludge that anyone writing such plugins must always remember to follow. If I open Plugin Manager and see something marked as a library, it should be a library. May be I am a purist, but since plugins are new to MC, it would be a shame to start with a kludge that is not necessary. So, in my view, the following categories of plugins should be recognized: Passive plugins -- plugins that are opened only manually by the user. Any MetaCard or Revolution stack can be used as a passive plugin. The Plugins menu is basically a launchpad to open them convieniently. Auto-open plugins -- plugins that are opened automatically at startup. Any MetaCard or Revolution stack can be set to be an auto-open plugin. The standard sequence of preOpen and open messages is sent when the stack opens. Library plugins -- plugins that are installed as libraries (through start using) automatically at startup: they are not opened but a 'libraryStack' message is sent to them. They open as a normal stack when selected from the Plugins menu or opened in the Plugin Manager. (new) Active plugins -- plugins that are executed automatically at startup: they are not opened but a 'pluginStack' message is sent to them. Such plugins are meant to perform one-time actions just after the MetaCard IDE loads. They open as normal stacks when selected from the Plugins menu or opened in the Plugin Manager. A given plugin can actually belong to multiple categories. They are not exclusive (except passive of course). Furthermore, I postulate that the order of events at startup should be to 1. build plugins menu 2. start using all library plugins 3. execute all active plugins 4. open plugins to be opened at startup Holding shift key down, should disable 2, 3, and 4. These are mostly all good, I like it. The only one that probably isn't essential though is the active type. As Richard said, that can already be done using a library type stack. Something like this: on librarystack doMyOneStartupThing stop using the script of this stack end librarystack Would work, yes? Why invent another type? -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
I wrote: These are mostly all good, I like it. The only one that probably isn't essential though is the active type. As Richard said, that can already be done using a library type stack. I saw Robert's response to this after I read his message a second time, so I withdraw this comment. Apologies for the clutter. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Plugins, fonts
Auto-open plugins -- plugins that are opened automatically at startup. Any MetaCard or Revolution stack can be set to be an auto-open plugin. The standard sequence of preOpen and open messages is sent when the stack opens. (new) Active plugins -- plugins that are executed automatically at startup: they are not opened but a 'pluginStack' message is sent to them. Such plugins are meant to perform one-time actions just after the MetaCard IDE loads. They open as normal stacks when selected from the Plugins menu or opened in the Plugin Manager. Can you give me an example of an active plugin that wouldn't work properly if it was an auto-open plugin? They look nearly identical... Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Plugins, fonts
These are mostly all good, I like it. The only one that probably isn't essential though is the active type. As Richard said, that can already be done using a library type stack. Something like this: on librarystack doMyOneStartupThing stop using the script of this stack end librarystack Would work, yes? Why invent another type? Could they also be done via the auto-open type: on preOpenStack doMyOneStartupThing close this stack end preOpenStack Cheers Monte PS Here's my rather long winded draft proposal for Revolution modularity which is plugin related and could be implemented in mc or a fork of mc as a demo (it's in Wiki format): IDE Modularity !!!Introduction In general all the IDE truly needs to do is the basics. Allow setting of object properties, scripting, standalone building, object creation etc. Everything else can be done with script libraries and user interfaces for them that are either part of the IDE or not. What I'm suggesting here is a way to integrate libraries and user interfaces for them into the IDE in a general way that can be exposed to third parties. So what would we need to do this? #auto loading of modules the user has chosen to load #module documentation that integrates with the Rev docs yet is clearly marked as belonging to a particular module as the current libraries are now #standalone building support (partially implemented) #manager style stacks able to be listed under the Tools menu #inspector panels able to be listed for specific objects #preference panes So what's the benefit of this effort? #Third parties can seamlessly extend the IDE (think Jan's reporting package) #Some of the more complex components of the ide can be moved into optional modules to simplify maintenance and allow those that don't use them to switch them off (think Geometry library) #Simplify management of the IDE differences required for Express, Studio and Enterprise Editions (think Database Manager and library for Express or additional CVS Manager for Enterprise) #Some components that haven't been used much and are costly to maintain could become community projects (think Animation Manager and library) !!!Basic IDE components Script editor and debug tools Inspector shell including -All properties pane (cetegorized and using disclosure triangles for main categories) -Custom properties pane Help interface and general documentation Menubar/Toolbar shell Tools palette Icon manager Standalone builder Preferences shell including -preferences for the basic IDE components -switching on/off modules Application browser Message box !!!Configurable Modules A configurable module may contain resources to add to the IDE the following components: -Toolbar buttons -Externals -Library stacks -Back scripts -Front scripts -Inspector panes -Preference panes -Documentation -menuItems/buttons on menubar -Contextual menuItems on objects -Contextual menuItems in application browser !!Module Design The revPreferences stack will have a custom property set that identifies which modules are to be loaded at startup. Any modules that don't have a setting here should be loaded by default. Module names are identified by the name of the directory in the modules subdirectory. A module name should be considered like a namespace so custom properties, message names, stack names etc should be prefixed with it. Looping over the directories of the modules subdirectory and testing against the custom property set in revPreferences is the first stage of the module loading process. For each module to be loaded the IDE must loop over the files in the directory to identify how and where to extend the IDE. For each stackFile found a custom property set of the mainStack of the stackFile should identify how it should be integrated into the IDE. For example, if the custom property set had two keys (componentType and standaloneOption) with values (libraryStack and true) the stack would be loaded as a library and it would be provided as an option during the standalone build process for inclusion into standalones. Implementation details for each component type are provided below: !Toolbar buttons (componentType = toolbarButton) Stack containing X number of buttons each representing 1 toolbar button to be added to the revMenubar stack. It's possible that we could end up with too many buttons here so a means to choose which order these are displayed in might be nice with a button at the end that showed any remainders in a menu. The icon properties and label of the buttons are copied to the shell button created on the revMenubar stack. From there it's just a matter of trapping button related messages and sending them to the original button. If we have object frontscripts by then that may be the way to go. !Externals (not stackFiles) Work needs to be done here to work out the best options for dynamic external loading but the ideal situation is at loadtime the correct external for that platform can be loaded and inserted into
Fonts in Linux
Has anyone found a workaround to the MC font problems in Linux? Particularly Red Hat 9, TrueType fonts just do not work...well, they work in everything but MC. JR ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Cross-platform fonts
On Thursday, July 10, 2003, at 10:57 AM, Richard Gaskin wrote: I know some slipped thru the cracks, as initially I chose Helvetica as the default, only to discover it was not very consistent on the platforms, so I switched to Arial for most text, and occasionally Verdana. They seem to be pretty consistent from platform to platform. This raises a question: Now that Micro$oft has abandoned EI for the Mac, what will become of the useful set of cross-platform fonts that used to be pre-installed on both Mac and Win? I expect to use the multi-platform Revolution fonts that come with Revolution 3.0. ;-) Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Fun with Large Fonts
In Microsoft operating systems the user can set the default font size for controls, window titles, etc. According to the spec, an application should respond by querying the registry to get the current font metrics and adjust all controls to match the formatted width and height. If controls overlap as a result of this resizing, the window should be enlarged too accomodate them. That's a lot of work, and for little benefit: by the time the controls are resized to accomodate the text and the window is resized to accomodate the controls, the result is not much different from simply lowering the resolution of the monitor. But here's the punchline: this setting is set in the Display control panel, which in XP ignores the font size settings altogether. ;) So my question for you folks is: Do any of you know if this is a bug in XP's Display control panel, or is Microsoft now telling us we can also ignore the Large Fonts setting? -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Installing fonts - Windows weirdness
Hi Mark, i am also highly interested in looking at these scripts :-) I have made a font installer that we use for our font products. If you or anyone would like a copy I can make it available via revnet. Pros: 1. Installs fonts on either Mac or Win 2. You can registration number protect the installer so only your users can install fonts 3. Could be modified to install other files as well with a little extra work. 4. Is commented pretty well. No docs for it though. Negatives: 1. Is highly geared towards our needs, but you can modify to suite your needs. Sounds wonderful. Does anyone remember the old x-command collection of Tuviah? There was also a function that could do exactly that on windows. But if Mark has a native metatalk solution, wow :-) Best regards, Mark Talluto http://www.canelasoftware.com Regards Klaus Major [EMAIL PROTECTED] www.major-k.de ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Installing fonts - Windows weirdness
Thanks Ken... These are .ttf (TrueType) fonts...I am also starting to discover the 'fun' involved with installing things in Linux too! JR From: Ken Ray [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Installing fonts - Windows weirdness Date: Tue, 17 Jun 2003 16:29:28 -0500 Organization: Sons of Thunder Software Reply-To: [EMAIL PROTECTED] JR, What kind of fonts are they (TrueType, OpenType, PostScript)? If you don't know, post the names of the files you're trying to install. Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Installing fonts - Windows weirdness
Do you need to do this from inside RunRev, or can you use an installer? The reason I ask is that there are probably a few registry updates that need to be made that an installer will do for you. Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RCS Sent: Wednesday, June 18, 2003 12:30 PM To: [EMAIL PROTECTED] Subject: Re: Installing fonts - Windows weirdness Thanks Ken... These are .ttf (TrueType) fonts...I am also starting to discover the 'fun' involved with installing things in Linux too! JR From: Ken Ray [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Installing fonts - Windows weirdness Date: Tue, 17 Jun 2003 16:29:28 -0500 Organization: Sons of Thunder Software Reply-To: [EMAIL PROTECTED] JR, What kind of fonts are they (TrueType, OpenType, PostScript)? If you don't know, post the names of the files you're trying to install. Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metac ard ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Installing fonts - Windows weirdness
I have a strange problem when installing fonts on Windows computers. The fonts will install correctly (just copying them from a 'source' folder to the 'Fonts' folder) but the system will not recognize them...even after restart. The strange thing is, when I go to the fonts folder (checking if they are there), they are now 'seen' by the system (I guess openning the folder is refreshing something?). Is there something else I am supposed to do? Thanks for any help, JR ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Retaining fonts
Hello, I have searched both Metacard and Revolution archives in order to find something I read perhaps a few weeks ago, but I have not been able to retrace it. It was not only about how to get all the various styles of the original text file into a field (italic, underline etc.) but also have to retain the fonts used in the original file. Can someone direct me to the right posting, or even better, provide the script line? Thanks in advance. Regards Signe Marie Sanne -- 1. amanuensis Signe Marie Sanne e-mail: [EMAIL PROTECTED] Romansk Institutttel: +47 55 58 21 27 Oysteins gt. 1 5007 Bergen http://www.hf.uib.no/hfolk/mlab/default.html Norway ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Fonts
Hi Everyone, I'm working on a Mac, creating my first cross-platform stack, and I've read in the archives that Arial, Time New Roman and Helvetica are fairly safe fonts to use. Any others? Regards, Greg Gregory Lypny Associate Professor John Molson School of Business Concordia University Montreal, Canada It's not dark yet, But it's gettin' there. - Bob Dylan Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Fonts
Recently, Gregory Lypny wrote: I'm working on a Mac, creating my first cross-platform stack, and I've read in the archives that Arial, Time New Roman and Helvetica are fairly safe fonts to use. Any others? Verdana is also good for on-screen use. Regards, Scott _ Scott Rossi Tactile Media - Multimedia Design Creative Director Email: [EMAIL PROTECTED] Web: www.tactilemedia.com Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Fonts
Gregory Lypny asked: I've read in the archives that Arial, Time New Roman and Helvetica are fairly safe fonts to use. Any others? Helvetica is not listed in my MSWord. But Century, the Latinate font which my Japanese OS prefers, seems ubiquitous. Cheers. Nicolas Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Fonts
Thanks, Nicholas and Scott for the font advice. Greg _ Gregory Lypny Associate Professor of Finance John Molson School of Business Concordia University _ Take chances, make mistakes! - Ms Frizzle, The Magic School Bus E-mail forum: [EMAIL PROTECTED] Visit Pareto at http://rubbersoul.concordia.ca Visit Borsa at http://rubbersoul.concordia.ca/Borsa_Classroom Crash site for notes and quizzes at http://homepage.mac.com/gregorylypny/FileSharing1.html Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
RE: Fonts
Fonts are a bugger! I can't remember the url but if you search for fonts on the Microsoft website you will find a cross platform package of fonts that are free to download and are also distributed with IE 5. I think you can even distribute them but I'm not sure. Note that Windows 95 has a very limited set of fonts and unless they have installed IE 5 or Office then you will have trouble. Also Arial is quite a bit larger on MacOS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Rossi Sent: Thursday, 1 November 2001 6:06 AM To: [EMAIL PROTECTED] Subject: Re: Fonts Recently, Gregory Lypny wrote: I'm working on a Mac, creating my first cross-platform stack, and I've read in the archives that Arial, Time New Roman and Helvetica are fairly safe fonts to use. Any others? Verdana is also good for on-screen use. Regards, Scott _ Scott Rossi Tactile Media - Multimedia Design Creative Director Email: [EMAIL PROTECTED] Web: www.tactilemedia.com Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Large fonts, revisited
I was at a conference yesterday where some software I had built was being
demo'd, and the presenter had his monitor turned up to 1600x1200 with the
Large Fonts option on. Ugly as sin and hard to use, but even uglier than
Windows was what it did to my control layouts: text gets clipped, menus
appear cramped and overlapping, etc.
In order to put the Made for Windows logo on your box you need to gracefully
support Large Fonts (and a few other things). Given that the apporpriate
behavior for an app is to resize controls to match the font setting,
effectively you'd get pretty much the same result ('cept for the size of the
drag bar) by simply turning one's resolution down. But logic aside, people
will continue to use this feature, and we need a strategy to deal with it.
Aside from getting the formattedWidth of each control on every card in every
window, are there other ways to deal with Large Fonts? With VB, the
resizing seems to happen automatically.
--
Richard Gaskin
Fourth World Media Corporation
Multimedia Design and Development for Mac, Windows, UNIX, and the Web
_
[EMAIL PROTECTED] http://www.FourthWorld.com
Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716
Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to [EMAIL PROTECTED], not this list.
Fonts in MC
Hi again, Yes, it's question day...;-) I have a few questions regarding font display quality (aliasing, etc) in MC Revolution... Does anyone have a strong experience on this topic ? Thanks. JB Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: System Colors Fonts
Monte Goulding wrote/ schreef: Hi this is somewhat related to Sjoerd's comment about determining system fonts. I don't know what the Mac situation is but on Windows you can change the color of all the windows. Many development environments allow you to specify that you want to use a specific system color for a button or whatever. This means that when your app opens on a non standard windows color scheme it doesn't look totally crap. At the moment you can use the external collection to do it but it really should be incorporated into the engine and be the default settings for Windows look and feel unless something else is specified. I think this will be an even more important issue with Windows XP as you will be able to apply skins to the GUI. If anybody doesn't think it's an issue go to the display settings and change it to something really different. Everything in windows looks the same appart from your app. What's more it all changes the instant you change the settings. Which should be incorporated into the engine if possible. Agreed wholeheartedly! Sorry if this is a hard one. Also, the standard fonts/ colors of objects should be "System", so that MC looks OS- like by default. Regards, Sjoerd Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
System Colors Fonts
Hi this is somewhat related to Sjoerd's comment about determining system fonts. I don't know what the Mac situation is but on Windows you can change the color of all the windows. Many development environments allow you to specify that you want to use a specific system color for a button or whatever. This means that when your app opens on a non standard windows color scheme it doesn't look totally crap. At the moment you can use the external collection to do it but it really should be incorporated into the engine and be the default settings for Windows look and feel unless something else is specified. I think this will be an even more important issue with Windows XP as you will be able to apply skins to the GUI. If anybody doesn't think it's an issue go to the display settings and change it to something really different. Everything in windows looks the same appart from your app. What's more it all changes the instant you change the settings. Which should be incorporated into the engine if possible. Sorry if this is a hard one. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Installing Fonts
Thanks Peter Is FontoGrapher freeware because I'm a bit short on cash at the moment;-) Regards Monte Sorry to say no, FontoGrapher is decidedly unfreeware, it costs about £220 here in the UK, about $300 I guess!! I don't know what if any free/shareware there is that does a similar job, certainly next to nothing on the Mac which is where I tend to operate most of the time. There used to be other packages on the Mac, but these have been discontinued leaving FontoGrapher as the only package and this hasn't been updated for some time. Not that it needs updating especially, it still seems to do the job OK and generates fonts for Mac and Windows. Cheers Peter -- Peter Reid Reid-IT Limited, Loughborough, Leics., UK Tel: +44 (0)1509 268843 Fax: +44 (0)870 052 7576 E-mail: [EMAIL PROTECTED] Web: http://www.reidit.co.uk Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Installing Fonts
On 18/11/00 7:15 pm, Sjoerd Op 't Land [EMAIL PROTECTED] wrote: Now that we're on the subject, is it possible to 'include' a font file in a stack, and install it on start? I think this can be done on the Mac by storing the fonts in the resource fork, on Windows use the Externals Collection. Regards, Kevin Kevin Miller [EMAIL PROTECTED] http://www.runrev.com/ Runtime Revolution Limited (formerly Cross Worlds Computing). Tel: +44 (0)131 672 2909. Fax: +44 (0)1639 830 707. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Installing Fonts
So what is the general theme here can we copy font files that have been installed in our font directory and distribute them with our apps? I commonly use a font that was not part of Windows 95 but has been part Windows since. I just need to check if it's there which it probably is and if it's not install it. Any advice? Regards Monte From: Richard Gaskin [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Installing Fonts Date: Sat, 18 Nov 2000 22:00:32 -0800 Fonts are copyrighted. However, strictly speaking, it is the name of the font rather than the actual font itself that is copyrighted. So, technically, you could duplicate a font and distribute it under a different name. This is being looked at by various copyright authorities across the world, so don't trust this as a reliable tactic! Ethically of course, this "copy rename" strategy is a no-no! This changes so much that I can't be sure, but last I heard this was the story with copyrighting fonts: The letter forms are not copyrightable. They are viewed as having primarily "utilitarian" value only, and are therefore not protected under copyright law. IMHO this is silly, and has dire ramifications for all industrial design, but hey, the Bern folks never asked me. However - OUTLINE fonts ARE copyrightable, not as letter forms but as software. Since they contain descriptions of the math needed to render the letter forms, outline fonts (as opposed to bitmap, which I just don't see very often anymore) are considered a form of "executable code", and are protected as with any software program. Again, I haven't followed this issue closely in the last few years, so it may have changed again, but that's how I last heard it. More than just renaming the code, running it through a tool like Fontographer may fully satisfy the requirements, since doing so will, if done properly, cause the code to be regenerated in a different form, hopefully substantially different enough to avoid copyright conflicts. Since this practice of making "knock off" fonts this way had become rather popular, this may have given rise to the perception that merely changing the name is all that's required -- since the law doesn't recognize letter forms as a creative work, to the user the only discernable difference is the name (even though the underlying code may be very differently structured). But as they require us to say here in Kalifornia: "I am not an attorney. If you need the services of an attorney you should contact a qualified professional in your area." ;) -- Richard Gaskin Fourth World Media Corporation Multimedia Design and Development for Mac, Windows, UNIX, and the Web _ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 ICQ#60248349Fax: 323-225-0716 Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Installing Fonts
Thanks Peter Is FontoGrapher freeware because I'm a bit short on cash at the moment;-) Regards Monte From: Peter Reid [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Installing Fonts Date: Mon, 20 Nov 2000 00:58:33 + So what is the general theme here can we copy font files that have been installed in our font directory and distribute them with our apps? I commonly use a font that was not part of Windows 95 but has been part Windows since. I just need to check if it's there which it probably is and if it's not install it. Any advice? Legally, I believe the answer is that you cannot distribute fonts unless specifically licensed to do so (very rare) or unless they are your own designs. You could try the FontoGrapher route to making your "own" fonts?? However, if they are fonts which are no commonly available with Win 98, etc. then you might get away with it (but it's still illegal!). Cheers Peter -- Peter Reid Reid-IT Limited, Loughborough, Leics., UK Tel: +44 (0)1509 268843 Fax: +44 (0)870 052 7576 E-mail: [EMAIL PROTECTED] Web: http://www.reidit.co.uk Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Installing Fonts
Hi all Does anyone have experience with the legal issues of using fonts in programs. Do they have copyright? What about distributing fonts with programs? What hapens if your'e using a font thats not installed on the computer running the machine? PS Still interested if anyone knows how to find the My Documents folder ie a a function that will return the url of the my documents folder for the current user of whatever version of windows their using. Best regards Monte _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Installing Fonts
Does anyone have experience with the legal issues of using fonts in programs. Do they have copyright? What about distributing fonts with programs? What hapens if you're using a font thats not installed on the computer running the machine? Fonts are copyrighted. However, strictly speaking, it is the name of the font rather than the actual font itself that is copyrighted. So, technically, you could duplicate a font and distribute it under a different name. This is being looked at by various copyright authorities across the world, so don't trust this as a reliable tactic! Ethically of course, this "copy rename" strategy is a no-no! Most fonts are licensed based on up to 5 users being connected to a common printer (historically, fonts were licensed for printers rather than the computers). So if you had a workgroup of 15 people sharing a common printer, then you'd need 3 licence packs. A "font" is actually a "typeface" and if you buy a "font", you'll end up having to buy it either as a "family" or a series of different "weights" such as Roman, Italic, Bold, Bold-Italic, Light, Normal, Ultra, etc. It's not uncommon ending up paying $150+ for a full "font" and this could be used by up to 5 people sharing a common printer. You are not licensed to distribute fonts! If you use a font that is not on a users' machine, then a substitute will be used and this will almost certainly disrupt your screen layouts. This is why I tend to stick to the boring but always available Arial and Times New Roman. There are other "standard" fonts, but these depend on the version of the OS your end user is using (the standard fonts differ between versions of MacOS and versions of Windows). Cheers Peter -- Peter Reid Reid-IT Limited, Loughborough, Leics., UK Tel: +44 (0)1509 268843 Fax: +44 (0)870 052 7576 E-mail: [EMAIL PROTECTED] Web: http://www.reidit.co.uk Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
Re: Installing Fonts
Thanks Peter I think I better test my current project with other fonts and perhaps develop an algorithmn for what to do in the case a font isn't available. Does anyone know what fonts are replaced with I assume Arial but don't know. Best regards Monte From: Peter Reid [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Installing Fonts Date: Sat, 18 Nov 2000 14:53:06 + Does anyone have experience with the legal issues of using fonts in programs. Do they have copyright? What about distributing fonts with programs? What hapens if you're using a font thats not installed on the computer running the machine? Fonts are copyrighted. However, strictly speaking, it is the name of the font rather than the actual font itself that is copyrighted. So, technically, you could duplicate a font and distribute it under a different name. This is being looked at by various copyright authorities across the world, so don't trust this as a reliable tactic! Ethically of course, this "copy rename" strategy is a no-no! Most fonts are licensed based on up to 5 users being connected to a common printer (historically, fonts were licensed for printers rather than the computers). So if you had a workgroup of 15 people sharing a common printer, then you'd need 3 licence packs. A "font" is actually a "typeface" and if you buy a "font", you'll end up having to buy it either as a "family" or a series of different "weights" such as Roman, Italic, Bold, Bold-Italic, Light, Normal, Ultra, etc. It's not uncommon ending up paying $150+ for a full "font" and this could be used by up to 5 people sharing a common printer. You are not licensed to distribute fonts! If you use a font that is not on a users' machine, then a substitute will be used and this will almost certainly disrupt your screen layouts. This is why I tend to stick to the boring but always available Arial and Times New Roman. There are other "standard" fonts, but these depend on the version of the OS your end user is using (the standard fonts differ between versions of MacOS and versions of Windows). Cheers Peter -- Peter Reid Reid-IT Limited, Loughborough, Leics., UK Tel: +44 (0)1509 268843 Fax: +44 (0)870 052 7576 E-mail: [EMAIL PROTECTED] Web: http://www.reidit.co.uk Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. Archives: http://www.mail-archive.com/metacard@lists.runrev.com/ Info: http://www.xworlds.com/metacard/mailinglist.htm Please send bug reports to [EMAIL PROTECTED], not this list.
