MESSAGE
DATE | 2015-02-25 |
FROM | Paul Robert Marino
|
SUBJECT | Re: [NYLXS - HANGOUT] Fwd: Re: Wayland support?
|
From owner-hangout-outgoing-at-mrbrklyn.com Wed Feb 25 14:57:11 2015 Return-Path: X-Original-To: archive-at-mrbrklyn.com Delivered-To: archive-at-mrbrklyn.com Received: by mrbrklyn.com (Postfix) id 3179B161162; Wed, 25 Feb 2015 14:57:11 -0500 (EST) Delivered-To: hangout-outgoing-at-mrbrklyn.com Received: by mrbrklyn.com (Postfix, from userid 28) id 22056161168; Wed, 25 Feb 2015 14:57:11 -0500 (EST) Delivered-To: hangout-at-nylxs.com Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by mrbrklyn.com (Postfix) with ESMTP id 8B6F7161162 for ; Wed, 25 Feb 2015 14:57:10 -0500 (EST) Received: by mail-oi0-f48.google.com with SMTP id a3so5343762oib.7 for ; Wed, 25 Feb 2015 11:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nixQSgXc4+u71Y6UavNaJFV9Gig5zdpzXpizUXGHvUg=; b=BpVoFY/aNWfE9UMhhB8AAHZiTwAnfdkg2Vf9tK4z2Jy/eEwWjX4sKZDjkY/DZvZkiI YbAhV7AFrBERyE5fsKPPPYeDp9PwEnLoCJyhihP0ATmS9I3oRPZ024H83m9OlcvbjOp7 0nm3Kna+mNrEVtYLSgjFdAuWl0tY/pPJqlCHRP0/9oSvULKzuimlpiIwxdjpfmTlcHYy cuqjIIIay1gczRA6h6wDiWTZjx9XOr1DvRJFmTMCovNeQTnklgVjXJEFHANgKqwo3ayv zmYpK59PhHIdkyJKGf+budY6RWWVmN/d18C6x1UZW66kaQk7rLBbC+0HjESi9Hs54p1v J30Q== MIME-Version: 1.0 X-Received: by 10.202.193.214 with SMTP id r205mr3226301oif.63.1424894229474; Wed, 25 Feb 2015 11:57:09 -0800 (PST) Received: by 10.202.108.143 with HTTP; Wed, 25 Feb 2015 11:57:09 -0800 (PST) In-Reply-To: <54E3FE76.9080402-at-panix.com> References: <54E3FE76.9080402-at-panix.com> Date: Wed, 25 Feb 2015 14:57:09 -0500 Message-ID: Subject: Re: [NYLXS - HANGOUT] Fwd: Re: Wayland support? From: Paul Robert Marino To: NYLXS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-hangout-at-mrbrklyn.com Precedence: bulk Reply-To: hangout-at-nylxs.com [NYLXS: HANGOUT] X-BeenThere: hangout-at-nylxs.com X-Mailing-list: hangout-at-nylxs.com Precedence: list List-Id: NYLXS General Discussion Forum List-Unsubscribe: List-Archive: List-Post: List-Help: List-Subscribe:
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=C3=ADa Pe=C3=B1as (kix) > CC: wmaker-dev-at-lists.windowmaker.org > > On Tue, 17 Feb 2015, Rodolfo Garc=C3=ADa Pe=C3=B1as (kix) wrote: >> thanks a lot for your reply. I will try to reply you later again, with m= ore >> 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 propos= e > 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 apar= t > 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 of= f > 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 make= s > 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 les= s > 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 objec= t > member functions and names are not just invented randomly. If the renamin= g > 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 o= r > fix this design rather than messing it up further. > > Regards, > BALATON Zoltan > >
|
|