On Tue, Feb 18, 2003 at 05:31:34PM +0100, Per Olofsson wrote: > A border around the whole dock? Like the tabs?
Yes. > Which means I should keep the dockapp list, since the dockapps will be > children of a WScreen? Even if I can store data in uldata I still need > to be able to iterate over the dockapps. The dockapps will be children and managed by the dock object because it is a window. WRegions contain mgr_next/mgr_prev links for the manager to use with its list(s). FOR_ALL_MANAGED_ON_LIST and such macros are provided for iteration. > relationships. Which makes sense since only a managing relationship > shouldn't impose any restrictions on window geometry (which is now > circumvented with WWinGeomParams). It is is the manager object that imposes restrictions on the managed objects; an object need not know of its children that it is not also managing. > But does this mean that there will > be separate lists for windowed and windowless (managing) children of a > WScreen? Or did I get everything wrong? :) All children of an object are on the WThing children list as they are now. However, objects like a WWorkspace don't have children anymore. Instead, such objects keep an implementation dependent list of the parent's children that they manage (and the parent does not). Example: (let's forget viewports for now to make things simpler) screens have workspaces and frames and whatever as children. Screens only manage the workspaces (and full screen client windows). Workspaces manage frames (that are children of the screen). Frames have client windows as children and also manage them. A dock window would be an _unmanaged_ child of the screen it is on for now. Later some kind of WFloatingOnTopLayer manager object may be implemented (just a PWM workspace of sorts actually). -- Tuomo
