Announcement

Collapse
No announcement yet.

GNOME Display Settings Now Working On Wayland

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

  • Awesomeness
    replied
    Originally posted by daniels View Post
    that's really not even close to either of the main reasons.
    That was the reason given in the talk. I also recall a corner case of something related to Inkscape window resizing stated in the forums once by someone.

    Thing is, you people worked for years only on back-end stuff. You seem to know nothing about usability of user-facing parts (as evident by Weston's crappy usability). If KDE, Gnome, and Ubuntu applications got totally different title bars (in Ubuntu's case even with window buttons on the left side) because they're practically hardcoded because of CSD, it would hurt usability a lot more than stupid jagged pixel lines and those handful of people who resize Inkspace windows all the time.

    At least in GTK and Qt CSD are optional. If you want to live in a usability nightmare, have fun there. I don't and that's why I'll turn CSD off and let KWin5 handle the window borders.
    KWin has a good track record with performance and usability ever since Martin and Thomas took over main KWin development.

    Leave a comment:


  • daniels
    replied
    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.


    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.

    Leave a comment:


  • dee.
    replied
    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.

    Leave a comment:


  • mrugiero
    replied
    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.

    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.

    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.

    Leave a comment:


  • TheBlackCat
    replied
    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, 06:30 PM.

    Leave a comment:


  • Maxjen
    replied
    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.

    Leave a comment:


  • TheBlackCat
    replied
    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.

    Leave a comment:


  • dee.
    replied
    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.

    Leave a comment:


  • mrugiero
    replied
    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.

    Leave a comment:


  • dee.
    replied
    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.

    Leave a comment:

Working...
X