Hi all,
using browser version of LCC on Safari/Sequoia.
As a recent post stated, importing old projects recognises cards in the project browser, but “layouts” seem to equate to stacks.
To test this, I created a button on a layout to create a new card.
This creates a new card (which is only apparent because the button disappears).
However this new card does not appear in the project browser (as opposed to importing Classic stacks).
The only way to navigate is using the messageBox.
Cards and stacks are an essential part of LiveCode as they were in HC and MC, and they are loved for a reason. They just work.
I am hoping the intent is to bring in card management properly but if they don’t show in the project browser that will be a problem…
Yes, please bring back cards. Or make layouts cards and the app itself the stack.
With the current layout (stack) model, I have questions on how to implement global variables, constants and hierarchical functions and custom command handlers. It doesn’t make sense to me to have multiple stacks as the only method of building a multi-screen app.
I suppose the work around is to create your app structure in Livecode Classic (e.g. a stack and multiple cards) then import it to Livecode Create. Seems a bit clunky though.
Thanks for the post! With Create we’re moving away from Stacks and Cards and replacing them with layouts. We will still support projects with multiple cards within a stack and are still discussing how this will be implemented within the project browser etc.
We may change it so that in the project browser a stack with multiple cards appears as a stack rather than a layout. In future it likely won’t be possible to create cards in script on a layout too. This is all still in discussion though so keep an eye out for future updates!
Thank you for taking the time to help us improve LiveCode Create!
Losing the separation of stack/card would be very disappointing.
What I and I’m sure many other are really asking for is the ability to have multiple layouts in 1 window (in LC terms multiple cards in 1 stack).
What you are saying is that this will no longer be possible.
It raises the question: Which exact niche is Create intended to fill long term?
Is it intended to gradually replace all of the existing and become the sole IDE in the future?
Or will LiveCode Classic continue to be developed indefinitely, alongside this low-code IDE?
The very naming of it to “Classic” suggests this will not be developed further but perhaps there are plans to launch a 3rd IDE.
If Classic will persist in some form then great, we as developers can continue to make use of the great namespacing, logic separation/MVC style development it permits and all the benefits the stack/card structure affords.
If it is to be that LC Create replaces everything in the long term and Classic will eventually go away with no direct replacement, then I already lament the loss of this rare facility and would feel disheartened about embracing this platform.
Beyond the technical issues and complexity the stack/card paradigm creates for implementation I wonder if there are other reasons as well, such as wanting to get an away from being seen as HyperCard’s descendent?
If that is the case then why not simply rename these for example card = layout and stack = window. It’s a great thing to have this ability not only for layout but for coding purposes as well. FileMaker Pro thrives on multiple layouts per window. The equivalent in XOJO (adding a Page Panel control) is a real pain because it doesn’t natively cater for multiple layouts per window. Namespacing with multiple panels is a nightmare.
If Create is to be the long term destination for LiveCode and Classic is the temporising measure its name suggests it is, then flattening everything to 1 card = 1 stack = 1 layout seems unwise. But maintaining 2 (or maybe 3) separate IDEs long term also seems unwise…
Thank you for letting us know this is still under discussion, but as this is truly a key feature of LiveCode it would be great if we could hear more about this and what the officially planned direction of travel is…
We have no plans to remove cards and stacks from the Create platform (ever) and they will always continue to work. You can continue to use them if you prefer. I will talk to the team about including some better ways to ensure they remain easy to manipulate in the IDE.
For new users we are not encouraging them as a concept. It was not an easy decision however here are some of the reasons for it:
Today’s audience is universally familiar with the concept of a “layout”. So to have cards and stacks we have to introduce another, unfamiliar metaphor.
The term “card” is now used in the Material theme to mean something entirely different to our much older use of the term. Cards – Material Design 3 Material is a major design standard today (which we are implementing in the platform) and for better or worse, new users are far more likely to be familiar with this use of “card” than of our decades old meaning for it.
The metaphor is of far less use today than it was when cards and stacks were (primarily) used to store multiple records in a data store. Create has data binding to external data sources and navigating between cards has no relationship to data storage.
You can do everything you can with cards and stacks with layouts. Navigation can work in exactly the same way - at present you can use “go in window”, in the future we will tweak the syntax so it performs just like navigating between cards does now by default. So nothing is going to be lost here.
Internally implementing layouts (internally as individual stack files within a project) has advantages when it comes to doing clever things with data transfer. We can be much more granular with what we serve up in lower bandwidth environments.
With the introduction of the project concept (which is managed by the IDE) we have a natural and easy to explain home for libraries and other things that need to set more broadly accessible in the message path.
I imagined the reasons were as you say, which is why I was wondering if it would be perhaps useful to change the concept “stack “ to “window”.
A window can then have multiple ”layouts” (ie cards).
I think that would be an easily digestible nomenclature for new users, and not incompatible with concepts from other languages. While maintaining the goodness of LiveCode.
Maybe I’m older now and don’t represent the new users but when I think I need something equivalent to what a stack is, I’m thinking “window” not “layout”.
I think the current term “layout” is misleading actually. The implication mentally is that “this is one entity with many layouts”.
But the current definition of “layout” in LCC is basically a window that can have different window properties (eg rect, colours etc). It would be great if that particular window could have its own collection of layouts. If needed. It just use the window as is if there is no need for layouts.
But that is my personal view and maybe I’m out of touch. But as far as I know, the concept of “window” is probably a more representative translation for LC “stack”?
Otherwise it messages “windows in LCC are called layouts” which is probably stranger to new users of LCC?
If you take a look at other web based low code tools (Microsoft PowerApps for example), they do have similar concepts. PowerApps uses the term “screen” for “layout” rather than “window” and it allows you to build a GUI with drag ‘n drop components similar to Create. Interestingly PowerApps also has an “App” level container for want of a better word, where you can establish app properties, constants, variables, dynamic collections etc. All the screens created in PowerApps are children of the App level container, so in one way this is similar to Livecode Classics Stack and Card structure. I’m sure other low code/no code platforms use their own terminology too which would indicate there’s no hard and fast rule on what names to use.
Personally I prefer using the term “layout” for each of the screen views you create in an LC Create app - it makes sense to my brain. However I must admit to being somewhat confused that a layout is the equivalent of a stack and not a card. It appears that Livecode have some good reasons for this change of tack… maybe Kevin or the team could share some more details with us so we understand why and how best to take advantage of using the “stack” approach to building multi-layout apps in Create?
thank you for the infos about crads/stacks/layouts!
I will only get my license at the end of november, so I am reading here to mentally prepare for the change.
However I am having a hard time to wrap my head around the “layout approach”.
After 25 years of working with MC, RunRev, Rev and LC it is hard to NOT think in cards/stacks.
I was thinking “layouts” could be some sort of GROUP, but seems like this is wrong!?
Question, how do you navigate (?) to a layout or just put it onto the screen:
GO TO layout “xyz”
show layout “xyz”
or what?
Been unable to find almost any time to code at all in recent months. But I’m pretty sure that navigating layouts is the same as navigating stacks and you can probably refer to layouts with the “stack” keyword, although I’m unable to check…
