> I think Monte's talking about engine v2.6, which hasn't been released
> yet.  In all earlier versions you just enter the info you want into the
> Standalone Builder's "Windows Info" window, and after the standalone is
> built that info will appear in the Windows Properties window.

Nope... talking about older engines too with this point. Windows executables
apparently have two product and file version numbers. One text and one
binary. The binary ones weren't being set by either the Rev or MC standalone
builder and unfortunately it's the binary file version that Windows displays
prominently. To check this out you simply need to right-click on a
standalone and pull up the version info.

So what the Rev standalone builder now does is offer an interface for
entering the 4 numbers for each of these and then uses the same 4 numbers to
set both the text and binary fields in the exe.

PS Don't ask me why this duplication exists. The guy that wrote the EXE file
format might help you there ;-)

Cheers

Monte

johnrule@... wrote:

> --- In MC_IDE@yahoogroups.com, "Monte Goulding" <monte@s...> wrote:
>
>>There's probably one other change that you might be interested in
>> making and that's the work I did on the binary product version
  >> and file version numbers. Without this you will continue to get
  >> the engine numbers in the windows file properties dialog.
>
  > Yes, I for one am interested in that. It has been very embarassing
  > to have customers ask me "Why is the version number different in the
  > properties?"...from my 'splash screen' version of course  ;-)

I think Monte's talking about engine v2.6, which hasn't been released
yet.  In all earlier versions you just enter the info you want into the
Standalone Builder's "Windows Info" window, and after the standalone is
built that info will appear in the Windows Properties window.

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

Yes, I for one am interested in that. It has been very embarassing
to have customers ask me "Why is the version number different in the
properties?"...from my 'splash screen' version of course  ;-)

JR

--- In MC_IDE@yahoogroups.com, "Monte Goulding" <monte@s...> wrote:
>
> > Thank you, Monte.  Your contribution will be noted in the About
box.
>
> Anytime... if you want me to actually do this then I can but I
have no idea
> of the process for checking ot an IDE component here...
>
> There's probably one other change that you might be interested in
making and
> that's the work I did on the binary product version and file
version
> numbers. Without this you will continue to get the engine numbers
in the
> windows file properties dialog.
>
> Cheers
>
> Monte

> > What are you doing about maintaining IDE support for older engines? I'd
> > suggest making the Standalone Builder a separate stackFile so
> you can offer
> > the current one and the one I modify for download.
>
> Historically, each IDE version was tied to a specific engine release.
> Swapping IDEs is not difficult; most folks don't even bother, just
> keeping a separate copy for each build.
>
> But there is merit in allowing the new open source IDE to be more
> universal.  I'll discuss this on the MC List. It would be a simple
> matter to just rename the old one and have it open instead when the
> engine version number is pre-2.6.

Oh... actually I think I could handle it as long as we can assume the engine
you are pointing the standalone builder at is the same version as the
running one...
>
> We've discussed the relative merits of breaking the IDE up into separate
> stack files, but there were more votes for keeping it simple and
> self-contained, and moving stacks in and out during development is easy
> to do so it hardly matters either way.
>

Well... add my vote to a stack file based setup. You can keep it neat with
folders just as well as you can with stackfiles. The advantages are obvious
if you are working with multiple contributors and would make it far simpler
for people to take ownership of components.

Cheers

Monte

Monte Goulding wrote:

> What are you doing about maintaining IDE support for older engines? I'd
> suggest making the Standalone Builder a separate stackFile so you can offer
> the current one and the one I modify for download.

Historically, each IDE version was tied to a specific engine release.
Swapping IDEs is not difficult; most folks don't even bother, just
keeping a separate copy for each build.

But there is merit in allowing the new open source IDE to be more
universal.  I'll discuss this on the MC List. It would be a simple
matter to just rename the old one and have it open instead when the
engine version number is pre-2.6.

We've discussed the relative merits of breaking the IDE up into separate
stack files, but there were more votes for keeping it simple and
self-contained, and moving stacks in and out during development is easy
to do so it hardly matters either way.

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

