|
|
|
|
|
by SkyMarshal
5159 days ago
|
|
> As for Chrome, the sin Chrome commits on Linux in particular is that it defaults to something called client-side window decorations, that is it tells the window manager not to display the decorations it would normally put around the client area and then proceeds to draw its own inside this client area, which behave potentially vastly differently from whatever the user has configured for his native system decorations. One man's sin is another man's salvation. That's one of the main reasons I use Chromium and Chrome as my primary browsers on Linux, besides their superb performance optimization. It works well with Ubuntu's integration of the top OS info bar and the app's menu bar, and saves noticeable screen space. I love it. I'm hoping Firefox at least provides that as an option in future builds as well. |
|
As for app menu in a panel: That's actually something we had back in KDE 3.x but are still lacking in the KDE 4 mainline at present, mainly because it's taken a while to coordinate the standard with folks like Canonical and because we really wanted the core patches to be integrated at the Qt level. Things look to be coming together now for the upcoming 4.9 release, though I believe (K)Ubuntu has actually been shipping the patches for a while already, for the benefit of KDE apps running in Unity, but also to support the same sort of arrangement in KDE workspaces.
As for CSDs, there's bunch of other things they break that I didn't list in the original post. For example, with WM-provided decos, the window manager can detect when you're trying to interact with a frozen app and offer to kill it, which is in fact something we're doing. If you move the deco into the app process, though, well, then it hangs together with the app, and things get a little more complicated. And there's performance issues in some remote desktop cases, and so on.