Re: alwaysBuffer not set...

[Jeanne A. E. DeVoto]

At 2:33 PM -0700 7/21/2004, Richard Gaskin wrote:
Run this test in the message box:
1. put the width of the templateGraphic
   -- return 128
2. set the width of the templateGraphic to 500
3. put the width of the templateGraphic
   -- return 500
Because any property changes are persistent throughout the session, 
the reset command is provided to reset a template object to its 
default engine values:

Huh. You're completely right.
--
jeanne a. e. devoto ~ [EMAIL PROTECTED]
http://www.jaedworks.com
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Kevin Miller]

On 20/7/04 10:55 pm, "Wouter" <[EMAIL PROTECTED]> wrote:

> Then in other words, RR itself is going down this slippery slope
> (looking at the script in the revmenubar and other rev stacks :-)
> Or the slope is not that slippery.

I think this is a valid concern.  Its important that we make the IDE as
close to the engine defaults as possible, something the next couple of Rev
releases will address.  AlwaysBuffer should be the default in the engine,
saving both IDEs from making any changes that have the potential to cause
confusion in a standalone environment.

Kevin Miller ~ [EMAIL PROTECTED] ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools

___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Scott Rossi]

Recently, "Richard Gaskin"  wrote:

>>> < The properties of the templateGraphic are reset to their defaults
>>> when all running handlers finish executing. >
>>> 
>>> which is obviously not the case (and I should have checked this).
>> 
>> 
>> No, the docs are correct on this point.
> 
> Run this test in the message box:
> 
> 1. put the width of the templateGraphic
>   -- return 128
> 
> 2. set the width of the templateGraphic to 500
> 
> 3. put the width of the templateGraphic
>   -- return 500
> 
> Because any property changes are persistent throughout the session, the
> reset command is provided to reset a template object to its default
> engine values:
> 
> 4.  reset the templateGraphic
> 
> 5.  put the width of the templateGraphic
>-- return 128 again

FWIW, the MC docs under "reset" state:

"Resetting a template object returns it to its startup settings.  It is a
good practice to reset any template object changed in your scripts after
you've created an object from the template."

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: alwaysBuffer not set...

[Richard Gaskin]

Jeanne A. E. DeVoto wrote:
At 8:37 PM +0200 7/21/2004, Wouter wrote:
But then there is an inconsistency in the transcript library where is 
stated:

< The properties of the templateGraphic are reset to their defaults 
when all running handlers finish executing. >

which is obviously not the case (and I should have checked this).

No, the docs are correct on this point.
Run this test in the message box:
1. put the width of the templateGraphic
   -- return 128
2. set the width of the templateGraphic to 500
3. put the width of the templateGraphic
   -- return 500
Because any property changes are persistent throughout the session, the 
reset command is provided to reset a template object to its default 
engine values:

4.  reset the templateGraphic
5.  put the width of the templateGraphic
-- return 128 again
--
 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: alwaysBuffer not set...

[Jeanne A. E. DeVoto]

At 8:37 PM +0200 7/21/2004, Wouter wrote:
But then there is an inconsistency in the transcript library where is stated:
< The properties of the templateGraphic are reset to their defaults 
when all running handlers finish executing. >

which is obviously not the case (and I should have checked this).
No, the docs are correct on this point.
--
jeanne a. e. devoto ~ [EMAIL PROTECTED]
http://www.jaedworks.com
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Richard Gaskin]

Wouter wrote:
 Remember that long before your scripts become active the Rev IDE does 
its initialization. While I haven't read the code for Rev's boot 
sequence the evidence suggests that their IDE alters some properties 
of the template graphic so that by the time your script comes into 
play the template graphic is different.

You can verify that it isn't the engine by using the same Rev engine 
with the MC IDE. Merely copying that executable file won't alter it, 
so any differences are accounted for in the IDEs.
Ok I see, thank you.
But then there is an inconsistency in the transcript library where is 
stated:

< The properties of the templateGraphic are reset to their defaults when 
all running handlers finish executing. >

which is obviously not the case (and I should have checked this).
I just Bugzilla'd that:

--
 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: alwaysBuffer not set...

[Wouter]

Re: alwaysBuffer not set...
•From: Richard Gaskin
• Subject: Re: alwaysBuffer not set...
• Date: Wed, 21 Jul 2004 10:16:19 -0700
-- snip
 Remember that long before your scripts become active the Rev IDE does 
its initialization. While I haven't read the code for Rev's boot 
sequence the evidence suggests that their IDE alters some properties 
of the template graphic so that by the time your script comes into 
play the template graphic is different.

You can verify that it isn't the engine by using the same Rev engine 
with the MC IDE. Merely copying that executable file won't alter it, 
so any differences are accounted for in the IDEs.
Ok I see, thank you.
But then there is an inconsistency in the transcript library where is 
stated:

< The properties of the templateGraphic are reset to their defaults 
when all running handlers finish executing. >

which is obviously not the case (and I should have checked this).
--
 Richard Gaskin
 Fourth World Media Corporation
Greetings,
Wouter
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Jeanne A. E. DeVoto]

At 6:39 PM +0200 7/21/2004, Wouter wrote:
I agree that they are handled or used by the engine.
But the question still remains: where are those default template objects
physically (it's data) stored?
In the binary of the engine or in the binary of one or more stacks?
Template objects are never stored per se; they live only in memory.  The
property settings which define them are, in my understanding, hard-wired
into the code of the engine, and not in any stack file.
This is exactly the puzzling part.
If they are hardwired in the code of  the engine then why is there a 
difference between the MC IDE and the RR IDE in at least 1 of those 
settings
Because the IDE (or any stack) can change the properties of the 
defaultGraphic, etc. What Rev does is to change the default objects 
in new object handlers. (For example, in a newGraphic handler, it 
sets the opaque of the defaultGraphic.) This makes the default 
setting different from the engine setting - but it's all done with a 
newGraphic handler, so it doesn't require engine differences.
--
jeanne a. e. devoto ~ [EMAIL PROTECTED]
http://www.jaedworks.com
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Richard Gaskin]

Wouter wrote:
Template objects are never stored per se; they live only in memory.  The
property settings which define them are, in my understanding, hard-wired
into the code of the engine, and not in any stack file.
This is exactly the puzzling part.
If they are hardwired in the code of  the engine then why is there a 
difference between the MC IDE and the RR IDE in at least 1 of those 
settings
Compare the opaque of the templateGraphic between the 2 IDE's (the 
engine from RR 2.2.1)
That's why I said if they are hardwired then the engine is making a 
difference between these 2 IDE's.
I had already answered that, in the portion you quoted below:
However, any script can change the default engine properties of template
objects, which appears to be what Rev's initialization script does.
Remember that long before your scripts become active the Rev IDE does 
its initialization.  While I haven't read the code for Rev's boot 
sequence the evidence suggests that their IDE alters some properties of 
the template graphic so that by the time your script comes into play the 
template graphic is different.

You can verify that it isn't the engine by using the same Rev engine 
with the MC IDE.  Merely copying that executable file won't alter it, so 
any differences are accounted for in the IDEs.

--
 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: alwaysBuffer not set...

[Wouter]

On 21 Jul 2004, at 18:00, [EMAIL PROTECTED] wrote:
Message: 3
Date: Wed, 21 Jul 2004 08:37:17 -0700
From: Richard Gaskin <[EMAIL PROTECTED]>
Subject: Re: alwaysBuffer not set...
To: Discussions on Metacard <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-- big snip

I agree that they are handled or used by the engine.
But the question still remains: where are those default template 
objects
physically (it's data) stored?
In the binary of the engine or in the binary of one or more stacks?
Template objects are never stored per se; they live only in memory.  
The
property settings which define them are, in my understanding, 
hard-wired
into the code of the engine, and not in any stack file.
This is exactly the puzzling part.
If they are hardwired in the code of  the engine then why is there a 
difference between the MC IDE and the RR IDE in at least 1 of those 
settings
Compare the opaque of the templateGraphic between the 2 IDE's (the 
engine from RR 2.2.1)
That's why I said if they are hardwired then the engine is making a 
difference between these 2 IDE's.

When checking this setting in the last version of RR  (2.5.1) they 
changed it so both are false.
(But when producing a new polygon they turn it on as not to confuse 
users)
Btw 2.5.1 looks awsome, a lot of big changes and not only in what meets 
the eye.