> >>Thank you, Monte.  Your contribution will be noted in the About box.
> >
> >
> > Anytime... if you want me to actually do this then I can but I
> have no idea
> > of the process for checking ot an IDE component here...
> >
> > There's probably one other change that you might be interested
> in making and
> > that's the work I did on the binary product version and file version
> > numbers. Without this you will continue to get the engine numbers in the
> > windows file properties dialog.
>
> If you would like to make the change it would be very generous of you
> and much appreciated.  You can work with the latest release build in the
>   Yahoo Group file repository.
>
> The only other changes in progress at the moment are for a plugins menu
> (you'll see some more recent review builds we've been playing with), but
> those changes can easily be moved into the master once their finalized,
> so if you keep your changes limited to the Standalone Builder substack
> we'll be in great shape.
>

What are you doing about maintaining IDE support for older engines? I'd
suggest making the Standalone Builder a separate stackFile so you can offer
the current one and the one I modify for download.

Cheers

Monte

Monte Goulding wrote:

>>Thank you, Monte.  Your contribution will be noted in the About box.
>
>
> Anytime... if you want me to actually do this then I can but I have no idea
> of the process for checking ot an IDE component here...
>
> There's probably one other change that you might be interested in making and
> that's the work I did on the binary product version and file version
> numbers. Without this you will continue to get the engine numbers in the
> windows file properties dialog.

If you would like to make the change it would be very generous of you
and much appreciated.  You can work with the latest release build in the
   Yahoo Group file repository.

The only other changes in progress at the moment are for a plugins menu
(you'll see some more recent review builds we've been playing with), but
those changes can easily be moved into the master once their finalized,
so if you keep your changes limited to the Standalone Builder substack
we'll be in great shape.

--
   Richard Gaskin
   Fourth World Media Corporation
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com

> Thank you, Monte.  Your contribution will be noted in the About box.

Anytime... if you want me to actually do this then I can but I have no idea
of the process for checking ot an IDE component here...

There's probably one other change that you might be interested in making and
that's the work I did on the binary product version and file version
numbers. Without this you will continue to get the engine numbers in the
windows file properties dialog.

Cheers

Monte

Monte Goulding wrote:
>>Has anyone successfully used the new RunRev engine that has the
>>larger icon compatibility? I imagine that all we need to do change
>>the size limitation now in the MC IDE...correct?
>
>
> Yep ;-) I wrote the code that replaces them in the engine.
>
> Actually it's rather complex because it seems there's no standard in what
> order the image formats are saved in and the engine needs them in a specific
> order. So this involved parsing the ico file format, extracting the
> individual bitmaps then reordering them.
>
> I've included the function below (watch out for wrapping). It throws
> comprehensive error messages too and I use these both when building the
> standalone and choosing the file.
>
> You will also need to find out where in the standalone builder the icon data
> is stored and put char 151 to -1 of the rev sample icons into each.
>
> Cheers
>
> Monte

Thank you, Monte.  Your contribution will be noted in the About box.

--
   Richard Gaskin
   Fourth World Media Corporation
   Developer of WebMerge: Publish any database on any Web site
   ___________________________________________________________
   Ambassador@...       http://www.FourthWorld.com


> -- This script parses an ICO file and reorders it's bitmaps to the required
> order for the
> -- Revolution exe. If the icons are changed in the Revolution exe then this
> script may
> -- need to be altered.
>
> constant kIconImageBytes = "296,1384,744,2216,1640,3752,1128,4264,9640"
>
> function revGetIcoFile pFile
>   local
> tReserved,tType,tCount,tWidth,tHeight,tColorCount,tPlanes,tBitCount,tBytesIn
> Res,\
>
> tImageOffset,tIcon,tWidthA,tHeightA,tBytesInResA,tDataA,tICOFile,tReturn,tMi
> ssingFormats,tNum,tRemove
>   put url ("binfile:"&pFile) into tICOFile
>   if the result is not empty then
>     throw "Standalone: Can't open Windows icon file."
>   end if
>  put char 1 to 6 of tICOFile into tHead
>   if not littleEndian() then
>     put char 2 of tHead&char 1 of tHead&char 4 of tHead&char 3 of tHead&char
> 6 of tHead&char 5 of tHead into tHead
>   end if
>   get binaryDecode("S3",tHead,tReserved,tType,tCount)
>   delete char 1 to 6 of tICOFile
>   repeat with tIcon=1 to tCount
>     put char 1 to 16 of tICOFile into tEntry
>     if not littleEndian() then
>       put char 1 to 4 of tEntry&char 6 of tEntry&char 5 of tEntry&char 8 of
> tEntry&\
>           char 7 of tEntry&char 12 of tEntry&char 11 of tEntry&char 10 of
> tEntry&char 9 of tEntry&\
>           char 16 of tEntry&char 15 of tEntry&char 14 of tEntry&char 13 of
> tEntry into tEntry
>     end if
>     get
> binaryDecode("C4S2I2",tEntry,tWidth,tHeight,tColorCount,tReserved,tPlanes,tB
> itCount,tBytesInRes,tImageOffset)
>     if tIcon=1 then put tImageOffset-1 into tRemove
>     put tImageOffset-tRemove into tImageOffsetA[tIcon]
>     put tWidth into tWidthA[tIcon]
>     put tHeight into tHeightA[tIcon]
>     put tBytesInRes into tBytesInResA[tIcon]
>     delete char 1 to 16 of tICOFile
>   end repeat
>   put the length of tICOFile+1 into tImageOffsetA[tCount+1]
>   repeat with tIcon=1 to tCount
>     put char tImageOffsetA[tIcon] to tImageOffsetA[tIcon+1]-1 of tICOFile
> into tDataA[tBytesInResA[tIcon]]
>   end repeat
>   repeat for each item tBytes in kIconImageBytes
>     if tDataA[tBytes] <> "" then
>       put tDataA[tBytes] after tReturn
>     else
>       switch tBytes
>       case 296
>         put "16 color 16 x 16 pixels"&cr after tMissingFormats
>         break
>       case 1384
>         put "256 color 16 x 16 pixels"&cr after tMissingFormats
>         break
>       case 744
>         put "16 color 32 x 32 pixels"&cr after tMissingFormats
>         break
>       case 2216
>         put "256 color 32 x 32 pixels"&cr after tMissingFormats
>         break
>       case 1640
>         put "16 color 48 x 48 pixels"&cr after tMissingFormats
>         break
>       case 3752
>         put "256 color 48 x 48 pixels"&cr after tMissingFormats
>         break
>       case 1128
>         put "Windows XP (32 bit color) 16 x 16 pixels"&cr after
> tMissingFormats
>         break
>       case 4264
>         put "Windows XP (32 bit color) 32 x 32 pixels"&cr after
> tMissingFormats
>         break
>       case 9640
>         put "Windows XP (32 bit color) 48 x 48 pixels"&cr after
> tMissingFormats
>         break
>       end switch
>     end if
>   end repeat
>   delete char -1 of tMissingFormats
>   if tMissingFormats <> "" then
>     if the number of lines of tMissingFormats = 1 then
>       put "1 required image format:" into tNum
>     else
>       put the number of lines of tMissingFormats&" required image formats:"
> into tNum
>     end if
>     throw "Standalone: The icon file "&pFile&cr&"does not include
> "&tNum&cr&cr&tMissingFormats
>   end if
>   return tReturn
> end revGetIcoFile
>
> function littleEndian
>   return charToNum(char 1 of binaryEncode("S",1)) = 1
> end littleEndian
>
>
>

>
> Has anyone successfully used the new RunRev engine that has the
> larger icon compatibility? I imagine that all we need to do change
> the size limitation now in the MC IDE...correct?

Yep ;-) I wrote the code that replaces them in the engine.

Actually it's rather complex because it seems there's no standard in what
order the image formats are saved in and the engine needs them in a specific
order. So this involved parsing the ico file format, extracting the
individual bitmaps then reordering them.

I've included the function below (watch out for wrapping). It throws
comprehensive error messages too and I use these both when building the
standalone and choosing the file.

You will also need to find out where in the standalone builder the icon data
is stored and put char 151 to -1 of the rev sample icons into each.

Cheers

Monte

-- This script parses an ICO file and reorders it's bitmaps to the required
order for the
-- Revolution exe. If the icons are changed in the Revolution exe then this
script may
-- need to be altered.

constant kIconImageBytes = "296,1384,744,2216,1640,3752,1128,4264,9640"

function revGetIcoFile pFile
   local
tReserved,tType,tCount,tWidth,tHeight,tColorCount,tPlanes,tBitCount,tBytesIn
Res,\

