KDE-Forum.org

• There should be 6 discrete/well-defined layers to the KDE desktop.

= = Description of the 6 layers:
1.) Screen. This is the layer at which a wallpaper, movie, screensaver can be selected for the background "Desktop."
2.) Desktop. This layer contains the icons layout for the desktop.
3.) Deskies. Desktop widgets. Widgets that you can see/use without bringing up a hidden layer.
4.) Panels. This is for the menubar/panels/docks.
5.) WorkSpace(s). This is where the applications windows go and handles virtual desktops.
6.) Dashboard. A hidden layer which becomes visible by key command. Same as Deskies only hidden.

= = Layer Order (From bottommost to topmost, what's on top of what...)
1.) Screen
2.) Desktop
3.) Deskies
4.) WorkSpace(s)
5.) Panels
6.) Dashboard

= = Startup Order/Priority
1.) Screen
2.) Panels
3.) Desktop
4.) WorkSpace(s)
5.) Deskies
6.) Dashboard

• These layers should be controlled separately and be modular. For instance, the Screen module could be as simple as defining a static image/wallpaper to having a Screen module that could handle making the desktop into a live screensaver. But a Screen module should never go as far as to support widgets as that function is explicitly defined as the job of layer/module 3. An appropriate expansion of Deskies and Dashboard would be to support Google Gadgets, or OS X Widgets, in those defined spaces along with native Deskies widgets.

• Layers/modules can have interaction between each other and with other applications. For instance, a double click on the Desktop layer folder icon could open the folder in your default file manager, which is handled in the WorkSpace(s) layer of course. Or a Deskies widget could turn on-off Panel hiding. Since Virtual Desktops are handled in the WorkSpace layer, it can have the action of changing your Screen background image.

• WorkSpace(s) is where all the application windows will go, and can spawn itself in the fashion of virtual desktops. The WorkSpace module may not have any virtual desktop capabilities or it may be as advanced as "Spaces" is on OS X Leopard.

• A single GUI KDE application should be created to handle user preferences of importing modules and selecting the default modules for the different layers.

Note: While I do not think that the common KDE end-user will be using anything but the default modules (which I expect to be sufficiently flexible and advanced for most) this separation has other benefits. For one, portability, as a different KDE modules can be created to integrate with the host OS's native capabilities for use instead of the Linux KDE modules. It is also easier to maintain well defined smaller modules as well as debug, upgrade, and expand upon them. Stability is also huge, as a crash in any of these modules will not cripple the user, and the system can auto-restart the module so the user isn't left hanging.