However, any script can change the default engine properties of 
template
objects, which appears to be what Rev's initialization script does.

--
  Richard Gaskin
  Fourth World Media Corporation
Greetings,
Wouter
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Richard Gaskin]

Wouter wrote:
The engine has no "face" of its own; that is, it has no windows or other
visible UI components of its own.  It has only the Transcript
interpreter and a handful of data resources the interpeter needs (such
as the list of color names, month names, etc.).
Any visible element, such as a window, menu, etc., is part of the IDE.
But it is the engine that provides them according to it's own drawing 
routines or calls to the system it thrives on.
Yes indeed.  Think of it as the DNA for making objects, rather than the 
objects themselves.

One of the reasons you may need to use the Resource Mover to copy the
Ask and Answer dialogs and other components into your stack before
building is that they live in mctools.mc.  Once your stack is a
standalone it no longer has access to stacks in mctools.mc.
Being used to resourceforks the older Mac programmers had to redefine 
the word *resource mover* :^)
Ah, but the word "resource" in computing had a much more generic meaning 
long before Mac OS.  MetaCard's vernacular uses this more common 
meaning, not specifically limited to the Mac OS file format's resource 
fork, more in keeping with the vernacular common to the majority of 
supported platforms.

So when it comes to the template objects, those are handled by the
engine.  It is possible, however, for any script to modify the
properties of a template object so that any future objects created will
have that property, which appears to be what the Rev IDE is doing with
graphics.
I agree that they are handled or used by the engine.
But the question still remains: where are those default template objects 
physically (it's data) stored?
In the binary of the engine or in the binary of one or more stacks?
Template objects are never stored per se; they live only in memory.  The 
property settings which define them are, in my understanding, hard-wired 
into the code of the engine, and not in any stack file.

However, any script can change the default engine properties of template 
objects, which appears to be what Rev's initialization script does.

--
 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: alwaysBuffer not set...

[Wouter]

Richard Gaskin ambassador at fourthworld.com
Tue Jul 20 19:55:43 EDT 2004
* Previous message: alwaysBuffer not set...
* Next message: alwaysBuffer not set...
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Alain Farmer wrote:
> Wouter wrote:
>> I look at MC and RR as stacks interacting with
>> an engine ... but the impression is growing that
>> what is called the engine, is something composed
>> of stacks and the engine. Where are the borders
>> between the IDE, stacks and the engine?
>
> Very *VERY* good point, Wouter.
>
> Where is it? .. indeed!
The engine is the executable file that drives everything, which gets
bound to your stackfile when building a standalone.
That is also my understanding of *the engine*
The engine has no "face" of its own; that is, it has no windows or 
other
visible UI components of its own.  It has only the Transcript
interpreter and a handful of data resources the interpeter needs (such
as the list of color names, month names, etc.).

Any visible element, such as a window, menu, etc., is part of the IDE.
But it is the engine that provides them according to it's own drawing 
routines or calls to the system it thrives on.

One of the reasons you may need to use the Resource Mover to copy the
Ask and Answer dialogs and other components into your stack before
building is that they live in mctools.mc.  Once your stack is a
standalone it no longer has access to stacks in mctools.mc.
Being used to resourceforks the older Mac programmers had to redefine 
the word *resource mover* :^)

-- snip
So when it comes to the template objects, those are handled by the
engine.  It is possible, however, for any script to modify the
properties of a template object so that any future objects created will
have that property, which appears to be what the Rev IDE is doing with
graphics.
I agree that they are handled or used by the engine.
But the question still remains: where are those default template 
objects physically (it's data) stored?
In the binary of the engine or in the binary of one or more stacks?
(I really should learn how to express myself, grmbl)

If you want to see the default engine properties reflected in newly
created objects you can use the reset command, like this:
   reset the templateButton
   reset the templateStack
--
  Richard Gaskin
  Fourth World Media Corporation
Greetings,
Wouter
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Chipp Walters]

Hi Richard et al...
I agree with Richard, in fact, his often well-thought expression of 
MetaCard's strict compliance to the vanilla is the primary reason why 
I'm 'attempting' to switch to MC (I'm sure a first, going back to MC 
from one who has started with RR:-)

I believe the alwaysBuffer should be set true for the IDE to display 
properly (else it's a bug in the IDE?). I also agree, we should not 
'pre-modify' any default behaviors of the engine. That is, IMHO, why the 
default for stacks should be 'true' for alwaysbuffer AND set by the 
engine, not the IDE.

Rev has indeed already moved quite a ways down the slippery slope. I've 
spend a few hours lately converting my altPlugins for use in MC, and 
have already discovered a couple of such anomolies-- things I never knew 
Rev did until trying them in the MC IDE.

Of course, it's super easy to add a MC plugin (I have one) which can 
create a new stack and set the alwaysBuffer to true.

best to you all,
Chipp
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Richard Gaskin]

Alain Farmer wrote:
Wouter wrote:
I look at MC and RR as stacks interacting with
an engine ... but the impression is growing that 
what is called the engine, is something composed
of stacks and the engine. Where are the borders
between the IDE, stacks and the engine?
Very *VERY* good point, Wouter.
Where is it? .. indeed!
The engine is the executable file that drives everything, which gets 
bound to your stackfile when building a standalone.

The engine has no "face" of its own; that is, it has no windows or other 
visible UI components of its own.  It has only the Transcript 
interpreter and a handful of data resources the interpeter needs (such 
as the list of color names, month names, etc.).

Any visible element, such as a window, menu, etc., is part of the IDE.
One of the reasons you may need to use the Resource Mover to copy the 
Ask and Answer dialogs and other components into your stack before 
building is that they live in mctools.mc.  Once your stack is a 
standalone it no longer has access to stacks in mctools.mc.

In most cases, the dividing line between commands and function in the 
engine and anything that might be available in a library or backscript 
is made clear by a convention of prefacing scripted commands with some 
identifier that makes it clear where they come from.

For example, most libURL calls begin with "libUrl", such as 
"libUrlSetStatusField", and most calls to Rev libraries begin with 
"rev", such as "revAppVersion".  I tend to preface stuff in my libraries 
with "fw", and Chipp prefaces his with "alt", etc.

By following these conventions those who publish libraries for others to 
use make it easy to determine where the handler resides.

So when it comes to the template objects, those are handled by the 
engine.  It is possible, however, for any script to modify the 
properties of a template object so that any future objects created will 
have that property, which appears to be what the Rev IDE is doing with 
graphics.

If you want to see the default engine properties reflected in newly 
created objects you can use the reset command, like this:

  reset the templateButton
  reset the templateStack
--
 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: alwaysBuffer not set...

[Alain Farmer]

--- Wouter

> I look at MC and RR as stacks interacting with
> an engine ... but the impression is growing that 
> what is called the engine, is something composed
> of stacks and the engine. Where are the borders
> between the IDE, stacks and the engine?

Very *VERY* good point, Wouter.

Where is it? .. indeed!

Alain



__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Wouter]

alwaysBuffer not set...
Richard Gaskin ambassador at fourthworld.com
Tue Jul 20 16:13:47 EDT 2004
* Previous message: alwaysBuffer not set...
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wouter wrote:
--big snip
> If this is at engine level then the engine itself is making a 
difference
> between the MC IDE and the RR IDE. And this could cause slippy-ness.
> Also implicating separated  or singlesided engine improvement. ???

No, you can verify this by using the same engine in both environments.
Any differences between the two are specific to the IDEs.
That is exactly what I did.
And because of this difference I supposed the templates (where the 
default alwaysBuffer of the templateStack is lodged) were not hidden in 
the engine itself. And this made me wonder why you called this 

So I seem not to be grasping the point.
I look at  MC and RR as stacks interacting with an engine (and from a 
low level point of view :-).
But because of things said on the lists  the impression is growing that 
what is called the engine, is something composed of stacks and the 
engine. Where are the borders between the IDE, stacks and the engine?

-- snip
I'm not sure any Rev behaviors are undocumented.  You'd have the check
the Rev docs.  My role here is just to support the MC IDE maintenance
and development, honoring the community's preference that its value as 
a
closer-to-the-engine alternative be maintained.
And you are doing a great job.
(and I still prefer MC over RR)
--
  Richard Gaskin
  Fourth World Media Corporation

Greetings,
Wouter
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Richard Gaskin]

Wouter wrote:
Re-reading Chipp's post more carefully, he's referring only to IDE
stacks, and yes, the IDE stacks should have their alwaysBuffer set to
true.
Can anyone think of a reason not to?  Unless someone tells me not to I'm
inclined to do it for the next release.
As for doing that for all new stacks, I would happily add it as a
preference (and will do so after this next build is released), but I'm
disinclined to make non-optional changes that contradict how the engine
works.
Admittedly I'm a bit of a Transcript purist, but I feel one of the most
useful aspects of the MC IDE is that it keeps you close to engine
behaviors, minimizing differences between development and runtime, and
keeping any additional libraries fully optional and under the
developer's control.
If we were to start down the slippery slope of altering behaviors from
how they work in the engine and requiring specific additional scripts to
get the behaviors we expect, we not only complicate our work but also
miss the opportunity to improve the engine itself.
Then in other words, RR itself is going down this slippery slope 
(looking at the script in the revmenubar and other rev stacks :-)
Or the slope is not that slippery.
Opinons have been posted both ways.
The Rev IDE alters a number of engine behaviors, mostly because when 
they started they didn't have access to the engine.

If one prefers the Rev IDE it's easily available and ever-improving.
If we feel a default behavior is incorrect or suboptimal, it seems a
good opportunity to address it at the source in the engine itself.
 I am not sure if this is really located at engine level.
If you compare the opaque setting of the default templateGraphic in MC 
and in RR they are different though they use the same engine  (or is the 
templateGraphic stashed far away from the templateStack?).
Yes, the Rev IDE alters many default engine behaviors.
If this is at engine level then the engine itself is making a difference 
between the MC IDE and the RR IDE. And this could cause slippy-ness.
Also implicating separated  or singlesided engine improvement. ???
No, you can verify this by using the same engine in both environments. 
Any differences between the two are specific to the IDEs.

I can think of no reason to have the alwaysBuffer set to false (though
there might be so we should retain the property as an option), and agree
that having it on by default would be far better than its current
default behavior.  Shall we post it to Bugzilla and see if it gets any
votes?
I agree with this alwaysBuffer set to true and wouldn't mind templatePrefs.
Only wondering why slowly all those little differences are creeping in.
Undocumented little changes, to be discovered by (sometimes enervated 
:-) users.
I'm not sure any Rev behaviors are undocumented.  You'd have the check 
the Rev docs.  My role here is just to support the MC IDE maintenance 
and development, honoring the community's preference that its value as a 
closer-to-the-engine alternative be maintained.

--
 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: alwaysBuffer not set...

[Wouter]

alwaysBuffer not set...
Richard Gaskin ambassador at fourthworld.com
Tue Jul 20 14:46:17 EDT 2004
-- snip

Re-reading Chipp's post more carefully, he's referring only to IDE
stacks, and yes, the IDE stacks should have their alwaysBuffer set to
true.
Can anyone think of a reason not to?  Unless someone tells me not to 
I'm
inclined to do it for the next release.

As for doing that for all new stacks, I would happily add it as a
preference (and will do so after this next build is released), but I'm
disinclined to make non-optional changes that contradict how the engine
works.
Admittedly I'm a bit of a Transcript purist, but I feel one of the most
useful aspects of the MC IDE is that it keeps you close to engine
behaviors, minimizing differences between development and runtime, and
keeping any additional libraries fully optional and under the
developer's control.
If we were to start down the slippery slope of altering behaviors from
how they work in the engine and requiring specific additional scripts 
to
get the behaviors we expect, we not only complicate our work but also
miss the opportunity to improve the engine itself.
Then in other words, RR itself is going down this slippery slope 
(looking at the script in the revmenubar and other rev stacks :-)
Or the slope is not that slippery.

If we feel a default behavior is incorrect or suboptimal, it seems a
good opportunity to address it at the source in the engine itself.
 I am not sure if this is really located at engine level.
If you compare the opaque setting of the default templateGraphic in MC 
and in RR they are different though they use the same engine  (or is 
the templateGraphic stashed far away from the templateStack?).
If this is at engine level then the engine itself is making a 
difference between the MC IDE and the RR IDE. And this could cause 
slippy-ness.
Also implicating separated  or singlesided engine improvement. ???

