MESSAGE
| DATE | 2015-02-17 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] Fwd: Re: Wayland support?
|
It seems that Wayland is about ready to be released and there is a bit
of a conversation on many mailing lists about it. Since I know we have
more than a few wmaker users, I just wanted to forward this one
mailinglist post to the list to give a sample of the discussions. It
seems that wayland has no independent WM like X11 does and this will be
a problem going forward for many, if not all X11, window management
systems. I don't completely understand the differences between X and
Wayland but a feww things have become clear, which is it have no
networking backend and it is closely bound to video drivers with few
abstractions.... and it will be default soon on Fedora...
I'm willing to hear opinions.
Ruben
-------- Forwarded Message --------
Subject: Re: Wayland support?
Date: Tue, 17 Feb 2015 23:34:59 +0100 (CET)
From: BALATON Zoltan
To: Rodolfo García Peñas (kix)
CC: wmaker-dev-at-lists.windowmaker.org
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
|
|
