KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 1609 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/1609/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Tue, 31 May 2022 01:54:07 + Build duration: 1 hr 38 min and counting JUnit Tests Name: projectroot Failed: 2 test(s), Passed: 59 test(s), Skipped: 0 test(s), Total: 61 test(s)Failed: projectroot.autotests.commandlauncherjob_servicetestFailed: projectroot.autotests.kiowidgets_dropjobtestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: projectroot.src.ioslaves.trash.tests.testtrashName: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)
KDE CI: Frameworks » ktexteditor » kf5-qt5 FreeBSDQt5.15 - Build # 839 - Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/ktexteditor/job/kf5-qt5%20FreeBSDQt5.15/839/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Tue, 31 May 2022 01:54:30 + Build duration: 1 hr 34 min and counting JUnit Tests Name: projectroot Failed: 0 test(s), Passed: 70 test(s), Skipped: 0 test(s), Total: 70 test(s)Name: projectroot.autotests.src Failed: 1 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 6 test(s)Failed: projectroot.autotests.src.vimode.vimode_keys
KDE CI: Frameworks » kio » kf5-qt5 SUSEQt5.15 - Build # 1595 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.15/1595/ Project: kf5-qt5 SUSEQt5.15 Date of build: Tue, 31 May 2022 01:54:07 + Build duration: 1 hr 10 min and counting BUILD ARTIFACTS acc/KF5KIO-5.95.0.xml JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 61 test(s), Skipped: 0 test(s), Total: 62 test(s)Failed: projectroot.autotests.kiowidgets_dropjobtestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: projectroot.src.ioslaves.trash.tests.testtrashName: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s) Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report59% (24/41)69% (298/433)69% (298/433)56% (38467/68532)41% (21335/52400)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests95% (62/65)95% (62/65)91% (11396/12577)45% (7190/15860)autotests.http100% (5/5)100% (5/5)99% (527/528)58% (167/290)autotests.kcookiejar100% (1/1)100% (1/1)94% (173/185)63% (70/112)src100% (1/1)100% (1/1)89% (8/9)71% (10/14)src.core89% (109/123)89% (109/123)61% (9517/15584)52% (4766/9151)src.core.kssl100% (1/1)100% (1/1)38% (33/86)50% (2/4)src.filewidgets79% (31/39)79% (31/39)57% (5443/9472)44% (2323/5330)src.gui100% (12/12)100% (12/12)72% (947/1307)58% (493/846)src.gui.systemd50% (2/4)50% (2/4)4% (7/178)1% (1/108)src.ioslaves.file71% (5/7)71% (5/7)49% (690/1394)39% (476/1225)src.ioslaves.file.kauth0% (0/2)0% (0/2)0% (0/187)0% (0/83)src.ioslaves.ftp100% (2/2)100% (2/2)40% (549/1378)30% (435/1430)src.ioslaves.help0% (0/5)0% (0/5)0% (0/253)0% (0/138)src.ioslaves.http88% (7/8)88% (7/8)43% (1874/4354)37% (1361/3719)src.ioslaves.http.kcookiejar40% (2/5)40% (2/5)49% (664/1364)56% (588/1053)src.ioslaves.remote100%
Re: Fwd: Approval request for feature idea
I also found this: https://github.com/Alexhuszagh/BreezeStyleSheets#gallery On Mon, May 30, 2022 at 4:32 PM Sven Brauch wrote: > Hi, > > On 5/30/22 20:37, samuel ammonius wrote: > > I've worked with regular CSS and I'm sure that stylesheets offer just as > > many customization options as things like QtCurve or QStylePlugins. The > > reason that it may not seem this way is because Qt didn't document > > regular CSS syntax in the documentation for stylesheets. > > No, the reason is that Qt's CSS has absolutely nothing to do with the > regular CSS known from browsers. It's a proxy style which tweaks how a > base style (e.g. Fusion or Breeze) draws elements on the screen, by e.g. > modifying the palette and then forwarding the draw call to the base > style. It implements maybe 1% of the CSS stuff a modern browser can do, > and that's a favourable estimate. And not even all of that will work as > expected in all cases. For details, see [1]. > > That this proxy style's behaviour can be configured using a CSS-like > syntax is coincidental, or, well, intentionally made that way for ease > of use. But: this is not the CSS you know or expect. > > > I can't verify that stylesheets can do everything that a style plugin > > can do > > They can't. Regular CSS 3 in Firefox is probably pretty close, > practically speaking, but Qt's CSS, not so much. > > > but I know for sure that Breeze can be made using a qstylesheet > > Where did you get this information? This is certainly not the case. Just > try to make e.g. the animated fades in Breeze using Qt's CSS and Fusion > as the base style and you will immediately discover that it's not possible. > > Greetings, > Sven > > _ > [1] > > https://code.woboq.org/qt5/qtbase/src/widgets/styles/qstylesheetstyle.cpp.html >
Re: Fwd: Approval request for feature idea
https://doc.qt.io/qt-5/stylesheet-reference.html#:~:text=widget%2Danimation%2Dduration* Wouldn't this allow animated fades? On Mon, May 30, 2022 at 4:32 PM Sven Brauch wrote: > Hi, > > On 5/30/22 20:37, samuel ammonius wrote: > > I've worked with regular CSS and I'm sure that stylesheets offer just as > > many customization options as things like QtCurve or QStylePlugins. The > > reason that it may not seem this way is because Qt didn't document > > regular CSS syntax in the documentation for stylesheets. > > No, the reason is that Qt's CSS has absolutely nothing to do with the > regular CSS known from browsers. It's a proxy style which tweaks how a > base style (e.g. Fusion or Breeze) draws elements on the screen, by e.g. > modifying the palette and then forwarding the draw call to the base > style. It implements maybe 1% of the CSS stuff a modern browser can do, > and that's a favourable estimate. And not even all of that will work as > expected in all cases. For details, see [1]. > > That this proxy style's behaviour can be configured using a CSS-like > syntax is coincidental, or, well, intentionally made that way for ease > of use. But: this is not the CSS you know or expect. > > > I can't verify that stylesheets can do everything that a style plugin > > can do > > They can't. Regular CSS 3 in Firefox is probably pretty close, > practically speaking, but Qt's CSS, not so much. > > > but I know for sure that Breeze can be made using a qstylesheet > > Where did you get this information? This is certainly not the case. Just > try to make e.g. the animated fades in Breeze using Qt's CSS and Fusion > as the base style and you will immediately discover that it's not possible. > > Greetings, > Sven > > _ > [1] > > https://code.woboq.org/qt5/qtbase/src/widgets/styles/qstylesheetstyle.cpp.html >
Re: Fwd: Approval request for feature idea
Hi, On 5/30/22 20:37, samuel ammonius wrote: I've worked with regular CSS and I'm sure that stylesheets offer just as many customization options as things like QtCurve or QStylePlugins. The reason that it may not seem this way is because Qt didn't document regular CSS syntax in the documentation for stylesheets. No, the reason is that Qt's CSS has absolutely nothing to do with the regular CSS known from browsers. It's a proxy style which tweaks how a base style (e.g. Fusion or Breeze) draws elements on the screen, by e.g. modifying the palette and then forwarding the draw call to the base style. It implements maybe 1% of the CSS stuff a modern browser can do, and that's a favourable estimate. And not even all of that will work as expected in all cases. For details, see [1]. That this proxy style's behaviour can be configured using a CSS-like syntax is coincidental, or, well, intentionally made that way for ease of use. But: this is not the CSS you know or expect. I can't verify that stylesheets can do everything that a style plugin can do They can't. Regular CSS 3 in Firefox is probably pretty close, practically speaking, but Qt's CSS, not so much. but I know for sure that Breeze can be made using a qstylesheet Where did you get this information? This is certainly not the case. Just try to make e.g. the animated fades in Breeze using Qt's CSS and Fusion as the base style and you will immediately discover that it's not possible. Greetings, Sven _ [1] https://code.woboq.org/qt5/qtbase/src/widgets/styles/qstylesheetstyle.cpp.html OpenPGP_0xA4AAD0019BE03F15.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Fwd: Approval request for feature idea
I've worked with regular CSS and I'm sure that stylesheets offer just as many customization options as things like QtCurve or QStylePlugins. The reason that it may not seem this way is because Qt didn't document regular CSS syntax in the documentation for stylesheets. I can't verify that stylesheets can do everything that a style plugin can do, but I know for sure that Breeze can be made using a qstylesheet so there shouldn't be any reason to say that stylesheets don't have enough features to be added to KDE. On Mon, May 30, 2022 at 3:51 PM Sven Brauch wrote: > Hi, > > On 5/30/22 19:52, samuel ammonius wrote: > > Adding this feature won't make the C++ styles disappear. It will only > > make it possible for users who don't know how to make a style plugin in > > C++ to make their own styles > > the problem is that the Qt stylesheets are pretty bad at that. The > customization options they provide are limited, work in unexpected ways, > and sometimes look flat-out buggy, especially if applications have their > own widgets or drawing code or if the stylesheet is applied on top of an > unusual base style. > > They are fine for coloring a combo box or line edit in red if the input > is invalid, but they are not a useful user-configurable theme engine. > > I do see the value in the feature you envision, but IMO it needs to > happen in the form of something like the QtCurve style, which does its > painting in a way that is directly intended to be customized. > Customization needs to be offered by the style; it cannot be kludged on > top of the style with the QCssStyle proxy style, at least not in its > current form (but probably not at all). I suggest looking into something > like this if you'd like to provide user-customizable styles. > > Greetings, > Sven >
Re: Fwd: Approval request for feature idea
Hi, On 5/30/22 19:52, samuel ammonius wrote: Adding this feature won't make the C++ styles disappear. It will only make it possible for users who don't know how to make a style plugin in C++ to make their own styles the problem is that the Qt stylesheets are pretty bad at that. The customization options they provide are limited, work in unexpected ways, and sometimes look flat-out buggy, especially if applications have their own widgets or drawing code or if the stylesheet is applied on top of an unusual base style. They are fine for coloring a combo box or line edit in red if the input is invalid, but they are not a useful user-configurable theme engine. I do see the value in the feature you envision, but IMO it needs to happen in the form of something like the QtCurve style, which does its painting in a way that is directly intended to be customized. Customization needs to be offered by the style; it cannot be kludged on top of the style with the QCssStyle proxy style, at least not in its current form (but probably not at all). I suggest looking into something like this if you'd like to provide user-customizable styles. Greetings, Sven OpenPGP_0xA4AAD0019BE03F15.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Fwd: Approval request for feature idea
Adding this feature won't make the C++ styles disappear. It will only make it possible for users who don't know how to make a style plugin in C++ to make their own styles, while other users get to choose between using C++ styles for their performance or using stylesheet styles that may look better to that user. Besides the performance cost, I didn't understand most of the items on that chart, but I think the choice to use this feature should be available for users regardless of the weaknesses QStylesheets may have, because the existence of the feature won't affect any other choices. On another note: the performance cost of QStylesheets can be dodged by making the Style plugin only parse the stylesheet once, and then return the resulting style to all applications without needing to parse it again.
Re: KPipeWire in kdereview
On Mon, May 30, 2022 at 3:44 PM Albert Astals Cid wrote: > > El dilluns, 30 de maig de 2022, a les 14:55:55 (CEST), Aleix Pol va escriure: > > Hi, > > I'd like to get KPipeWire (https://invent.kde.org/plasma/kpipewire) > > released from KDE eventually. > > > > At the moment it's under Plasma as it's the only place where it's > > being used, I know we might want to use it in spectacle eventually, > > although I feel like it's premature to get it in frameworks just yet, > > although it should be a possibility down the line. > > > > If you wanted to test it beyond what Plasma does, you can try this > > little app for recording your wayland desktops and windows. > > https://invent.kde.org/apol/screenrecord > > It needs a Messages.sh Added > This signal is never emited? > void cursorModeChanged(Screencasting::CursorMode cursorMode); Addressed. > > This property NOTIFY signal is wrong? > Q_PROPERTY(QString outputName READ outputName WRITE setOutputName NOTIFY > uuidChanged) > Addressed. > The 3 signals in ScreencastingStream are never emitted? they are emitted from ScreencastingStreamPrivate, the overriden methods from the qtwayland generated code. > > PipeWireCore header is installed but not exported. If you export it, it will > need a d-pointer Not installed anymore. > PipeWireSourceItem is exported but has no d-pointer Not installed anymore. Left it to only install PipeWireSourceStream for now, which is the one that is useful when you don't want to do QML. Aleix
Re: KPipeWire in kdereview
> - xdp-recordme probably shouldn't be installed (by default)? Thing is you need the test to be installed to work to request more privileges to KWin. I guess we could default to BUILD_TESTING=OFF? The rest of the points here are either addressed in master. On Mon, May 30, 2022 at 3:17 PM Nicolas Fella wrote: > > On Monday, May 30, 2022 2:55:55 PM CEST Aleix Pol wrote: > > > Hi, > > I'd like to get KPipeWire (https://invent.kde.org/plasma/kpipewire) > > released from KDE eventually. > > > > At the moment it's under Plasma as it's the only place where it's > > being used, I know we might want to use it in spectacle eventually, > > although I feel like it's premature to get it in frameworks just yet, > > although it should be a possibility down the line. > > > > If you wanted to test it beyond what Plasma does, you can try this > > little app for recording your wayland desktops and windows. > > https://invent.kde.org/apol/screenrecord > > > > Cheers! > > Aleix > > > Hi, > > - The repo could use a README that explains what it is and isn't > - The repo probably shouldn't have a .kdev4 file > - CMakeLists.txt states 5.20 as minimum ECM version. That sounds wrong > - (some of) the pkg_check_modules calls should probably have REQUIRED > - I get some build warnings: > > [9/46] Building CXX object src/CMakeFiles/KPipeWire.dir/pipewirecore.cpp.o > /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing > initializer for member ‘pw_core_events::done’ [-Wmissing-field-initializers] >21 | }; > | ^ > /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing > initializer for member ‘pw_core_events::ping’ [-Wmissing-field-initializers] > /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing > initializer for member ‘pw_core_events::remove_id’ [-Wmissing-field- > initializers] > /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing > initializer for member ‘pw_core_events::bound_id’ [-Wmissing-field- > initializers] > /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing > initializer for member ‘pw_core_events::add_mem’ > [-Wmissing-field-initializers] > /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing > initializer for member ‘pw_core_events::remove_mem’ [-Wmissing-field- > initializers] > > - ecm_add_qtwayland_client_protocol can take a target since recently > - xdp-recordme probably shouldn't be installed (by default)? > - There's no FreeBSD CI yet > > These are some minor things I noticed while glossing over. I won't pretent to > understand enough about PipeWire to comment on the actual code. > > Cheers > > Nico
Re: KPipeWire in kdereview
El dilluns, 30 de maig de 2022, a les 14:55:55 (CEST), Aleix Pol va escriure: > Hi, > I'd like to get KPipeWire (https://invent.kde.org/plasma/kpipewire) > released from KDE eventually. > > At the moment it's under Plasma as it's the only place where it's > being used, I know we might want to use it in spectacle eventually, > although I feel like it's premature to get it in frameworks just yet, > although it should be a possibility down the line. > > If you wanted to test it beyond what Plasma does, you can try this > little app for recording your wayland desktops and windows. > https://invent.kde.org/apol/screenrecord It needs a Messages.sh This signal is never emited? void cursorModeChanged(Screencasting::CursorMode cursorMode); This property NOTIFY signal is wrong? Q_PROPERTY(QString outputName READ outputName WRITE setOutputName NOTIFY uuidChanged) The 3 signals in ScreencastingStream are never emitted? PipeWireCore header is installed but not exported. If you export it, it will need a d-pointer PipeWireSourceItem is exported but has no d-pointer > > Cheers! > Aleix >
Re: KPipeWire in kdereview
On Monday, May 30, 2022 2:55:55 PM CEST Aleix Pol wrote: >Hi, >I'd like to get KPipeWire (https://invent.kde.org/plasma/kpipewire) >released from KDE eventually. > >At the moment it's under Plasma as it's the only place where it's >being used, I know we might want to use it in spectacle eventually, >although I feel like it's premature to get it in frameworks just yet, >although it should be a possibility down the line. > >If you wanted to test it beyond what Plasma does, you can try this >little app for recording your wayland desktops and windows. >https://invent.kde.org/apol/screenrecord > >Cheers! >Aleix Hi, - The repo could use a README that explains what it is and isn't - The repo probably shouldn't have a .kdev4 file - CMakeLists.txt states 5.20 as minimum ECM version. That sounds wrong - (some of) the pkg_check_modules calls should probably have REQUIRED - I get some build warnings: [9/46] Building CXX object src/CMakeFiles/KPipeWire.dir/pipewirecore.cpp.o /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing initializer for member ‘pw_core_events::done’ [-Wmissing-field-initializers] 21 | }; | ^ /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing initializer for member ‘pw_core_events::ping’ [-Wmissing-field-initializers] /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing initializer for member ‘pw_core_events::remove_id’ [-Wmissing-field- initializers] /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing initializer for member ‘pw_core_events::bound_id’ [-Wmissing-field- initializers] /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing initializer for member ‘pw_core_events::add_mem’ [-Wmissing-field-initializers] /home/nico/kde/src/kpipewire/src/pipewirecore.cpp:21:1: warning: missing initializer for member ‘pw_core_events::remove_mem’ [-Wmissing-field- initializers] - ecm_add_qtwayland_client_protocol can take a target since recently - xdp-recordme probably shouldn't be installed (by default)? - There's no FreeBSD CI yet These are some minor things I noticed while glossing over. I won't pretent to understand enough about PipeWire to comment on the actual code. Cheers Nico
KPipeWire in kdereview
Hi, I'd like to get KPipeWire (https://invent.kde.org/plasma/kpipewire) released from KDE eventually. At the moment it's under Plasma as it's the only place where it's being used, I know we might want to use it in spectacle eventually, although I feel like it's premature to get it in frameworks just yet, although it should be a possibility down the line. If you wanted to test it beyond what Plasma does, you can try this little app for recording your wayland desktops and windows. https://invent.kde.org/apol/screenrecord Cheers! Aleix
Re: Approval request for feature idea
On Montag, 30. Mai 2022 02:33:56 CEST samuel ammonius wrote: > I wanted to submit a feature for kde that would allow users to set the > application style to a qstylesheet file (style.qss for example). This > feature would greatly increase the amount of themes available for KDE, make > it possible for users to tweak themes themselves, and make it easier to > include custom icons/images with themes if necessary by using the url() > function in the stylesheet. It would also make it easier for experienced > developers who can make KDE themes in C++ to make multiple, more complex > themes in less time. The feature would also be very easy to make and would > probably take less than 1 Megabyte of total storage. > > I originally wanted to submit this as a project in Google summer of code, > but I missed the deadline for applying. Who should I contact to get > approval for this before submitting a pull request? https://www.kdab.com/say-no-to-qt-style-sheets/ -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
