KDE Gear 22.08 release service schedule

[Albert Astals Cid]

Hi people, 

This is the release schedule the release team agreed on

  https://community.kde.org/Schedules/KDE_Gear_22.08_Schedule

Dependency freeze is in five weeks (July 7) and feature freeze one after that. 
Get your stuff ready!

Cheers,
  Albert

Re: Asking for a new project

[Bourumir Wyngs]

Sorry, I was not expecting that my message will go to the big mailing list,
initially assumed this will be directed to some person responsible for
handling the new project proposals. The request to send the message to this
address can be found at https://community.kde.org/Incubator.

Speaking about the "big button", I am a Krita contributor and already have
the fork with multiple branches containing my merge requests under review
and others. I wanted to keep this existing fork separate from the much more
independent project, there is nothing pretty in branches from the two
projects in one repository. Because of that I have registered the proposed
project separately but you are right, one of the ways to proceed would be
to take a master branch of my fork as  a master of the independent project.

I would be surprised if Krita developer team would be willing to help me
reach the users but who knows? It is obviously possible to post to they
mailing list as well. The C++20 code, they are unlikely to merge any time
soon.


On Wed, Jun 1, 2022 at 2:45 AM Aleix Pol  wrote:

> There's a big "Fork" button on top here:
> https://invent.kde.org/graphics/krita/
>
> That said, please coordinate with krita devs to make sure your work is
> ever going to reach users.
>
> Best,
> Aleix
>
>
> On Tue, May 31, 2022 at 9:10 AM Bourumir Wyngs 
> wrote:
> >
> > Hello, KDE team,
> >
> > I would like to create the independent fork of Krita that would allow to
> use all modern features of C++, up till that is supported by the latest GCC
> release, 12.1 at the time of writing.
> >
> > The current Krita development rules are capped by C++11 that is now the
> ten years old standard. Even that is limited by the lengthy list of
> restrictions. The rules also require using deprecated features of the Qt
> framework like Q_FOREACH. I understand the care of the community not to
> spoil anything and to preserve the beauty of the existing code. This means,
> radical changes should be done in a form.
> >
> > I tried to setup the project on KDE myself (
> https://invent.kde.org/bourumir/kreed) but for some reason was not able
> to push Krita code (about 1 Gb) into repository - hangs at the end of the
> push. It may have something to do with quotas or things the like. It may be
> that I need more assistance from your side to setup the project. I decided
> to contact you first before starting the work on GitHub or independent
> server instead.
> >
> > I, the project initiator, am currently 54 year old. I am robotic
> engineer with very long programming experience, including significant
> industrial experience with C++. In the past I made notable contribution to
> GNU Classpath project, providing them a fully functional and interoperable
> implementation of CORBA. It is obviously sad there are no other
> contributors so far but I expect some people to come. I also made several
> contributions for Krita so have some understanding about code base and
> architecture of this project. My real name is Audrius Meskauskas.
> >
> >
> >
>

Re: Approval request for feature idea

[samuel ammonius]

This sounds amazing! However, I still don't see the point of avoiding QSS
because it seems to be able to do everything CSS can (besides
transformations, which are the only difference that I've been able to find
so far).

On Wed, Jun 1, 2022 at 1:25 AM Nate Graham  wrote:

> Hello Samuel,
>
> There's an idea for the future of theming in Plasma 6 that would use CSS
> to define a "universal theme" that would then be consumed by our QQC2,
> Plasma, and GTK theming to keep them all in sync automatically. See
> https://phabricator.kde.org/T13467. This is one of the options presented
> there, but to my knowledge the only one with a prototype implementation,
> made by Arjen Hiemstra (CCd). If you're interested in pursuing this, you
> might want to get in touch with him about it.
>
> Nate
>

Re: Asking for a new project

[Nate Graham]

If you're aiming to compete with Krita and try to siphon users away from 
it and towards your fork instead, then you are producing what's known as 
a "hostile fork" and I very much doubt that Krita's developers will be 
interested in helping you with it.


If on the other hand your fork is simply a development area for you to 
send merge requests to Krita's main repo, then relations are likely to 
be friendly and they will probably be much more open to your proposals 
and merge requests.


Nate



On 6/1/22 12:26, Bourumir Wyngs wrote:
Sorry, I was not expecting that my message will go to the big mailing 
list, initially assumed this will be directed to some person responsible 
for handling the new project proposals. The request to send the message 
to this address can be found at https://community.kde.org/Incubator 
.


Speaking about the "big button", I am a Krita contributor and already 
have the fork with multiple branches containing my merge requests under 
review and others. I wanted to keep this existing fork separate from the 
much more independent project, there is nothing pretty in branches from 
the two projects in one repository. Because of that I have registered 
the proposed project separately but you are right, one of the ways to 
proceed would be to take a master branch of my fork as  a master of the 
independent project.


I would be surprised if Krita developer team would be willing to help me 
reach the users but who knows? It is obviously possible to post to they 
mailing list as well. The C++20 code, they are unlikely to merge any 
time soon.



On Wed, Jun 1, 2022 at 2:45 AM Aleix Pol > wrote:


There's a big "Fork" button on top here:
https://invent.kde.org/graphics/krita/


That said, please coordinate with krita devs to make sure your work is
ever going to reach users.

Best,
Aleix


On Tue, May 31, 2022 at 9:10 AM Bourumir Wyngs
mailto:bourumir.wy...@gmail.com>> wrote:
 >
 > Hello, KDE team,
 >
 > I would like to create the independent fork of Krita that would
allow to use all modern features of C++, up till that is supported
by the latest GCC release, 12.1 at the time of writing.
 >
 > The current Krita development rules are capped by C++11 that is
now the ten years old standard. Even that is limited by the lengthy
list of restrictions. The rules also require using deprecated
features of the Qt framework like Q_FOREACH. I understand the care
of the community not to spoil anything and to preserve the beauty of
the existing code. This means, radical changes should be done in a form.
 >
 > I tried to setup the project on KDE myself
(https://invent.kde.org/bourumir/kreed
) but for some reason was not
able to push Krita code (about 1 Gb) into repository - hangs at the
end of the push. It may have something to do with quotas or things
the like. It may be that I need more assistance from your side to
setup the project. I decided to contact you first before starting
the work on GitHub or independent server instead.
 >
 > I, the project initiator, am currently 54 year old. I am robotic
engineer with very long programming experience, including
significant industrial experience with C++. In the past I made
notable contribution to GNU Classpath project, providing them a
fully functional and interoperable implementation of CORBA. It is
obviously sad there are no other contributors so far but I expect
some people to come. I also made several contributions for Krita so
have some understanding about code base and architecture of this
project. My real name is Audrius Meskauskas.
 >
 >
 >

Re: Delivery Status Notification (Failure)

[samuel ammonius]

This sounds amazing! However, I still don't see the point of avoiding QSS
because it seems to be able to do everything CSS can (besides
transformations, which are the only difference that I've been able to find
so far).

On Wed, Jun 1, 2022 at 3:59 PM Mail Delivery Subsystem <
mailer-dae...@googlemail.com> wrote:

> [image: Error Icon]
> Address not found
> Your message wasn't delivered to *n...@kde.org* because the address
> couldn't be found, or is unable to receive mail.
> The response from the remote server was:
>
> 550 5.1.1 : Recipient address rejected: User unknown in
> virtual alias table
>
>
>
> -- Forwarded message --
> From: samuel ammonius 
> To: kde-devel@kde.org, n...@kde.org
> Cc:
> Bcc:
> Date: Wed, 1 Jun 2022 15:59:23 -0230
> Subject: Re: Approval request for feature idea
> This sounds amazing! However, I still don't see the point of avoiding QSS
> because it seems to be able to do everything CSS can (besides
> transformations, which are the only difference that I've been able to find
> so far).
>
> On Wed, Jun 1, 2022 at 1:25 AM Nate Graham  wrote:
>
>> Hello Samuel,
>>
>> There's an idea for the future of theming in Plasma 6 that would use CSS
>> to define a "universal theme" that would then be consumed by our QQC2,
>> Plasma, and GTK theming to keep them all in sync automatically. See
>> https://phabricator.kde.org/T13467. This is one of the options presented
>> there, but to my knowledge the only one with a prototype implementation,
>> made by Arjen Hiemstra (CCd). If you're interested in pursuing this, you
>> might want to get in touch with him about it.
>>
>> Nate
>>
>

Re: Approval request for feature idea

[samuel ammonius]

This sounds amazing! However, I still don't see the point of avoiding QSS
because it seems to be able to do everything CSS can (besides
transformations, which are the only difference that I've been able to find
so far).

Re: Approval request for feature idea

[Sven Brauch]

Hi,

On 6/1/22 20:41, samuel ammonius wrote:
However, I still don't see the point of avoiding QSS because it seems to 
be able to do everything CSS can (besides transformations, which are the 
only difference that I've been able to find so far).


Sorry but then you're not looking very hard. Look at e.g. [1].

Just from a quick scroll-through, I find a lot of stuff QSS has never 
heard about, such as animations, box-shadow, caret-color, clipping, 
filter, float, advanced font options, text transform, text shadow, media 
queries, blend mode, overflow, perspective, transitions, n-th-child 
selectors, in general half the selectors, all CSS functions, 
before/after content, etc etc etc.


But that's not even the problem. The problem is that QSS is not a style 
by itself, it is applied *on top of* a style such as Fusion, and does 
*not* give you full control over that style.


So what do you even want to achieve?

Do you want a fully customizable style? QSS isn't, it's not even *a* 
style to begin with.


Do you want to apply some customization while preserving the base looks 
of whatever style the user has configured? Then QSS is a nice thing but 
unless you limit yourself to really basic stuff (mainly colors) some 
widgets will look weird or broken in some base styles, or in some 
applications. They might even break with colors alone, simply from the 
fact that a style sheet is set at all.


I suggest we stop discussing this here at this point, I don't think it's 
very productive. I'd recommend you try to make a complete style changing 
appearance of all widgets (especially the more funky stuff: scrollbars, 
checkable combo boxes, progress bars, tool buttons with dropdowns, 
checkable menu items with icons, tree view items, ...) as you want them 
to look like with QSS, and open a few complicated applications (krita, 
dolphin, kdevelop, gwenview, the KDE file dialogs) with that style. I 
recommend a dark style, it tends to make problems more obvious. Try to 
make it perfect, like you'd actually want it to look like, not a 
prototype. I hope this experience helps you understand the concerns 
raised here. And if not -- well, maybe people here are wrong and this 
idea will fly after all ;)


Greetings,
Sven

_
[1] https://www.w3schools.com/cssref/default.asp


OpenPGP_0xA4AAD0019BE03F15.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[ANNOUNCE] CMake 3.21.7 available for download

[John Parent]

We are pleased to announce that CMake 3.21.7 is now available for download.

Please use the latest release from our download page:
  https://github.com/Kitware/CMake/releases

Thanks for your support!


Changes made since CMake 3.21.6:

Brad King (9):
  BinUtils: Avoid llvm-mt because it is missing 'mt' features we use
  BinUtils: Restore llvm-ar fallback on Apple platforms
  Utilities/Release: Add "source" stage to Windows docker spec
  AIX: Fix executable ENABLE_EXPORTS in Makefile generators
  Tests: Teach RunCMake to ignore Xcode extension point warnings
  gitlab-ci: update macOS jobs to use Xcode 13.3
  file(GET_RUNTIME_DEPENDENCIES): Support VS 2022 without VS 2019
  cmake-gui: Restore support for internationalization with Qt5 on Windows
  CMake 3.21.7

Gregor Jasny (1):
  Tests: Ignore all classes in Xcode internal objc warnings

Ken Matsui (1):
  AppleClang: Add C++20 and C++23 flags

[ANNOUNCE] CMake 3.22.5 available for download

[John Parent]

We are pleased to announce that CMake 3.22.5 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!


Changes made since CMake 3.22.4:

Brad King (10):
  Tests: Teach RunCMake to ignore Xcode extension point warnings
  gitlab-ci: update macOS jobs to use Xcode 13.3
  FindPkgConfig: Fix preservation of ENV{PKG_CONFIG_ALLOW_SYSTEM_LIBS}
  FortranCInterface: Fix failure with gfortran 12 and Clang
  file(GET_RUNTIME_DEPENDENCIES): Support VS 2022 without VS 2019
  libarchive: Update script to get 3.5.3
  libarchive: include archive_platform.h first in blake2s sources
  libarchive: Update build within CMake after changes in 3.5.3
  cmake-gui: Restore support for internationalization with Qt5 on Windows
  CMake 3.22.5

Gregor Jasny (1):
  Tests: Ignore all classes in Xcode internal objc warnings

LibArchive Upstream (1):
  LibArchive 2022-02-08 (673c1eae)