I will consider the LwVCL library ideas mostly in Java terms since this is the basic version (J2SE LwVCL) where all new features and components were born.

LwVCL has layered architecture to make the library independent from the concrete platforms and languages. There are three levels:

• Native Level. The level presents native objects like Java AWT, WinForms in the case of the .NET platform. The level doesn't belong to the library, it is considered as a graphics canvas and native events stream provider.
  
  
• Adaptive Level. The main purpose of the layer is to hide the native specificity from the LwVCL level and make LwVCL components free from the native stuff. This layer contains a set of objects supposed to be re-implemented for any specific platform or language.
  
  
• LwVCL Level. All the library components, managers, and everything that you meet during LwVCL programming belong to this level. This level should be independent from a concrete LwVCL implementation.

The image below shows the library layered architecture:

LwVCL component is an interface intended for achieving the following:

• To make the library components set more abstract and independent from other platforms and languages.
  
  
• To reduce in some cases system resources usage and improve the library performance. (especially it is actual in the case of Java AWT usage).
  
  
• Basic lightweight components, like canvas and panel, can be easily re-implemented to attain desired aims.

Memory usage minimization. The library widely uses shared object. The idea of shared objects suggests that some instantiated object can be re-used safely by different components. In this case, it is not necessary to create additional instances of the object. For example, checkbox skins are the same for all created checkboxes. Such an object is called static or shared. LwVCL provides the possibility to store and share static objects.

Events handling mechanism. There are a lot of situations when you should listen to all originated events, or hook child component events, or make a child component transparent for the given event in your application. For such cases, the library provides the following events handling features:

• Controlling events handling for child components. You can make a child component transparent for some events. The feature is useful for development of composite components. For example, a button component is a container whose face is defined by child components (images, labels, etc.), but the child component should not handle events since this is the button component that knows how to react.
  
  
• Listening to different events. You can use an event manager or listen to some child components events by implementing a special child events listener interface in the parent component.
  
  
• Getting event by implementing an appropriate listener interface. It means you don't need to register your listener after it has been implemented. The notion concerns only the input events, like mouse, key, focus and so on, inside lightweight components. Furthermore, it is not necessary to have the listener support inside lightweight components, the feature makes the development more simple and resource-saving.

Mandatory layout managers usage. It doesn't mean that you cannot layout components by using specified (X, Y) coordinates and given width and height. For that purpose, the raster layout manager is provided in the library. The mandatory layout usage makes an application behavior more predictable.

Flexible and customizable.

• The library component supports the MVC (Model-View-Controller) concept. The data models, their rendering, and event handling are separated.
  
  
• Most of LwVCL components' views can be easily customized with the "skins" you prefer.
  
  
• The event handling, focus management, painting mechanisms and the like can be customized. For that, purpose, there is a set of different manager classes (focus manager, paint manager, and the like) to be re-implemented.
  
  
• The layered desktop can be used to develop your own layers. For example, LwVCL implements a special window layer where all internal frames are resided.
  
  
• Layout managers provided by the library are more abstract than Java AWT managers. The managers are not LwVCL component oriented and can be re-used to layout any objects that implement special interfaces (Layoutable and LayoutContainer).