Including stacks from different locations
tereza
applications that share a common code base. All but one of the stacks
in the project are used by every application. Each application
contributes its own config stack which alters its appearance,
behavior, and data source. Its vital, however that there exist only
one development copy of the stacks -- including the main program
stack.
I would like to take advantage of the framework's ability to load
stacks and put them into use automatically, and I would like it if the
packager could grab stacks from my 'core components' development
folder and stow them in the individual applications' components folder
(which should be put inside the .app on the mac side). Can the
framework/packager handle this? If so, what's the best way to set up
the application stack to accomplish it?
Trevor DeVore
> I would like to take advantage of the framework's ability to load
> stacks and put them into use automatically, and I would like it if the
> packager could grab stacks from my 'core components' development
> folder and stow them in the individual applications' components folder
> (which should be put inside the .app on the mac side). Can the
> framework/packager handle this? If so, what's the best way to set up
> the application stack to accomplish it?
While the plugin will store relative paths to stacks outside of the
application directory I don't know how well loading and packaging of
the stacks would work in practice.
You would probably need to make some modifications to the application
packager and the code that loads stacks from disk but that shouldn't
be terribly hard to do. Perhaps any stack that is stored in a folder
above the application folder just gets copied into the application
folder when packaged.
What would you need to update? I don't know for sure but look at:
* _loadStacks in the framework library stack.
* Look at the _CopyApplicationToFolder in the application packager.
--
Trevor DeVore
Blue Mango Learning Systems
ScreenSteps: http://www.screensteps.com
Releasable Revolution Resources for Developers: http://revolution.bluemangolearning.com
tereza
On Feb 18, 4:08 pm, Trevor DeVore <glx...@gmail.com> wrote:
...
> While the plugin will store relative paths to stacks outside of the
> application directory I don't know how well loading and packaging of
> the stacks would work in practice.
>
> You would probably need to make some modifications to the application
> packager and the code that loads stacks from disk but that shouldn't
> be terribly hard to do. Perhaps any stack that is stored in a folder
> above the application folder just gets copied into the application
> folder when packaged.
>
> What would you need to update? I don't know for sure but look at:
>
> * _loadStacks in the framework library stack.
>
> * Look at the _CopyApplicationToFolder in the application packager.
I will look at those handlers.
So far, I've set it up so that it packages two "component" folders
with the app. One for the core stacks and files, and the other for the
specific application folders and files. The sticky part is that not
all the stacks in the core components folder are needed by the
standalones, so I can't just plop the folder of stacks into the
standalone component folder.
I'll keep you posted...
t
tereza
> > You would probably need to make some modifications to the application
> > packager and the code that loads stacks from disk but that shouldn't
> > be terribly hard to do. Perhaps any stack that is stored in a folder
> > above the application folder just gets copied into the application
> > folder when packaged.
>
> > What would you need to update? I don't know for sure but look at:
>
> > * _loadStacks in the framework library stack.
>
> > * Look at the _CopyApplicationToFolder in the application packager.
I managed to coerce the framework library stack to copy the stacks
from the core components folder to the application components folder
by putting aliases to the core stacks in the app's components folder,
and modifying this line in the function glxstack_getProp:
put theRootDirectory & slash & the uObjectProps["relative file name"]
of pObject into theFile
to read:
put aliasReference(theRootDirectory & slash & the
uObjectProps["relative file name"] of pObject) into theFile
I also made a button on the application packager "Increment build
number" with this inelegant script:
--------------------------
on mouseUp
IncrementBuildNumber
end mouseUp
constant kApplicationStackName = "application"
on IncrementBuildNumber
if there is a stack kApplicationStackName then
put GetApplicationObject() into theAppObject
put glxapp_getProp("version array") into theVersionA
set the uVersion["build"] of theAppObject to theVersionA["build"]
+1
save stack kApplicationStackName
_RefreshApplicationStackAndInfo
else beep
end IncrementBuildNumber
function GetApplicationObject
return the long ID of group "ApplicationObject" of stack
kApplicationStackName
end GetApplicationObject
-----------------------------------------
Which I needed because I was making so many builds to test different
strategies, and I wanted to compare the results
Trevor DeVore
> I managed to coerce the framework library stack to copy the stacks
> from the core components folder to the application components folder
> by putting aliases to the core stacks in the app's components folder,
> and modifying this line in the function glxstack_getProp:
>
> put theRootDirectory & slash & the uObjectProps["relative file name"]
> of pObject into theFile
>
> to read:
>
> put aliasReference(theRootDirectory & slash & the
> uObjectProps["relative file name"] of pObject) into theFile
Cool.
I just thought of something though. Using the plugin, if you select a
stack outside of your application folder a proper relative path will
be store (i.e. ../../path/to/stack). The only problem right now is
that the relative path won't be resolved properly when you call
glxstack_getProp(pObject, "file path").
BUT with the addition of one tiny private function to the framework
library we can fix all of that. Now you can just keep your core
components wherever you wish and then just add them as stacks to your
app.
ADD THIS PRIVATE FUNCTION
private function _resolveRelativePath pRootDirectory, pRelativeFilename
set the itemdelimiter to slash
repeat forever
if char 1 to 3 of pRelativeFilename is "../" then
delete char 1 to 3 of pRelativeFilename
delete the last item of pRootDirectory
else
exit repeat
end if
end repeat
replace "./" with empty in pRelativeFilename
put pRootDirectory & slash & pRelativeFilename into theFile
return theFile
end _resolveRelativePath
UPDATE glxstack_getProp WITH THIS:
function glxstack_getProp pObject, pProperty
local theFile,theRootDirectory
switch pProperty
case "file path"
put _rootExecutableDirectory(word 9 to -1 of pObject) into
theRootDirectory
put _resolveRelativePath(theRootDirectory, the
uObjectProps["relative file name"] of pObject) into theFile
if there is not a file theFile then put empty into theFile
return theFile
break
case "load at startup"
## default is true
return the uObjectProps[pProperty] of pObject is not false
break
default
return the uObjectProps[pProperty] of pObject
end switch
end glxstack_getProp
Would that work for you?
> I also made a button on the application packager "Increment build
> number" with this inelegant script:
>
> ...
>
> Which I needed because I was making so many builds to test different
> strategies, and I wanted to compare the results
I've gone back and forth on whether to add something like this to the
application packager. I usually have the app open in one instance of
the IDE and the app packager open in another instance of the IDE. If I
update the build number in the Application Packager then the actual
stack doesn't get updated in the version of the IDE with the actual
application.
The Application Packager, on the other hand, always updates itself on
resumeStack so if you update the version number in the plugin and
switch back to the application packager then the app packager has the
correct version.
Perhaps we add your code to the plugin? What do you think?
tereza
On Feb 20, 9:38 pm, Trevor DeVore <glx...@gmail.com> wrote:
...
> Cool.
>
> I just thought of something though. Using the plugin, if you select a
> stack outside of your application folder a proper relative path will
> be store (i.e. ../../path/to/stack). The only problem right now is
> that the relative path won't be resolved properly when you call
> glxstack_getProp(pObject, "file path").
>
> BUT with the addition of one tiny private function to the framework
> library we can fix all of that. Now you can just keep your core
> components wherever you wish and then just add them as stacks to your
> app.
>
> ADD THIS PRIVATE FUNCTION
...
> UPDATE glxstack_getProp WITH THIS:
> ....
> Would that work for you?
Hmmm, maybe it would! I discovered that aliasReference() didn't work
the same way in Windows. Whereas on the Mac it would return the
correct path whether or not the parameter was an alias, on Windows it
returned empty when the it was NOT an alias. I didn't test this
observation too finely; I discovered that if I branched around it in
Windows (I don't build in Windows), my standalone functioned
properly.
However, would _resolveRelativePath() allow the packager to build the
app with the stacks tucked inside the components folder? As you know,
I keep all my stacks in a subfolder of "components". Using
aliasReference(), all I have to do is put aliases in there... wait a
minute ... Oh I just realized what you meant by "Using the plugin, if
you select a stack outside of your application folder a proper
relative path will be stored (i.e. ../../path/to/stack)." I went
behind the plugin's back by editing the app object properties
directly, setting each relative path to "STK/stackname.rev", which is
the correct relative path to the alias in the components folder. Once
glxstack_getProp was made to treat aliases properly, I could both
develop and package, and keep total control of what goes into the
components folder
>
> > I also made a button on the application packager "Increment build
> > number" with this inelegant script:
>
> > ...
>
> I've gone back and forth on whether to add something like this to the
> application packager.
...
>
> Perhaps we add your code to the plugin? What do you think?
I ended up converting my single button to increment the build number
to a pull-down that allows me to choose which numerical component to
increment. Certainly the plugin could use a similar button (code
below). I've already stepped on myself once by saving over
application.dat, so I know you're right, but I think I'll keep a
button on the packager, too, because it's when I'm packaging that my
mind in on versioning. I'll just have to remember to revert
application.dat when I switch back to the rev I'm using for coding.
script of btn "Increment Version Component" ----------
constant kApplicationStackName = "application"
on menuPick pItemName
if there is a stack kApplicationStackName then
put GetApplicationObject() into theAppObject
put glxapp_getProp("version array") into theVersionA
set the uVersion[pItemName] of theAppObject to
theVersionA[pItemName]+1
save stack kApplicationStackName
_RefreshApplicationStackAndInfo
else beep
end menuPick
tereza
On Feb 20, 9:38 pm, Trevor DeVore <glx...@gmail.com> wrote:
...
> Cool.
>
> I just thought of something though. Using the plugin, if you select a
> stack outside of your application folder a proper relative path will
> be store (i.e. ../../path/to/stack). The only problem right now is
> that the relative path won't be resolved properly when you call
> glxstack_getProp(pObject, "file path").
>
> BUT with the addition of one tiny private function to the framework
> library we can fix all of that. Now you can just keep your core
> components wherever you wish and then just add them as stacks to your
> app.
>
> ADD THIS PRIVATE FUNCTION
...
> UPDATE glxstack_getProp WITH THIS:
> ....
> Would that work for you?
Hmmm, maybe it would! I discovered that aliasReference() didn't work
the same way in Windows. Whereas on the Mac it would return the
correct path whether or not the parameter was an alias, on Windows it
returned empty when the it was NOT an alias. I didn't test this
observation too finely; I discovered that if I branched around it in
Windows (I don't build in Windows), my standalone functioned
properly.
However, would _resolveRelativePath() allow the packager to build the
app with the stacks tucked inside the components folder? As you know,
I keep all my stacks in a subfolder of "components". Using
aliasReference(), all I have to do is put aliases in there... wait a
minute ... Oh I just realized what you meant by "Using the plugin, if
you select a stack outside of your application folder a proper
relative path will be stored (i.e. ../../path/to/stack)." I went
behind the plugin's back by editing the app object properties
directly, setting each relative path to "STK/stackname.rev", which is
the correct relative path to the alias in the components folder. Once
glxstack_getProp was made to treat aliases properly, I could both
develop and package, and keep total control of what goes into the
components folder
>
> > I also made a button on the application packager "Increment build
> > number" with this inelegant script:
>
> > ...
>
> I've gone back and forth on whether to add something like this to the
> application packager.
...
>
> Perhaps we add your code to the plugin? What do you think?
I ended up converting my single button to increment the build number
to a pull-down that allows me to choose which numerical component to
increment. Certainly the plugin could use a similar button (code
below). I've already stepped on myself once by saving over
application.dat, so I know you're right, but I think I'll keep a
button on the packager, too, because it's when I'm packaging that my
mind in on versioning. I'll just have to remember to revert
application.dat when I switch back to the rev I'm using for coding.
script of btn "Increment Version Component" ----------
constant kApplicationStackName = "application"
on menuPick pItemName
if there is a stack kApplicationStackName then
put GetApplicationObject() into theAppObject
put glxapp_getProp("version array") into theVersionA
set the uVersion[pItemName] of theAppObject to
theVersionA[pItemName]+1
save stack kApplicationStackName
_RefreshApplicationStackAndInfo
else beep
end menuPick
Trevor DeVore
> However, would _resolveRelativePath() allow the packager to build the
> app with the stacks tucked inside the components folder?
I was making some changes in the Application Packager today and added
support for stacks that reside above the folder where application.dat
is stored.
Basically if the relative path to a stack stored in the framework
Application object starts with a "../" then the stack will be stored
alongside "application.dat" during the packaging process.
So now I have the framework library itself and the Application
Packager supporting stacks that reside in a common repository for
multiple applications. Let me know if you want to test a copy.
Tereza Snyder
On Feb 24, 2010, at 8:42 AM, Trevor DeVore wrote:
> On Feb 21, 2010, at 12:42 AM, tereza wrote:
>
>> However, would _resolveRelativePath() allow the packager to build the
>> app with the stacks tucked inside the components folder?
>
> I was making some changes in the Application Packager today and added support for stacks that reside above the folder where application.dat is stored.
Though I prefer to keep application stacks nested in a folder inside the folder where application.dat is stored, this will do!
>
>
> Basically if the relative path to a stack stored in the framework Application object starts with a "../" then the stack will be stored alongside "application.dat" during the packaging process.
>
> So now I have the framework library itself and the Application Packager supporting stacks that reside in a common repository for multiple applications. Let me know if you want to test a copy.
I do. Thanks.
t
--
Tereza Snyder
Califex Software, Inc.
<www.califexsoftware.com>
Trevor DeVore
> On Feb 24, 2010, at 8:42 AM, Trevor DeVore wrote:
>>
>> I was making some changes in the Application Packager today and
>> added support for stacks that reside above the folder where
>> application.dat is stored.
>
> Though I prefer to keep application stacks nested in a folder inside
> the folder where application.dat is stored, this will do!
At this point you could add another property to the stack resource
object that specified the relative output folder. If set then you
could use it in the Application Packager.
>> So now I have the framework library itself and the Application
>> Packager supporting stacks that reside in a common repository for
>> multiple applications. Let me know if you want to test a copy.
>
> I do. Thanks.
Here is the link. This build also has preliminary support for linux
(enough to ScreenSteps to launch and behave well). Proxy server
detection and other internet features aren't working yet though.