tImageOffset,tIcon,tWidthA,tHeightA,tBytesInResA,tDataA,tICOFile,tReturn,tMi
ssingFormats,tNum,tRemove
   put url ("binfile:"&pFile) into tICOFile
   if the result is not empty then
     throw "Standalone: Can't open Windows icon file."
   end if
  put char 1 to 6 of tICOFile into tHead
   if not littleEndian() then
     put char 2 of tHead&char 1 of tHead&char 4 of tHead&char 3 of tHead&char
6 of tHead&char 5 of tHead into tHead
   end if
   get binaryDecode("S3",tHead,tReserved,tType,tCount)
   delete char 1 to 6 of tICOFile
   repeat with tIcon=1 to tCount
     put char 1 to 16 of tICOFile into tEntry
     if not littleEndian() then
       put char 1 to 4 of tEntry&char 6 of tEntry&char 5 of tEntry&char 8 of
tEntry&\
           char 7 of tEntry&char 12 of tEntry&char 11 of tEntry&char 10 of
tEntry&char 9 of tEntry&\
           char 16 of tEntry&char 15 of tEntry&char 14 of tEntry&char 13 of
tEntry into tEntry
     end if
     get
binaryDecode("C4S2I2",tEntry,tWidth,tHeight,tColorCount,tReserved,tPlanes,tB
itCount,tBytesInRes,tImageOffset)
     if tIcon=1 then put tImageOffset-1 into tRemove
     put tImageOffset-tRemove into tImageOffsetA[tIcon]
     put tWidth into tWidthA[tIcon]
     put tHeight into tHeightA[tIcon]
     put tBytesInRes into tBytesInResA[tIcon]
     delete char 1 to 16 of tICOFile
   end repeat
   put the length of tICOFile+1 into tImageOffsetA[tCount+1]
   repeat with tIcon=1 to tCount
     put char tImageOffsetA[tIcon] to tImageOffsetA[tIcon+1]-1 of tICOFile
into tDataA[tBytesInResA[tIcon]]
   end repeat
   repeat for each item tBytes in kIconImageBytes
     if tDataA[tBytes] <> "" then
       put tDataA[tBytes] after tReturn
     else
       switch tBytes
       case 296
         put "16 color 16 x 16 pixels"&cr after tMissingFormats
         break
       case 1384
         put "256 color 16 x 16 pixels"&cr after tMissingFormats
         break
       case 744
         put "16 color 32 x 32 pixels"&cr after tMissingFormats
         break
       case 2216
         put "256 color 32 x 32 pixels"&cr after tMissingFormats
         break
       case 1640
         put "16 color 48 x 48 pixels"&cr after tMissingFormats
         break
       case 3752
         put "256 color 48 x 48 pixels"&cr after tMissingFormats
         break
       case 1128
         put "Windows XP (32 bit color) 16 x 16 pixels"&cr after
tMissingFormats
         break
       case 4264
         put "Windows XP (32 bit color) 32 x 32 pixels"&cr after
tMissingFormats
         break
       case 9640
         put "Windows XP (32 bit color) 48 x 48 pixels"&cr after
tMissingFormats
         break
       end switch
     end if
   end repeat
   delete char -1 of tMissingFormats
   if tMissingFormats <> "" then
     if the number of lines of tMissingFormats = 1 then
       put "1 required image format:" into tNum
     else
       put the number of lines of tMissingFormats&" required image formats:"
into tNum
     end if
     throw "Standalone: The icon file "&pFile&cr&"does not include
"&tNum&cr&cr&tMissingFormats
   end if
   return tReturn
end revGetIcoFile

function littleEndian
   return charToNum(char 1 of binaryEncode("S",1)) = 1
end littleEndian

Has anyone successfully used the new RunRev engine that has the
larger icon compatibility? I imagine that all we need to do change
the size limitation now in the MC IDE...correct?

The 'Windows XP' theme is nice, but a little flaky I think. Many
native objects 'flash' (especially tabs) when you are moving the
mouse...

JR

Can someone point me to where they could be archived?

Seem to remember someone was kind enough to do this?

This messages is being copied to both the MetaCard list and the MC_IDE group
at Yahoo to update folks about the IDE and to ask the question:  do we need
two mailing lists?

While Yahoo Groups require membership in a group in order to access its
files, I hadn't intended to suggest that we also use the mailing list that
comes with the group to augment/displace the conversation on the existing
MetaCard list.  If I recall correctly, when we took an informal poll of the
topic in the MetaCard list back in August it seemed that most folks
preferred to keep discussion of the MetaCard IDE on the main list.

