[sdk/kdesrc-build/docbook_historied_per_file] doc/kdesrc-buildrc: Add documentation for use-inactive-modules

[Kevin Ottens]

Git commit 008559d6d7c2a7bbeba1e61f0a6ee6693000b095 by Kevin Ottens.
Committed on 07/05/2021 at 17:16.
Pushed by ashark into branch 'docbook_historied_per_file'.

Add documentation for use-inactive-modules

Original commit: 81df5728
https://invent.kde.org/sdk/kdesrc-build/-/commit/81df57281f23f4d5a513ca3e48ca42e1f6e0ccca

M  +9-0doc/kdesrc-buildrc/conf-options-table.docbook

https://invent.kde.org/sdk/kdesrc-build/-/commit/008559d6d7c2a7bbeba1e61f0a6ee6693000b095

diff --git a/doc/kdesrc-buildrc/conf-options-table.docbook 
b/doc/kdesrc-buildrc/conf-options-table.docbook
index 27e88e33..d1dd4e9a 100644
--- a/doc/kdesrc-buildrc/conf-options-table.docbook
+++ b/doc/kdesrc-buildrc/conf-options-table.docbook
@@ -1253,6 +1253,15 @@ the lower disk priority set this to 
true.
 
 
 
+
+use-inactive-modules
+Cannot be overridden
+This option when enabled will allow kdesrc-build to also clone and
+pull from repositories marked as inactive. The default is to be disabled,
+to allow inactive modules set this to true.
+
+
+
 
 use-modules
 Can only use in module-set

Re: Proposal unify back our release schedules

[Kevin Ottens]

Hello,

On Monday 22 April 2024 18:08:04 CEST Carl Schwan wrote:
> On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote:
> > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker
> > here I think. I'll try to add a couple of extra aspects to feed the
> > thinking on this topic.
> 
> Thanks you all for raising some important points. Taking into account the
> feedback, I would like to slightly change my proposal.
> 
> - Unify only the release schedule of Gear and Plasma with a frequency of
> either 4 months or 6 months. This would follow the Fibonacci release
> schedule.

Sounds good to me, although we probably want others to chip in.

> - Keep framework release once every month. But ensure that once every 4 (or
> 6) months, it happens at the same time as Gear and Plasma. We can keep the
> frequent features release of framework, which seems to be valuable for
> people not compiling the whole stack from source.

That doesn't sound too hard to achieve.

Back when releases were done by David it was tagged at a fixed predictable day 
of the month. It seems this is not the case anymore (although it's hard to 
extrapolate from two data points: 6.0 and 6.1), so should make it easier to 
meeting Gear and Plasma releases if it's floating a bit.

If there's a will to go back to a predictable day in the month, then we might 
want to instead have Gear and Plasma target this.

It's merely details though, a question of putting new habits in place, nothing 
blocking IMHO even probably the right time to do so.

> For the occasion where the Framework, Gear and Plasma, we should then ensure
> that the framework release is done at the same time or slightly before the
> gear and plasma release and ideally there is also a special beta release of
> Framework done at the same time as the gear and  Plasma beta, which can be
> tested together with the other beta releases.

I guess it depends on how long the beta phase is for Plasma and Gear at this 
point. If it's around a month you might want in fact this Frameworks n-1 to be 
the "beta" and having the n-1 to n month to be only about bugfixes and no 
features.

It'd make for a regular "stabilization only" KDE Frameworks release.

The alternative would be to add an extra beta release in between n-1 and n. So 
it's a question of the release team wanting to do it or not.

> If Plasma decides to switch to a release every 6 months and Gear prefers to
> keep a shorter release cycle, then I would suggest using 3 months for gear
> so that we still have an unified released of framework, gear and plasma
> once every 6 months. I'm less fan of this and if we have a very good reason
> to switch to a 6 months release cycle for Plasma, this argument should also
> apply to Gear.

I have no strong opinion about the 4 vs 6 months. Having the frequency of Gear 
allowing of an alignment with Plasma from time to time definitely makes sense.

> > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote:
> > > * We end up with 3 different products which are released at different
> > > times but are connected together. Apps and Plasma both need Framework,
> > > Plasma needs some packages from gear like kio-extra, Gear needs some
> > > package from Plasma like Breeze. Coordinating all these inter-groups
> > > dependencies is complex and was one the reason we had to do a
> > > megarelease for Plasma 6. Also for the end user, one product is a lot
> > > easier to understand.
> > 
> > This is an engineering topic in this case.
> > 
> > And, to me, this is an excellent reason not to reunify release schedules!
> > Because what it tells me is that we're still having dependency issues
> > which need to be solved.
> > 
> > The example you give shows Plasma depending on Gear, this shouldn't
> > happen, so I'd argue: let's fix that instead.
> > 
> > Aligning the release schedules would only hide such structural issues.
> > 
> > This was one of the main engineering motives to split things up: when it
> > wasn't splitted this would stay hidden much longer everyone being comfy
> > with it.
> > 
> > Now it's creating pain: perfect, that makes the issue obvious, but it
> > should be addressed not masked.
> > 
> > This is in part what Volker highlighted pointing out this should be less
> > of a problem with key components being moved to Plasma. Again, if there
> > are more, let's just address them.
> > 
> > So as pointed out by Sune and Volker: this is a feature (at least in the
> > Frameworks case) not a bug.
> 
> I'm been working a lot on the visual of applications across the whole stack
> and for me, the pain is mostly caused by the fact element of our styl

Re: Proposal unify back our release schedules

[Kevin Ottens]

Hello,

On Monday 22 April 2024 18:08:04 CEST Carl Schwan wrote:
> On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote:
> > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker
> > here I think. I'll try to add a couple of extra aspects to feed the
> > thinking on this topic.
> 
> Thanks you all for raising some important points. Taking into account the
> feedback, I would like to slightly change my proposal.
> 
> - Unify only the release schedule of Gear and Plasma with a frequency of
> either 4 months or 6 months. This would follow the Fibonacci release
> schedule.

Sounds good to me, although we probably want others to chip in.

> - Keep framework release once every month. But ensure that once every 4 (or
> 6) months, it happens at the same time as Gear and Plasma. We can keep the
> frequent features release of framework, which seems to be valuable for
> people not compiling the whole stack from source.

That doesn't sound too hard to achieve.

Back when releases were done by David it was tagged at a fixed predictable day 
of the month. It seems this is not the case anymore (although it's hard to 
extrapolate from two data points: 6.0 and 6.1), so should make it easier to 
meeting Gear and Plasma releases if it's floating a bit.

If there's a will to go back to a predictable day in the month, then we might 
want to instead have Gear and Plasma target this.

It's merely details though, a question of putting new habits in place, nothing 
blocking IMHO even probably the right time to do so.

> For the occasion where the Framework, Gear and Plasma, we should then ensure
> that the framework release is done at the same time or slightly before the
> gear and plasma release and ideally there is also a special beta release of
> Framework done at the same time as the gear and  Plasma beta, which can be
> tested together with the other beta releases.

I guess it depends on how long the beta phase is for Plasma and Gear at this 
point. If it's around a month you might want in fact this Frameworks n-1 to be 
the "beta" and having the n-1 to n month to be only about bugfixes and no 
features.

It'd make for a regular "stabilization only" KDE Frameworks release.

The alternative would be to add an extra beta release in between n-1 and n. So 
it's a question of the release team wanting to do it or not.

> If Plasma decides to switch to a release every 6 months and Gear prefers to
> keep a shorter release cycle, then I would suggest using 3 months for gear
> so that we still have an unified released of framework, gear and plasma
> once every 6 months. I'm less fan of this and if we have a very good reason
> to switch to a 6 months release cycle for Plasma, this argument should also
> apply to Gear.

I have no strong opinion about the 4 vs 6 months. Having the frequency of Gear 
allowing of an alignment with Plasma from time to time definitely makes sense.

> > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote:
> > > * We end up with 3 different products which are released at different
> > > times but are connected together. Apps and Plasma both need Framework,
> > > Plasma needs some packages from gear like kio-extra, Gear needs some
> > > package from Plasma like Breeze. Coordinating all these inter-groups
> > > dependencies is complex and was one the reason we had to do a
> > > megarelease for Plasma 6. Also for the end user, one product is a lot
> > > easier to understand.
> > 
> > This is an engineering topic in this case.
> > 
> > And, to me, this is an excellent reason not to reunify release schedules!
> > Because what it tells me is that we're still having dependency issues
> > which need to be solved.
> > 
> > The example you give shows Plasma depending on Gear, this shouldn't
> > happen, so I'd argue: let's fix that instead.
> > 
> > Aligning the release schedules would only hide such structural issues.
> > 
> > This was one of the main engineering motives to split things up: when it
> > wasn't splitted this would stay hidden much longer everyone being comfy
> > with it.
> > 
> > Now it's creating pain: perfect, that makes the issue obvious, but it
> > should be addressed not masked.
> > 
> > This is in part what Volker highlighted pointing out this should be less
> > of a problem with key components being moved to Plasma. Again, if there
> > are more, let's just address them.
> > 
> > So as pointed out by Sune and Volker: this is a feature (at least in the
> > Frameworks case) not a bug.
> 
> I'm been working a lot on the visual of applications across the whole stack
> and for me, the pain is mostly caused by the fact element of our styl

Re: Proposal unify back our release schedules

[Kevin Ottens]

Hello,

On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote:
> On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote:
> > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens  wrote:
> > > The example you give shows Plasma depending on Gear, this shouldn't
> > > happen, so
> > > I'd argue: let's fix that instead.
> 
> In my opinion the same goes for Gear depending on Plasma.

Agreed, just didn't want to muddy my message and so focused on only one 
direction. But it's definitely a topic to explore as well.

One thing I'm unsure for instance is: do we want to make Gear -> Plasma 
dependencies completely forbidden?

We might consider this going one step too far. I could understand if a Gear 
app wants to provide "more integration" in a Plasma session. So mandatory Gear 
-> Plasma dependencies, I agree are to forbid, but optional ones? I'm less 
certain.

> > > > * We currently don't have a stable branch for Framework and it takes
> > > > often
> > > > up to one month for fixes to be deployed. The Framework releases is
> > > > also
> > > > not in sync with either Gear nor Plasma while these two modules
> > > > heavily
> > > > make use of Framework and contribute to Framework.
> > 
> > Changing the Frameworks release cadence away from monthly isn't going to
> > get fixes out any faster - as if you are using distribution packages it
> > still has to be packaged.
> > If anything it will make them take longer as the Frameworks release would
> > end up being every couple of months instead of monthly? (you can always
> > build Frameworks locally if you need the fixes now)
> 
> For (non-rolling) distributions that update packages on patch releases but
> not on minor releases it would make a difference if there where patch
> releases of Frameworks. Not all distributions can follow and backport
> important fixes in Frameworks. At worst, users will have to suffer a bug in
> Frameworks until the next LTS release.
> 
> Regards,
> Ingo
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Proposal unify back our release schedules

[Kevin Ottens]

Hello,

Wished to react to a point in there. :-)

On Friday 19 April 2024 17:33:02 CEST Volker Krause wrote:
> On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote:
> > * We currently don't have a stable branch for Framework and it takes often
> > up to one month for fixes to be deployed. The Framework releases is also
> > not in sync with either Gear nor Plasma while these two modules heavily
> > make use of Framework and contribute to Framework.
> 
> The fast feature-releases of KF have major advantages though, comparing to
> how things worked prior to 5. They allow apps to work against released (and
> thus distro-packaged) frameworks while still making it practical to
> contribute needed features to KF directly.
> 
> The alternatives are:
> * Depend on KF master (like Plasma does), significantly increasing the
> threshold of entry for new contributors, especially for more self-contained
> apps, where you'd now have to build 70+ repos rather than a few.
> * Depend on the latest release but develop new features locally rather than
> in KF. I'm not sure whether we have meanwhile finally cleaned up all the
> forked kdelibs classes in PIM from the 3 and 4 era due to that.
> * Depend on the latest release and wait for new features to become available
> before making use of them in the app, effectively increasing the delay to
> reach users to twice the release cycle.
> 
> Ie. this makes contributing to KF less attractive from an app developer
> perspective.
> 
> 
> The main issues with out-of-sync KF and Plasma should have been solved with
> some frameworks being moved to Plasma with KF6, if there is more of this
> remaining we should look at the specific cases, for the vast majority of
> frameworks I don't think we have a problem there.
> 
> > * Helps with outside usage of our frameworks. These didn't get as much
> > success as we were hoping when splitting. I think having a stable branch
> > for Framework might help but this is only a guess. It would be interesting
> > to know of cases where people considered using some Framework and to know
> > why they decided against or for it and if this proposal would helps or
> > not.
> 
> I disagree with the often repeated statement that this wasn't successful. It
> might not happened as widely and visibly as we might want, but KF is most
> certainly used vastly more often than kdelibs ever was. And the release
> schedule isn't the impediment here, it's things like dependencies and the
> build system making it hard to vendor copies.
> 
> > In effect this proposal would mean:
> > 
> > * We do one major release every 4 months and then minor releases with a
> > frequency based on the Fibonacci numbers as this releases cycle works very
> > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We
> > could
> > unify that for one or the other one. Or let each component keep their
> > current versioning scheme depending whether we want to merge Plama and
> > Gear
> > as product or keep it separate. I'm a bit undecided about this.
> 
> From my app developer perspective that is fine, Fibonacci rather than
> equidistant patch releases look like an improvement to me. However, assuming
> the feature release interval basically remains the same.
> 
> AFAIK Plasma is discussing a 6 month interval though, and I do understand
> longer cycles are better for promo, but it means users have to wait longer
> for features. It therefore also matters whether we are tying Plasma's
> release to Gear or Gear's releases to Plasma here.

Users waiting longer for features is not necessarily a bad thing though. One 
of the potential advantages is extra QA time, I assume people are happy to 
wait if there are less rough edges.

Now if we assume the longer cycle don't lead to more QA, this becomes a 
balancing act... the burden on the users to discover and assimilate new 
features is real. So it's a bit of a trade-off between dropping a larger set 
of features on them increasing the chance of such features not being noticed, 
or pushing less features towards the user at higher frequency which is 
potentially higher cognitive load (they more likely to notice them all and be 
in a constant "learning new stuff" and "adapting to change" loop).

> > * "KDE Framework" will still exists as an entity and its ABI and API
> > 
> >   compatibility requirement. Only change is the release frequency and the
> > 
> > introduction of a stable branch in sync with the other components.
> 
> That part I'm against for the above mentioned reasons, KF's release
> frequency is a major feature of it.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Proposal unify back our release schedules

[Kevin Ottens]

Hello,

Wished to react to a point in there. :-)

On Friday 19 April 2024 17:33:02 CEST Volker Krause wrote:
> On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote:
> > * We currently don't have a stable branch for Framework and it takes often
> > up to one month for fixes to be deployed. The Framework releases is also
> > not in sync with either Gear nor Plasma while these two modules heavily
> > make use of Framework and contribute to Framework.
> 
> The fast feature-releases of KF have major advantages though, comparing to
> how things worked prior to 5. They allow apps to work against released (and
> thus distro-packaged) frameworks while still making it practical to
> contribute needed features to KF directly.
> 
> The alternatives are:
> * Depend on KF master (like Plasma does), significantly increasing the
> threshold of entry for new contributors, especially for more self-contained
> apps, where you'd now have to build 70+ repos rather than a few.
> * Depend on the latest release but develop new features locally rather than
> in KF. I'm not sure whether we have meanwhile finally cleaned up all the
> forked kdelibs classes in PIM from the 3 and 4 era due to that.
> * Depend on the latest release and wait for new features to become available
> before making use of them in the app, effectively increasing the delay to
> reach users to twice the release cycle.
> 
> Ie. this makes contributing to KF less attractive from an app developer
> perspective.
> 
> 
> The main issues with out-of-sync KF and Plasma should have been solved with
> some frameworks being moved to Plasma with KF6, if there is more of this
> remaining we should look at the specific cases, for the vast majority of
> frameworks I don't think we have a problem there.
> 
> > * Helps with outside usage of our frameworks. These didn't get as much
> > success as we were hoping when splitting. I think having a stable branch
> > for Framework might help but this is only a guess. It would be interesting
> > to know of cases where people considered using some Framework and to know
> > why they decided against or for it and if this proposal would helps or
> > not.
> 
> I disagree with the often repeated statement that this wasn't successful. It
> might not happened as widely and visibly as we might want, but KF is most
> certainly used vastly more often than kdelibs ever was. And the release
> schedule isn't the impediment here, it's things like dependencies and the
> build system making it hard to vendor copies.
> 
> > In effect this proposal would mean:
> > 
> > * We do one major release every 4 months and then minor releases with a
> > frequency based on the Fibonacci numbers as this releases cycle works very
> > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We
> > could
> > unify that for one or the other one. Or let each component keep their
> > current versioning scheme depending whether we want to merge Plama and
> > Gear
> > as product or keep it separate. I'm a bit undecided about this.
> 
> From my app developer perspective that is fine, Fibonacci rather than
> equidistant patch releases look like an improvement to me. However, assuming
> the feature release interval basically remains the same.
> 
> AFAIK Plasma is discussing a 6 month interval though, and I do understand
> longer cycles are better for promo, but it means users have to wait longer
> for features. It therefore also matters whether we are tying Plasma's
> release to Gear or Gear's releases to Plasma here.

Users waiting longer for features is not necessarily a bad thing though. One 
of the potential advantages is extra QA time, I assume people are happy to 
wait if there are less rough edges.

Now if we assume the longer cycle don't lead to more QA, this becomes a 
balancing act... the burden on the users to discover and assimilate new 
features is real. So it's a bit of a trade-off between dropping a larger set 
of features on them increasing the chance of such features not being noticed, 
or pushing less features towards the user at higher frequency which is 
potentially higher cognitive load (they more likely to notice them all and be 
in a constant "learning new stuff" and "adapting to change" loop).

> > * "KDE Framework" will still exists as an entity and its ABI and API
> > 
> >   compatibility requirement. Only change is the release frequency and the
> > 
> > introduction of a stable branch in sync with the other components.
> 
> That part I'm against for the above mentioned reasons, KF's release
> frequency is a major feature of it.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Proposal unify back our release schedules

[Kevin Ottens]

Hello,

On Friday 19 April 2024 14:03:01 CEST Luigi Toscano wrote:
> Nate Graham ha scritto:
> > I expect a vast amount of discussion to result from this proposal, and I
> > think that's great. It'll be good to talk about it. But I suspect in the
> > end we'll likely not achieve 100% consensus, and in that event I'd like
> > for us to put it to a formal KDE e.V. vote so that the topic doesn't
> > become stale and die after everyone's exhausted from a long discussion.
> 
> Is this an eV topic?

I guess it was rhetorical in which case I'll humor you: no, it's not an e.V. 
topic.

On a more serious tone: I'm actually concerned about such an early mention of 
an e.V. vote. This is the wrong tool and forum for this discussion.

Also, I don't see the need to assume what early that it'll lead to "everyone's 
exhausted from a long discussion". 

This assumption and the mention of a vote is IMHO setting the stage for the 
conversation to get out of hand before any indication that it otherwise 
would... a bit like a self fulfilling prophecy unfortunately. I hope we won't 
collectively walk into it.

I'd be more optimistic as despite initial push backs I see ways for a quick 
consensus to emerge on something different than the initial proposal.

Anyway, if it would get out of hand nonetheless (I could be wrong and too 
optimistic after all), I'd propose to have a volunteer and *neutral* 
facilitator talking independently to the various parties and producing a final 
proposal with high chances of consensus reaching. A bit like we did at the 
time of the production of the KDE Manifesto.

Note I wouldn't volunteer because obviously I got some more skin in the game 
this time and already engaged in the conversation. So if you're someone who 
didn't reply to this thread and have no strong opinion about the topic: keep 
monitoring that thread and maybe evaluate volunteering to facilitate if we 
start throwing mud at each other. ;-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Proposal unify back our release schedules

[Kevin Ottens]

Hello,

On Friday 19 April 2024 14:03:01 CEST Luigi Toscano wrote:
> Nate Graham ha scritto:
> > I expect a vast amount of discussion to result from this proposal, and I
> > think that's great. It'll be good to talk about it. But I suspect in the
> > end we'll likely not achieve 100% consensus, and in that event I'd like
> > for us to put it to a formal KDE e.V. vote so that the topic doesn't
> > become stale and die after everyone's exhausted from a long discussion.
> 
> Is this an eV topic?

I guess it was rhetorical in which case I'll humor you: no, it's not an e.V. 
topic.

On a more serious tone: I'm actually concerned about such an early mention of 
an e.V. vote. This is the wrong tool and forum for this discussion.

Also, I don't see the need to assume what early that it'll lead to "everyone's 
exhausted from a long discussion". 

This assumption and the mention of a vote is IMHO setting the stage for the 
conversation to get out of hand before any indication that it otherwise 
would... a bit like a self fulfilling prophecy unfortunately. I hope we won't 
collectively walk into it.

I'd be more optimistic as despite initial push backs I see ways for a quick 
consensus to emerge on something different than the initial proposal.

Anyway, if it would get out of hand nonetheless (I could be wrong and too 
optimistic after all), I'd propose to have a volunteer and *neutral* 
facilitator talking independently to the various parties and producing a final 
proposal with high chances of consensus reaching. A bit like we did at the 
time of the production of the KDE Manifesto.

Note I wouldn't volunteer because obviously I got some more skin in the game 
this time and already engaged in the conversation. So if you're someone who 
didn't reply to this thread and have no strong opinion about the topic: keep 
monitoring that thread and maybe evaluate volunteering to facilitate if we 
start throwing mud at each other. ;-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Proposal unify back our release schedules

[Kevin Ottens]

 us back to the kdelibs 
big ball of mud and high coupling of all apps Plasma and otherwise to this 
kdelibs-ng. We spent years trying to get out of this particular mess, I'd 
appreciate if we don't jump back into it.

It'd also mean that the progress made on third parties using KDE Frameworks 
would completely go away. And in "fool me once, not twice" fashion we'd hardly 
get a chance of attracting them again.

> In effect this proposal would mean:
>
> * We do one major release every 4 months and then minor releases with a
> frequency based on the Fibonacci numbers as this releases cycle works very
> well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could
> unify that for one or the other one. Or let each component keep their
> current versioning scheme depending whether we want to merge Plama and Gear
> as product or keep it separate. I'm a bit undecided about this.

Indeed, the Fibonacci approach seems to work well for stabilizing minor 
releases of apps. Still, between minor releases the cadence should be 
constant.

I think Gear and Plasma should be separate products. Which doesn't exclude 
moving some apps from Gear to Plasma. To me this both strengthen Plasma and 
Gear if we're clear where things stand.

If an application is in Plasma it is expected to have a mandatory deep 
integration with Plasma sessions. If it's in Gear it is expected to be 
portable, maybe it does more under a Plasma session, but it shouldn't be 
crippled by running outside of a Plasma session.

Also, on the Plasma and Gear products I think it should be clearer which KDE 
Frameworks version is targeted.

> * "KDE Framework" will still exists as an entity and its ABI and API 
> compatibility requirement. Only change is the release frequency and the 
> introduction of a stable branch in sync with the other components.

I hope by now I made the case clear that the release cadence of this one is an 
intended feature and not a bug. In my opinion, any pain KDE Frameworks being 
on its own cadence creates somewhere else should be treated as a symptom of a 
structural problem and addressed for what it is (decoupling required, some 
component in the wrong product being an issue in the dependency chain, missing 
QA or automated tests to catch regressions, etc.).

Fun fact: "back then" we even toyed with the idea of an even faster cadence, 
it'd require quite some more automated QA and so was left on the side.
I still think it would be a possibility for a subset of frameworks for go on a 
faster cadence, but let's not open that can of worms.

> * Only have one release announcement on our website. We can call it
> Megarelease 6.XX like we did for Plasma 6/Gear 24.02 or find a better name.
> I would avoid reusing Software Collection first because the name is quite
> technical and second because these was already used in the past.

Sure, why not. This is not engineering I'm less opinionated about it. Apart 
from decoupling more between engineering effort and marketing announcements 
that is.

Maybe reconsider the "Megarelease" term though... I've literally been laughed 
at for the use of that term outside of our community. Also, I think it was a 
fine term for a one off when moving on a major new version of Qt, but it'll 
get old quickly for the "business as usual".

Again no strong opinion there, but I thought I'd mention what I've seen around 
me.

Regards.
--
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Proposal unify back our release schedules

[Kevin Ottens]

 us back to the kdelibs 
big ball of mud and high coupling of all apps Plasma and otherwise to this 
kdelibs-ng. We spent years trying to get out of this particular mess, I'd 
appreciate if we don't jump back into it.

It'd also mean that the progress made on third parties using KDE Frameworks 
would completely go away. And in "fool me once, not twice" fashion we'd hardly 
get a chance of attracting them again.

> In effect this proposal would mean:
>
> * We do one major release every 4 months and then minor releases with a
> frequency based on the Fibonacci numbers as this releases cycle works very
> well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could
> unify that for one or the other one. Or let each component keep their
> current versioning scheme depending whether we want to merge Plama and Gear
> as product or keep it separate. I'm a bit undecided about this.

Indeed, the Fibonacci approach seems to work well for stabilizing minor 
releases of apps. Still, between minor releases the cadence should be 
constant.

I think Gear and Plasma should be separate products. Which doesn't exclude 
moving some apps from Gear to Plasma. To me this both strengthen Plasma and 
Gear if we're clear where things stand.

If an application is in Plasma it is expected to have a mandatory deep 
integration with Plasma sessions. If it's in Gear it is expected to be 
portable, maybe it does more under a Plasma session, but it shouldn't be 
crippled by running outside of a Plasma session.

Also, on the Plasma and Gear products I think it should be clearer which KDE 
Frameworks version is targeted.

> * "KDE Framework" will still exists as an entity and its ABI and API 
> compatibility requirement. Only change is the release frequency and the 
> introduction of a stable branch in sync with the other components.

I hope by now I made the case clear that the release cadence of this one is an 
intended feature and not a bug. In my opinion, any pain KDE Frameworks being 
on its own cadence creates somewhere else should be treated as a symptom of a 
structural problem and addressed for what it is (decoupling required, some 
component in the wrong product being an issue in the dependency chain, missing 
QA or automated tests to catch regressions, etc.).

Fun fact: "back then" we even toyed with the idea of an even faster cadence, 
it'd require quite some more automated QA and so was left on the side.
I still think it would be a possibility for a subset of frameworks for go on a 
faster cadence, but let's not open that can of worms.

> * Only have one release announcement on our website. We can call it
> Megarelease 6.XX like we did for Plasma 6/Gear 24.02 or find a better name.
> I would avoid reusing Software Collection first because the name is quite
> technical and second because these was already used in the past.

Sure, why not. This is not engineering I'm less opinionated about it. Apart 
from decoupling more between engineering effort and marketing announcements 
that is.

Maybe reconsider the "Megarelease" term though... I've literally been laughed 
at for the use of that term outside of our community. Also, I think it was a 
fine term for a one off when moving on a major new version of Qt, but it'll 
get old quickly for the "business as usual".

Again no strong opinion there, but I thought I'd mention what I've seen around 
me.

Regards.
--
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

[Discover] [Bug 476654] Allow Discover to manually update updateable Snaps

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED
  Latest Commit||https://invent.kde.org/plas
   ||ma/discover/-/commit/03f3e0
   ||5cae6484126410efef0f4e43310
   ||cb92e10

--- Comment #6 from Kevin Ottens  ---
Git commit 03f3e05cae6484126410efef0f4e43310cb92e10 by Kevin Ottens, on behalf
of Kevin Ottens.
Committed on 05/04/2024 at 07:03.
Pushed by ervin into branch 'master'.

snap: place a refresh request for upgradeable packages

This allows to manually upgrade snap packages as well.

M  +2-0libdiscover/backends/SnapBackend/SnapTransaction.cpp

https://invent.kde.org/plasma/discover/-/commit/03f3e05cae6484126410efef0f4e43310cb92e10

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: 32 bit build failure (smb, narrowing)

[Kevin Ottens]

Hello,

Sorry for the delay, end of last week has been a bit hectic... I see you 
already made a fix. Thanks a lot!

Regards.

On Friday, 8 March 2024 08:23:29 CET Rene Engelhard wrote:
> Hi,
> 
> see
> https://buildd.debian.org/status/fetch.php?pkg=libreoffice=i386=4%3
> A24.2.2~rc1-1=1709881487=1:
> 
> /<>/sal/osl/unx/file.cxx: In function ‘void
> osl_file_adjustLockFlags(const rtl::OString&, int*, sal_uInt32*)’:
> /<>/sal/osl/unx/file.cxx:71:26: error: narrowing conversion
> of ‘4283649346’ from ‘unsigned int’ to ‘int’ [-Wnarrowing]
> 71 | #define CIFS_SUPER_MAGIC 0xFF534D42
> 
>|  ^~
> 
> /<>/sal/osl/unx/file.cxx:795:14: note: in expansion of
> macro ‘CIFS_SUPER_MAGIC’
> 
>795 | case CIFS_SUPER_MAGIC:
>|  ^~~~
> 
> /<>/sal/osl/unx/file.cxx:72:26: error: narrowing conversion
> of ‘4266872130’ from ‘unsigned int’ to ‘int’ [-Wnarrowing]
> 72 | #define SMB2_SUPER_MAGIC 0xFE534D42
> 
>|  ^~
> 
> /<>/sal/osl/unx/file.cxx:796:14: note: in expansion of
> macro ‘SMB2_SUPER_MAGIC’
> 
>796 | case SMB2_SUPER_MAGIC:
>|  ^~~~
> 
> make[2]: *** [/<>/solenv/gbuild/LinkTarget.mk:340:
> /<>/workdir/CxxObject/sal/osl/unx/file.o] Error 1
> 
> This is due to
> 
> commit a8814b5921676b1c01a19b0af243712c55fb0307
> Author: Kevin Ottens 
> Date:   Fri Feb 2 15:39:36 2024 +0100
> 
>  tdf#55004 Fix backup copy creation for files on mounted samba shares
> 
>  There is an unfortunate interaction between file locking and backup
>  creation at save time.
> 
>  openFilePath has logic to lock a file when opening. This goes through
>  fcntl to set a write lock on the file. Later on, when the user wants to
> save changes, a backup copy might be created (very likely now since this
>  is the defaults in the settings). To create this backup, the file is
>  opened again for reading. Unfortunately this open call fails due to the
> lock (even though it is a write lock).
> 
>  This commit changes the behavior. osl_file_adjustLockFlags now
> checks if
>  the file is on a mounted samba share. If that's the case we force the
>  osl_File_OpenFlag_NoLock flag. No issue is then exhibited at backup
>  creation, allowing the save to proceed properly.
> 
>  Change-Id: Ieab252f9f68598834e13339fc5fcea440f0a4c2f
>  Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162935
>  Tested-by: Jenkins
>  Reviewed-by: Stephan Bergmann 
>  (cherry picked from commit 63efbc8ad8aae12b54e649c1495d1233c1a9b33f)
>  Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163549
> 
> Can you have a look, please? I had a brief one, but that is a simple
> define which shoudln't break. Then the switch does
>  switch (aFileStatFs.f_type) {
> which uses
>  struct statfs aFileStatFs;
> 
> So it probably is a type difference in the kernel struct already for 32
> vs 64 bit?
> 
> Regards,
> 
> Rene


-- 
Kévin Ottens
kevin.ott...@enioka.com
+33 7 57 08 95 13

core.git: Branch 'libreoffice-24-2' - sal/osl

[Kevin Ottens (via logerrit)]

 sal/osl/unx/file.cxx |   54 ---
 1 file changed, 47 insertions(+), 7 deletions(-)

New commits:
commit a8814b5921676b1c01a19b0af243712c55fb0307
Author: Kevin Ottens 
AuthorDate: Fri Feb 2 15:39:36 2024 +0100
Commit: Stephan Bergmann 
CommitDate: Mon Feb 19 21:14:59 2024 +0100

tdf#55004 Fix backup copy creation for files on mounted samba shares

There is an unfortunate interaction between file locking and backup
creation at save time.

openFilePath has logic to lock a file when opening. This goes through
fcntl to set a write lock on the file. Later on, when the user wants to
save changes, a backup copy might be created (very likely now since this
is the defaults in the settings). To create this backup, the file is
opened again for reading. Unfortunately this open call fails due to the
lock (even though it is a write lock).

This commit changes the behavior. osl_file_adjustLockFlags now checks if
the file is on a mounted samba share. If that's the case we force the
osl_File_OpenFlag_NoLock flag. No issue is then exhibited at backup
creation, allowing the save to proceed properly.

Change-Id: Ieab252f9f68598834e13339fc5fcea440f0a4c2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162935
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 
(cherry picked from commit 63efbc8ad8aae12b54e649c1495d1233c1a9b33f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163549

diff --git a/sal/osl/unx/file.cxx b/sal/osl/unx/file.cxx
index 7c803fd8..0ca8822016e1 100644
--- a/sal/osl/unx/file.cxx
+++ b/sal/osl/unx/file.cxx
@@ -64,6 +64,14 @@
 #include 
 #endif
 
+#ifdef LINUX
+#include 
+// As documented by the kernel
+#define SMB_SUPER_MAGIC  0x517B
+#define CIFS_SUPER_MAGIC 0xFF534D42
+#define SMB2_SUPER_MAGIC 0xFE534D42
+#endif
+
 namespace {
 
 enum class State
@@ -736,9 +744,11 @@ oslFileHandle osl::detail::createFileHandleFromFD(int fd)
 return static_cast(pImpl);
 }
 
-static int osl_file_adjustLockFlags(const OString& path, int flags)
+static void osl_file_adjustLockFlags(const OString& path, int *flags, 
sal_uInt32 *uFlags)
 {
 #ifdef MACOSX
+(void) uFlags;
+
 /*
  * The AFP implementation of MacOS X 10.4 treats O_EXLOCK in a way
  * that makes it impossible for OOo to create a backup copy of the
@@ -751,20 +761,50 @@ static int osl_file_adjustLockFlags(const OString& path, 
int flags)
 {
 if(strncmp("afpfs", s.f_fstypename, 5) == 0)
 {
-flags &= ~O_EXLOCK;
-flags |=  O_SHLOCK;
+*flags &= ~O_EXLOCK;
+*flags |=  O_SHLOCK;
 }
 else
 {
 /* Needed flags to allow opening a webdav file */
-flags &= ~(O_EXLOCK | O_SHLOCK | O_NONBLOCK);
+*flags &= ~(O_EXLOCK | O_SHLOCK | O_NONBLOCK);
+}
+}
+#elif defined(LINUX)
+(void) flags;
+
+/* get filesystem info */
+struct statfs aFileStatFs;
+if (statfs(path.getStr(), ) < 0)
+{
+int e = errno;
+SAL_INFO("sal.file", "statfs(" << path << "): " << UnixErrnoString(e));
+}
+else
+{
+SAL_INFO("sal.file", "statfs(" << path << "): OK");
+
+// We avoid locking if on a Linux CIFS mount otherwise this
+// fill fail later on when opening the file for reading
+// during backup creation at save time (even though this is a
+// write lock and not a read lock).
+// Fixes the following bug:
+// https://bugs.documentfoundation.org/show_bug.cgi?id=55004
+switch (aFileStatFs.f_type) {
+case SMB_SUPER_MAGIC:
+case CIFS_SUPER_MAGIC:
+case SMB2_SUPER_MAGIC:
+*uFlags |= osl_File_OpenFlag_NoLock;
+break;
+default:
+break;
 }
 }
 #else
 (void) path;
+(void) flags;
+(void) uFlags;
 #endif
-
-return flags;
 }
 
 static bool osl_file_queryLocking(sal_uInt32 uFlags)
@@ -981,7 +1021,7 @@ oslFileError openFilePath(const OString& filePath, 
oslFileHandle* pHandle,
 }
 else
 {
-flags = osl_file_adjustLockFlags (filePath, flags);
+osl_file_adjustLockFlags (filePath, , );
 }
 
 // O_EXCL can be set only when O_CREAT is set

Kevin Ottens license statement

[Kevin Ottens]

Hello,

Since I've submitted my first patch, I've been requested to send such a 
statement, so here it is:

All of my past & future contributions to LibreOffice may be licensed under the 
MPLv2/LGPLv3+ dual license.

Regards.
-- 
Kévin Ottens
kevin.ott...@enioka.com
+33 7 57 08 95 13

core.git: sal/osl

[Kevin Ottens (via logerrit)]

 sal/osl/unx/file.cxx |   54 ---
 1 file changed, 47 insertions(+), 7 deletions(-)

New commits:
commit 63efbc8ad8aae12b54e649c1495d1233c1a9b33f
Author: Kevin Ottens 
AuthorDate: Fri Feb 2 15:39:36 2024 +0100
Commit: Stephan Bergmann 
CommitDate: Sun Feb 18 14:39:57 2024 +0100

tdf#55004 Fix backup copy creation for files on mounted samba shares

There is an unfortunate interaction between file locking and backup
creation at save time.

openFilePath has logic to lock a file when opening. This goes through
fcntl to set a write lock on the file. Later on, when the user wants to
save changes, a backup copy might be created (very likely now since this
is the defaults in the settings). To create this backup, the file is
opened again for reading. Unfortunately this open call fails due to the
lock (even though it is a write lock).

This commit changes the behavior. osl_file_adjustLockFlags now checks if
the file is on a mounted samba share. If that's the case we force the
osl_File_OpenFlag_NoLock flag. No issue is then exhibited at backup
creation, allowing the save to proceed properly.

Change-Id: Ieab252f9f68598834e13339fc5fcea440f0a4c2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162935
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann 

diff --git a/sal/osl/unx/file.cxx b/sal/osl/unx/file.cxx
index 5acfe2803189..03d685a997e9 100644
--- a/sal/osl/unx/file.cxx
+++ b/sal/osl/unx/file.cxx
@@ -64,6 +64,14 @@
 #include 
 #endif
 
+#ifdef LINUX
+#include 
+// As documented by the kernel
+#define SMB_SUPER_MAGIC  0x517B
+#define CIFS_SUPER_MAGIC 0xFF534D42
+#define SMB2_SUPER_MAGIC 0xFE534D42
+#endif
+
 namespace {
 
 enum class State
@@ -736,9 +744,11 @@ oslFileHandle osl::detail::createFileHandleFromFD(int fd)
 return static_cast(pImpl);
 }
 
-static int osl_file_adjustLockFlags(const OString& path, int flags)
+static void osl_file_adjustLockFlags(const OString& path, int *flags, 
sal_uInt32 *uFlags)
 {
 #ifdef MACOSX
+(void) uFlags;
+
 /*
  * The AFP implementation of MacOS X 10.4 treats O_EXLOCK in a way
  * that makes it impossible for OOo to create a backup copy of the
@@ -751,20 +761,50 @@ static int osl_file_adjustLockFlags(const OString& path, 
int flags)
 {
 if(strncmp("afpfs", s.f_fstypename, 5) == 0)
 {
-flags &= ~O_EXLOCK;
-flags |=  O_SHLOCK;
+*flags &= ~O_EXLOCK;
+*flags |=  O_SHLOCK;
 }
 else
 {
 /* Needed flags to allow opening a webdav file */
-flags &= ~(O_EXLOCK | O_SHLOCK | O_NONBLOCK);
+*flags &= ~(O_EXLOCK | O_SHLOCK | O_NONBLOCK);
+}
+}
+#elif defined(LINUX)
+(void) flags;
+
+/* get filesystem info */
+struct statfs aFileStatFs;
+if (statfs(path.getStr(), ) < 0)
+{
+int e = errno;
+SAL_INFO("sal.file", "statfs(" << path << "): " << UnixErrnoString(e));
+}
+else
+{
+SAL_INFO("sal.file", "statfs(" << path << "): OK");
+
+// We avoid locking if on a Linux CIFS mount otherwise this
+// fill fail later on when opening the file for reading
+// during backup creation at save time (even though this is a
+// write lock and not a read lock).
+// Fixes the following bug:
+// https://bugs.documentfoundation.org/show_bug.cgi?id=55004
+switch (aFileStatFs.f_type) {
+case SMB_SUPER_MAGIC:
+case CIFS_SUPER_MAGIC:
+case SMB2_SUPER_MAGIC:
+*uFlags |= osl_File_OpenFlag_NoLock;
+break;
+default:
+break;
 }
 }
 #else
 (void) path;
+(void) flags;
+(void) uFlags;
 #endif
-
-return flags;
 }
 
 static bool osl_file_queryLocking(sal_uInt32 uFlags)
@@ -981,7 +1021,7 @@ oslFileError openFilePath(const OString& filePath, 
oslFileHandle* pHandle,
 }
 else
 {
-flags = osl_file_adjustLockFlags (filePath, flags);
+osl_file_adjustLockFlags (filePath, , );
 }
 
 // O_EXCL can be set only when O_CREAT is set

[okular] [Bug 478276] Wrong paper color until zoom when overprint preview enabled

[Kevin Ottens]

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

--- Comment #9 from Kevin Ottens  ---
I can indeed confirm it. Now I don't have much bandwidth at the moment, so
don't hold your breath... in any case, at first glance, it looks like it might
be something in Poppler/Qt rather than Okular itself.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 478276] Wrong paper color until zoom when overprint preview enabled

[Kevin Ottens]

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

--- Comment #9 from Kevin Ottens  ---
I can indeed confirm it. Now I don't have much bandwidth at the moment, so
don't hold your breath... in any case, at first glance, it looks like it might
be something in Poppler/Qt rather than Okular itself.

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

[lokalize] [Bug 477039] lokalize does not open project file using --project

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Latest Commit||https://invent.kde.org/fram
   ||eworks/kio/-/commit/01a9c8c
   ||06dec7d748ed964c9e2f2c4091f
   ||9c125a
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Kevin Ottens  ---
Git commit 01a9c8c06dec7d748ed964c9e2f2c4091f9c125a by Kevin Ottens, on behalf
of Kevin Ottens.
Committed on 23/01/2024 at 09:46.
Pushed by ervin into branch 'master'.

KDirModel: Consider invalid roots are local fs

If the item set on a node (typically the root node) was null it was
implicitly considered local fs. But if the item was not null and the
url invalid, it'd be considered network fs.

In the context of KDirModel caching of the fs type guessing this would
mean we'd wrongly assume the whole tree is network fs even if it's not.

That's why we change this to consider non-null items with invalid URLs
as local fs.

M  +5-1src/widgets/kdirmodel.cpp

https://invent.kde.org/frameworks/kio/-/commit/01a9c8c06dec7d748ed964c9e2f2c4091f9c125a

-- 
You are receiving this mail because:
You are watching all bug changes.

[lokalize] [Bug 477039] lokalize does not open project file using --project

[Kevin Ottens]

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

--- Comment #7 from Kevin Ottens  ---
To be expected, nobody reviewed the patch, feels like it fell through the
cracks. I'll poke.

-- 
You are receiving this mail because:
You are watching all bug changes.

[lokalize] [Bug 477039] lokalize does not open project file using --project

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

 CC||er...@kde.org

--- Comment #5 from Kevin Ottens  ---
So now we got a MR for KIO which should fix this. Indeed, Lokalize seems to
exploit a corner case in KDirModel's API and the previous patch slightly
changed the behavior for this particular case.

This being said, it's one of those where I think we can consider the bug
"shared" between KDirModel and Lokalize. It looks like this just uncovered
another bug in Lokalize itself, I suspect it didn't really work as it should
previously and might have cases where it'd break anyway. 

Indeed, the project model wrapping KDirModel in Lokalize seems to use rowCount
but not canFetchMore/fetchMode to decide to go one level down the hierarchy.
This is a bit optimistic in the general case since models (like KDirModel) can
decide to not eagerly fetch children nodes. Also it set an invalid url as the
root of the model which is allowed but I think a bit fishy.

I don't know Lokalize enough to feel confident investing the time to look
deeper into how this project model works, I'd probably just unwillingly break
it. Also, the MR in KIO does the job for now... still revisiting the project
model in Lokalize might be worth it at some point.

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now

[Kevin Ottens]

Hello,

On Sunday, 5 November 2023 15:32:21 CET christ...@cullmann.io wrote:
> On 2023-11-05 15:11, Nate Graham wrote:
> > Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make
> > them haul in Plasma stuff.
> 
> some applications link to kactivities, too.
> I think it just makes it more clear that this will just work with
> Plasma.
>
> But I can live with the status quo, too, just thought it would be
> cleaner.

Yes, I think it'd make sense to have a clearer and cleaner separation between 
KDE Frameworks dependencies which can work outside of a Plasma sessions and 
libraries which require Plasma runtime components.

I was clumsily advocating for this Akademy 2021 or 2022 (can't remember 
which).

This way it's clearer to application authors when they tie themselves to a 
given workspace or not.

Also, isn't Elisa able to work without Baloo? It even seems to do the right 
thing if I trust its CMakeLists.txt. It has Baloo as a recommended but 
optional dependency, and disable it altogether for Win32 builds.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now

[Kevin Ottens]

Hello,

On Sunday, 5 November 2023 15:32:21 CET christ...@cullmann.io wrote:
> On 2023-11-05 15:11, Nate Graham wrote:
> > Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make
> > them haul in Plasma stuff.
> 
> some applications link to kactivities, too.
> I think it just makes it more clear that this will just work with
> Plasma.
>
> But I can live with the status quo, too, just thought it would be
> cleaner.

Yes, I think it'd make sense to have a clearer and cleaner separation between 
KDE Frameworks dependencies which can work outside of a Plasma sessions and 
libraries which require Plasma runtime components.

I was clumsily advocating for this Akademy 2021 or 2022 (can't remember 
which).

This way it's clearer to application authors when they tie themselves to a 
given workspace or not.

Also, isn't Elisa able to work without Baloo? It even seems to do the right 
thing if I trust its CMakeLists.txt. It has Baloo as a recommended but 
optional dependency, and disable it altogether for Win32 builds.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

[frameworks-kio] [Bug 474451] Okular cannot save

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

  Latest Commit|https://invent.kde.org/fram |https://invent.kde.org/fram
   |eworks/kio/-/commit/a6f7d31 |eworks/kio/-/commit/48322f4
   |17f159f3e0a88ff08b5f69b9bc8 |4323a1fc09305d66d9093fe6c37
   |612cf7  |80709e

--- Comment #17 from Kevin Ottens  ---
Git commit 48322f44323a1fc09305d66d9093fe6c3780709e by Kevin Ottens, on behalf
of Kevin Ottens.
Committed on 15/09/2023 at 19:00.
Pushed by ngraham into branch 'kf5'.

Don't crash if KMountPoint gives nothing back while checking for CIFS

M  +3-0src/ioslaves/file/file_unix.cpp

https://invent.kde.org/frameworks/kio/-/commit/48322f44323a1fc09305d66d9093fe6c3780709e

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 474451] Okular cannot save

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

  Latest Commit||https://invent.kde.org/fram
   ||eworks/kio/-/commit/a6f7d31
   ||17f159f3e0a88ff08b5f69b9bc8
   ||612cf7
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #13 from Kevin Ottens  ---
Git commit a6f7d3117f159f3e0a88ff08b5f69b9bc8612cf7 by Kevin Ottens, on behalf
of Kevin Ottens.
Committed on 15/09/2023 at 13:34.
Pushed by ervin into branch 'master'.

Don't crash if KMountPoint gives nothing back while checking for CIFS

M  +3-0src/kioworkers/file/file_unix.cpp

https://invent.kde.org/frameworks/kio/-/commit/a6f7d3117f159f3e0a88ff08b5f69b9bc8612cf7

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454693] Okular throws error when saving to mounted Samba share

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

  Latest Commit|https://invent.kde.org/fram |https://invent.kde.org/fram
   |eworks/kio/-/commit/d248949 |eworks/kio/-/commit/3e6800b
   |eea3e3dcbb9283f30eebcb9ae86 |378cd143cb9c4ca4cfa500916a5
   |412cd1  |e5c17c

--- Comment #16 from Kevin Ottens  ---
Git commit 3e6800b378cd143cb9c4ca4cfa500916a5e5c17c by Kevin Ottens, on behalf
of Kevin Ottens.
Committed on 24/08/2023 at 19:02.
Pushed by ervin into branch 'kf5'.

Don't unlink + rename on CIFS mounts during copy operations

It turns out that the behavior of unlink() on CIFS mounts can be a bit
"interesting". If the file one tries to unlink is opened then the
operation is claimed to have succeeded but the filename is still visible
in the file hierarchy until the last handle is closed.

Since we rightfully attempt to copy under a temporary name + unlink +
rename during copy() operations this would end badly (as the unlink()
would "succeed" but the rename() would fail!). For instance Okular would
constantly hit this case but it's likely not the only one to be affected.

So instead we detect if the destination is a CIFS mount, in such cases
we now overwrite the file directly since this actually succeed.
(cherry picked from commit d248949eea3e3dcbb9283f30eebcb9ae86412cd1)

M  +7-1src/ioslaves/file/file_unix.cpp

https://invent.kde.org/frameworks/kio/-/commit/3e6800b378cd143cb9c4ca4cfa500916a5e5c17c

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

[okular] [Bug 454693] Okular throws error when saving to mounted Samba share

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

  Latest Commit|https://invent.kde.org/fram |https://invent.kde.org/fram
   |eworks/kio/-/commit/d248949 |eworks/kio/-/commit/3e6800b
   |eea3e3dcbb9283f30eebcb9ae86 |378cd143cb9c4ca4cfa500916a5
   |412cd1  |e5c17c

--- Comment #16 from Kevin Ottens  ---
Git commit 3e6800b378cd143cb9c4ca4cfa500916a5e5c17c by Kevin Ottens, on behalf
of Kevin Ottens.
Committed on 24/08/2023 at 19:02.
Pushed by ervin into branch 'kf5'.

Don't unlink + rename on CIFS mounts during copy operations

It turns out that the behavior of unlink() on CIFS mounts can be a bit
"interesting". If the file one tries to unlink is opened then the
operation is claimed to have succeeded but the filename is still visible
in the file hierarchy until the last handle is closed.

Since we rightfully attempt to copy under a temporary name + unlink +
rename during copy() operations this would end badly (as the unlink()
would "succeed" but the rename() would fail!). For instance Okular would
constantly hit this case but it's likely not the only one to be affected.

So instead we detect if the destination is a CIFS mount, in such cases
we now overwrite the file directly since this actually succeed.
(cherry picked from commit d248949eea3e3dcbb9283f30eebcb9ae86412cd1)

M  +7-1src/ioslaves/file/file_unix.cpp

https://invent.kde.org/frameworks/kio/-/commit/3e6800b378cd143cb9c4ca4cfa500916a5e5c17c

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454693] Okular throws error when saving to mounted Samba share

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

  Latest Commit||https://invent.kde.org/fram
   ||eworks/kio/-/commit/d248949
   ||eea3e3dcbb9283f30eebcb9ae86
   ||412cd1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Kevin Ottens  ---
Git commit d248949eea3e3dcbb9283f30eebcb9ae86412cd1 by Kevin Ottens, on behalf
of Kevin Ottens.
Committed on 24/08/2023 at 18:42.
Pushed by ervin into branch 'master'.

Don't unlink + rename on CIFS mounts during copy operations

It turns out that the behavior of unlink() on CIFS mounts can be a bit
"interesting". If the file one tries to unlink is opened then the
operation is claimed to have succeeded but the filename is still visible
in the file hierarchy until the last handle is closed.

Since we rightfully attempt to copy under a temporary name + unlink +
rename during copy() operations this would end badly (as the unlink()
would "succeed" but the rename() would fail!). For instance Okular would
constantly hit this case but it's likely not the only one to be affected.

So instead we detect if the destination is a CIFS mount, in such cases
we now overwrite the file directly since this actually succeed.

M  +7-1src/kioworkers/file/file_unix.cpp

https://invent.kde.org/frameworks/kio/-/commit/d248949eea3e3dcbb9283f30eebcb9ae86412cd1

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

[okular] [Bug 454693] Okular throws error when saving to mounted Samba share

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

  Latest Commit||https://invent.kde.org/fram
   ||eworks/kio/-/commit/d248949
   ||eea3e3dcbb9283f30eebcb9ae86
   ||412cd1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Kevin Ottens  ---
Git commit d248949eea3e3dcbb9283f30eebcb9ae86412cd1 by Kevin Ottens, on behalf
of Kevin Ottens.
Committed on 24/08/2023 at 18:42.
Pushed by ervin into branch 'master'.

Don't unlink + rename on CIFS mounts during copy operations

It turns out that the behavior of unlink() on CIFS mounts can be a bit
"interesting". If the file one tries to unlink is opened then the
operation is claimed to have succeeded but the filename is still visible
in the file hierarchy until the last handle is closed.

Since we rightfully attempt to copy under a temporary name + unlink +
rename during copy() operations this would end badly (as the unlink()
would "succeed" but the rename() would fail!). For instance Okular would
constantly hit this case but it's likely not the only one to be affected.

So instead we detect if the destination is a CIFS mount, in such cases
we now overwrite the file directly since this actually succeed.

M  +7-1src/kioworkers/file/file_unix.cpp

https://invent.kde.org/frameworks/kio/-/commit/d248949eea3e3dcbb9283f30eebcb9ae86412cd1

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: Splitting KGlobalAccel interface and runtime

[Kevin Ottens]

Hello,

On Monday, 13 February 2023 21:25:54 CET Vlad Zahorodnii wrote:
> On 2/13/23 22:05, Nicolas Fella wrote:
> > Hi,
> > 
> > the kglobalaccel framework currently contains two pieces: kglobalacceld,
> > the runtime component that manages global shortcuts, and an
> > application-side library to interact with it.
> > 
> > The two communicate with each other via DBus. On X11 there is a
> > standalone kglobalacceld5 process providing the interface, on Wayland
> > the runtime is linked into KWin and thus the kwin_wayland process
> > provides the interface.
> > 
> > The current architecture has a number of downsides:
> > 
> > - Any call to the KGlobalAccel library may DBus-activate the
> > kglobalacceld5 process, which may be undesired on Desktop other than
> > Plasma since it competes with their native shortcut system. We tried
> > fixing that by making such calls no-op on !Plasma, but that broke things
> > for people that did want it to run, for example people using KWin with
> > LXQt, because KWin relies on KGlobalAccel for shortcuts
> > 
> > - We want to keep the dependencies of the interface library minimal,
> > which is inconvenient for the development of the runtime part. For
> > example we really want to use KIO::ApplicationLauncherJob in the
> > runtime, but currently can't, because that would introduce a dependency
> > cycle in Frameworks (KIO depends on KXmlGui, which depends on
> > KGlobalAccel, which would depend on KIO)
> > 
> > - Coinstallability of KF5 and KF6. Conceptually there can only be one
> > kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel install a
> > kglobalacceld this is going to be problematic. This also means that a
> > KF6-based kglobalacceld must work with a KF5 interface library
> > 
> > - Other shortcut daemon implementations. Since somewhat recently there
> > is an XDG Portal for global shortcuts. Platforms like Windows and macOS
> > also have ways for applications to register global shortcuts. While we
> > are currently not using any of these it's very well possible that we
> > would eventually want to use the KGlobalAccel interface library to
> > interact with those. Having the kglobalacceld runtime in the same
> > frameworks therefore doesn't feel right.
> > 
> > To address these issues I suggest we split out the runtime part of
> > kglobalaccel into its own project, under the Plasma release group,
> > because that's primarily where it's used/supported. The interface
> > library would remain in frameworks. We have a similar situation with
> > activities, where the manager (kactivitymanagerd) is in Plasma and the
> > interface is in Frameworks. When doing this we'd also change the way how
> > kglobalacceld is started away from DBus activation towards explicitly
> > starting it as part of the Plasma startup. This avoids accidentally
> > launching it when it shouldn't be but still allows to explicitly start
> > outside of Plasma if really wanted. It would also allow for greater
> > flexibility in the development of the runtime, especially around
> > dependency constraints.
> > 
> > It wouldn't automatically solve the coinstallability problem of KF5 and
> > KF6, because a kglobalacceld provided by KF5-KGlobalAccel would still
> > conflict with a Plasma-provided kglobalacceld, but it's at least
> > conceptually less messy since it's clear that the Plasma-provided one
> > would be the preferred one to use.
> > 
> > Thoughts about this?
> 
> +1
> 
> There's one caveat though: given that the library and the runtime parts
> will have different release schedules, we will have to be careful about
> protocol changes. Perhaps we could borrow a thing or two from activities?

Or... move both runtime and API on the Plasma side? This way no problem of 
different release schedules and it makes it clear that using it ties you to a 
specific desktop anyway?

With a quick grep it looks like most of the users are already shipped with 
Plasma or desktop specific anyway. Granted that leaves with a couple of tough 
nuts to crack though.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

[Planet KDE] [Bug 458350] Remove Kevin Otten's "Web review" from Planet feed

[Kevin Ottens]

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

--- Comment #7 from Kevin Ottens  ---
Ah also, for the record: I also got at least a yearly Akademy post and one KDE
PIM Summary (should be later this year for both). Granted it's not much.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Planet KDE] [Bug 458350] Remove Kevin Otten's "Web review" from Planet feed

[Kevin Ottens]

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

--- Comment #6 from Kevin Ottens  ---
Yeah well, I wish I could post more KDE content but lately... well... life. I
started this web review for two reasons:
 1. it's actually my coping strategy for the guilt of not finding the time to
write more original content
 2. I see it as a service to the KDE community to get a chance to see what
happens in other tech circles (I know very well how as a contributor we can
tend to not be exposed much to trends outside our bubble).

At least from the comments here and emails I received during the past year (2)
seems to be somewhat working I guess.

-- 
You are receiving this mail because:
You are watching all bug changes.

[yakuake] [Bug 377955] yakuake does no longer accept input

[Kevin Ottens]

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

--- Comment #6 from Kevin Ottens  ---
Seems to be related to ibus not starting anymore somehow:
systemctl --user status 'app-ibus\x2dautostart@autostart.service'

Shows the service as failed. If I force the start:
systemctl --user start 'app-ibus\x2dautostart@autostart.service'

Then it all works fine again.

Only thing I could find in the logs related to this is:
Aug 30 16:23:50 wintermute systemd[1987]:
app-ibus\x2dautostart@autostart.service: start operation timed out.
Terminating.
Aug 30 16:23:50 wintermute systemd[1987]:
app-ibus\x2dautostart@autostart.service: Failed with result 'timeout'.

-- 
You are receiving this mail because:
You are watching all bug changes.

[yakuake] [Bug 377955] yakuake does no longer accept input

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

 CC||er...@kde.org

--- Comment #5 from Kevin Ottens  ---
I have the same issue, two things I noted though which make me wonder if that's
really a yakuake bug though:
 1. if I kill yakuake and launch it again, then it works just fine
 2. keepassxc is also affected

I didn't spot any other application which are affected though.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kwallet] [Bug 458085] Wallet system takes about 1 minute to start

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

 CC||er...@kde.org

--- Comment #1 from Kevin Ottens  ---
For the record this seems to be somehow related to the Server Service DBus API.
I didn't downgrade but just disabling this in systemsettings solved the issue
for me.

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: request to move Zanshin to KDE Gear

[Kevin Ottens]

Hello,

On Tuesday, 26 October 2021 22:12:47 CEST Albert Astals Cid wrote:
> El dimarts, 26 d’octubre de 2021, a les 20:58:13 (CEST), Jonathan Riddell va 
escriure:
> > Hola, me and Kevin would like to move the To Do manager Zanshin to be
> > released with KDE Gear.  I've done some sanity review today on it.  Can it
> > be released with KDE Gear 21.12?
> 
> If we don't count your commits from today, it seems slightly "under
> developed" lately, but let's see if actually getting releases means people
> do more commits ;)

At least the fact that it's on the same beat than the rest of KDE PIM should 
make a few things easier. It's been sometimes a bit of a pain to strike the 
right release time if some SC changes happened in PIM (which actually happened 
recently).

Not sure I'll find time to do more commits, but it'll definitely lower my 
mental load, there's been a couple of times in the past where I was pondering 
between "should I spend time on a release" and "should I spend time on that 
cleanup/feature". Less options fighting for my attention.

> If no one disagrees I'll add it to the release-tools/modules.git file on Nov
> 2nd.

Thanks!

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: request to move Zanshin to KDE Gear

[Kevin Ottens]

Hello,

On Tuesday, 26 October 2021 21:02:10 CEST David Faure wrote:
> On mardi 26 octobre 2021 20:58:13 CEST Jonathan Riddell wrote:
> > Hola, me and Kevin would like to move the To Do manager Zanshin to be
> > released with KDE Gear.  I've done some sanity review today on it.  Can it
> > be released with KDE Gear 21.12?
> > 
> > https://invent.kde.org/pim/zanshin/
> > https://zanshin.kde.org/
> > https://apps.kde.org/zanshin/
> 
> Thumbs up from me, I use this app every day, and it's really time for a new
> release indeed.

Yes, master even contains a couple of things the latest release doesn't 
have... I just couldn't get around to make a proper release.

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Croutons in kdereview

[Kevin Ottens]

Hello,

I don't think Jonah's question got an answer. If it did somehow it didn't show 
up in my mail client and my apologies in advance. :-)

In any case I've been wondering exactly the same thing. I'm asking because the 
fate of libraries like QCoro and Croutons would be to end up in KDE Frameworks 
at some point (at least would make sense to me). It'd be odd to have two 
overlapping libraries like this.

Regards.

On Monday, 30 August 2021 13:10:35 CEST Jonah Brüchert wrote:
> Hi Janet,
> 
> I know I have asked this earlier already, but what is the relationship
> between your library and QCoro?
> 
> Especially now that we are starting to use QCoro in some KDE projects
> (namely spacebar and plasma-dialer), it would be really unfortunate if
> they are not compatible.
> 
> The scope of both libraries seems to largely overlap, except for the
> future type that can be passed to JavaScript, which I think is something
> that QCoro is missing.
> 
> 
> I hope this hasn't been asked already on this list, but I tried to check
> all replies I could find.
> 
> 
> Thanks,
> 
> Jonah
> 
> Am 29.08.21 um 05:10 schrieb Janet Blackquill:
> > Hello,
> > 
> > https://invent.kde.org/libraries/croutons is in kdereview now
> > 
> > Croutons is a library containing assorted functionality for dealing
> > with asynchronous code in Qt, most notably a future type that can be
> > passed into QML as a JavaScript Thennable (similarly to Qt IVI's
> > PendingReply) and headers for C++20 coroutine integration for the
> > Croutons Future types + some Qt types that make sense to co_await.
> > 
> > The library is largely headers-only, sans the FutureBase, which has
> > one (1) associated source file needing to be compiled into a binary.
> > 
> > -- Janet


-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

[sdk/kdesrc-build/make_it_mojo] doc: Add documentation for use-inactive-modules

[Kevin Ottens]

Git commit 81df57281f23f4d5a513ca3e48ca42e1f6e0ccca by Kevin Ottens.
Committed on 07/05/2021 at 17:16.
Pushed by mpyne into branch 'make_it_mojo'.

Add documentation for use-inactive-modules

M  +9-0doc/index.docbook

https://invent.kde.org/sdk/kdesrc-build/commit/81df57281f23f4d5a513ca3e48ca42e1f6e0ccca

diff --git a/doc/index.docbook b/doc/index.docbook
index bdbf92f..781e91c 100644
--- a/doc/index.docbook
+++ b/doc/index.docbook
@@ -3005,6 +3005,15 @@ the lower disk priority set this to 
true.
 
 
 
+
+use-inactive-modules
+Cannot be overridden
+This option when enabled will allow kdesrc-build to also clone and
+pull from repositories marked as inactive. The default is to be disabled,
+to allow inactive modules set this to true.
+
+
+
 
 use-modules
 Can only use in module-set

T13927: Pop!_os style window tiling

[Kevin Ottens]

ervin added a comment.


  As far as tiling is concerned, there's a KWin script available: 
https://github.com/kwin-scripts/kwin-tiling
  
  I've been using it productively for a while now, it's really nice.
  
  My 0.02€ hoping it might help the conversation. If not ignore me. :-)

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

To: ervin
Cc: ervin, 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: KF6 meeting notes 2021-06-12

[Kevin Ottens]

Hello,

On Friday, 18 June 2021 22:36:34 CEST Volker Krause wrote:
> On Freitag, 18. Juni 2021 22:27:40 CEST Kevin Ottens wrote:
> > On Friday, 18 June 2021 15:21:07 CEST Volker Krause wrote:
> > > Added now, Monday 09:00 UTC.
> > 
> > OK, I will show up only at 10 though. I can't do 9.
> 
> oh, sorry, I did this from the top of my head ("Monday morning works for
> everyone"), I missed you could only do 10:00 UTC. Should we move it?

Well, moving + keeping the "morning slots" constraint means shortening the BoF 
though. Unsure if that's wise. Obviously I'm mainly interested in what I'll 
present in my talk. So we can also cross our fingers that nothing I'm really 
into gets discussed before 10am. ;-)

Other option is moving to 5pm, unsure that suits many people though...

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: KF6 meeting notes 2021-06-12

[Kevin Ottens]

On Friday, 18 June 2021 15:21:07 CEST Volker Krause wrote:
> Added now, Monday 09:00 UTC.

OK, I will show up only at 10 though. I can't do 9.

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: KF6 meeting notes 2021-06-12

[Kevin Ottens]

Hello,

On Tuesday, 15 June 2021 18:17:27 CEST Volker Krause wrote:
> On Dienstag, 15. Juni 2021 12:45:21 CEST Luigi Toscano wrote:
> > David Faure ha scritto:
> > > On dimanche 13 juin 2021 20:32:42 CEST Luigi Toscano wrote:
> > >> -> we need need input about dfaure presence and try to avoid conflicts
> > >> with
> > >> Plasma BoFs
> > > 
> > > I'm available Mon-Thu, but since Tue-Wed is also Qt Contributor Summit,
> > > maybe better plan for the KF6 BoF on Monday (outside the AGM time)?
> > 
> > It seems Monday is pretty packed already, but there is space at 09:00 UTC
> > and 10:00 UTC, unless people are fine with overlapping with the "KDE goal"
> > slots at 17:00 UTC and 18:00 UTC (there is Kirigami at 16:00 UTC, so maybe
> > not that one):
> > 
> > https://community.kde.org/Akademy/2021/Monday
> > 
> > What do you (plural you) think?
> 
> I'd vote for the Monday morning slots as well, we can then still schedule
> subsequent session later that week if needed, QtCS and Akadmey BoF slots are
> not overlapping all day AFAIK.

Did we book anything after all? Couldn't find anything in the wiki, wondering 
if I missed it somehow?

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: KF6 meeting notes 2021-06-12

[Kevin Ottens]

Hello,

On Tuesday, 15 June 2021 12:45:21 CEST Luigi Toscano wrote:
> David Faure ha scritto:
> > On dimanche 13 juin 2021 20:32:42 CEST Luigi Toscano wrote:
> >> -> we need need input about dfaure presence and try to avoid conflicts
> >> with
> >> Plasma BoFs
> > 
> > I'm available Mon-Thu, but since Tue-Wed is also Qt Contributor Summit,
> > maybe better plan for the KF6 BoF on Monday (outside the AGM time)?
> 
> It seems Monday is pretty packed already, but there is space at 09:00 UTC
> and 10:00 UTC, unless people are fine with overlapping with the "KDE goal"
> slots at 17:00 UTC and 18:00 UTC (there is Kirigami at 16:00 UTC, so maybe
> not that one):
> 
> https://community.kde.org/Akademy/2021/Monday
> 
> What do you (plural you) think?

FWIW, best for me would be Monday at 10:00 UTC. Second best is 17:00 UTC.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Re KIO workers

[Kevin Ottens]

Hello,

On Saturday, 5 June 2021 22:01:54 CEST David Faure wrote:
> On samedi 5 juin 2021 21:07:39 CEST Kevin Ottens wrote:
> > On Saturday, 5 June 2021 17:51:18 CEST David Faure wrote:
> > > On samedi 5 juin 2021 16:29:10 CEST Volker Krause wrote:
> > > > Do KIO slaves still need the klauncher/kinit loading mechanism?
> > > 
> > > No. My request for developers to test KIO_FORK_SLAVES=1
> > > for daily use is so that apps fork kio worker processes directly,
> > > without going via klauncher/kinit. BTW it seems to work fine. I wonder
> > > if we should toggle that in 5.84, as part of the incremental move to the
> > > KF6 world.
> > 
> > Actually it works so well that I almost forgot I turned KIO_FORK_SLAVES
> > on...
> 
> I hope we're both wrong: the env var is *KDE*_FORK_SLAVES :)

I forgot it so well that I got the variable wrong under the influence of your 
email. Yes, I got KDE_FORK_SLAVES enabled... went and check since you gave me 
a doubt. :-D

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Re KIO workers

[Kevin Ottens]

Hello,

On Saturday, 5 June 2021 17:51:18 CEST David Faure wrote:
> On samedi 5 juin 2021 16:29:10 CEST Volker Krause wrote:
> > Do KIO slaves still need the klauncher/kinit loading mechanism?
> 
> No. My request for developers to test KIO_FORK_SLAVES=1
> for daily use is so that apps fork kio worker processes directly, without
> going via klauncher/kinit. BTW it seems to work fine. I wonder if we should
> toggle that in 5.84, as part of the incremental move to the KF6 world.

Actually it works so well that I almost forgot I turned KIO_FORK_SLAVES on...
 
Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: Koko in KDEReview

[Kevin Ottens]

Hello,

Disclaimer: likely a super useless email.

On Wednesday, 5 May 2021 15:23:11 CEST Nate Graham wrote:
> On 5/5/21 6:41 AM, Harald Sitter wrote:
> > On 04.05.21 17:53, Carl Schwan wrote:
> > Side note: this isn't a special need TBH ;)
> > Pretty much everyone has that need. So much so that I kind of have a
> > general game plan that there ought to be a kbugreport utility which is
> > able to gobble up all the very specific data $product needs through
> > scripts or something and either attaches the data to an existing report
> > or files a new one. Cause a filing template also only gets you so far  +
> > for the causal user it's still a fairly meh experience.
> 
> I am super duper in favor of this and I think it's a great idea. VDG has
> some mockups for a desktop bug filing app, in fact. We'd love to share
> them with you if you pop by in the chatroom (#kde-vdg).

A long time ago in a gal... well... a long time ago, we had something called 
KBugBuster. Was probably a bit too much bugzilla and triaging focused. Looks 
like it completely disappeared though, didn't find trace of its code.

Cheers.

PS: I warned you.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: KF6 online sprint: March 27-28

[Kevin Ottens]

Hello,

On Wednesday, 24 March 2021 14:11:19 CET David Edmundson wrote:
> I wanted to bump this thread, just so people remember that it is this
> weekend! There are many many slots still available.

Well, in our great tradition, my expectation is that the first hour will be 
devoted to filling the other slots. ;-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: KF6 online sprint: March 27-28

[Kevin Ottens]

Hello,

On Wednesday, 24 March 2021 14:11:19 CET David Edmundson wrote:
> I wanted to bump this thread, just so people remember that it is this
> weekend! There are many many slots still available.

Well, in our great tradition, my expectation is that the first hour will be 
devoted to filling the other slots. ;-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: KCGroups in KDEreview

[Kevin Ottens]

Hello,

On Tuesday, 2 March 2021 12:06:51 CET David Edmundson wrote:
> > > (where 1000 is of course dynamic)
> > 
> > Ditto, what enum names could we give to those?
> 
> / -> All
> /system.slice -> System
> user.slice/user-1000.slice/user@1000.service -> User
> user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps
> user.slice/user-1000.slice/user@1000.service/session.slice -> UserSession
> user.slice/user-1000.slice/user@1000.service/background.slice ->
> UserBackground

Sounds good to me. Let's go for this.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: KCGroups in KDEreview

[Kevin Ottens]

Hello,

On Tuesday, 2 March 2021 12:06:51 CET David Edmundson wrote:
> > > (where 1000 is of course dynamic)
> > 
> > Ditto, what enum names could we give to those?
> 
> / -> All
> /system.slice -> System
> user.slice/user-1000.slice/user@1000.service -> User
> user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps
> user.slice/user-1000.slice/user@1000.service/session.slice -> UserSession
> user.slice/user-1000.slice/user@1000.service/background.slice ->
> UserBackground

Sounds good to me. Let's go for this.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

Re: KDE Frameworks 6 - Virtual Sprint setup

[Kevin Ottens]

Hello,

On Saturday, 30 January 2021 12:14:27 CET Volker Krause wrote:
> Thanks for driving this, I'm in! European hours preferred, any weekend
> starting from w6 should be possible.

Same here, not before week 10 or even better not before week 13.

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: KDE Frameworks 6 - Virtual Sprint setup

[Kevin Ottens]

Hello,

On Saturday, 30 January 2021 12:14:27 CET Volker Krause wrote:
> Thanks for driving this, I'm in! European hours preferred, any weekend
> starting from w6 should be possible.

Same here, not before week 10 or even better not before week 13.

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: KCGroups in KDEreview

[Kevin Ottens]

On Sunday, 13 December 2020 22:41:24 CET David Edmundson wrote:
> On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens  wrote:
> > Hello,
> > 
> > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote:
> > > Ultimately this isn't really dealing with cgroups directly but with
> > > the manager to control them, systemd.
> > > 
> > > That's correct usage, kernel docs of cgroups say to go via a
> > > controller for write operations. However that at point is it worth
> > > naming the library ksystemd?
> > > It might cause some contention due to people who get angsty at a name,
> > > but it's a lot more fitting. It would then give us a place to dump a
> > > lot of other wrappers (especially logind) that we're seeing duplicated
> > > in a bunch of places throughout KDE.
> > 
> > Aren't you concerned this might lead to one of our infamous dumping
> > grounds?
> > 
> > There's always a tension between making it too focused and tiny or
> > unfocused and with blackhole mass... we'd need to find where it stands
> > but "systemd wrappers" looks too loosely defined to me.
> > 
> > 
> > Do we have a list of the wrappers you got in mind and which piece of
> > feature they all provide?
> 
> StartUnit, given this has a StopUnit
> Used by plasma-workspace and plasma-firewall
> 
> Logind I have wrappers in:
>  - kwin
>  - libkworkspace
>  - SDDM
>  - powerdevil
>  - kscreenlocker
> 
> None wrapping all of it, only what they need, but there's still overlap.
> You're right that could be a separate framework if that's preferred.

I'll be honest I'm still unsure what that'd mean in practice... What about 
drafting API for a couple of those? Let's not get overboard implementing stuff 
and so on, it's more exploratory that anything for now.

> > > I think we've artificially limited the usage of the library.
> > > The code is very generic for handling units, but all the names and one
> > > tiny line limit it to only managing a subset of units.
> > > 
> > > If we make the "glob" static used in KApplicationScopeLister's have a
> > > public setter (or a protected virtual) we can rename this class and it
> > > becomes a much more generic library for others to use outside of any
> > > initial use-case.
> > 
> > Good point. Got a similar question though, which other unit types would be
> > useful to control? Reason being that API wise I'd smell an enum for
> > something like this.
> 
> Enum potentially works too.
> 
> Describing things in terms of cgroup hierarchy, I think the key use cases
> are:
> 
> /
> user.slice/user-1000.slice/user@1000.service
> user.slice/user-1000.slice/user@1000.service/app.slice
> user.slice/user-1000.slice/user@1000.service/session.slice
> user.slice/user-1000.slice/user@1000.service/background.slice
> (where 1000 is of course dynamic)

Ditto, what enum names could we give to those?

Yes, I know I roll with questions. :-)

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: KCGroups in KDEreview

[Kevin Ottens]

On Sunday, 13 December 2020 22:41:24 CET David Edmundson wrote:
> On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens  wrote:
> > Hello,
> > 
> > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote:
> > > Ultimately this isn't really dealing with cgroups directly but with
> > > the manager to control them, systemd.
> > > 
> > > That's correct usage, kernel docs of cgroups say to go via a
> > > controller for write operations. However that at point is it worth
> > > naming the library ksystemd?
> > > It might cause some contention due to people who get angsty at a name,
> > > but it's a lot more fitting. It would then give us a place to dump a
> > > lot of other wrappers (especially logind) that we're seeing duplicated
> > > in a bunch of places throughout KDE.
> > 
> > Aren't you concerned this might lead to one of our infamous dumping
> > grounds?
> > 
> > There's always a tension between making it too focused and tiny or
> > unfocused and with blackhole mass... we'd need to find where it stands
> > but "systemd wrappers" looks too loosely defined to me.
> > 
> > 
> > Do we have a list of the wrappers you got in mind and which piece of
> > feature they all provide?
> 
> StartUnit, given this has a StopUnit
> Used by plasma-workspace and plasma-firewall
> 
> Logind I have wrappers in:
>  - kwin
>  - libkworkspace
>  - SDDM
>  - powerdevil
>  - kscreenlocker
> 
> None wrapping all of it, only what they need, but there's still overlap.
> You're right that could be a separate framework if that's preferred.

I'll be honest I'm still unsure what that'd mean in practice... What about 
drafting API for a couple of those? Let's not get overboard implementing stuff 
and so on, it's more exploratory that anything for now.

> > > I think we've artificially limited the usage of the library.
> > > The code is very generic for handling units, but all the names and one
> > > tiny line limit it to only managing a subset of units.
> > > 
> > > If we make the "glob" static used in KApplicationScopeLister's have a
> > > public setter (or a protected virtual) we can rename this class and it
> > > becomes a much more generic library for others to use outside of any
> > > initial use-case.
> > 
> > Good point. Got a similar question though, which other unit types would be
> > useful to control? Reason being that API wise I'd smell an enum for
> > something like this.
> 
> Enum potentially works too.
> 
> Describing things in terms of cgroup hierarchy, I think the key use cases
> are:
> 
> /
> user.slice/user-1000.slice/user@1000.service
> user.slice/user-1000.slice/user@1000.service/app.slice
> user.slice/user-1000.slice/user@1000.service/session.slice
> user.slice/user-1000.slice/user@1000.service/background.slice
> (where 1000 is of course dynamic)

Ditto, what enum names could we give to those?

Yes, I know I roll with questions. :-)

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: KCGroups in KDEreview

[Kevin Ottens]

Hello,

On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote:
> Ultimately this isn't really dealing with cgroups directly but with
> the manager to control them, systemd.
> 
> That's correct usage, kernel docs of cgroups say to go via a
> controller for write operations. However that at point is it worth
> naming the library ksystemd?
> It might cause some contention due to people who get angsty at a name,
> but it's a lot more fitting. It would then give us a place to dump a
> lot of other wrappers (especially logind) that we're seeing duplicated
> in a bunch of places throughout KDE.

Aren't you concerned this might lead to one of our infamous dumping grounds?

There's always a tension between making it too focused and tiny or unfocused 
and with blackhole mass... we'd need to find where it stands but "systemd 
wrappers" looks too loosely defined to me.

Do we have a list of the wrappers you got in mind and which piece of feature 
they all provide?
 
> I think we've artificially limited the usage of the library.
> The code is very generic for handling units, but all the names and one
> tiny line limit it to only managing a subset of units.
> 
> If we make the "glob" static used in KApplicationScopeLister's have a
> public setter (or a protected virtual) we can rename this class and it
> becomes a much more generic library for others to use outside of any
> initial use-case.

Good point. Got a similar question though, which other unit types would be 
useful to control? Reason being that API wise I'd smell an enum for something 
like this.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: KCGroups in KDEreview

[Kevin Ottens]

Hello,

On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote:
> Ultimately this isn't really dealing with cgroups directly but with
> the manager to control them, systemd.
> 
> That's correct usage, kernel docs of cgroups say to go via a
> controller for write operations. However that at point is it worth
> naming the library ksystemd?
> It might cause some contention due to people who get angsty at a name,
> but it's a lot more fitting. It would then give us a place to dump a
> lot of other wrappers (especially logind) that we're seeing duplicated
> in a bunch of places throughout KDE.

Aren't you concerned this might lead to one of our infamous dumping grounds?

There's always a tension between making it too focused and tiny or unfocused 
and with blackhole mass... we'd need to find where it stands but "systemd 
wrappers" looks too loosely defined to me.

Do we have a list of the wrappers you got in mind and which piece of feature 
they all provide?
 
> I think we've artificially limited the usage of the library.
> The code is very generic for handling units, but all the names and one
> tiny line limit it to only managing a subset of units.
> 
> If we make the "glob" static used in KApplicationScopeLister's have a
> public setter (or a protected virtual) we can rename this class and it
> becomes a much more generic library for others to use outside of any
> initial use-case.

Good point. Got a similar question though, which other unit types would be 
useful to control? Reason being that API wise I'd smell an enum for something 
like this.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: KCGroups in KDEreview

[Kevin Ottens]

Hello,

On Friday, 20 November 2020 14:55:16 CET Henri Chain wrote:
> KCgroups has been moved to KDEReview !
> What is that, you ask ? It's a library that wraps the systemd dbus API to
> expose a higher-level concept of desktop application and allow control of
> its system resource usage (CPU, RAM, IO, etc).
> 
> It relies on the recent ability of plasma to launch applications in their
> own systemd scopes, with correspond to cgroups and provides a more robust
> definition for an application (more details at
> https://lwn.net/Articles/834329/ ) .
> 
> The main use of the library is to expose related resource control settings
> for those applications, at a user space level that other KDE applications
> and frameworks can use, including consumption straight from QML as
> demonstrated in the test application.
> 
> KCgroups is intended to become a (Tier 1) framework. A first user of this
> library might be the foreground window CPU booster daemon that is available
> here:
> https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster
> 
> Packages are already available for both Neon and Arch Linux.
> 
> Looking forward to your feedback and ideas for using this,

Glad to see this come to fruition.

One concern regarding use with other libraries:
 * the OPTIONAL_GADGET use introduce names that I could see potentially 
clashing with application code or code in third party libraries, I wonder if 
they should be moved in a namespace as well (as in "like optional") or have a 
K name at least;

Minor things I found:
 * tests/main.cpp needs to have some of its includes cleaned up (at a glance 
QDebug and QTimer aren't needed there);
 * tests/main.qml should have better ids for its elements IMHO, often those 
manual tests end up used as examples by people and having better readability 
helps (also avoids having people copying and pasting shameful things). ;-)

That's not much but I'm obviously biased by the fact that we discussed this 
API together already. :-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: KCGroups in KDEreview

[Kevin Ottens]

Hello,

On Friday, 20 November 2020 14:55:16 CET Henri Chain wrote:
> KCgroups has been moved to KDEReview !
> What is that, you ask ? It's a library that wraps the systemd dbus API to
> expose a higher-level concept of desktop application and allow control of
> its system resource usage (CPU, RAM, IO, etc).
> 
> It relies on the recent ability of plasma to launch applications in their
> own systemd scopes, with correspond to cgroups and provides a more robust
> definition for an application (more details at
> https://lwn.net/Articles/834329/ ) .
> 
> The main use of the library is to expose related resource control settings
> for those applications, at a user space level that other KDE applications
> and frameworks can use, including consumption straight from QML as
> demonstrated in the test application.
> 
> KCgroups is intended to become a (Tier 1) framework. A first user of this
> library might be the foreground window CPU booster daemon that is available
> here:
> https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster
> 
> Packages are already available for both Neon and Arch Linux.
> 
> Looking forward to your feedback and ideas for using this,

Glad to see this come to fruition.

One concern regarding use with other libraries:
 * the OPTIONAL_GADGET use introduce names that I could see potentially 
clashing with application code or code in third party libraries, I wonder if 
they should be moved in a namespace as well (as in "like optional") or have a 
K name at least;

Minor things I found:
 * tests/main.cpp needs to have some of its includes cleaned up (at a glance 
QDebug and QTimer aren't needed there);
 * tests/main.qml should have better ids for its elements IMHO, often those 
manual tests end up used as examples by people and having better readability 
helps (also avoids having people copying and pasting shameful things). ;-)

That's not much but I'm obviously biased by the fact that we discussed this 
API together already. :-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: Add loop device interface to Solid framework

[Kevin Ottens]

Hello,

Sorry for the slow reply time. :-)

On Monday, 15 June 2020 20:19:54 CEST Kwon-Young Choi wrote:
> Well, I don't know if it possible to make an optional action such as a
> delete method which would work only if the device is a loop device
> backed by a file.

That's totally doable, and probably a good idea to put it on a separate 
DeviceInterface.
 
> In my opinion, it would be better to check if the device is a loop
> device, if it is you can convert it to the Loop type and can call
> methods like `delete` and access properties like `backingFile`.

Exactly.

> However, I still have no idea where to put the create loop device method
> since there is no concept of a device manager in solid which can modify
> the global state of the system.

That's something I'd be a bit more wary of having into solid. We used to have 
a device manager concept in the API and well... let's say it didn't end up 
well.

The problem of having one is that it somehow starts behaving like an attractor 
for all kinds of weird features and we'd end up doing too much in solid.

Since it's something very specific to loop devices... if we eally want it 
in solid (I suspect it's more something you'd want in the file manager and 
solid reacting to it) then maybe just this time we could have a static method 
in the future "LoopDevice" (or whatever name ends up picked) interface for 
creating those.

Just my 0.02€.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)

[Kevin Ottens]

Hello,

On Friday, 12 June 2020 20:47:55 CEST Carl Schwan wrote:
> Le vendredi, juin 12, 2020 1:45 PM, Kevin Ottens  a écrit :
> > Incidentally it's been the top discussion topics for the past few KDEPIM
> > sprints. And also during BoFs at Akademy. I even think there's been
> > discussions about that on the pim list and IRC channels.
> 
> And I think the PIM team did a lot of good work in this direction, there is
> documentation on how to build the PIM libs and apps, a big list of junior
> jobs with that in my experience get active mentoring when someone wants to
> claim one of them.
> 
> Could the PIM team make the whole onboarding process easier? Probably but it
> would also impact the limited time the PIM devs have to work on the PIM
> apps. But in my opinion that makes it very hard to get more devs working on
> the PIM apps is that this is a complex system and that it is not the cool
> new tech but instead, deals with tons of legacy systems. If someone wants
> to help the PIM team, I would recommend taking one of the junior jobs or
> updating the documentation related to PIM on the wikis.

Thanks. This is exactly why I send my email. Thing is more people are needed, 
the tiny team around KDEPIM did everything it could to attract said people and 
we can't say many hands showed up so far.
 
> If I remember correctly I got my KDE developer account with the support of
> Laurent after completing one of the Junior Job, so merci beaucoup Laurent
> and the rest of the team for making me discover the KDE community.

Didn't get a chance to say it earlier, but I'll use the opportunity: I'm glad 
we have you on board. :-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

Re: Showing respect (was: Re: The KDEPIM / Akonadi situation)

[Kevin Ottens]

On Friday, 12 June 2020 15:17:46 CEST Christian Loosli wrote:
> Am Freitag, 12. Juni 2020, 15:04:34 CEST schrieb Friedrich W. H. Kossebau:
> > I am missing what this email thread here should achieve, despite being
> > demotivating for those whose product is talked about or even bad-mouthing
> > them. We all know there are big and small flaws. Those get fixed by people
> > working on them. Not by people showing off their knowledge that there are
> > flaws. And I doubt the developers of the products do not know about the
> > flaws. They just do not have the resources left to handle them, given
> > resources are limited.
> 
> My personal hope would be that some solutions could be discussed, e.g. on
> how to get more developers, if some parts should be dropped / rewritten
> instead of fixed etc.

Incidentally it's been the top discussion topics for the past few KDEPIM 
sprints. And also during BoFs at Akademy. I even think there's been 
discussions about that on the pim list and IRC channels.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net


signature.asc
Description: This is a digitally signed message part.

D28590: Add a QString Solid::Device::displayName, used in Fstab Device for network mounts

[Kevin Ottens]

ervin added inline comments.

INLINE COMMENTS

> meven wrote in device.h:99
> Well I have to make this virtual it seems so this call is dynamically 
> dispatched by `return_SOLID_CALL(Ifaces::Device *, d->backendObject(), 
> QString(), displayName());`
> I assumed this would work based on my review comments rather than on tests :/

Woops... my bad, indeed didn't notice it wasn't marked virtual anymore. It has 
to be indeed.

REPOSITORY
  R245 Solid

REVISION DETAIL
  https://phabricator.kde.org/D28590

To: meven, #frameworks, bruns, sitter, dfaure, ngraham
Cc: ngraham, dfaure, broulik, ervin, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, bruns

D28590: Add a QString Solid::Device::displayName, used in Fstab Device for network mounts

[Kevin Ottens]

ervin added a comment.


  LGTM now, I'll let the other reviewers weight in though.

REPOSITORY
  R245 Solid

REVISION DETAIL
  https://phabricator.kde.org/D28590

To: meven, #frameworks, bruns, sitter, dfaure
Cc: dfaure, broulik, ervin, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D28590: Add a QString Solid::Device::displayName, used in Fstab Device for network mounts

[Kevin Ottens]

ervin added inline comments.

INLINE COMMENTS

> device.h:99
> +  */
> +virtual QString displayName() const = 0;
> +

Why not have a default implementation which returns descriptions()? This would 
make for a less intrusive patch (I think it's in part what @bruns suggested 
earlier).

REPOSITORY
  R245 Solid

REVISION DETAIL
  https://phabricator.kde.org/D28590

To: meven, #frameworks, bruns, sitter, dfaure
Cc: dfaure, broulik, ervin, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

[elisa] [Bug 406467] Option to sort artists' albums by year

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

 CC||er...@kde.org

--- Comment #3 from Kevin Ottens  ---
Any news about this? This is the main deal breaker for me regarding Elisa. In
my case it's not only about display BTW, when I queue an artist in the
playlist, I expect the albums to be added by ascending year, not
alphabetically.

-- 
You are receiving this mail because:
You are watching all bug changes.

D28194: Fix loading button icons from qrc

[Kevin Ottens]

ervin added a comment.


  In D28194#632629 , @apol wrote:
  
  > Fixing QIcon would make sense but I'd say getting this in is not the worst 
thing either.
  
  
  I don't think it's QIcon's fault to be honest. The pattern used in several 
places of `(icon.name || icon.source)` doesn't help, it makes the lower layer 
loose the information of an icon specified by name (thus going through theme 
loading) or by URL (thus going through direct loading). Due to that the lower 
layer ends up having code trying to guess in which situation it is.

INLINE COMMENTS

> kquickstyleitem.cpp:182
>  
>  const QVariant icon = m_properties[QStringLiteral("icon")];
>  if (icon.canConvert()) {

Note that this construct is duplicated three times in that file. It really 
calls for having a findIcon like that:

  QIcon KQuickStyleItem::findIcon(const QVariant ) const
  {
  if (iconProp.canConvert()) {
  return iconProp.value();
  } else if (iconProp.canConvert()) {
  const auto iconId = iconProp.toString();
  if (iconId.startsWith(QLatin1Char('/')) || 
iconId.startsWith(QStringLiteral(":/"))) {
  return QIcon(iconId);
  } else if (iconId.startsWith(QStringLiteral("file:"))) {
  return QIcon(QUrl(iconId).toLocalFile());
  } else if (iconId.startsWith(QStringLiteral("qrc:"))) {
  return QIcon(QLatin1Char(':') + QUrl(iconId).path());
  } else {
  return m_theme->iconFromTheme(iconId, 
m_properties[QStringLiteral("iconColor")].value());
  }
  } else {
  return QIcon();
  }
  }

And then using it for setting opt->icon and opt->currentIcon (combobox case). 
Yes, I did that locally and that definitely helped.

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

REVISION DETAIL
  https://phabricator.kde.org/D28194

To: nicolasfella, #plasma, mart, ervin
Cc: apol, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, ahiemstra, mart

D29120: KCM Fonts disable AA items if they are immutable

[Kevin Ottens]

ervin added a comment.


  LGTM but I'll let others weight in.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D29120

To: crossi, #plasma, ervin, bport, meven
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27188: KCM Notifications : Manage app-specific notifications with KCconfigXT's magic

[Kevin Ottens]

ervin requested changes to this revision.
ervin added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> kcm.cpp:315
>  ManagedConfigModule::defaults();
> -m_settings->defaults();
> +for (auto *behaviorSettings : m_behaviorSettingsList) {
> +behaviorSettings->setDefaults();

qAsConst(m_behaviorSettingsList), otherwise it will unfortunately detach.

> kcm.cpp:334
> +bool notDefault = std::any_of(m_behaviorSettingsList.cbegin(),
> +m_behaviorSettingsList.cend(),
> +[](const 
> NotificationManager::BehaviorSettings *settings) { return 
> !settings->isDefaults(); });

I'd align that (and the next line) with the previous parameter.

> kcm.cpp:335
> +m_behaviorSettingsList.cend(),
> +[](const 
> NotificationManager::BehaviorSettings *settings) { return 
> !settings->isDefaults(); });
> +return !notDefault;

This starts being a long line, please break it after the opening brace and 
again after the first semicolon.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D27188

To: crossi, #plasma, ervin, broulik, bport, meven
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28461: In sidebar mode show if a module is in default state or not

[Kevin Ottens]

ervin accepted this revision.
ervin added a comment.


  LGTM

REPOSITORY
  R124 System Settings

REVISION DETAIL
  https://phabricator.kde.org/D28461

To: bport, #plasma, ervin, meven, crossi, hchain, #vdg, mart
Cc: GB_2, mart, ngraham, abetts, filipf, The-Feren-OS-Dev, ndavis, broulik, 
plasma-devel, Orage, LeGast00n, cblack, jraleigh, zachus, fbampaloukas, 
ragreen, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, sebas, 
apol, ahiemstra

D28460: Add KCModuleDada as base class for plugin

[Kevin Ottens]

ervin accepted this revision.
ervin added a comment.
This revision is now accepted and ready to land.


  Please fix the typo in the commit title before pushing, otherwise looks fine 
to me.

REPOSITORY
  R295 KCMUtils

REVISION DETAIL
  https://phabricator.kde.org/D28460

To: bport, #plasma, ervin
Cc: broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28462: [KCM][WIP] Add KCModuleData

[Kevin Ottens]

ervin requested changes to this revision.
ervin added a comment.
This revision now requires changes to proceed.


  Only a small thing left I think

INLINE COMMENTS

> cursorthemedata.h:33
> +Q_OBJECT
> +//Q_PROPERTY(CursorThemeSettings *cursorThemeSettings READ 
> cursorThemeSettings CONSTANT)
> +

Needs a cleanup I guess

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D28462

To: bport, #plasma, ervin, meven, crossi, hchain
Cc: broulik, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

[frameworks-kconfig] [Bug 420379] Checkbox and its label move themselves to upper left corner when unchecked

[Kevin Ottens]

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

Kevin Ottens  changed:

   What|Removed |Added

 CC|er...@kde.org   |

--- Comment #2 from Kevin Ottens  ---
(In reply to Nate Graham from comment #1)
> Can reproduce. I think this is a regression in the "show changed settings"
> feature.

You're talking about a reverted patch which had no visible impact on that
particular window. Please go fish somewhere else.

-- 
You are receiving this mail because:
You are watching all bug changes.

D27540: KCModule: Indicate when a setting has been changed from the default or previous value

[Kevin Ottens]

ervin added a comment.


  You know it started as a proper painted indicator within the widget area, 
right? As such it couldn't have any of the issues you're pointing out now... 
Who pushed me to have them at distance I wonder? Right, was people from the 
VDG. So I find grand that then it goes all to revert because after weeks of 
pushing me to add more weird constraints then disappearing letting me alone 
trying to figure out where to go (and it was a large struggle at every step), 
the conclusion is "let's revert because VDG wasn't involved". There were 
technical reasons for the very first iteration and they had to be disregarded 
for design license.
  
  Honestly I'm disgusted by the way it's been handled.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D27540

To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik
Cc: bam, GB_2, alexde, ndavis, iasensio, davidre, kde-frameworks-devel, 
LeGast00n, cblack, michaelh, ngraham, bruns

D29014: Fix the exclusive group box case for default indicators

[Kevin Ottens]

This revision was automatically updated to reflect the committed changes.
Closed by commit R265:14ecec53296a: Fix the exclusive group box case for 
default indicators (authored by ervin).

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29014?vs=80664=80682

REVISION DETAIL
  https://phabricator.kde.org/D29014

AFFECTED FILES
  src/kconfigdialogmanager.cpp

To: ervin, ngraham, davidedmundson, bport, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29014: Fix the exclusive group box case for default indicators

[Kevin Ottens]

ervin updated this revision to Diff 80664.
ervin added a comment.


  Fix misplaced *

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29014?vs=80661=80664

REVISION DETAIL
  https://phabricator.kde.org/D29014

AFFECTED FILES
  src/kconfigdialogmanager.cpp

To: ervin, ngraham, davidedmundson, bport, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D27540: KCModule: Indicate when a setting has been changed from the default or previous value

[Kevin Ottens]

ervin added a comment.


  In D27540#652669 , @ngraham wrote:
  
  > Finally clicking on the revert button in Spectacle's settings page causes a 
segfault for me: P590 Spectacle crash backtrace 

  
  
  Couldn't quite reproduce it the way you described, but indeed managed to get 
it to crash. It's fixed with D29014 

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D27540

To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik
Cc: alexde, ndavis, iasensio, davidre, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D29014: Fix the exclusive group box case for default indicators

[Kevin Ottens]

ervin created this revision.
ervin added reviewers: ngraham, davidedmundson, bport, crossi.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
ervin requested review of this revision.

REVISION SUMMARY
  Turns out there was an oversight here, in case of an exclusive group
  box, the emitter widget is a button inside the group box which can have
  any name (this was thus caught by the assert).
  
  So now we also check if the sender is a button and if that's the case we
  verify if its in one of the known exclusive group boxes. If yes we use
  the group box as reference for the indicator work.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D29014

AFFECTED FILES
  src/kconfigdialogmanager.cpp

To: ervin, ngraham, davidedmundson, bport, crossi
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D27540: KCModule: Indicate when a setting has been changed from the default or previous value

[Kevin Ottens]

ervin added a comment.


  In D27540#652664 , @ngraham wrote:
  
  > David asked for VDG to approve before this landed, which wasn't done.
  
  
  Dude, I jumped through all the hoops for the past weeks. Also it got no 
further reply after I updated the screenshot almost two weeks ago so yes I 
assumed you guys had nothing else.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D27540

To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik
Cc: alexde, ndavis, iasensio, davidre, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D27841: Port desktoptheme, icons and workspace KCMs to SettingStateBinding

[Kevin Ottens]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:dfc144bf3f45: Port desktoptheme, icons and workspace KCMs 
to SettingStateBinding (authored by ervin).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27841?vs=76953=80655

REVISION DETAIL
  https://phabricator.kde.org/D27841

AFFECTED FILES
  kcms/desktoptheme/package/contents/ui/main.qml
  kcms/icons/package/contents/ui/IconSizePopup.qml
  kcms/icons/package/contents/ui/main.qml
  kcms/workspaceoptions/package/contents/ui/main.qml

To: ervin, crossi, hchain, meven, bport, davidedmundson, mart, ngraham, 
#frameworks, #plasma, #vdg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27840: Introduce SettingState* elements to ease KCM writing

[Kevin Ottens]

This revision was automatically updated to reflect the committed changes.
Closed by commit R296:24211925f835: Introduce SettingState* elements to ease 
KCM writing (authored by ervin).

REPOSITORY
  R296 KDeclarative

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27840?vs=80305=80654

REVISION DETAIL
  https://phabricator.kde.org/D27840

AFFECTED FILES
  src/qmlcontrols/kcmcontrols/CMakeLists.txt
  src/qmlcontrols/kcmcontrols/kcmcontrolsplugin.cpp
  src/qmlcontrols/kcmcontrols/qml/SettingStateBinding.qml
  src/qmlcontrols/kcmcontrols/qml/SettingStateIndicator.qml
  src/qmlcontrols/kcmcontrols/qml/qmldir
  src/qmlcontrols/kcmcontrols/settingstatebindingprivate.cpp
  src/qmlcontrols/kcmcontrols/settingstatebindingprivate.h
  src/qmlcontrols/kcmcontrols/settingstateproxy.cpp
  src/qmlcontrols/kcmcontrols/settingstateproxy.h

To: ervin, crossi, hchain, meven, bport, davidedmundson, mart, ngraham, 
#frameworks, #plasma
Cc: broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D27841: Port desktoptheme, icons and workspace KCMs to SettingStateBinding

[Kevin Ottens]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:dfc144bf3f45: Port desktoptheme, icons and workspace KCMs 
to SettingStateBinding (authored by ervin).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27841?vs=76953=80655

REVISION DETAIL
  https://phabricator.kde.org/D27841

AFFECTED FILES
  kcms/desktoptheme/package/contents/ui/main.qml
  kcms/icons/package/contents/ui/IconSizePopup.qml
  kcms/icons/package/contents/ui/main.qml
  kcms/workspaceoptions/package/contents/ui/main.qml

To: ervin, crossi, hchain, meven, bport, davidedmundson, mart, ngraham, 
#frameworks, #plasma, #vdg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27839: Properly name the content of the kcmcontrols project

[Kevin Ottens]

This revision was automatically updated to reflect the committed changes.
Closed by commit R296:3501bcbe8da6: Properly name the content of the 
kcmcontrols project (authored by ervin).

REPOSITORY
  R296 KDeclarative

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27839?vs=76951=80653

REVISION DETAIL
  https://phabricator.kde.org/D27839

AFFECTED FILES
  src/qmlcontrols/kcmcontrols/CMakeLists.txt

To: ervin, crossi, hchain, meven, bport, davidedmundson, mart, ngraham, 
#frameworks, #plasma
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D27540: KCModule: Indicate when a setting has been changed from the default or previous value

[Kevin Ottens]

This revision was automatically updated to reflect the committed changes.
Closed by commit R265:11186c056198: KCModule: Indicate when a setting has been 
changed from the default or previous… (authored by ervin).

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27540?vs=79656=80652

REVISION DETAIL
  https://phabricator.kde.org/D27540

AFFECTED FILES
  src/CMakeLists.txt
  src/kconfigdialogmanager.cpp
  src/kconfigdialogmanager.h
  src/kconfigdialogmanager_p.h
  src/settingsstatusindicator.cpp
  src/settingsstatusindicator_p.h

To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik
Cc: alexde, ndavis, iasensio, davidre, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

Re: Problems in KWayland causes by API and ABI compatibility promises

[Kevin Ottens]

Hello,

On Thursday, 16 April 2020 23:38:23 CEST David Edmundson wrote:
> On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens  wrote:
> > On Wednesday, 1 April 2020 14:04:10 CEST David Edmundson wrote:
> > > Here is a list of active uses of the KWayland::Client API.
> > > 
> > > frameworks
> > > 
> > > plasma-framework (for window positioning)
> > > 
> > > apps:
> > > spectacle (for window positioning)
> > > kdeconnect-kde  (for fake input)
> > > yakuake (for window positioning)
> > > 
> > > extragear
> > > 
> > > latte-dock (for window positioning, custom shadow (which could be
> > > 
> > > ported already) and windowmanagement)
> > 
> > The part of the list above makes me wonder, shouldn't the window
> > positioning and windowmanager features be on KWindowSystem?
> 
> Yeah, doing that will resolve 90% of the client cases.
> In general for things like blur and everything the slightly higher
> level abstraction is working out better as we can abstract X and
> wayland in one go, which really helps the client code.

Sounds like a plan then.
 
> Also, it's worth really clarifying that in absolutely any proposal
> KWayland as-is can't go away, so clients using that will still
> function.

Of course, it's just that the one in KF would become frozen and deprecated 
until KF6. But then the development would move on with the other copy which 
would be less of a burden for everyone.

> The slight twist on that which we need to be wary of is that client
> code will return shared objects if you request a
> KWaylandClient::PlasmaShellSurface::get(window())
> for the same window from two places you'll get the same PlasmaShell
> instance returned - and therefore the same wl_resource.
> If we hypothetically had a kwayland2::client also have a
> plasmashellsurface::get() method we would have two plasma_shellsurface
> wl_resources's for the same wl_surface which is a protocol error and
> our client will get violently killed.

Honestly you lost me here. :-)

> > > workspace:
> > > kwin unit tests
> > > libkscreen
> > > breeze (till Qt5.15)
> > > oxyen (till Qt5.15)
> > > xdg-desktop-portal
> > > kinfocenter
> > > plasma-workspace
> > > plasma-nano
> > > kscreenlocker
> > > powerdevil
> > > kwayland-integration (the backend for kwindowsystem)
> > > plasma-phone-components
> > >     plasma-integration
> > 
> > I think the above is less of an issue, right? Because workspace would have
> > a copy of KWayland which could be shared with whatever stability
> > constraints needed.
> 
> It means it has to stay as an exported workspace lib, but yeah it
> wouldnt' be a problem.

Yes, exactly my position as well.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

D27840: Introduce SettingState* elements to ease KCM writing

[Kevin Ottens]

ervin updated this revision to Diff 80305.
ervin added a comment.


  Fix issues found with Cyril's patches on various KCMs.

REPOSITORY
  R296 KDeclarative

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27840?vs=78698=80305

REVISION DETAIL
  https://phabricator.kde.org/D27840

AFFECTED FILES
  src/qmlcontrols/kcmcontrols/CMakeLists.txt
  src/qmlcontrols/kcmcontrols/kcmcontrolsplugin.cpp
  src/qmlcontrols/kcmcontrols/qml/SettingStateBinding.qml
  src/qmlcontrols/kcmcontrols/qml/SettingStateIndicator.qml
  src/qmlcontrols/kcmcontrols/qml/qmldir
  src/qmlcontrols/kcmcontrols/settingstatebindingprivate.cpp
  src/qmlcontrols/kcmcontrols/settingstatebindingprivate.h
  src/qmlcontrols/kcmcontrols/settingstateproxy.cpp
  src/qmlcontrols/kcmcontrols/settingstateproxy.h

To: ervin, crossi, hchain, meven, bport, davidedmundson, mart, ngraham, 
#frameworks, #plasma
Cc: broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

Re: Kup in KDE Review

[Kevin Ottens]

Hello,

On Thursday, 9 April 2020 07:25:34 CEST Simon Persson wrote:
> On 2020-04-07 06:01, Nicolas Fella wrote:
> > I briefly skimmed trough the codebase. Looks all sane to me. A few
> > minor observations:
> > 
> > - You may want to look into KConfigXT. It should be able to generate
> > the classes from settings/ from an XML description.
> 
> I think that I looked at it when I started Kup, about 10 years ago...
> don't remember exactly but I think the issue was about dynamic
> configuration entries. Kup allows user to create as many backup plans as
> they want and each will have some settings.

By the sound of it you might want to look into parameterized groups:
https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html

This feature has been there forever but is often overlooked.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.

D28742: Add KDialogJobUiDelegate(KJobUiDelegate::Flags) constructor

[Kevin Ottens]

ervin added a comment.


  Agreed, nullptr is going to be the boolean flag of our time, before it was 0 
though, so still an improvement. ;-)
  
  More seriously, here I'm not sure how to avoid it, at least it's a case of 
"if you feel like passing nullptr here you might be doing something wrong".

REPOSITORY
  R288 KJobWidgets

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28742

To: dfaure, broulik, davidedmundson, ervin
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28742: Add KDialogJobUiDelegate(KJobUiDelegate::Flags) constructor

[Kevin Ottens]

ervin accepted this revision.

REPOSITORY
  R288 KJobWidgets

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28742

To: dfaure, broulik, davidedmundson, ervin
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28742: Add KDialogJobUiDelegate(KJobUiDelegate::Flags) constructor

[Kevin Ottens]

ervin added a comment.


  In D28742#646050 , @dfaure wrote:
  
  > In D28742#646009 , @kossebau 
wrote:
  >
  > > And perhaps could be defaulted to nullptr, for use-cases which do not 
have a window at hand and are fine with any default?
  >
  >
  > I've been wondering. But people tend to forget to do so, and in most cases, 
if we choose the dialog delegate, then there's a QWidget based window somewhere.
  >  Plasma uses KNotificationJobUiDelegate so it's not a problem here.
  >  My thinking is that I'd rather force people to think about it, and 
possibly pass a nullptr in case there's really no window around.
  
  
  +1, I don't think defaulting to nullptr is a good idea.

REPOSITORY
  R288 KJobWidgets

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28742

To: dfaure, broulik, davidedmundson, ervin
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28742: Add KDialogJobUiDelegate(KJobUiDelegate::Flags) constructor

[Kevin Ottens]

ervin accepted this revision.
ervin added a comment.


  Indeed, good point.

REPOSITORY
  R288 KJobWidgets

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28742

To: dfaure, broulik, davidedmundson, ervin
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D28753: Add KNotificationJobUiDelegate(KJobUiDelegate::Flags) constructor

[Kevin Ottens]

ervin accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28753

To: dfaure, broulik, davidedmundson, ervin
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D28742: Add KDialogJobUiDelegate(KJobUiDelegate::Flags) constructor

[Kevin Ottens]

ervin accepted this revision.

REPOSITORY
  R288 KJobWidgets

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28742

To: dfaure, broulik, davidedmundson, ervin
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns

D28743: Port kruntest to ApplicationLauncherJob

[Kevin Ottens]

ervin accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28743

To: dfaure, broulik, davidedmundson, ervin
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D28742: Add KDialogJobUiDelegate(KJobUiDelegate::Flags) constructor

[Kevin Ottens]

ervin accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R288 KJobWidgets

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28742

To: dfaure, broulik, davidedmundson, ervin
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D28741: [KJobUiDelegate] Add AutoHandlingEnabled flag

[Kevin Ottens]

ervin accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R244 KCoreAddons

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28741

To: dfaure, broulik, davidedmundson, ervin
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D27540: KCModule: Indicate when a setting has been changed from the default or previous value

[Kevin Ottens]

ervin updated this revision to Diff 79656.
ervin marked 6 inline comments as done.
ervin added a comment.


  Addresses David's comments

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27540?vs=78703=79656

REVISION DETAIL
  https://phabricator.kde.org/D27540

AFFECTED FILES
  src/CMakeLists.txt
  src/kconfigdialogmanager.cpp
  src/kconfigdialogmanager.h
  src/kconfigdialogmanager_p.h
  src/settingsstatusindicator.cpp
  src/settingsstatusindicator_p.h

To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik
Cc: alexde, ndavis, iasensio, davidre, kde-frameworks-devel, LeGast00n, cblack, 
GB_2, michaelh, ngraham, bruns

D27540: KCModule: Indicate when a setting has been changed from the default or previous value

[Kevin Ottens]

ervin marked 6 inline comments as done.
ervin added inline comments.

INLINE COMMENTS

> davidedmundson wrote in kconfigdialogmanager.cpp:609
> Why not item->readDefault()?

Wouldn't do the same thing at all. readDefault() takes a KConfig object and 
updates the default value stored in the item with what it found in there.

Yes, I know... the item API is weird...

> davidedmundson wrote in kconfigdialogmanager.cpp:625
> won't it do it itself when the property changes?

Good point, was indeed unnecessary now, I removed the line.

> davidedmundson wrote in settingsstatusindicator.cpp:75
> > This is equivalent to calling showFullScreen(), showMaximized(), or 
> > setVisible(true), depending on the platform's default behavior for the 
> > window flags.
> 
> For X and wayland it's setVisible(true)
> 
> but we shouldn't count on it.

I don't think it matters for widgets which have a parent and not the Qt::Window 
window flag, but OK, switching to setVisible() instead of show/hide.

> davidedmundson wrote in settingsstatusindicator.cpp:175
> unused?

I'm not sure how you end up to this conclusion, it's written two below if we 
are at the window edge, and it's used in the move call at the end.

> davidedmundson wrote in settingsstatusindicator.cpp:184
> Can we be sure the tracked widget always has a parent widget?
> 
> If someone doesn't use layouts a widget might not have a parent.

Well that'd mean the tracked widget is a window... it's pretty much an 
impossibility IMO.

> davidedmundson wrote in settingsstatusindicator.cpp:192
> that's not true for the RTL case where the widget is expected to resize.
> 
> It would be   w->pos().x() + w->width() - widgetExpectedWidth(w)

Either I misunderstood what you meant or you got the math wrong on that one.

What you're proposing (or what I understood you're proposing) breaks the "RTL + 
widget at edge" case in my tests. The line I wrote is working perfectly fine 
for my tests with desktoppath and qtquicksettings both in LTR and RTL modes.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D27540

To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik
Cc: alexde, ndavis, iasensio, davidre, kde-frameworks-devel, LeGast00n, cblack, 
GB_2, michaelh, ngraham, bruns

D27540: KCModule: Indicate when a setting has been changed from the default or previous value

[Kevin Ottens]

ervin added a comment.


  In D27540#638985 , @ndavis wrote:
  
  > Somehow I missed the notification that this was updated.
  >
  > Thanks for the horizontal alignment. Could you also add a left margin to 
the column of reset buttons? It should be the same as the spacing between the 
labels and the controls, which is equivalent to `Kirigami.Units.smallSpacing`, 
IIRC.
  
  
  Actually was already the case, forgot to update the screenshot.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D27540

To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik
Cc: alexde, ndavis, iasensio, davidre, kde-frameworks-devel, LeGast00n, cblack, 
GB_2, michaelh, ngraham, bruns

D27540: KCModule: Indicate when a setting has been changed from the default or previous value

[Kevin Ottens]

ervin edited the test plan for this revision.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D27540

To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik
Cc: alexde, ndavis, iasensio, davidre, kde-frameworks-devel, LeGast00n, cblack, 
GB_2, michaelh, ngraham, bruns

Re: Problems in KWayland causes by API and ABI compatibility promises

[Kevin Ottens]

Hello,

On Wednesday, 1 April 2020 14:04:10 CEST David Edmundson wrote:
> Here is a list of active uses of the KWayland::Client API.
> 
> frameworks
> plasma-framework (for window positioning)
> 
> apps:
> spectacle (for window positioning)
> kdeconnect-kde  (for fake input)
> yakuake (for window positioning)
> 
> extragear
> latte-dock (for window positioning, custom shadow (which could be
> ported already) and windowmanagement)

The part of the list above makes me wonder, shouldn't the window positioning 
and windowmanager features be on KWindowSystem?

I got no idea regarding kdeconnect-kde and the fake input...
 
> workspace:
> kwin unit tests
> libkscreen
> breeze (till Qt5.15)
> oxyen (till Qt5.15)
> xdg-desktop-portal
> kinfocenter
> plasma-workspace
> plasma-nano
> kscreenlocker
> powerdevil
> kwayland-integration (the backend for kwindowsystem)
> plasma-phone-components
> plasma-integration

I think the above is less of an issue, right? Because workspace would have a 
copy of KWayland which could be shared with whatever stability constraints 
needed.

Hope that helps. :-)

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.