Axel Dörfler wrote: > Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote: > >> Now, I'm very curios in your opinions. What do you have to say? > > > Considering the fact that write locking is only needed when something > on screen is changed, I think we can safely switch to what Stephan has > in mind (or you have for the Desktop :-)). I can't really see any > advantages of the current design in terms of speed, I only see that it > complicates things unnecessarily. I partially agree. I read some articles about how a software should be written for multiple CPU performance. I tried to apply a couple concepts here. > Also, IMO RootLayer does too much. This one I agree. > For example, why does it own the Workspaces objects? The answer is simple. Because RootLayer "emulates" its children. That's because of the Workspace feature. > While RootLayer may need to react on changes made > to them, I can hardly see a reason why it encapsulates them and hides > them from others. The window order is not something that is easily manageable. For that reason I think I will make private all WinBorder-related methods. What would remain, would be only color and resolution methods. (You can consider Workspace as an inner class of RootLayer). > Ideally, RootLayer would only care about compositing and clipping, IMO. Mmm, if it is that we should go with the names, RootLayer should have nothing to do with clipping. RootLayer was created so that we had a "surface" to start from, and it always had WinBorders as "children". The role of RootLayer was/should_be to manage the proper window order - the window manager. Composition and clipping should go elsewhere. A new class/module. bye, Adi.