I have no objection to using the mailing list at the MC_IDE Group if it's
useful, but since we're all subscribed to MetaCard list there may be merit
in keeping the discussion there as much as possible.  For myself, to
minimize duplicate posts in people's In Boxes while reaching the most MC IDE
users, going forward I'll post just to the MetaCard list unless there's a
compelling reason to use the MC_IDE group list that I may have overlooked.


On the status of the MC IDE:

It took us a while to iron out licensing and stuff, but we finlly have an
initial open source release of the MC IDE.

Looking ahead we see two camps forming:  those who say "The MC IDE must
change" and those who say "The MC IDE must remain the same."  As my
grandpappy used to say, "When faced with two compelling options, the earnest
designer finds a way to choose both."  :)

So here's my proposal for the next set of changes to the MC IDE:

Regardless of whatever other changes which might be made, any future options
can, and arguably should, include the addition of a Plugins menu.

I think it would be easier to use it as a main menu in the menubar as
opposed to a submenu in the Tools menu, but if there's a reason that
wouldn't be a good idea we should discuss it.

As RunRev's marketing continues to expand the Rev audience, I think it makes
sense to implement a Plugins menu in a way which is compatible with Rev
plugins and would encourage developers to use methods that allow a plugin to
be used in the Rev IDE also.  Since a plugin is just a stack and a Plugins
menu simply a way to open the stack, this shouldn't be too hard. :)

Keeping with the spirit of MC's engine-centric focus, I would propose that
we use the built-in style property of stacks to govern mode, with the
default being modeless unless you hold down the Option key (Mac) or Alt key
(Win) in which case it opens as toplevel so it can be easily modified.  If
you want your plugin to be a palette just set the style and save it.  We
could just as well use palette as the default - opinions?

The Rev IDE provides other custom properties for plugins, and I think it
makes sense to support the style property for those plugins that already
have it.  Other IDE-specific custom properties, such as those that register
a plugin for custom IDE messages, can be supported as an option settable in
a Plugins Manager window, which would be off by default to keep the message
path as clean and simple as possible.

While the mechanism for custom IDE messages like revSelectedObjectChanged
can be easily supported, for simplicity I would encourage the use of
frontscripts to handle messages directly, so long as we all play nice and
maintain the good habit of always passing system messages.

Once we have a Plugins menu in place you can mix and match your favorite
editing components without bothering with wacky stuff like my UmbrellaMan
tool. :)  We can play around with those and start a duscussion of candidates
for inclusion in the main distribution, possibly including some directly in
mctools.mc.  I'm anxious to see what Ken and Hugh are cooking up with their
script library, and Scott Rossi has some good ideas about a resize tool....

I'm game for implementing a first pass at a Plugins menu and posting it for
your review, but I should warn you that I won't be able to get back to the
IDE again until after the Rev Seminar at MacWorld on Jan. 9 & 10
<http://www.runrev.com/macworldschedule.html>.  So if one of you has time
and energy to dig into that before then that would be cool but we should
probably coordinate it on the MetaCard list to avoid duplication of effort.
If not, I'll be able to resume work on the IDE on the 11th.

In the meantime you can always trade plugins easily in RevNet, so if you
want to extend IDEs you can start yesterday -- all you need for a plugin is
a stack file and a way to open it. :)


Notes about plugin design:

There's not much to it since it's just a stack file, but there are a few
basics worth keeping in mind with any IDE components:

- Pass system messages.
   Never assume your plugin will be last in line; any library or
   backscript inserted after yours may need that message.  This
   is especially important with frontscripts, because if they
   don't pass a message nothing in the user's stack will get it
   either.

- Keep it simple.
   Most plugins do one thing really well.  There may be good
   reason to do something deep like Geoff Canyon did with his
   Navigator tool, but usually the pugins people will enjoy
   most often are the simple gems that shine at one specific
   task.  Specialization is not just for insects. :)

- Restore any changed global properties.
   If you change global properties, save them first and restore
   those values again as soon as possible before your routine
   exits. You never know what values a developer might be relying
   on for global properties, or when.

- Make it self-contained.
   Reliance on IDE-specific features may limit your tool's
   audience, and with IDEs being in a process of continual
   improvement this may help prevent having to update your
   tool each time an IDE changes.

- Frontscripts are your friend.
   You can insert them when your stack opens and remove them
   when it closes and you get access to all messages sent to
   any object.  Very handy -- just be sure to pass such messages
   when you're done with them.

- Write for explicitVars.
   A developer using your tool may be working with the
   explicitVariables global property set the true.  If
   you leave it on as you write plugins you can catch
   any undeclared variables before your users does.

- Test.
   You know how it goes.


Side note about messges: If you're making anything that responds to the
selectedbjectChanged message you might want to consider using the "message
buffering" technique used in 4W Props (downloadable from
<http://www.fourthworld.com/rev/index.html>).  This method allows palettes
to appear much more responsive when updating their UIs after user selection
changes; keep MC's Inspector, Colors, and Font palettes open and drag-select
around 50 objects and you'll see what I mean. :)


That's more than enough for now. I gotta get back to work wrapping up
year-end projects and preparing for the Rev seminar.  Hope to see you folks
in SF....

--
  Richard Gaskin
  ___________________________________________________________
  Ambassador@...       http://www.FourthWorld.com
  Tel: 323-225-3717                       AIM: FourthWorldInc

On 12/27/03 2:24 AM, dzynr wrote:

> As Richard has stated on several occasions (and I
> think we all agree), the sparseness/simplicity of the IDE can be a benefit
> at times.  I agree the IDE is boring but it is functional and for now it
> might be less hassle to keep it that way unless there's some substantial
> usage of the MC IDE going on.

I'd agree. How about just enlarging the existing card a bit and adding
the missing properties? It would be a start for now.

--
Jacqueline Landman Gay         |     jacque@...
HyperActive Software           |     http://www.hyperactivesw.com

On 12/24/03 6:58 PM, "Alejandro Tejada" <capellan2000@...> wrote:

> Did you read a previous post were I wrote that Everaldo
> could give us permision to use his png images of the crystal
> icons to spice the interface of MetaCard?

I joined the group late so will try to go back through the messages...

Regards,

- Scott Rossi
Tactile Media

>>> ...I would like to propose the addition of objects'
>>> dimensional/positional
>>> properties being added to the IDE (width, height, position, more?). 
>>
>> Do you refer adding these properties to one of the palettes?
>> Or create another different floating palette (like some Design
>> programs have) that lets you change these properties with a
>> preview of the changes?

My initial thought was of adding fields to the existing object editing
cards.  This would have the least amount of impact on the current IDE.  I
suppose creating a completely new palette is an option -- something that
could be made constantly visible could be useful for myself but what do
others think about this?


>>> I'm not sure what the proper procedure here is (Grand Poobah?)
>>> but the omission of these items is one of the reasons why I
>>> initially built an alternate IDE. 
>>
>> An alternate IDE?
>> Could we see screenshots of this work, Scott?

I almost deleted these just before reading your post.  A few screenshots
were posted some time ago:

   http://www.tactilemedia.com/TLE/

Without going into the boring details again, this was developed as
alternative to the current MC IDE before Rev existed.  As such, it does not
have its own script editor nor any of the extra tools present in MC
(MenuBuilder, Standalone Builder, etc).


>>> I believe this would be fairly easy to add so I'll volunteer myself
>>> to carry it out unless someone has objections to the proposal.
>
> 100 % agreed :-)
>
> I would also offer my "heim2" palette, but i am sure Scott already has
> something nifty up his sleeve

Nothing nifty just for the position info, unless we decide to employ a
completely new palette.  As Richard has stated on several occasions (and I
think we all agree), the sparseness/simplicity of the IDE can be a benefit
at times.  I agree the IDE is boring but it is functional and for now it
might be less hassle to keep it that way unless there's some substantial
usage of the MC IDE going on.


>> Actually, I encourage you, to do so.
>>
>> Did you read a previous post were I wrote that Everaldo
>> could give us permision to use his png images of the crystal
>> icons to spice the interface of MetaCard?
>
> I personally would not mind a little eye-candy...

Nor would eye (pun intended) but if you add it to one place you need to add
it all over, and it becomes a fair amount of work.  Any more opinions?...

Regards,

- Scott Rossi
Tactile Media

Klaus Major wrote:

> I would also offer my "heim2" palette, but i am sure Scott already
> has something nifty up his sleeve ;-)

