Page 5 of 5 FirstFirst ... 345
Results 41 to 50 of 50

Thread: KDE/KWin On Wayland To Use Server-Side Decorations

  1. #41
    Join Date
    Oct 2008
    Posts
    3,135

    Default

    To me, SSDs seems like a solution in search of a problem. All the negatives people list about CSDs seem pretty unimportant and easily bypassed to me.

    But then, I don't really care about it much. If KWin wants to try providing SSDs on Wayland, then that's fine with me. We'll see how it works out.

  2. #42
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,105

    Default

    Quote Originally Posted by smitty3268 View Post
    To me, SSDs seems like a solution in search of a problem. All the negatives people list about CSDs seem pretty unimportant and easily bypassed to me.
    Can you elaborate on that?

    In particular Martin's point about very inconsistent decoration _will_ happen in a CSD system. How would it be easily bypassed without going SSD? The hypothetical libdeco is no solution, we both know every toolkit will have their own solution, as will every app started before toolkits get the functionality.

  3. #43
    Join Date
    Oct 2010
    Posts
    437

    Default

    Quote Originally Posted by curaga View Post
    Can you elaborate on that?

    In particular Martin's point about very inconsistent decoration _will_ happen in a CSD system. How would it be easily bypassed without going SSD? The hypothetical libdeco is no solution, we both know every toolkit will have their own solution, as will every app started before toolkits get the functionality.
    Inconsistent decoration _will_ happen in a SSD system, too. However, I have no reason to believe kwrite and gnome-terminal will suddenly decide to create their own decorations just because we switched over to CSD. Not only is it stupid, but it also means they will have to (each) write their own controls and hook them into their program themselves. Talk about code duplication.

    No, most programs will continue as they have, and allow the other layers to handle decoration. There will be exceptions, as there are now (__with SSD__), but I believe they will remain the minority.

  4. #44
    Join Date
    Aug 2012
    Posts
    245

    Default

    Maybe settle for a "middle-ground" in the end?
    Like, Wayland provides a library to make/render decorations, which also is themable. Even better, it can provide capability to add a button/menu or whatever in the decoration to "increase creativity" for those who want it.(It would need to care for cases like window shading and undecorating windows that have extra stuff in the decoration of course.)
    So the application(actually its toolkit) would use this library to render the decoration in the same texture. But the server/compositor can still "command" the decoration through said library. So shading a window should still be possible, without coding it in the app. You can still have a single texture coming from a window and less IPC. And applications can look consistent(global theming of decoration, just like now). Specifically for the latter,there would be a default theme and the app can still force/request a certain theme, but the compositor optionally can do so as well, and the latter would always come on top in this case(so he compositor would decide if it let's the app choose or not).
    I think it's should be possible, then we should get the best of both worlds. We shouldn't have to only look at two extreme ends, there's always the middle too.

  5. #45
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,105

    Default

    Quote Originally Posted by Nobu View Post
    Inconsistent decoration _will_ happen in a SSD system, too. However, I have no reason to believe kwrite and gnome-terminal will suddenly decide to create their own decorations just because we switched over to CSD. Not only is it stupid, but it also means they will have to (each) write their own controls and hook them into their program themselves. Talk about code duplication.

    No, most programs will continue as they have, and allow the other layers to handle decoration. There will be exceptions, as there are now (__with SSD__), but I believe they will remain the minority.
    What exceptions there are (Chromium and friends) can still be forced to use the system/wm decorations in a SSD system. Such won't be possible in a CSD system unless I'm mistaken.

  6. #46
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,892

    Default

    Quote Originally Posted by curaga View Post
    What exceptions there are (Chromium and friends) can still be forced to use the system/wm decorations in a SSD system. Such won't be possible in a CSD system unless I'm mistaken.
    It probably wouldn't be too hard to set it up where IF they have client-side-decorations, they can use them, UNLESS the compositor has a specific setting set to true. Such as Kwin might have "Force consistent window decorations." as a true/false setting. Which would let the apps THINK they had CSD but would override them with SSD if set to true. If false then Kwin would provide decorations unless they had some built in.

  7. #47
    Join Date
    Feb 2013
    Posts
    49

    Default

    Quote Originally Posted by Ericg View Post
    It probably wouldn't be too hard to set it up where IF they have client-side-decorations, they can use them, UNLESS the compositor has a specific setting set to true. Such as Kwin might have "Force consistent window decorations." as a true/false setting. Which would let the apps THINK they had CSD but would override them with SSD if set to true. If false then Kwin would provide decorations unless they had some built in.
    it's not (only) a matter of aesthetics or user preference
    as mentioned earlier, for KWin there's also the matter of providing window tabbed grouping, which is something that could be handled client side if windows all belonged to the same application (as the application would know about the windows, their number and their names), but would lose application isolation and complicate the protocol in the case of different applications (because one should know about the others, handle tab group enter/leave notifications, have access to the whole window stack) - so this case needs to be handled in the server / compositor

    so an application running under Kwin could and would use CSD, but SHOULD switch to SSD when tab grouped - thus it would have to support both anyway (for KDE at least)
    otoh, since putting a window in a tab group this is an external action initiated by the wm/compositor, asynchronously for the application, it would be the compositor telling the application to disable (on tab group enter) or reenable (on tab group leave) CSD's, rather than the application requesting them (apart from maybe the initial window creation)

    oh and lets not forget windowed games (especially FPS's..), those hardly have a decoration of their own...

  8. #48
    Join Date
    Aug 2012
    Posts
    245

    Default

    New blog post regarding decorations ..
    Quick, new article!

  9. #49
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,892

    Default

    Quote Originally Posted by Rigaldo View Post
    New blog post regarding decorations ..
    Quick, new article!

    Kind of sounds like my idea above-- let the user choose, hybrid approach is gonna be the best option.

  10. #50
    Join Date
    Oct 2008
    Posts
    3,135

    Default

    Quote Originally Posted by curaga View Post
    Can you elaborate on that?

    In particular Martin's point about very inconsistent decoration _will_ happen in a CSD system. How would it be easily bypassed without going SSD? The hypothetical libdeco is no solution, we both know every toolkit will have their own solution, as will every app started before toolkits get the functionality.
    "Easily bypassed OR unimportant."

    I don't really care about that. There are already tons of inconsistencies - just try running a GNOME app next to a KDE one and try to count up all the different inconsistencies you can find. Adding the window decorations to that list seems like a pretty unimportant addition to me.

    And within GTK/Qt apps, i think the toolkit would provide a pretty good job at keeping things consistent. There would obviously be some issues that would pop up, but again - i don't really care.

    Other people apparently do, so I'm not necessarily against KWin providing SSDs. I just personally don't find it important.
    Last edited by smitty3268; 02-10-2013 at 06:34 PM.

Posting Permissions

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