MESSAGE
| DATE | 2015-03-01 |
| FROM | Paul Robert Marino
|
| SUBJECT | Re: [NYLXS - HANGOUT] Fwd: Re: Wayland support?
|
Well I suspect the changes have a lot to do with the classic issues
the needed additional complexity needed for network based graphics
engines vs directly using the local frame buffer.
Also if you look at its original design it was clearly stated that it
meant for mobile devices.
there is also probably an added misconception that most Linux users
are running servers in the cloud which abstracts the local console via
a web GUI. while these methods work often times I find XForwarding
faster smother and more reliable.
All I can say is when its first deployed in Fedora try it and complain
about it immediately if it starts breaking XForwarding over ssh.
On Wed, Feb 25, 2015 at 11:37 PM, Ruben Safir wrote:
>
>
> 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
>>>
>>>
>
|
|