I'll like an option to choose between small and medium size icons
like some web browsers and eudora mail reader...

> I personally would not mind a little eye-candy...
> But maybe Scott has already something to offer in this case...
> (C'mon, you know how he is ;-)

If everaldo approves the use of his icons in this proyect,
it will be easier that everyone collaborate.


al

Hi all,

> Scott Rossi wrote:
>
> > ...I would like to propose the addition of objects'
> dimensional/positional
> > properties being added to the IDE (width, height, position, more?). 
>
> Do you refer adding these properties to one of the palettes?
> Or create another different floating palette (like some Design
> programs have) that lets you change these properties with a
> preview of the changes?
>
> >I'm not sure what the proper procedure here is (Grand Poobah?)
> >but the omission of these items is one of the reasons why I
> >initially built an alternate IDE. 
>
> An alternate IDE?
> Could we see screenshots of this work, Scott?
>
> >I believe this would be fairly easy to add so I'll volunteer myself
> to carry
> > it out unless someone has objections to the proposal.

100 % agreed :-)

I would also offer my "heim2" palette, but i am sure Scott already has
something
nifty up his sleeve ;-)

> Actually, I encourage you, to do so.
>
> Did you read a previous post were I wrote that Everaldo
> could give us permision to use his png images of the crystal
> icons to spice the interface of MetaCard?

I personally would not mind a little eye-candy...
But maybe Scott has already something to offer in this case...
(C'mon, you know how he is ;-)

> al

Regards

Klaus Major
klaus@...
www.major-k.de

Scott Rossi wrote:

> ...I would like to propose the addition of objects'
dimensional/positional
> properties being added to the IDE (width, height, position,
more?).

Do you refer adding these properties to one of the palettes?
Or create another different floating palette (like some Design
programs have) that lets you change these properties with a
preview of the changes?

>I'm not sure what the proper procedure here is (Grand Poobah?)
>but the omission of these items is one of the reasons why I
>initially built an alternate IDE.

An alternate IDE?
Could we see screenshots of this work, Scott?

>I believe this would be fairly easy to add so I'll volunteer myself
to carry
> it out unless someone has objections to the proposal.

Actually, I encourage you, to do so.

Did you read a previous post were I wrote that Everaldo
could give us permision to use his png images of the crystal
icons to spice the interface of MetaCard?

al

...I would like to propose the addition of objects' dimensional/positional
properties being added to the IDE (width, height, position, more?).  I'm not
sure what the proper procedure here is (Grand Poobah?) but the omission of
these items is one of the reasons why I initially built an alternate IDE.  I
believe this would be fairly easy to add so I'll volunteer myself to carry
it out unless someone has objections to the proposal.

Regards,

  - Scott Rossi
Tactile Media

Will the 'open driver' function ever be explained (or does it NOT
work)?

Does anyone have a working example with USB?

Thanks,
JR

Hi Richard,

Thanks a lot Richard!! :-)

I've written to Everaldo, the icon designer of the Crystal series
for KDE, about using his designs in web and multimedia.

He responds:

"Crystal is free for non comercial use
But include the credits and a link to www.everaldo.com"

Now I ask you and all MC users:

Could we use the Crystal icons in the MetaCard IDE?
Does this use qualifies as non commercial use?

Everaldo wrote that if any doubt arises, we can send him
links to webpages or web links to screenshots of these projects.

al

I finished the changes needed in mctools.mc for compatibility with the
v2.5.1 engine, and have updated the license info to reflect the X11 license
governing the new distribution.  This being the first release under the X11
license, I sent it to Scott for his approval.  Once I get his approval I'll
post it here, and going forward these types of update will be smooth and
quick.  I appreciate your patience with the lengthy process of this initial
open source release.

--
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador@...       http://www.FourthWorld.com
  Tel: 323-225-3717                       AIM: FourthWorldInc

Johnr91468 wrote:

> The Rev engines are not compatible with the MC_IDE in two respects
> (so far):
>
> - Custom icons (Standalone Builder) generates an error stating
> that 'the engine file is not a valid file'.
>
> - Error on start up 'wrong version of Tools stack!'.
>
> Wasn't it part of Scott's agreement that the future engines be
> compatible with the MC_IDE? Is there a work around?

