On 2018-08-05 01:14, Mark Wieder via use-livecode wrote:
I do realize that. But now that we've opened that can of worms I don't
think we can just go on ignoring it. And the difference between LC
script-only stacks and C source files is that you don't get to
distribute a single compiled object in LC... you end up with a
mainstack and several text files to distribute, and they need to stay
together and in the same relative position. It's messy.
Yes - however, as @Brian already pointed out in another message which
distracted me in terms of a technical point of performance rather than
the more important' high-level point he made...
Perhaps 'Show IDE Stacks in lists' (or whatever it is called) has
become far far too blunt an instrument...
What I was thinking.
For example, the PB could offer a new 'top-level' - which is project.
A project being defined by a set of stacks which share a common name
prefix...
Well, when the PB was first proposed, that's where I thought this was
heading.
Yes - 'projects' are a concept which LiveCode needs - although like lots
of things its a case of 'when' rather than 'if' (even if the 'when' has
been and still is measured in rather long timecales!).
One thing I'd like, since you're asking (place this in the 'watch what
you ask for' category) is to be able to use script-only stacks as
substacks. That way I could edit them with a text editor and still
work with only a single unified object. And the PB would hide the
component stacks within the mainstack until I chose to examine them,
the same way that substacks now work. Obviously there are script-only
stacks that would not need to be substacks, but that's no different
from the way stacks and substacks work now.
I think modifications to the PB and a stricter naming convention for
stacks could solve most of the problems which do exist here.
After all it doesn't matter if (in memory) all stacks are in a 'flat'
list (its up to the engine to optimize lookup) really - what matter is
the view of them which is presented in the IDE - which is almost purely
a PB concern.
The other side of this, is what Brian hinted at - when building for
distribution script-only stacks which are essentially 'children' of some
component should be built into a single stack with substacks.
This is essentially what scriptification and descriptification do: we
have code for this in the repository... For example, there is an
embedded UI stack in the engine which deals with licensing (the one
which really does anything is in the livecode-private - which you all
never see as that's the commercial side of the code). The environment
stack (whether public or private) exists as a collection of script-only
stacks and a single binary stack which holds the UI in the github
repository, and when building the engine those collection of files get
turned into a single mainstack.
This could be done for all the IDE components which are composed in this
way at the point we build the distribution - it would cut down the
number of mainstacks considerably, and again perhaps mean 'show LiveCode
UI elements' actually does the same as it did before things started to
be scriptified.
The other place this could come to bear is making the S/B (or some
variant there-of) not only work to produce an application, but also a
'component/extension' - i.e. a distributable 'compiled' (in some sense)
form of a collection of script only stacks which were much more easily
distributable.
The only thing we would lose by using this kind of process on the IDE
would be the easy ability to 'monkey-hack' the IDE - although not
significantly - it would just be slightly harder to pull out the changes
to submit as a PR if you wanted too...
However, that being said - we then just add a way you could just pull
the IDE repository and have it use an engine from a pre-installed
distribution.
Internally we tend to edit the IDE from engines built from the engine
repository - there's various redirection logic in the IDE and engine, so
that when a 'build-from-source' engine is run, it looks to see if it is
a github checkout, and if so loads and runs the IDE from the IDE
submodule checkout.
So upshot - in reality - we have most of the code and mechanisms already
to at least get a long way to the ideal (which is a much more
structured, built-in component architecture), it is 'just' a case of
plumbing it in in some of the ways outlined above. Admittedly, not a
small project, but certainly not one which would needed to be started
from ground-zero.
And btw, thanks for your input on this list. On a Saturday even. Much
appreciated.
Hehe - well it is a working day for me today, and tomorrow and the next
week - I'm currently in Dallas, Texas, for FileMaker DevCon.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