I can think of no reason to have the alwaysBuffer set to false (though
there might be so we should retain the property as an option), and 
agree
that having it on by default would be far better than its current
default behavior.  Shall we post it to Bugzilla and see if it gets any
votes?
I agree with this alwaysBuffer set to true and wouldn't mind 
templatePrefs.
Only wondering why slowly all those little differences are creeping in.
Undocumented little changes, to be discovered by (sometimes enervated 
:-) users.


--
  Richard Gaskin
  Fourth World Media Corporation

Regards,
Wouter
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Richard Gaskin]

Wouter wrote:
> I noticed in the latest DL of MetaCard, the alwaysBuffer of most IDE
> stacks is not set. While this was not necessary in previous versions of
> the engine, it is now used to disable the 'flashing' effect around
> windowsXP look and feel.
>
> I recommend setting the alwaysBuffer of all IDE stacks to true.
I agree that it should be the default setting, and can add a preference
for that. But with modern systems being how they are I would go further
to request that it be changed in the engine.
Why going to that extend? It is only 1 line of code? Sounds like overkill.
The default alwaysbuffer of the templatestack is false, both in MC and RR.
But in RR they set this property of the templatestack in the "New 
Mainstack" case of the menupick handler
Why not add this 1 line (or more if more properties ought to be set) to 
the "New Stack" menupick handler of the "file" button?
Re-reading Chipp's post more carefully, he's referring only to IDE 
stacks, and yes, the IDE stacks should have their alwaysBuffer set to 
true.

Can anyone think of a reason not to?  Unless someone tells me not to I'm 
inclined to do it for the next release.

As for doing that for all new stacks, I would happily add it as a 
preference (and will do so after this next build is released), but I'm 
disinclined to make non-optional changes that contradict how the engine 
works.

Admittedly I'm a bit of a Transcript purist, but I feel one of the most 
useful aspects of the MC IDE is that it keeps you close to engine 
behaviors, minimizing differences between development and runtime, and 
keeping any additional libraries fully optional and under the 
developer's control.

If we were to start down the slippery slope of altering behaviors from 
how they work in the engine and requiring specific additional scripts to 
get the behaviors we expect, we not only complicate our work but also 
miss the opportunity to improve the engine itself.

If we feel a default behavior is incorrect or suboptimal, it seems a 
good opportunity to address it at the source in the engine itself.

I can think of no reason to have the alwaysBuffer set to false (though 
there might be so we should retain the property as an option), and agree 
that having it on by default would be far better than its current 
default behavior.  Shall we post it to Bugzilla and see if it gets any 
votes?

--
 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: alwaysBuffer not set...

[Wouter]

alwaysBuffer not set...
Richard Gaskin ambassador at fourthworld.com
Tue Jul 20 12:27:24 EDT 2004
* Previous message: alwaysBuffer not set...
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Chipp Walters wrote:
> I noticed in the latest DL of MetaCard, the alwaysBuffer of most IDE
> stacks is not set. While this was not necessary in previous versions 
of
> the engine, it is now used to disable the 'flashing' effect around
> windowsXP look and feel.
>
> I recommend setting the alwaysBuffer of all IDE stacks to true.

I agree that it should be the default setting, and can add a preference
for that. But with modern systems being how they are I would go further
to request that it be changed in the engine.
Why going to that extend? It is only 1 line of code? Sounds like 
overkill.
The default alwaysbuffer of the templatestack is false, both in MC and 
RR.
But in RR they set this property of the templatestack in the "New 
Mainstack" case of the menupick handler
Why not add this 1 line (or more if more properties ought to be set) to 
the "New Stack" menupick handler of the "file" button?


Have you submitted a Bugzilla request for that, or shall I?
--
  Richard Gaskin
  Fourth World Media Corporation

Greetings,
WA
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard

Re: alwaysBuffer not set...

[Richard Gaskin]

Chipp Walters wrote:
I noticed in the latest DL of MetaCard, the alwaysBuffer of most IDE 
stacks is not set. While this was not necessary in previous versions of 
the engine, it is now used to disable the 'flashing' effect around 
windowsXP look and feel.

I recommend setting the alwaysBuffer of all IDE stacks to true.
I agree that it should be the default setting, and can add a preference 
for that. But with modern systems being how they are I would go further 
to request that it be changed in the engine.

Have you submitted a Bugzilla request for that, or shall I?
--
 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