Announcement

Collapse
No announcement yet.

Client Side Decorations For Wayland

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Client Side Decorations For Wayland

    Client Side Decorations For Wayland

    Phoronix: Client Side Decorations For Wayland

    Besides OpenWF support in Wayland being talked about and on the roadmap, another item that's been hotly discussed the past couple of days is about client side decoration support for the Wayland Display Server...

    http://www.phoronix.com/vr.php?view=OTQxMA

  • jrch2k8
    replied
    Originally posted by Drago View Post
    I am all for CSD.
    i don't believe decorations should be a problem of wayland beyond icccm-extensions/wm-spec. configurable decoration should be a job of your user level toolkit like it is now, is madness handle the decoration drawing inside wayland or X11.

    about client side decoration this can be done with plugins and some apirework in kwin and metacity but so far no one seems interested but it should not be that hard to implement

    wayland should protocolize and render only otherwise in few years wayland will be a mamut of useless extensions like X11, i mean wayland should protocolize stuff like network session (only transmit process not actual rendered data), windows manager protocol (not mess with the decoration), render protocol (not widgets, components, label, images. try to do an app in motif and you will see my point, motif is an monstruosity), etc and the actual process should be client side job of the toolkit/desktop you use which help a lot to get more fresh ideas and performance.

    in the case of network render i think wayland should only protocolize a very basic open protocol where you can transmit data in the way you feel like it from a client side app and establish the basics like encryption and hand checking, that way every toolkit/desktop/3rd party app can attach his network renderer adapted to that exact enviroment: for Exmaple
    CASE 1: i wanna check my ktorrent app in home from my office and have it in my plasma desktop like a locally rendered app conserving the target machine visual settings(my offices one)
    CASE 2: for example 1 way to save lot of bandwith would be for example render this app locally using my local Oxygen icons theme wich should be pretty much the same as my home's (in case of kde should be easy gnome i don't know)
    CASE 3: another probable way of save lots of bandwith is sending LZOed packet's of the actual render commands to a remote QT/KDE library or daemon and get this library to actually perform the rendering on the local wayland server using some sort of jit compiler dunno need more thinking

    in any of this scenarios (assuming they can be made) would be insane to have wayland to karate chop part of the render buffer and send it to a remote client but handling the rendering stage at client side level and having a solid and secure transport on the wayland server side would make this a very elegant solution and every desktop or ISV can implement their own solutions without have to mess with wayland internal code and wait N months to be included in the next release.

    btw X11 network was a nice idea a billion years ago but today is bloated, insecure and a band murdered but network render is always something useful so im not saying remove it im saying let do it right from the start

    Leave a comment:


  • Drago
    replied
    I am all for CSD.

    Leave a comment:


  • elanthis
    replied
    CSD has nothing to do with giving app developers more control. For fuck's sake, they can ALREADY use CSD if they want to on X11 today right now on your existing window manager! CSD is about solving real technical problems with the way that server-side decorations work that still today have no workable solution.

    In practice, all apps will just use their toolkit's window borders and controls, which will be made to work with the desktop as shipped by the distribution. All KDE apps will use Qt and hence all have the same standard KDE controls that you'd expect, all GNOEM apps will use GTK+, and so on.

    Apps like Chrome are _more likely to have standard window controls_ with CSD because now the toolkits can add first-class support for things like the tabs-on-top layout that Chrome popularized. That means that future Chrome versions can use an existing toolkit for its window borders and management without needing to lose its compact layout, and those toolkit-provided borders will retain the controls that all the other apps on your desktop has. This is better for consistency and user control, not worse.

    p.s. Chrome allows you to turn off CSD if you don't like it for some reason. Contrast to many other Linux apps that don't give you such an option, today, on X11, with your existing window manager, because the app sets the necessary X11 properties to disable window controls and then draws their own. Think of XMMS2, or just about every other media player out there besides the ones that ship with KDE/GNOME.

    Leave a comment:


  • SunSet
    replied
    Originally posted by ?John? View Post
    I think that's the whole point of these "flames" - the whole concept seems to be lowering the bar too much and potentially putting users at risk introduced by incompetent/irresponsible "developers" with too much control/freedom.


    That's it, we're boned!
    if this is true, how'd you change the issue?

    Leave a comment:


  • yogi_berra
    replied
    Originally posted by movieman View Post
    Lately Linux developers seem to have decided that they want to reimplement Windows... badly.
    As opposed to re-inventing UNIX, badly... http://www.amazon.com/UNIX-Haters-Ha.../dp/1568842031

    Leave a comment:


  • ?John?
    replied
    Originally posted by etnlWings View Post
    It's possible that a CSD spec could include support for expandable spaces to be filled-out by a WM, or other daemon but you're unlikely to see anything like that supported.
    I think that's the whole point of these "flames" - the whole concept seems to be lowering the bar too much and potentially putting users at risk introduced by incompetent/irresponsible "developers" with too much control/freedom.

    Originally posted by movieman View Post
    Linux developers seem to have decided that they want to reimplement Windows... badly.
    That's it, we're boned!

    Leave a comment:


  • movieman
    replied
    Originally posted by kayosiii View Post
    With CSD I only get that if the individual application implements that feature - sounds like a massive step backwards to me.
    Wayland is a massive step backwards, so this shouldn't be surprising. Lately Linux developers seem to have decided that they want to reimplement Windows... badly.

    Leave a comment:


  • etnlWings
    replied
    I use the sticky/above/shade buttons, also. It's one of the simplest and most user-visible ways to expose WM functionality and report the status of a window (being able to see which windows are stickied/pinned above without needing to interact with them). It's not even used to it's full potential now, when a WM can (easily) implement a button for just about anything WM-related in the titlebar. It's possible that a CSD spec could include support for expandable spaces to be filled-out by a WM, or other daemon but you're unlikely to see anything like that supported.

    Leave a comment:


  • ?John?
    replied
    Originally posted by kayosiii View Post
    One of the biggest things I like about KDE is that I can have a button to keep the window on top. With CSD I only get that if the individual application implements that feature - sounds like a massive step backwards to me.
    I'm using Compiz with Emerald and my window title bar looks like this:
    icon, title, dynamic space, minimize, roll up/down, toggle always on top, toggle stickiness, maximize/restore, close.
    It may seem like an overkill, but sometimes it's actually invaluable.

    I also hate the idea of forcing people that often fail to get even the absolute basics right into position where they're much more likely to screw up, while giving up proven ways to save the day when the shit is about to hit the fan.

    Leave a comment:

Working...
X