MESSAGE
| DATE | 2015-02-25 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] Fwd: Re: Wayland support?
|
X11 is one of the really beautiful things in the world and I have no
idea why anyone would want to kill it.
When I read the reasons I just cringe at the misunderstand and the
misinformation about a desktop is suppose to do.
Ruben
On 02/25/2015 02:57 PM, Paul Robert Marino wrote:
> There are some really bad desktop/mobile device assumptions in the
> design. namely that Xclients are only utilized in GDM not even
> thinking about X Forwarding over ssh which almost every sysadmin I
> know does several times daily.
> Now there is a concept of using XOrg as a sort of X11 proxy server but
> as soon as Gnome and KDE are locked into wayland that means no
> application which utilize the KDE or Gnome API's will be compatible
> with X11 forwarding any more. furthermore it has a lot of implications
> for VM's and may break Spice which wouldn't make Red Hat happy at all
> because its one of their few trump cards in the financial and video
> streaming/editing virtualization markets.
>
> I'm not really sure if the developers of Gnome. KDE and Fedora really
> truly understand the impact of this.
> By the way this is also why its important for most shops running RHEL,
> Centos, Scientific Linus, etc.. to have at least one test server
> running the latest greatest Fedora at all times. Once its in RHEL its
> a done deal and any complaints will just make Red Hat dig their heals
> in deeper on the subject. If you catch these things early in the
> fedora implementations you can have some pull on influencing
> modifications or rejecting it before it hits your production
> installations. Plenty of people complain about system.d now thats its
> in distros they consider production ready; but where were they when
> Fedora put it in a few years ago? The answer is many of them were
> blissfully oblivious because they never pay attention to Fedora even
> though it is and has always been hugely influential testing ground for
> these kinds of sweeping changes.
>
>
>
>
> On Tue, Feb 17, 2015 at 9:52 PM, Ruben Safir wrote:
>>
>> 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
>>
>>
|
|
