Dmitry Boyarintsev schrieb:
LCL is not going to be network based, for one simple reason - it technically cannot - too much is bound to low lever WinAPI-like functions.
I'd say that the problem resides in the adaptation of the (given) VCL interface to multiple widgetsets. Some widgetsets fit better into this model than others do.
We could try something like Borland tried to achieve with CLX, and construct an subset of the LCL functionality that makes less assumptions about window/layout managers and built-in functionality of the basic controls. Unfortunately it's not sufficient to simply *not use* features not available in a certain (HTML...) widgetset, as long as the LCL controls use (and consequently rely on) such features internally. One solution could try to "outsource" specific features, i.e. move them into dedicated classes which can be overridden as suitable for every supported widgetset. This would allow to fully disregard properties or other programmatical requests internally (in the dumb base classes), without causing consequential errors. But it looks impossible to me, to separate all problematic functionality from the existing LCL. A complete refactoring would be required (too complicated), or a restart from point zero (who would be interested in doing that?).
DoDi -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
