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 there?
On 6/20/06, Jim Grandy <[EMAIL PROTECTED]> 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?
jim
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.
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
