Breeze:为什么在KDE 5中默认不提供它?

众所周知,几天前KDE Next(或您喜欢的KDE 5)已经稳定发布,它带来的新功能中,最受关注的就是名为Breeze的新图稿。

微风

那些已经尝试过这个新版本或看过视频的人可能已经注意到,对于窗户装饰器,默认情况下附带的是氧气而不是微风。 也一样 马丁格拉斯林 向我们解释 在他的博客上 这个决定的原因是什么。

由于文章是英文的,因此我将尽力带给您关于此的基本概念。

为什么默认不使用Breeze?

我首先解释窗口装饰在KWin 4中是如何工作的。KWin是所谓的窗口管理器重新父母。 这意味着将X11管理的窗口放入另一个提供窗口框架的X11窗口中。 在KWin,我们使用QWidget作为窗口框架。 因此,我们还受限于QWidget提供给我们的东西。我们的解决方案是拦截QWidget中的所有装饰画事件并抑制它,触发作曲家的重画,并在渲染步骤中保证对临时图像的装饰,然后复制到纹理中。


Breeze主题窗户装饰基于Aurorae主题引擎。 因为我是Aurorae的主要作者,所以我可以在本博文中继续关注它,而不会感到bad🙂ur Aurorae的设计非常容易创建装饰并利用新的半透明功能。 作为可以用作默认装饰的解决方案,但这并不是他们的目标。 这个想法是允许想要自定义此功能的用户使用,而大多数用户可以使用更快的本机主题。 Aurorae从不快,她也不会快。


现在在KWin 5中,使用QML是使Aurorae难以使用的主要问题。 QtQuick使用Scenegraph并使用QWindows而不是QWidget。 对于我们基于QWidget的API而言,这真是令人遗憾。 我们调整了内部用法以支持基于QWindows的装饰,但这是一条相当困难的路,因为窗口的行为存在差异。 由于它不再基于QWidget,因此我们的绘画事件陷阱已被打破,我们需要一个新的解决方案。 而且该解决方案比以前的解决方案还要难看,因为QtQuick当前正在通过OpenGL运行。 由于OpenGL Qt应用程序中的限制(可以在Qt 5.4中解决),我们无法与QtQuick使用的OpenGL上下文共享...这不仅是将内容从GPU复制到RAM并再次返回时的巨大开销到GPU,您还将损失大量内存。 在最大化窗口的情况下,它不仅是标题栏,而且是整个窗口。 每个窗口都有开销。


仅此一项就可以使Aurorae完全无法使用。 我目前正在使用Breeze主题,KWin需要超过200MB的RAM-确实不能接受。 但是情况更糟。 使用QWindows,我们无法知道哪些区域已更新。 因此,例如,当按钮被更新时,我们必须重新粉刷整个窗口,包括装饰内容的完整副本。 特别是在动画情况下,这是一个大问题。


那么前进的方向是什么? 通过从QWidget消除基于健康的装饰的限制,我开始为API实施新的装饰,与此同时,我也开始使用此新API实施Breeze装饰。 希望我们可以在KWin 5.1中引入它。


先生们,事情就是这样。 希望您或多或少地了解问题所在。 我要问马丁,制作像Oxygen这样的原生Breeze主题是否更实用,更快,尽管目前我并不担心,Oxygen虽然不是世界上最可爱的东西,但它有很多选择。


11条评论,留下您的评论

发表您的评论

您的电子邮件地址将不会被发表。 必填字段标有 *

*

*

  1. 负责数据:MiguelÁngelGatón
  2. 数据用途:控制垃圾邮件,注释管理。
  3. 合法性:您的同意
  4. 数据通讯:除非有法律义务,否则不会将数据传达给第三方。
  5. 数据存储:Occentus Networks(EU)托管的数据库
  6. 权利:您可以随时限制,恢复和删除您的信息。

  1.   伊万巴拉姆

    我读了所有东西,但我什么都不懂,今天我很慢。 无论如何,我仍然无法在OpenSUSE 5上测试KDE 13.1。 因为我有一些“旧的”依赖关系,这让我很烦。
    也许我会给您另一个在虚拟操作系统中使用其他操作系统的机会。

    问候和感谢您的输入。

    1.    纳米

      这并不容易,它基本上是试图解释实现的方法很复杂,尤其是对于插件而言,并且从本质上讲,极光比Syxygen要慢得多。

      从这个意义上讲,我不知道在窗户装饰器中,在我看来

    2.    纳米

      这并不容易,它基本上是试图解释实现的方法很复杂,尤其是对于插件而言,并且从本质上讲,极光比Syxygen要慢得多。

      从这个意义上讲,我不知道在窗口装饰器中,在我看来,KDE比GNOME落后了一步,并且请注意,我充其量只是KDE的粉丝,只是我承认自己并不难当它是真的。

    3.    特萨兰

      对此一无所知,我基本上理解的是,极光(Breeze使用的引擎)现在出现了问题,因为Kwin5不再像在kwin4中那样使用qwidget,并且Windows的行为也不相同。 相反,它使用可直接与opengl一起使用的QML和QTquick,因此qt 5.3中的某些现有限制似乎阻止了旧引擎及其主题在新的Kwin中无法正常运行。

  2.   mat1986

    创建(或适应)微风以适应氧气的工作方式或方式是否可行?

  3.   安德库拉

    有人知道qtcurve会发生什么吗?

    1.    特萨兰

      Qtcurve-qt5已经完美运行了一段时间。 新版本的KDE将一如既往。

      1.    艾奥里亚

        对于我来说已经很奇怪了,在始终处于最前沿的Kaos中,测试Kf5是默认情况下在Kaos linux血浆或kde 5氧气中已知的。 哇,您不知道您是Aurorae的创造者...

        1.    特萨兰

          我是极光的创造者吗? O_o;

  4.   塞尔吉奥·杜兰

    我也在极光中创建了一个微风的替代品,称为下一个新鲜风,后来又被称为微风,但是我无法根据主题对SVG进行改编,因此它的开发是不活跃的,如果您有机会我愿意向他展示,那么拉夫(Elav)微风主题的创造者,看看他们是否可以将我的极光装饰的想法移植到本地KDE装饰中,以代替微风装饰

    https://drive.google.com/file/d/0B6VUkpZzqL7hbk1QbWN6eVcycU0/edit?usp=sharing

  5.   埃利奥时间3000

    我认为当我有家人和孩子并且大约5岁的时候,KDE 30将会用于Fedora,Debian,Slackware和Arch。

    简而言之,要继续利用我留下的小青年。