OK, it's getting clearer now.

On Mon, 9 Sep 2013, Rodolfo García Peñas wrote:
My aim is that the Clip, Drawer and the Dock will be the same internal object, but if it is the Clip, then it has some properties active and if it is the Dock, others. Same for the Drawers. Then the code is easier.

So you want one single class that can be configured to behave like the Dock or the Clip or a Drawer? Wouldn't it be too complicated? Wouldn't it be a better object oriented design to have the common code in an abstract class and have the three specialised objects inherit from it and add/override what is needed?

The last week I asked about why in the screen.c file, some code initilize more than one Dock. The reply was about the possibility of having multiple monitors, with different workspaces, and then different Docks.

Maybe in a multiheaded X config with different screens. I never tried to run Window Maker on such a config so I don't know about that.

Then, the code will be something like, if we have one or more workspaces, but all uses the same Dock, no problem, we have one Dock object in the Workspace[0] and the other workspaces has pointers to that Dock. If we have multiple workspaces, with different Docks, then, we have different objects.

I think you mean instances of the above classes and want to share a single instance between multiple work spaces. Then I understand this.

because currently the code in the wmaker start process binds the dock to the screen, not to the workspace, and I need rewrite some code to change the wmaker start process to create the screen, create the workspaces with the docks, and then bind them. I cannot do that yet, because I have problems with the dock menu (they need the WScreen struct, and I need indpendency with the screen to do it).

Can't comment on this. But I just noticed that the Dock menu has an "Add a drawer" item but the Clip menu doesn't. Is there a way to add a drawer to the Clip?

Regards,
BALATON Zoltan

Reply via email to