With Jacque's excellent assistance, the cause has been identified:  the icon
data in MC's Buld button is used to find offsets for app icons in the Win
engine.  With v2.5.1 there is no longer a build specifically for MC and thus
the icon data doesn't match, so offset returns 0 and hence the error
message.

The workaround is to grab the icon data using a Win icon tool and replace
the data in those custom properties.  The solution was identified only
yesterday, which is why a more conveninent fix has not been delivered.

Before I deliver a fix myself I want to address some other considerations
for standalone building which may be less urgent but are at least as
important.  While I'm working on those, if someone has a moment to replace
the icon data in MC's Build button and email that copy of mctools.mc to me
(please use a virgin download from metacard.com),  I'll use that version to
include the X11 license and send that to Scott for posting as the baseline
release for the open source version.

--
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador@...       http://www.FourthWorld.com
  Tel: 323-225-3717                       AIM: FourthWorldInc

The Rev engines are not compatible with the MC_IDE in two respects
(so far):

- Custom icons (Standalone Builder) generates an error stating
that 'the engine file is not a valid file'.

- Error on start up 'wrong version of Tools stack!'.

Wasn't it part of Scott's agreement that the future engines be
compatible with the MC_IDE? Is there a work around?

JR

Alejandro Tejada wrote:

> Recently, Richard Gaskin wrote that
> the Metacard IDE was released by Scott
> Raney with the X11 license.
> Could someone explain in very lay terms
> or with the phrases "You could" or "You
> could not" what are the terms of this license.

X11 has been chosen, but your project poohbah (yours truly) has not yet
revised the MC IDE to include that license for Scott's approval and posting.
I know, I'm a very bad slacker; been way deep in client work for several
weeks; should be done soon.

The full text of the X11 license is at:

<http://www.x.org/Downloads_terms.html>

--
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador@...       http://www.FourthWorld.com
  Tel: 323-225-3717                       AIM: FourthWorldInc

Recently, Richard Gaskin wrote that
the Metacard IDE was released by Scott
Raney with the X11 license.
Could someone explain in very lay terms
or with the phrases "You could" or "You
could not" what are the terms of this license.

Thanks in advance

al

"Johnr91468" wrote:

[snip]

>How do we update the engine for the MC IDE, or are
>we going to use the RunRev engine...meaning that
>current registered MC users must upgrade to get
>upgrades?

I understand that you just have to rename the
engine to mc.exe and put it in place of the actual
metacard engine application.

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!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

I will answer my own question I guess:

(This issue was already discussed on the MetaCard list)

[JohnR - Thu, 10 Jul 2003 19:34:38 Vol 1 #701]
(Quoting the MetaCard license agreement)
"free access to all MetaCard updates that are released or go to
beta within that 1 year period. At least 2 upgrades are guaranteed
to be released within the duration of each subscription."


[Scott Raney - Fri, 11 Jul 2003 13:37:52 Vol 1 #707]
"I think you can expect Runtime Revolution to be a little tighter
about this than MetaCard Corporation was.  But there should be at
least a couple more engine releases that current MetaCard subscribers
will be able to use (e.g., 2.5.1 is already in alpha test).  You will
have to download and install the new versions RR to get those updated
engines to use with MetaCard, however.  And of course you'll need to
download the MC UI from someplace else if it turns out to need
changes due to the engine updates."


[Richard Gaskin - Tue, 26 Aug 2003 14:36:17 - Vol 1 #772]
"But it seems that every pro license that was renewed in that last
year, whether a MetaCard license or a Rev Enterprise license, will
continue to get upgrades on the same schedule regardless of the file
name of the engine."


Well, it's been about 7 months since I upgraded my professional
license with MetaCard, and I have seen no upgrades to the MC engine
to fix remaining bugs...


To reiterate Scott's statement:

"But there should be at least a couple more engine releases that
current MetaCard subscribers will be able to use"


What do we do if this doesn't happen? Do we get a refund on our
license? Is RunRev forced to comply?


JR


--- In MC_IDE@yahoogroups.com, "Johnr91468" <johnrule@r...> wrote:
> How do we update the engine for the MC IDE, or are we going to use
> the RunRev engine...meaning that current registered MC users must
> upgrade to get upgrades?
>
> JR

How do we update the engine for the MC IDE, or are we going to use
the RunRev engine...meaning that current registered MC users must
upgrade to get upgrades?

JR