On Tue, 17 Feb 2015, Rodolfo García Peñas (kix) wrote:
thanks a lot for your reply. I will try to reply you later again, with more info.
No need to hurry, I have no time to look at it or work on Window Maker so I could only share my thoughts in the hope it might help. What you propose is probably similar to gtk where there is a creation phase and a realize phase.
I'm still wondering if the added complexity of splitting to abstract objects and window system specific ones worth it? What does it bring apart from more complex code? (OK we could be window system independent but I don't think we really need that in a "Window Manager for X".) Shouldn't the split be done in the initialization functions instead to make object creation and tying it to a screen separate actions?
I mean couldn't the same be achieved by having a way to unmap and disassociate an object from a WScreen and add it to another? Isn't this enough to achieve screen independent objects that could be moved to another screen? Could this be implemented by two new methods on existing objects instead of introducing a new abstraction layer inbetween for everything? Some of this may already exist but probably it's part of creating the objects now so the only think needed would be to split it off into another method. (Although some objects like pixmaps need to be created on a screen so moving them to another screen would mean effectively destroying and recreating them so this independence only makes sense for higher level objects like windows but not for lower level ones like decorations.)
Another comment unrelated to this but reminded by your message mentioning WScreen and virtual_screen: I'm also not a big fan of partially renaming functions and breaking any conventions and creating a mess of mixed conventions in the same code. I mean previously the naming convention was similar to OpenStep but being pure C the objects were denoted by their names only: e.g. WScreen for object with object methods named wScreen*. (functions start with lower case while object types start with capital letter). Other funtions not being object methods were usually just named someFunctionName. (This was not always followed but one could more or less tell the idea and intended object separation by looking at the names.)
Then someone decided for no good reason other than personal preference that CamelCase is evil and better use underscore names instead like gtk for example. This could be OK if there was a mass renaming and folowing some convention because even in gtk there's a common prefix for all object member functions and names are not just invented randomly. If the renaming has been done object by object keeping some logic to show the object relations it would have been acceptable but what is happening now is that the object oriented design starts to disappear with names becoming a random mix of CamelCase and underscore_separated without following any convention.
I have no strong feelings for any of the conventions but I'd prefer to keep some consistency and follow one or the other but not mix them and keeping one convention at least within one object. So unless a whole object is converted to underscore names keeping its naming consistent, it's better to keep the previous naming convention. It also can be considered to keep the CamelCase names for objects and only rename non-object functions to underscore names to have a clear separation of objects and other helper functions or any other sensible approach other than messing up naming by partially renaming some functions while keeping others until noone can see what functions were meant to be members of which objects.
Keeping the object oriented design also helps with keeping separation between objects and to know their relations. It makes it simpler to know what is handled by which set of functions and while there is no language support for it in C one can still keep this separation and not mess up by accessing another object's data from a foreign one but use approprite member functions for that. This takes some discipline and is already broken in a few places but it would be better if new patches would keep or fix this design rather than messing it up further.
Regards, BALATON Zoltan
