[Laszlo-dev] couple of things in kernel/swf depend on LzView
henry.minsky at gmail.com
Tue Jun 20 12:03:15 EDT 2006
I don't exactly know how DrawView should be structured -- should it be a
portable skeleton of a file, which
makes all calls into sprite drawing APIs, and all the lower level draw
methods would be on some subclass of sprite, or on LzSprite itself?
It is only an accident of implementation that there
are a couple of classes for runtime library loading that are built using
LzView; that was done to piggyback
on the runtime loader machinery that LzView uses to load resources (e.g..,
LzView has a sprite , which is what now implenents a loader). Maybe I'll try
rewriting the library loader to try to use LzNode instead of LzView. There
shouldn't be any restriction against an LzNode having a sprite, should
On 6/20/06, Jim Grandy <jgrandy at openlaszlo.org> wrote:
> I'm OK with this for now. I do want to make sure we have a coherent
> kernel API, so please be careful with the dependencies -- a platform-
> specific extension outside the kernel should be an extra feature
> (like drawview or contextmenu) rather than core functionality.
> Put another way: imagine what it would take for a third party to
> write a new platform. Can they write the kernel, debug a limited-
> feature-set LFC, and then write a set of platform-specific
> extensions? Or do they have to code both the kernel and a set of
> interconnected extensions to bootstrap their platform?
> On Jun 20, 2006, at 6:18 AM, Henry Minsky wrote:
> > OK I propose then that we create a lfc/data/platform/swf
> > subdirectory, and put the LzLoader stuff in there
> > DrawView should go into a lfc/views/platform/swf directory also for
> > now, although it will get factored at some point.
> > ContextMenu should also be there, I don't know when we'll get any
> > kind of workaround for DHTML for that feature.
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Laszlo-dev