Let me first try to answer a couple of concerns raised here and in other posts.
We aren’t taking anything away - stacks/cards will still work the same in Create as they do in Classic - we just have some more work to do to make them be accessible properly (i.e. if you open a stack, then you get a stack node and card nodes underneath in the project browser - just like you get in the project browser in classic). If you want to still use that model then you can - the Create model is built on what LiveCode already has - the widgets are not tied to the layout concept, nor are any of the libraries.
Currently, it is true that a layout is implemented as a stack with a single card as if the card is the primary object - this is not yet an engine enforced thing but it will be - including ‘layout’ being a chunk you will be able to use in syntax. Right now if you want to display a layout in script, rather than using an action, you’d use ‘go to stack in window (the short name of this stack’, but at some point this will become ‘go to layout ’, or ‘go to layout as modal’, or ‘go to layout in a new window’. [ Internally, a layout will still be a stack with a card, its just the engine will hide the bits which shouldn’t be user accessible - and in the interim if you create a layout which is not by definition a layout when that engine change comes, it will just revert to appearing as a stack, so you won’t lose anything ].
In terms of application logic, globals, constants. Globals are as they are now - all of this is still running in one engine instance, so globals are shared amongst all scripts which reference them. Constants are only script-local so that’s not different. Code which is to be shared amongst multiple layouts should go in a library. Further, there will be a ‘top-level’ ‘application script’ at some point - I mention this because I believe J9V6 had an unfortunate encounter with ’systemAppearanceChanged’ recently - that is an application level message which gets sent to the ‘current card of the default stack’ - at the time the event is generated by the OS - this means to handle it reliably you have to do so in a backscript or front script… Said application script will be a place for that, and the other half-dozen such things which currently exist.
Now for new concepts…Perhaps the best way to think of the new concepts (ignoring implementation details) is to deconstruct the current model LiveCode has.
Currently, you’ll probably start by creating a stack - you’ll probably create multiple cards, one for each ‘screen’ which is displayed to the user. You’ll probably put your application logic in the stack script, to be shared with all the cards (screens).
Your app grows, you need a dialog to popup - obviously you can’t use a card in the main stack of your app as only a single card can be open at one time in a given stack, so you create another stack for that dialog. Of course you need to share the application logic (currently in the main stack script) so you probably make the dialog a substack (being careful to ensure that the substack’s script has the main event handlers in it so they don’t end up triggering those in the main stack script).
All well and good - you now have a few screens, the dialog you want and it works as you need. You can easily use the standalone builder to deploy your app - it’s all a single stackfile, you pretty much just target the platforms you want, set a few settings and deploy it. It works.
So now your app needs more stuff - so you add more cards and dialogs - the main stack script grows and grows to contain all your app logic which is shared by all the cards and dialogs.
At some point you realise you actually need one of the screens (cards) in your main stack to sometimes be a modal dialog, so you refactor that as a sub-stack, and then have to go back and modify code which displays it as not a modal dialog to use ‘go stack in window’. This then breaks your app as you main stack when showing that screen (not as modal) - but you can’t figure out why so you give up on that (‘shared code’) approach and just copy the card - so you then have two copies - one in a sub-stack which you use as the modal, and one in the main stack which you use when its not modal. (We’ll ignore the fact that subsequently you spend an inordinate amount of time making sure those two things are in sync…)
After a while you probably start to find this slightly unmanageable - the whole tree is under one node in the project browser - the main stack script has 1000’s of lines in it - you find yourself constants unfurling and furling up the branches int he project browser, and scrolling up and down in the script editor.
At a certain point you decide you really need to do something about this. So what you probably do is separate out all the substack dialogs as separate stacks, and refactor the main stack script as several library stacks.
You do this in the IDE and it all works fine - your stacks are all in the same folder on your computer, the engine’s method of finding stacks by name when they are not in memory means you don’t have to change any code.
Pleased with your nice cleanly refactored app which you are much happier with in terms of ease of working on it - you try to deploy. The standalone does not work even on the platform you are working on.
You then realise you have to either tell the standalone builder about all the stacks which comprise your project, or use the stackfiles property - you use the stackfiles property and you get a nicely deploying app again - on you Mac or Windows machine at least.
You try a Linux standalone - and it breaks. You scratch your head - and then you’ve made an error in the filename in the stackfiles property - you’ve used all lowercase when the file on disk is actually mixed case… Doh - Linux filesystems are case-sensitive. You fix that and things run again - yay!
This entire process is not straight-forward - it tends to be learnt organically through trial and error - its easy to forget (after working with a tool over many years) how much knowledge you have accumulated to use it, and how you’ve learned how to do things to not cause issues in the future (indeed, I strongly suspect every person who has contributed to this thread so far structures their apps differently!).
I chose the above example because it highlights several issues which the current LC model has - in particular, the rigidity of the card/stack model in terms of its relationship to displaying screens to the user (which is, at the end of the day, the primary need of any app which presents a user interface), and the lack of any prescribed project structure.
So how do we solve this in Create? Quite simply - we take the critical abstractions that the above really needs clearly exposed - projects, layouts and libraries. Note that I don’t include windows in this - windows are purely a means of displaying a layout - nothing more. What they are, and how they behave is defined by the environment the app is running in - sure apps need to be able to tweak that display sometimes, but most of the time you’ll either want to show a given screen to the user or popup one up modally (or, if in multi-window environments, show a screen in a separate window).
In this mind-frame a project is the collection of all the things needed to run your app - the screens (layouts), the libraries, the images, the settings needed to deploy to each platform, the themes etc. - all known about by the environment so you don’t have to worry about fettling with things.
We have a layout which is a collection of controls which are to be displayed together and presented to the user to interact with. On desktop, Layouts could be displayed in a top-level window, they could be in a modal dialog, they might temporarily be displayed inside an existing window on desktop - it doesn’t really matter - as they are not specifically tied to a ‘stack’ (the current thing which represents a window) they can be any of these things at the time they need to be.
We have a library which is basically just a collection of handlers which is accessible to all parts of the project.
With this model, the above rather protracted ‘learning’ process becomes this:
You start a project in create.
You create a layout and very quickly have something you can test/run and display the first screen.
You add more, having a modal dialog is the same as having any other screen - you create a layout and use a different action to show it as modal.
You don’t have to refactor your shared application logic at any point, because it was obvious that you should put that in a library at the start (it was obvious because clearly a layout is a top-level thing and the code there should be specific to a layout so you are led directly to looking for something which has greater scope - i.e. a library).
When you realise that you have a layout which needs to sometimes be modal and sometimes be part of the main window your app displays - it doesn’t matter. It’s just a change to the action which displays it.
At any point you want to test your app, you pretty much can just deploy it and test - the project you’ve created knows everything about your app so you aren’t going to forget anything.
Of course, the above is the goal and is not necessarily where we are in the Create journey right now - as it stands, we are still working on the deployment side and we are still working on the library side.
