The WS classes are very difficult to work with IMO. I've used them and they are just messy, as in difficult and not exactly straight forward or intuitive. I'd have to look them over again to put my finger on exactly what's hard to use about them, but I distinctly remember having unnecessary trouble with them. With regards to code size I believe the way it works with WS classes and how it could only work with static linking is to make use of defines and conditional uses that is hopefully limited to only one place.
The way I image interfaces working is that they serve as contracts. One master library unit file would define the interfaces which represent the entirety of every function of a window manager. That is managing windows, handling the mouse, keyboard, painting, and some common ideas such as image lists, canvas, fonts, printing, then a platform implementor writes concrete implementations of those. Native control interfaces for widgets such as TEdit, TButton, TTreeView, TPageControl would be independent interfaces defined in a cross platform control interface unit, but registered by name with the window management so that their function could be loaded by matching a window class name in the Params of WindowManager.WindowCreate(). Anyhow, to change anything now would mean a complete rewrite and at this point it would be a huge undertaking to say the least.
-- _______________________________________________ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus