T13927: Pop!_os style window tiling

[Thomas Platzer]

kloop added a comment.


  @ngraham It's more like the window tabs in the titlebar like we had in KDE4. 
From what I've seen in the video posted the KDE4 version was a lot slicker than 
the PopOS one. Incidentally, I'd sooo wish to see this feature come back.

TASK DETAIL
  https://phabricator.kde.org/T13927

To: kloop
Cc: kloop, plasma-devel, cblack, niccolove, ngraham, rafasantos, Orage, 
cacarry, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, 
mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, alexeymin, 
himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, 
sebas, apol, ahiemstra, mart

Re: monday meeting notes for 6/9/2021

[Tom Zander]

On maandag 6 september 2021 12:50:21 CEST Marco Martin wrote:
> # Bhushan
> * So I discussed this earlier as well, but one specific change
> I am interested in for soft-freeze exception is formats KCM
> QML port * I believe MR is now complete from hanyoung side
> * Main reason for that is,  without it some locale variables
> can not be configured on plasma mobile
> and those locale variables are used for detecting phone number
> format e.g. etc.

Are you aware of:

https://invent.kde.org/plasma-mobile/plasma-dialer/-/issues/35

Re: Gitlab CI - Inbound

[Tom Zander]

On maandag 6 september 2021 14:21:00 CEST Christoph Cullmann 
(cullmann.io) wrote:
> I would prefer to not have some optional category to be sure
> the CI always builds with the same state of dependencies, too.

A CI build would always build with the latest release (or 
whatever the repo owner stated). The "optional" would have zero 
effect on that.

Re: Gitlab CI - Inbound

[Tom Zander]

On maandag 6 september 2021 11:48:39 CEST Ben Cooksley wrote:
> > Pushing everything into required is likely not scalable,
> > causing projects too wait too long for compile.
> > Avoiding the optional ones means you lack coverage of compile
> > and testing failures due to changes in libs.
> 
> The CI system has reused the results of previous builds of
> dependencies since the very first generation of the system

We seem to be talking about two slightly different topics.

When the (for instance) KIO repo changes, then the CI will 
obviously rebuild that repo and will pull in all the things that 
kio depends on.

What many CIs do is additionally trigger rebuilds of projects 
that _use_ KIO, by them marking kio as a required dependency.

Imagine a small extragear app that uses some KIO stuff and it has 
some unit tests that would break as a result of the KIO change.
When the KDE CI triggers a rebuild of projects that mark KIO as a 
required dependency, this little app would show its breaking as a 
result of the KIO push. Helping the KIO dev to realize the 
fallout as well.
Without such a feature the app would show breakage at a random 
time in the future after a new push was made in that repo. Losing 
lots of dev time and compromising quality.

Now, the optional requirements would help diminish the effect of 
changes in frameworks paralysing the build system by limiting the 
apps that gets scheduled for a rebuild.

This kind of functionality becomes pretty easy to add to gen5.1 
of the CI, provided that at this time the dependencies are 
already split since doing it later is going to be an uphill 
battle.

monday meeting notes for 6/9/2021

[Marco Martin]

# Arjen
* I did a few kirigami things last week to improve startup performance
* biggest change there being switching a whole bunch of loaders to async
* which improved startup for my koko testcase by ~500ms which was
rather significant
* other than kirigami, I merged two bigger mrs for quick charts, which
change how line and bar charts are rendered so they can be batched by
the scene graph, which should improve performance

# David E
* We are now in soft feature freeze
* which is exciting
* We have a big backlog of reviews
* I've been trying to spend my evenings going through them
* There's a lot that have been abandoned by authors, so I'm making
heavy use of the "needs changes" tag
* and then doing searches based on that
* One potential issue is the new kwin "frost effect"
* we merged in all the surrounding infrastrcuture and API for it to
land this release, but it doesn't seem to have happened yet
* as that's quite a large change I would rather that happened sooner than later
* I also have a large kwin change I want to get in that's a bit of a
large refactor and potentially breaks the idea of the soft freeze, but
it's to fix a bug, so I'll ask for an exception on plasma-devel
* it's rewriting a bunch of D code to be much more sane
[discussion
d_ed -> Bhushan Shah: as you're here, what's the status of
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/147
Bhushan Shah -> d_ed: I'll try to follow up by this week (it won't get
in 5.23 anyway but let's try to move that review somewhat) ]
* Has anyone spoke to promo about release announcements?
* If not I'll give them a "heads up"

# Bhushan
* So I discussed this earlier as well, but one specific change I am
interested in for soft-freeze exception is formats KCM QML port
* I believe MR is now complete from hanyoung side
* Main reason for that is,  without it some locale variables can not
be configured on plasma mobile
and those locale variables are used for detecting phone number format e.g. etc.
* will write to plasma-devel about that
* Second topic, is modemmanager port we have in plasma-nm and
plasma-phone-components, we will merge it close to beta most likely
since it needs to sync up with other components as well (out of plasma
release schedule), it does not affect anything in desktop space
* main reason being it needs sync with other components as well
(dialer,spacebar)
https://invent.kde.org/plasma/plasma-phone-components/-/merge_requests/176
https://invent.kde.org/plasma/plasma-nm/-/merge_requests/33
* I will discuss with Nico and Devin later today and depending on
discussion will send email to plasma-devel thread about both formats
kcm and broadband one


# Nico
* A while ago I asked distros whether we can use C++20 in Plasma
* And no objections were raised
* So I started porting some of the async DBus stuff in plasma-nm to
use coroutines
* Since the combination of clang + libstdc++ + coroutines currently is broken
* The problem is we don't know when clang will fix that
* either wait or force Openmandriva to use gcc for now for plasma
* need to reach and say "we want to do this for this time, can you
find a way to make it work"

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Mon, Sep 6, 2021 at 9:00 PM Tom Zander  wrote:

> On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote:
> > In terms of the format of the 'Dependencies' section,
>
> Playing with kde-build script and noticing the fast growing
> dependency trees we have today, I think it may be beneficial to
> have two types of compile dependencies in this setup.
>
> 1. required-to-build.
>   Which means that if something in the parent tree changes, this
>   one is scheduled for re-build.
>
> 2. optional. Equivalent of the cmake feature, if its not there
>   some code is not compiled.
>   At least once before a release the full dependencies can be
>   compiled to see if it fully compiles.
>

>From the perspective of the CI system there is basically no difference in
terms of making a dependency available or not as all dependencies are
always satisfied using previously built binaries.
If a dependency is not available your build fails.

We also have to make a hard choice - we either bring in optional
dependencies or we don't.

If we were to randomise whether we brought them in - or just brought them
in at certain times - then we would make the system state deterministic.
This could in some cases cause builds to break if it was random whether or
not we included optional dependencies. This would occur if the dependency
of a dependency of a project were rebuilt without an optional dependency
being present which in turn caused it's API interface to change. That would
then cause the project to fail as the dependency would now be broken.


>
> Pushing everything into required is likely not scalable, causing
> projects too wait too long for compile.
> Avoiding the optional ones means you lack coverage of compile and
> testing failures due to changes in libs.
>

The CI system has reused the results of previous builds of dependencies
since the very first generation of the system (this would be generation 5)
so this is not a problem facing the CI system.
For individual developers, my understanding is that kdesrc-build makes use
of incremental builds which eliminates most of the issue as well.


> What do people think, is it useful to have an 'optional' category
> in future there?
> Maybe useful to think that far ahead now people are populating
> their dependencies :-)
>
>
>
>
Thanks,
Ben

Re: Gitlab CI - Inbound

[Tom Zander]

On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote:
> In terms of the format of the 'Dependencies' section,

Playing with kde-build script and noticing the fast growing 
dependency trees we have today, I think it may be beneficial to 
have two types of compile dependencies in this setup.

1. required-to-build.
  Which means that if something in the parent tree changes, this
  one is scheduled for re-build.

2. optional. Equivalent of the cmake feature, if its not there
  some code is not compiled.
  At least once before a release the full dependencies can be
  compiled to see if it fully compiles.


Pushing everything into required is likely not scalable, causing 
projects too wait too long for compile.
Avoiding the optional ones means you lack coverage of compile and 
testing failures due to changes in libs.

What do people think, is it useful to have an 'optional' category 
in future there?   
Maybe useful to think that far ahead now people are populating 
their dependencies :-)

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Mon, Sep 6, 2021 at 12:46 AM Nicolas Fella  wrote:

> On 05.09.21 08:13, Ben Cooksley wrote:
> > Hi all,
> >
> > This morning after much work i'm happy to announce that the new
> > generation CI scripts intended for use with Gitlab CI successfully
> > completed their first build (of ECM, and then subsequently of
> > KCoreAddons).
> >
> > This begins our first steps towards transferring CI over from Jenkins
> > to Gitlab.
> >
> > These scripts are 'Gitlab native' and are designed to work in an
> > environment where they will be running on merge requests, tags as well
> > as all branches of our repositories - something the existing scripts
> > were completely incompatible with. While there are still some
> > infrastructural elements to put in place (such as 'seed jobs' to mass
> > rebuild all projects after substantial changes and 'cleanup jobs' to
> > remove old builds from the Package Registry) the core elements needed
> > for initial testing of these scripts are now ready.
> >
> > For those curious, the results of those initials runs can be found at
> > https://invent.kde.org/groups/teams/ci-artifacts/-/packages
> > 
> >
> > Due to the challenges associated with having to handle all of the
> > different forms of build and the versioning of this information, these
> > scripts also represent a radical change in how CI builds will be
> > conducted - with a large part of the configuration of the jobs
> > themselves, including information on project dependencies now shifting
> > to files located within the repository themselves. Those who monitor
> > commits to Frameworks repositories will have noticed the appearance of
> > these '.kde-ci.yml' files in some repositories.
> >
> > To assist in the future rollout of the CI system it would be
> > appreciated if projects could please begin setting up these files
> > within their respective repositories.
> > You can find a template detailing the available options at
> >
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
> > <
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config-template.yml
> >
> >
> > Where possible please avoid overriding the system defaults except
> > where needed by your project (ie. don't just copy the template in full)
> > The defaults mirror the template and can be found at
> >
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
> > <
> https://invent.kde.org/sysadmin/ci-tooling/-/blob/work/bcooksley/gitlab-ci/config/global.yml
> >
> >
> > In terms of the format of the 'Dependencies' section, please bear in
> > mind the following:
> > - For the 'on' section, the special value '@all' can be used to mean
> > "All platforms" to avoid needing to update the file in the event
> > additional platforms are added in the future
> > - For the 'require' section:
> >   1) Please only include the projects you *explicitly* depend on.
> > Dependencies of your dependencies will be included automatically
> >   2) When specifying a project, you must use the repository path on
> > Gitlab. Legacy project paths (such as kde/workspace/plasma-desktop)
> > are no longer in use and will not work.
> >   3) There are three special values for the branch name - '@same',
> > '@latest' and '@stable' which can be used to refer to the branch/tag
> > of a dependency.
> >   '@same' means the branch name should be the same as that of the
> > project being built and should be used when declaring dependencies
> > among projects in a release group.
> >   '@latest' and '@stable' refer to the corresponding branches
> > defined in the branch-rules.yml file, which can be found in
> > sysadmin/repo-metadata
> >
> > As a general rule, unless you require the absolute latest version of
> > another project in another release unit, it is recommended that you
> > use @stable.
> > Please avoid using explicit branch names unless absolutely necessary.
> >
> > At this time it is expected that the first set of Gitlab CI builds
> > using the new scripts may be conducted for Frameworks within the next
> > week or so, assuming the build of the seed jobs goes according to plan.
> >
> > Once the scripts have been proven successfully for Frameworks, we will
> > look at extending them to projects that depend only on Frameworks and
> > repositories within their release unit and finally will extend them to
> > projects with more complex dependency requirements. It is expected
> > that the switch will be flipped on the Frameworks builds sometime in
> > the next week or two.
> >
> > Please let me know if you have any questions on the above.
> >
> > Thanks,
> > Ben Cooksley
> > KDE Sysadmin
>
> Hi Ben,
>

Hi Nicolas,


> thanks for your work on this!
>
> How would I best encode a dependency like "On Linux and FreeBSD depend
> on kwayland, but not on Windows and macOS"?
>

I would suggest doing something like the 

Re: Gitlab CI - Inbound

[Ben Cooksley]

On Mon, Sep 6, 2021 at 11:03 AM Michael Reeves  wrote:

> How do we get a visual on exactly which lines are covered by auto testing
> and which aren't?
>

Please see
https://docs.gitlab.com/ee/user/project/merge_requests/test_coverage_visualization.html
for more details on how this works on Merge Requests.
To my knowledge this isn't exposed outside of Merge Requests.

Cheers,
Ben

[Breeze] [Bug 441966] Spinner graphics need to be updated

[Harald Sitter]

https://bugs.kde.org/show_bug.cgi?id=441966

Harald Sitter  changed:

   What|Removed |Added

   Assignee|plasma-devel@kde.org|plasma-b...@kde.org

-- 
You are receiving this mail because:
You are the assignee for the bug.