Implement InputCapture portal as Google SoC project?
Am Donnerstag, 14. März 2024, 02:02:57 CET schrieb Gabe Klavans: > Hello! > > I'm a newish software developer and I've had my eye on this issue for > implementing the InputCapture portal in KDE for a while > https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12. From > my understanding, completing this would enable apps like Synergy and > InputLeap to function under KDE's Wayland session, and I use apps like > this all the time! I have no experience developing for KDE but I would > love to use this as a launchpad for getting involved. I have a > sufficient amount of development experience in several > languages/environments, including C++ and C-based build systems. Does > this seem like a good project proposal for something like Google's SoC? > Or would it be too small/convoluted? > > In any case, I just wanted to ask here and see if anyone with more > experience would be willing to serve as a mentor either for a SoC > project or just in general for this feature implementation. > > Thanks, > Gabe > Hi, I have good and bad news for you: I am working on it right now and aiming for Plasma 6.1 for this feature. The current progress is that the LibEi integration into KWin works, code here: https://invent.kde.org/plasma/kwin/-/merge_requests/5412 Currently I am writing the portal + communication with KWin. I am sorry that I 'snatched' this away from you but seeing so many people excited for this feature is a great! Cheers David
resvg
Hello, What do you think about https://github.com/RazrFalcon/resvg in case of processing and rendering SVGs? Judging by README it's impressive library with a lot of implemented SVG features. It's written in Rust, but can be used as C library and has Qt binding. Do you have any plans to have this in Craft?
Re: resvg
On 2024-03-14, Igor Mironchik wrote: > Hello, > > What do you think about https://github.com/RazrFalcon/resvg in case of > processing and rendering SVGs? > > Do you have any plans to have this in Craft? With the current revitalization of QtSvg, I kind of think we should work harder with that rather than try to replace it. It is after all hooked in quite deep in our stuff already, so most of our svg's needs to be compatible with QtSvg anyways. /Sune
Re: resvg
Hi, yeah I don’t see the appeal. Qt SVG has also finally seen some love in Qt 6.7 which addresses many of the issues we’ve had. If there’s more, we can fix it. Cheers Kai Uwe Am 14.03.24 um 13:53 schrieb Igor Mironchik: Hello, What do you think about https://github.com/RazrFalcon/resvg in case of processing and rendering SVGs? Judging by README it's impressive library with a lot of implemented SVG features. It's written in Rust, but can be used as C library and has Qt binding. Do you have any plans to have this in Craft?
[ANNOUNCE] CMake 3.29.0-rc4 is ready for testing
I am proud to announce the fourth CMake 3.29 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.29
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.29/release/3.29.html
Release milestone is available at:
https://gitlab.kitware.com/cmake/cmake/-/milestones/136
Some of the more significant changes in CMake 3.29 are:
* The LLVM/Clang GNU-like frontend on Windows ("clang++") may now be
used to compile "CUDA" language sources.
* TI Clang-based compilers are now supported with compiler id
"TIClang".
* The "cmake_language(EXIT)" sub-command was added to terminate "cmake
-P" scripts with a specified exit code.
* The "export(SETUP)" sub-command was added to configure export sets.
Its "TARGET" option's "XCFRAMEWORK_LOCATION" setting specifies the
location of a ".xcframework" that can be substituted for an
installed target.
* The "CMAKE_LINKER_TYPE" variable and corresponding "LINKER_TYPE"
target property were added to specify what linker to use with some
toolchains.
* A "CMAKE_TEST_LAUNCHER" variable and corresponding "TEST_LAUNCHER"
target property were added to specify a launcher to be used by
executable targets when invoked by tests added by the "add_test()"
command.
* The "ctest -j" option may now be given without a value to let ctest
choose a default level of parallelism, or with "0" to let ctest use
unbounded parallelism. The corresponding "CTEST_PARALLEL_LEVEL"
environment variable, if set to the empty string, is now equivalent
to passing "-j" with no value.
CMake 3.29 Release Notes
Changes made since CMake 3.28 include the following.
New Features
Command-Line
* "cmake(1)" "-E cat" can now print the standard input by passing the
"-" argument.
Generators
--
* Visual Studio Generators now support selecting between the Intel
oneAPI Fortran compiler ("ifx") and the Intel classic Fortran
compiler ("ifort") using a "fortran=" field in
"CMAKE_GENERATOR_TOOLSET".
File-Based API
--
* The "cmake-file-api(7)" "codemodel" version 2 "version" field has
been updated to 2.7.
* The "cmake-file-api(7)" "codemodel" version 2 "target" object gained
a new "launchers" field.
Compilers
-
* The LLVM/Clang GNU-like frontend on Windows ("clang++") may now be
used to compile "CUDA" language sources.
* Compilers targeting the GNU ABI on Windows (MinGW) may now be used
to compile Objective C ("OBJC") and Objective C++ ("OBJCXX"). These
include GNU compilers ("gcc" and "g++") and the LLVM/Clang GNU-like
frontends ("clang" and "clang++").
* TI Clang-based compilers are now supported with compiler id
"TIClang".
Commands
* The add_custom_command(TARGET) signature now supports adding build
events through Alias Targets.
* The "cmake_language(EXIT)" sub-command was added to terminate "cmake
-P" scripts with a specified exit code.
* The "export(SETUP)" sub-command was added to configure export sets.
Its "TARGET" option's "XCFRAMEWORK_LOCATION" setting specifies the
location of a ".xcframework" that can be substituted for an
installed target.
* The "if()" command gained new tests "IS_READABLE", "IS_WRITABLE" and
"IS_EXECUTABLE" to check file or directory permissions.
Variables
-
* The "CMAKE_INSTALL_PREFIX" environment variable was added to provide
a default value for the "CMAKE_INSTALL_PREFIX" variable.
* The "CMAKE_LINKER_TYPE" variable and corresponding "LINKER_TYPE"
target property were added to specify what linker to use with some
toolchains.
* The "CMAKE__COMPILER_LINKER",
"CMAKE__COMPILER_LINKER_ID",
"CMAKE__COMPILER_LINKER_VERSION" and
"CMAKE__COMPILER_LINKER_FRONTEND_VARIANT" variables were added
to describe the linker used by the language's link step.
* The "CMAKE_PROJECT_INCLUDE", "CMAKE_PROJECT_INCLUDE_BEFORE",
"CMAKE_PROJECT__INCLUDE", and "CMAKE_PROJECT__INCLUDE_BEFORE" variables learned to support a semicolon-
separated list of CMake language files to be included sequentially.
These variables can also reference module names to be found in
"CMAKE_MODULE_PATH" or builtin to CMake.
* The "CMAKE_SKIP_TEST_ALL_DEPENDENCY" variable was added to control
whether the "test" (or "RUN_TESTS") buildsystem target depends on
the "all" (or "ALL_BUILD") target.
* A "CMAKE_TEST_LAUNCHER" variable and corresponding "TEST_LAUNCHER"
target property were added to specify a launcher to be used by
executable targets when invoked by tests added by the "add_test()"
command.
Properties
--
* The "CROSSCOMPILING_EMULATOR" target property now supports
"generator expressions".
* The "UNITY_BUILD" target property now supports the Objective C
("OBJC") and Objective C++ ("OBJCXX") languages.
* The "XCODE_EMBED_XPC_SERVICES" target property was added to tell the
"Xcode" generator what targets to put in the "Em
Re: resvg
On Thursday, March 14, 2024 2:04:45 PM CET Sune Vuorela wrote: > On 2024-03-14, Igor Mironchik wrote: > > Hello, > > > > What do you think about https://github.com/RazrFalcon/resvg in case of > > processing and rendering SVGs? > > > > Do you have any plans to have this in Craft? > > With the current revitalization of QtSvg, I kind of think we should work > harder with that rather than try to replace it. > It is after all hooked in quite deep in our stuff already, so most of > our svg's needs to be compatible with QtSvg anyways. > > /Sune Well, QtSvg can only render (and create) SVGs, but there is no way to process an SVG document in a different way than to render it on a paint device. For me, this is a good reason to be interested in resvg.
Re: resvg
пт, 15 мар. 2024 г., 00:51 Laura David Hurka : > On Thursday, March 14, 2024 2:04:45 PM CET Sune Vuorela wrote: > > On 2024-03-14, Igor Mironchik wrote: > > > Hello, > > > > > > What do you think about https://github.com/RazrFalcon/resvg in case of > > > processing and rendering SVGs? > > > > > > Do you have any plans to have this in Craft? > > > > With the current revitalization of QtSvg, I kind of think we should work > > harder with that rather than try to replace it. > > It is after all hooked in quite deep in our stuff already, so most of > > our svg's needs to be compatible with QtSvg anyways. > > > > /Sune > > Well, QtSvg can only render (and create) SVGs, but there is no way to > process > an SVG document in a different way than to render it on a paint device. > For me, this is a good reason to be interested in resvg. > By processing meant reading and parsing of XML/SVG.
Re: resvg
Am Fr., 15. März 2024 um 05:38 Uhr schrieb Страшила : > пт, 15 мар. 2024 г., 00:51 Laura David Hurka : >> >> On Thursday, March 14, 2024 2:04:45 PM CET Sune Vuorela wrote: >> > On 2024-03-14, Igor Mironchik wrote: >> > > Hello, >> > > >> > > What do you think about https://github.com/RazrFalcon/resvg in case of >> > > processing and rendering SVGs? >> > > >> > > Do you have any plans to have this in Craft? >> > >> > With the current revitalization of QtSvg, I kind of think we should work >> > harder with that rather than try to replace it. >> > It is after all hooked in quite deep in our stuff already, so most of >> > our svg's needs to be compatible with QtSvg anyways. >> > >> > /Sune >> >> Well, QtSvg can only render (and create) SVGs, but there is no way to process >> an SVG document in a different way than to render it on a paint device. >> For me, this is a good reason to be interested in resvg. > > > By processing meant reading and parsing of XML/SVG. One thing I always wonder with these Rust projects, and resvg in particular, is future maintainability. Just to make resvg, its developer reimplemented: * Parts of the Skia graphics library in Rust (as tiny-skia) * Parts of the Harfbuzz text shaping engine algorithms in Rust (rustybuzz) * An entirely new XMl parsing library * A new CSS parser * A CLI arguments parser * An in-memory font database I am all for trying new things, but these rewrite-the-world projects have to be maintained somehow in the very long-term, most likely alongside the original projects. And there's only a finite amount of developers. Meanwhile QtSVG is built on top of Qt, which uses the regular Harfbuzz and Qt for drawing. For sure having dependencies on rewrites of existing projects absolutely does not rule out their use, but before depending on something this fundamental, I would love to see the project and its rewritten dependencies show that they are actively and long-term maintained (which looks excellent for resvg, but a bit less so for its dependencies). Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: resvg
Any example of "process an SVG document in a different way than to render it"? Laura David Hurka 于2024年3月15日周五 05:57写道： > > On Thursday, March 14, 2024 2:04:45 PM CET Sune Vuorela wrote: > > On 2024-03-14, Igor Mironchik wrote: > > > Hello, > > > > > > What do you think about https://github.com/RazrFalcon/resvg in case of > > > processing and rendering SVGs? > > > > > > Do you have any plans to have this in Craft? > > > > With the current revitalization of QtSvg, I kind of think we should work > > harder with that rather than try to replace it. > > It is after all hooked in quite deep in our stuff already, so most of > > our svg's needs to be compatible with QtSvg anyways. > > > > /Sune > > Well, QtSvg can only render (and create) SVGs, but there is no way to process > an SVG document in a different way than to render it on a paint device. > For me, this is a good reason to be interested in resvg. > > > >
