The changes won't ever show up in the cRevStandaloneSettings. They are only applied when you package up the application and the settings are applied to a temporary stack that is used to build the standalone.jim1001 wrote:After making a change to "version" and "build" in app.yaml, when should I expect to see those changes in
cRevStandaloneSettings: android,version name (same as LC IDE: Version Name) and cRevStandaloneSettings: android,version code (same as LC IDE: Version Code) of the LC IDE?
Creating LiveCode applications that play well with git
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: Creating LiveCode applications that play well with git
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: Creating LiveCode applications that play well with git
It looks like you are already considering the major drawbacks - cards sharing a group and visual properties like font and colors that can be set at the stack level. You don't have to worry about stack size. If you use `go stack "Untitled 2" in window "Untitled 1"` then stack "Untitled 2" will appear at the current size of stack "Untitled 1".trevordevore wrote:My UI components are all livecode binary stacks. I only use one card per component,jim1001 wrote:I can see the advantages but are there any drawbacks in doing this or anything to watch out for?
My projects rarely have stacks with more than one card although my preferences stack does have two or three. I don't bother splitting that up into different stacks. It may be that for the design needs of your project keeping everything together is best. For my Bell Conductor application the configuration screen and playback screen are so different that it made sense to break them up into different stacks. How many cards are you dealing with?
This won't be a factor at all.jim1001 wrote:Maybe another drawback would be that it's harder (& slower?) to communicate between cards if they are in different stacks.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Re: Creating LiveCode applications that play well with git
Maybe we're at cross-purposes here but I've found that the LevureStandalone stack android cRevStandaloneSettings (and hence Android Basic Application Settings) do change to the app.yaml values after a levurePackageApplication call. The changes are preserved even if I exit LC after the build and choose not to save changes to the stack...The changes won't ever show up in the cRevStandaloneSettings. They are only applied when you package up the application and the settings are applied to a temporary stack that is used to build the standalone.
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: Creating LiveCode applications that play well with git
I was mistaken. The packaging code in Levure does in fact store and save the version info prior to packaging the application. A temporary standalone stack is created during the packaging process but the standalone version information is updated and saved to the actual standalone stack before the temporary copy is made.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Re: Creating LiveCode applications that play well with git
Thanks - that's good to know as is that communication between stacks isn't a problem.You don't have to worry about stack size. If you use `go stack "Untitled 2" in window "Untitled 1"` then stack "Untitled 2" will appear at the current size of stack "Untitled 1".
With the current design I estimate about 10 different card layouts are required. I've designed them to be as uncluttered as possible so their layout is not complicated - however they are all distinct. The app is a self-help guide and includes a lot of video footage. It also allows users to take photos, write responses to activity questions and link to further information PDFs on the device. The first version of the app to be trialed won't use the internet.How many cards are you dealing with?
Re: Creating LiveCode applications that play well with git
Using a single stack with many cards for my UI, I wanted the same widget.navbar on all the cards to move between different screens of the UI. I put the navbar into a group which is shared across all the cards so that any changes to the group are propagated to all cards using it. If want to break up the UI into multiple stacks with a single card per stack (so that it's easier to manage in version control) what would be the best way to implement the navbar to avoid duplication?It looks like you are already considering the major drawbacks - cards sharing a group and visual properties like font and colors that can be set at the stack level.
Thanks for any advice.
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: Creating LiveCode applications that play well with git
You wouldn't be able to get around the fact that you would have multiple instances of the widget. You would have to write your own code that stored the master version of the navigation in a template and then updated it everywhere it appears if you make a change.
If you use a behavior then the code would be shared and you would only update the code in one place.
If you use a behavior then the code would be shared and you would only update the code in one place.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Re: Creating LiveCode applications that play well with git
Thanks Trevor for continuing to reply. The things I'm asking are as a consequence of adopting Levure with Git but if you think they'd be better off in a new thread then please don't hesitate to say.
A web search for "livecode templates" didn't turn up much. I also looked in the LC dictionary but I don’t think the templates talked about there are the same as you mean - could be wrong of course!
You've mentioned that you were experimenting with templates before and I can see you have a NoteTemplates stack in bellConductor although I’m sketchy as to how it works. Is there a standard way of implementing templates in LiveCode? Is there any lesson / post you can point me to describing how to implement & use?You would have to write your own code that stored the master version of the navigation in a template
A web search for "livecode templates" didn't turn up much. I also looked in the LC dictionary but I don’t think the templates talked about there are the same as you mean - could be wrong of course!
Re: Creating LiveCode applications that play well with git
Are they also known as as Custom Controls? http://lessons.livecode.com/m/4071/l/22 ... m-controlsIs there a standard way of implementing templates in LiveCode? Is there any lesson / post you can point me to describing how to implement & use?
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: Creating LiveCode applications that play well with git
A custom control is a group that is intended to act as a single control. A data grid is an example of a custom control. Widgets can replace custom controls in many cases.
In LiveCode there is the concept of templateGroup, templateField, etc. This settings applied to these template objects affect the properties of new controls. The idea is similar to what I'm referring to but these are not the templates that are used.
The NoteTemplates stack in the Bell Conductor app contains the templates of each note that can be displayed during playback of a song. When playing a note in a song the code looks for the note in the NoteTemplates stack and copies it to the playback stack. These notes are created and deleted while the song is played. Any changes that are made to the template will then be used the next time a song is played.
The concept is somewhat similar to what I referred to in creating a template for your header. You would have a widget, standard control, or custom control somewhere that represents your navigation control. You would write code that copies it into all of the cards that use it, replacing an existing instance of the control. You would run this code anytime you made changes to the navigation.
I hope that makes sense.
In LiveCode there is the concept of templateGroup, templateField, etc. This settings applied to these template objects affect the properties of new controls. The idea is similar to what I'm referring to but these are not the templates that are used.
The NoteTemplates stack in the Bell Conductor app contains the templates of each note that can be displayed during playback of a song. When playing a note in a song the code looks for the note in the NoteTemplates stack and copies it to the playback stack. These notes are created and deleted while the song is played. Any changes that are made to the template will then be used the next time a song is played.
The concept is somewhat similar to what I referred to in creating a template for your header. You would have a widget, standard control, or custom control somewhere that represents your navigation control. You would write code that copies it into all of the cards that use it, replacing an existing instance of the control. You would run this code anytime you made changes to the navigation.
I hope that makes sense.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Re: Creating LiveCode applications that play well with git
Trevor, thanks for the explanation. As I understand it then your notes templates are home-made & not part of core LiveCode.
Anyhow, as a trial, instead of adding another card to my single UI stack I added a single card stack and managed to link it with the main UI stack. Made it look to user like they share the same navigation bar. Used a new instance of the nav bar widget but set its items for all cards of the UI with the same library command. Probably trivial to many but made me happy.
To include the navigation bar widget in the Android standalone I had to check it on the Inclusions pane of the LevureStandalone. Not sure if there's any other way with Levure.
You've lost me there. I would have thought a template was fixed (at least in any one version of an app) but you make minor changes to the objects / instances which are created from it.Any changes that are made to the template will then be used the next time a song is played.
Anyhow, as a trial, instead of adding another card to my single UI stack I added a single card stack and managed to link it with the main UI stack. Made it look to user like they share the same navigation bar. Used a new instance of the nav bar widget but set its items for all cards of the UI with the same library command. Probably trivial to many but made me happy.
To include the navigation bar widget in the Android standalone I had to check it on the Inclusions pane of the LevureStandalone. Not sure if there's any other way with Levure.
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: Creating LiveCode applications that play well with git
That is correct.jim1001 wrote:As I understand it then your notes templates are home-made & not part of core LiveCode.
In the Bell Conductor application that template is not modified after a new version of the app is packaged. What that means is that there is no code in the application that modifies the note templates while the application is running. Any modifications are made by hand in the IDE. The point I was trying to make was that changing properties of a note template control will change what the note looks like when you play a song the next time. It doesn't really matter whether that change is made in the IDE during development or in a packaged application. The properties of the template control affect what copies of the control will look like.jim1001 wrote:You've lost me there. I would have thought a template was fixed (at least in any one version of an app) but you make minor changes to the objects / instances which are created from it.trevordevore wrote:Any changes that are made to the template will then be used the next time a song is played.
Great!jim1001 wrote:Anyhow, as a trial, instead of adding another card to my single UI stack I added a single card stack and managed to link it with the main UI stack. Made it look to user like they share the same navigation bar. Used a new instance of the nav bar widget but set its items for all cards of the UI with the same library command. Probably trivial to many but made me happy.
That is the proper way to include widgets.jim1001 wrote:To include the navigation bar widget in the Android standalone I had to check it on the Inclusions pane of the LevureStandalone. Not sure if there's any other way with Levure.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Re: Creating LiveCode applications that play well with git
OK - clear now, thanks.The point I was trying to make was that changing properties of a note template control will change what the note looks like when you play a song the next time
Now I’ve found another problem that has led to deeper questions.
Navigation around my multiple stack UI works fine in the IDE. However not on an Android tablet. So I started to have a poke around at various things along the way.
One thing I was checking was the IDE stack files tab for one of my single card UI stacks, called say UI1. I had a card behavior and stack behavior stack listed. I noticed the file paths were pointing to the behaviors folder of a different UI stack, say UI2/behaviors. Now let’s say I clear out both leaving me with no listed stack files. Then first I add the stack behavior stack. It appears listed as “behaviors/UI1_stack_behavior.livecodescript”. (I assume that this path is relative to the folder of the UI1 stack). Then I add the card behavior stack. It appears listed as “behaviors/UI1_card_behavior.livecodescript”. But then I notice that the IDE has changed the File Path for the stack behavior stack I added first which now appears as “C:/…../UI2/behaviors/stack_behavior.livecodescript”.
Why has it changed and why is it pointing to the absolute path of UI2/behaviors when I chose the file from UI1/behaviors? I also think that if the app is going to be installed on a tablet I need relative paths not absolute ones.
Let’s leave it at that for this post - thanks!
-
- VIP Livecode Opensource Backer
- Posts: 1005
- Joined: Sat Apr 08, 2006 3:06 pm
- Location: Overland Park, Kansas
- Contact:
Re: Creating LiveCode applications that play well with git
By any chance do your behavior stack files use the same name in memory? If you have two behaviors that are both named "Stack Behavior" in memory then perhaps it could confuse the IDE.jim1001 wrote:One thing I was checking was the IDE stack files tab for one of my single card UI stacks, called say UI1. I had a card behavior and stack behavior stack listed. I noticed the file paths were pointing to the behaviors folder of a different UI stack, say UI2/behaviors. Now let’s say I clear out both leaving me with no listed stack files. Then first I add the stack behavior stack. It appears listed as “behaviors/UI1_stack_behavior.livecodescript”. (I assume that this path is relative to the folder of the UI1 stack). Then I add the card behavior stack. It appears listed as “behaviors/UI1_card_behavior.livecodescript”. But then I notice that the IDE has changed the File Path for the stack behavior stack I added first which now appears as “C:/…../UI2/behaviors/stack_behavior.livecodescript”.
Why has it changed and why is it pointing to the absolute path of UI2/behaviors when I chose the file from UI1/behaviors? I also think that if the app is going to be installed on a tablet I need relative paths not absolute ones.
Trevor DeVore
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
ScreenSteps - https://www.screensteps.com
LiveCode Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode
LiveCode Builder Repos - https://github.com/search?q=user%3Atrevordevore+topic:livecode-builder
Re: Creating LiveCode applications that play well with git
Don’t think that is the problem. Before I saw your post I had tried re-creating the behavior files with different file names and different (unique) script names but it didn’t make any difference. I think I may have put them in the wrong UI folder originally which the IDE seems to have memorised and I’m unable to erase that memory. I’ve tried to recreate the problem with a new Levure project but haven’t been able.By any chance do your behavior stack files use the same name in memory? If you have two behaviors that are both named "Stack Behavior" in memory then perhaps it could confuse the IDE.
As a possible workaround and also because it may be better in long term for version control I’ve tried to set up a behavior by script.
I inserted the following lines in app.livecodescript:
Code: Select all
command InitializeApplication
# Called after script-only stacks, extensions, and externals in app.yml are loaded.
# Perform initialization operations before UI stack is opened.
local myPath, theStackFileIsLoaded
put levureAppFolder() & "/" & "ui/ui1/behaviors/stack_ui1_behavior.livecodescript" into myPath
set the stackFiles of stack "ui1" to myPath
put there is a stack myPath into theStackFileIsLoaded --checking existence of behavior stack loads it into memory if it exists
if theStackFileIsLoaded then
put "stack " & myPath & " is loaded"
set the behavior of stack "ui1" to stack "stack_ui1_behavior"
else
put "stack " & myPath & " not loaded"
end if
Code: Select all
Type Chunk: source is not a container
Object app
Line set the behavior of stack "ui1" to stack "stack_ui1_behavior"
Hint InitializeApplication
Code: Select all
script "stack_ui1_behavior"
Thank you.