Page 8 of 11 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 106

Thread: GNOME Display Settings Now Working On Wayland

  1. #71
    Join Date
    Dec 2011
    Posts
    1,932

    Default

    Quote Originally Posted by doom_Oo7 View Post
    Yes but nowadays everybody uses a toolkit like Qt / GTK / FLTK / ..., isn't it ? Apart from some folks in some famous video game company
    I hate the Steam looks so much xD
    Seems Valve use their own proprietary toolkit called VGUI in Steam and all their Source games.

  2. #72
    Join Date
    Jan 2013
    Posts
    1,353

    Default

    Quote Originally Posted by Awesomeness View Post
    I watched the Wayland talk from last year's X conference. The “compelling” reason given for CSD was:
    When you rotate a window, you won't get a single jagged pixel line between titlebar and window content.

    But the reality is:
    No one rotates windows and even if one did, nobody would care about a single line of pixels.
    It's not just rotation, the same applies to other transformation effects eg. wobbly windows, scaling and such.

    Thing is, however, the disadvantage of SSD can be overcome by merging the surfaces into one surface before transformation, but this of course requires one extra operation - however, if you have the extra power available to wobble your windows, I don't think it's much of a concern.

  3. #73
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by dee. View Post
    Default to CSD, but if the client wants to use SSD, it can just request the compositor to "draw me a simple decoration".
    So, default to what is used in corner cases. I don't think that's the best idea. Specially because this implies the ones who doesn't care about decorations still need to place code to handle decorations.

  4. #74
    Join Date
    Jan 2013
    Posts
    1,353

    Default

    Quote Originally Posted by mrugiero View Post
    So, default to what is used in corner cases. I don't think that's the best idea. Specially because this implies the ones who doesn't care about decorations still need to place code to handle decorations.
    They already need to place code to open windows on the screen. Having to call one extra function with arguments to the effect of "draw me decorations with this title text and these buttons" isn't really anything more than they'd have to do in a SSD-by-default model, either.

  5. #75
    Join Date
    Feb 2011
    Posts
    943

    Default

    But isn't this whole discussion academic, anyway? Any Wayland compositor has to support SSD for one simple reason: xwayland. xwayland requires SSD. So any compositor that supports xwayland will need to have SSD support.

    Weston already supports SSD for this reason. It is currently in the xwayland source, which means it is only exposed to xwayland clients, but the code is all there.

  6. #76
    Join Date
    Aug 2011
    Posts
    65

    Default

    Quote Originally Posted by Awesomeness View Post
    Not the same thing. For example you can't have shortcuts like ctrl+t to open new tabs.

    In my opinion the default should be whatever the application wants, but the user or the window manager should be able to switch to SSD. Otherwise things like unity or plasma active aren't possible.

  7. #77
    Join Date
    Feb 2011
    Posts
    943

    Default

    Quote Originally Posted by Maxjen View Post
    Not the same thing. For example you can't have shortcuts like ctrl+t to open new tabs.
    You can, there just needs to be an API allowing applications to manage such tabs. I am pretty sure this is planned for kwin, or at least was at one point. In principle there is no reason this should be any more complicated for applications than using a toolkit-provided tab manager. In fact it can even be simpler since they don't need to worry about the location or properties of the tab bar.
    Last edited by TheBlackCat; 08-18-2013 at 06:30 PM.

  8. #78
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by TheBlackCat View Post
    But isn't this whole discussion academic, anyway? Any Wayland compositor has to support SSD for one simple reason: xwayland. xwayland requires SSD. So any compositor that supports xwayland will need to have SSD support.

    Weston already supports SSD for this reason. It is currently in the xwayland source, which means it is only exposed to xwayland clients, but the code is all there.
    No, actually, there is no reason to. XWayland, as a client it is for Wayland, can have its own client side decorations, without the inner X window knowing it; since in X it's SSD, you just disable inner X window's decorations.

    Quote Originally Posted by Maxjen View Post
    In my opinion the default should be whatever the application wants, but the user or the window manager should be able to switch to SSD. Otherwise things like unity or plasma active aren't possible.
    I don't know what you call "default", but in my dictionary it's what happens when you don't say anything explicitly, so a default can't be "whatever the application wants". If the application doesn't states what it wants, THEN the default is applied.

    Quote Originally Posted by dee. View Post
    They already need to place code to open windows on the screen. Having to call one extra function with arguments to the effect of "draw me decorations with this title text and these buttons" isn't really anything more than they'd have to do in a SSD-by-default model, either.
    Yes. But it's still something not needed, and by basic logic, using custom decorations (the main advantage, IMO, of CSD) you'll need to place extra code, so an extra function call to state you'll use CSD makes more sense there.
    I think we agree that both should be supported and a sane default should be applied, along with two switches, one for the application to choose what it wants, and one for the user to override application's decisions, and I think that's the most important part. The other point is just a matter of preference, and I don't think it changes greatly the outcome.

  9. #79
    Join Date
    Jan 2013
    Posts
    1,353

    Default

    Quote Originally Posted by mrugiero View Post
    Yes. But it's still something not needed, and by basic logic, using custom decorations (the main advantage, IMO, of CSD) you'll need to place extra code, so an extra function call to state you'll use CSD makes more sense there.
    Why does it make sense to add an extra function call to CSD-using apps, vs. using an already necessary function call in SSD-using apps?

    Heck, the function call for CSD and SSD apps could even be the same:

    create_window(USE_SSD, title_text, button_configuration);
    vs.
    create_window(USE_CSD);

    doable with varargs.

    I think we agree that both should be supported and a sane default should be applied, along with two switches, one for the application to choose what it wants, and one for the user to override application's decisions, and I think that's the most important part. The other point is just a matter of preference, and I don't think it changes greatly the outcome.
    If you allow the user to always override the behaviour of apps, then apps will have to code for both CSD and SSD anyway. Which is kind of silly, when you think about it. If the application doesn't have CSD coded in, forcing it to CSD would just create a window sans decorations. If the application doesn't have the SSD codepaths, forcing it to use SSD would create possibly undefined behaviour, or in the best case a window with empty titlebar and buttons that may or may not do anything.

  10. #80
    Join Date
    Jul 2009
    Posts
    256

    Default

    Quote Originally Posted by Teho View Post
    Could you list them or point where those are explained?
    sorry, but no. this argument has raged on for about five years now (hell, it's been going on this forum for about three), and every time people have indulged it and given the right reasons. i'm not going to prolong it, by rehashing exactly the same thing year on year.


    Quote Originally Posted by Awesomeness View Post
    I watched the Wayland talk from last year's X conference. The “compelling” reason given for CSD was:
    When you rotate a window, you won't get a single jagged pixel line between titlebar and window content.

    But the reality is:
    No one rotates windows and even if one did, nobody would care about a single line of pixels.
    that's really not even close to either of the main reasons.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •