Re: Proposal unify back our release schedules

[Nate Graham]

On 4/22/24 19:19, Albert Astals Cid wrote:

El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va
escriure:

Now, let's say we make Gear use Plasma's current release schedule by
syncing up the feature releases and adopting the Fibonacci bugfix
releases. If we don't end up changing Plasma's own release schedule then
we already make our promo store more coherent by letting the marketing
team do three big glossy announcements of user-facing products a year,
rather than being stretched thin for 6. Even if we make Plasma go down
to 2 releases a year, then we have two synced Gear+Plasma
"mega-releases" and 2 independent Gear releases--down from 6 to 4. Both
of these options would improve the promo story IMO.

---

Moving on, the biggest points of contention I see revolve around
Frameworks. Personally I want to push back a bit on the idea of
developing an app against released frameworks.


I disagree.

In my ideal world, applications should be able to be built against a one year
old frameworks, before the Qt6 port, Okular's minimum requirement was Ubuntu
22.04, which makes sure virtually everyone can contribute to it without having
to build the world.

There's virtually no need in Okular to depend against any new frameworks shiny
feature, the existing features are more than enough.

Cheers,
   Albert


This is true for Okular, but we can't guarantee it for other apps.

However I was fortunate enough to be sitting across a table from Volker, 
who explained this point to me in a way that my tiny brain was capable 
of understanding: :) that having a fast Frameworks release cycle allows 
people developing apps with features in Frameworks to not have to live 
on master like we do in Plasma.


I'd love to have everywhere in my slide of KDE what Albert has for 
Okular, but I there are other barriers to it that we need to overcome.


As a result I'll rescind my idea to slow down Frameworks feature 
releases. I do still think Frameworks could benefit from un-branched 
bugfix releases a week after the feature releases--after which point 
feature development would be open again.


And I still support unifying or aligning the Gear and Plasma release 
schedules.


Nate

Re: Proposal unify back our release schedules

[Nate Graham]

Ok, so happily I actually see quite a bit of agreement here, regardless 
of what else we do.


1. Fibonacci bugfix releases are good, and we could benefit from having 
Gear adopt these.


2. Severing implicit dependencies is a good idea. Shared libraries in 
Gear are especially problematic and could benefit from being moved to 
Frameworks.


3. Fast frameworks releases in some capacity are a benefit and we don't 
want to lose this.



All in agreement? If so, that would be amazing.

---

Now, let's say we make Gear use Plasma's current release schedule by 
syncing up the feature releases and adopting the Fibonacci bugfix 
releases. If we don't end up changing Plasma's own release schedule then 
we already make our promo store more coherent by letting the marketing 
team do three big glossy announcements of user-facing products a year, 
rather than being stretched thin for 6. Even if we make Plasma go down 
to 2 releases a year, then we have two synced Gear+Plasma 
"mega-releases" and 2 independent Gear releases--down from 6 to 4. Both 
of these options would improve the promo story IMO.


---

Moving on, the biggest points of contention I see revolve around 
Frameworks. Personally I want to push back a bit on the idea of 
developing an app against released frameworks. This is only realistic if 
you use a rolling release distro and are okay with waiting a month to 
use the new Frameworks code. For users looking to contribute with common 
discrete-release distros, it is not at all realistic as many Frameworks 
consumers require versions newer than what those users have on their 
system, so they have to build some Frameworks anyway (note: not all of 
them; kdesrc-build/kde-builder are smart enough not to do unnecessary 
work). The older the distro's packages, the more likely this is to be.


Furthermore, because Frameworks has time-based releases and no beta 
releases, in practice the QA is provided by developers living on master. 
If KDE developers deliberately avoid this, they're not participating in 
QA. There are of course other ways to improve Frameworks' QA as well, 
but continuing to encourage KDE developers to use distro-packaged 
Frameworks goes against the larger goal: we can't QA software versions 
we're not using.


While 12 releases a year of Frameworks feels fast, it's actually not. 
Gear also has 12 releases a year: 3 feature releases and 9 bugfix 
releases. And Plasma currently gets 18: 3 feature releases and 15 bugfix 
releases. The lack of bugfix releases is notable. With Plasma if a major 
bug is discovered a day after the release (which is common) I can ship a 
fix within a week, whereas for Frameworks, it takes a month. This is not 
a theoretical problem; it has happened many times over the years.


To me it has always felt strange that the product that benefits most 
from stability gets 4 times as many yearly feature releases as Gear and 
Plasma, but no bugfix releases at all. And there have been many 
occasions oven the years where new features in Frameworks could have 
benefited from a bit more QA time in master before final release.


In this sense I find Frameworks' release schedule to be both too fast 
and too slow: too fast for new features and too slow for bugfixes. 
Shouldn't the product with the strongest stability guarantee ship 
bugfixes at least as fast as Plasma?


If Frameworks got a feature release every 2 or 3 months and a guaranteed 
bugfix release one week after each feature release, IMO the result would 
be much better. We could ship fixes for important bugs faster, 
developers would be more incentivized to live on master and therefore 
provide their own QA, the period of time during which issues with new 
features could be caught before release would be doubled or tripled, and 
we could even still have 12 total releases per year.


---

Thus, if we make Gear's release cycle identical to Plasma's to get it 
faster bugfixes, and then we also lengthen Frameworks' release cycle so 
it gets the bugfix releases it could benefit from while slowing down its 
feature releases to improve QA, then the result looks a lot like Carl's 
proposal, and that's ultimately why it looks appealing to me.


This doesn't preclude breaking implicit dependencies and relocating 
software into groups/release vehicles more suited for them. I don't find 
the argument convincing that we ought to deal with pain to make this 
happen. IMO we should make decisions about the final form we want, not 
based on what we think will torture us into getting there. :)


Nate

Re: AppStream Metadata with our releases

[Nate Graham]

On 3/25/24 23:27, Albert Astals Cid wrote:

El dilluns, 25 de març de 2024, a les 19:37:07 (CET), Volker Krause va
escriure:

As Itinerary was mentioned, the process there currently is to run David's KF
changelog script over all repositories in Itinerary's dependency chain and
take the top 5 or so most visible/important changes (which here are
actually often from other repositories). The commit adding the release to
appstream is my reminder for that currently, but there's other ways to do
that, so for Itinerary the proposed change wouldn't make much of a
difference either way.


This brings an interesting point, it would seem that the right time to add the
release description is at the end of the release cycle when you know all the
changes, not when a particular commit is made.


I like what Itinerary does. Idea: we run this script nightly in repos 
with AppStream metadata so that it appends changes newly committed 
changes to the notes quickly after they've made, not just all in one big 
blog towards the end of the release. Then a few more changes could make 
it acceptable to roll it out universally:


- When run for this purpose, modify the script to ignore anything that 
doesn't fix a bug report, so the changelog doesn't end up too long and 
spammy.


- Allow repos to opt out if they prefer to manually write/curate their 
release notes.



Nate

Re: Proposal unify back our release schedules

[Nate Graham]

Thanks for taking the time to assemble this email, Carl. These are 
arguments I've brought up individually myself for years, and I think 
they have merit.


Taken together, for me they paint a picture of a project that was 
attempted, faithfully executed on, but didn't end up delivering the 
benefits we hoped for while introducing some new drawbacks that have no 
easy path to being resolved. I'm in favor.


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.


Nate




On 4/19/24 11:04, Carl Schwan wrote:

Hello Community,

I know this might be a controversial idea, but I would like to propose reunify
our release schedules. I feel like splitting our releases schedules between
Frameworks, Plasma and Gear is not working as well as we intended it to be when
we split the releases schedules for Plasma 5. This is for multiple reasons:

* 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 results in very frequent releases which creates a lot of work for distros
   and talking with some distro maintainers they seems to agree that having a 
big
   releases every 4 months is better than having constantly a new minor or major
   release from either Framework, Gear or Plasma.

* 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.

* We could have an unified LTS release including more than just Plasma. This is
   something that distros have been asking for some time already because having
   just Plasma receiving bug-fixes but not Framework nor the apps is not that 
helpful.

* In term of promotion, it is very difficult to advertise the 3 releases because
   combined we have an important release of either Gear, Plasma or Framework 
every
   few weeks. This is too frequent and often while a combined announcement would
   have enough content to be published in a tech newspaper. When splitting the 
content
   accross 2 announcements (Gear and Plasma), we reduce the content per
   announcement and this makes it less interesting for the journalists to write
   about us. This doesn't come from me, this is that some journalists directly
   told me.

* We won't have 3 different release teams but instead have a bigger one with a
   bigger bus factor. We could also unify the tooling for doing this mass 
releases
   a bit.

I do understand that there was valid reasons for splitting KDE Software 
Collection
for Plasma 5 but I don't think this worked out. These were as far as I know the
main arguments used for splitting the Software Collection.

* Trying to move away from "KDE" being recognized as the software instead of the
   community. This unfortunately didn't really work out, everyone is still using
   KDE to refer to the desktop. Even distros call their edition "KDE" and I 
don't blame
   them, it's difficult to find a better term than that as for example "Fedora KDE 
Spin"
   not only contains Plasma but also a lot of KDE apps. Splitting the releases 
won't
   help with that, we need to find a better approach or just let it go and 
accept that
   people will keep using KDE to describe the desktop/software.

* Better promotion of our apps outside of Plasma. This is a valid point but I 
think
   pursuing our current strategy of putting our apps in many app store to be 
more
   effective. We could also show the platforms support of each applications more
   prominently in our releases announcements like we already do on apps.kde.org
   (e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot 
better
   in term of promotion than the gear announcements and showing the applications
   on an unified announcement would likely help spread the words about our 
applications
   better.

* 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.

In effect this proposal would 

Re: Automation & Systematization sprint in Berlin in late April

[Nate Graham]

Hello Tracey and anyone else interested--If you're coming, please add 
yourself to the table at https://community.kde.org/Sprints/Goals/2024. 
Also if you need support for travel and lodging costs, you can apply at 
https://reimbursements.kde.org/events/187. For those of us traveling 
across the world, it can add up fast, so don't be shy about applying!


Nate


On 1/31/24 18:27, Tracey Clark wrote:
I would be interested in a possible in-person sprint supporting the 
Automation & Systematization goal in April. I have a strong automated 
testing background (in perl). I would love to share my experience. Also, 
I would love to learn the testing framework used at KDE, as I'm looking 
to step up my contributions. What better way than in person :)

Re: Automation & Systematization sprint in Berlin in late April

[Nate Graham]

Sorry for the crazily delayed response. I'm digging out from under the 
megarelease email bomb.


On 3/3/24 16:23, Albert Astals Cid wrote:

What's the plan for travel support requests?

Should we start filing requests at https://reimbursements.kde.org ?


Yep. The event is https://reimbursements.kde.org/events/187


Should requests include travel and hosting or hosting will be booked
centrally?


Include both travel and accommodations; folks are on their own for both.

If you're planning to attend, please add yourself to 
https://community.kde.org/Sprints/Goals/2024.


Thanks everyone!


Nate

Re: Automation & Systematization sprint in Berlin in late April

[Nate Graham]

Quick update on this. the dates are now locked in, but we're still 
finalizing a venue in Berlin. More information will be provided as it 
becomes available.


Thanks for your patience here, everyone!

Nate




On 1/31/24 16:26, Nate Graham wrote:

Hello folks!

I'd like to gauge interest in an in-person sprint supporting the 
Automation & Systematization goal. Right now we are targeting Berlin on 
April 19th - April 24th. KDE e.V. has budget available to help with 
travel and lodging costs.


This will be a triple-threat sprint, with the Accessibility and 
Sustainability sprints co-located. People interested in multiple topics 
will be able to jump between them if they want.


Topics for the Automation & Systematization sprint might include:
- Writing tests
- Fixing failing tests
- Making tests mandatory to pass
- Documenting how to write good tests
- Updating outdated documentation
- Transition documentation to code (e.g. making kdesrc-build or the new 
kde-builder tool do more itself, so we don't have to write so much about 
it in our documentation)

- Make a push for enabling clang-format for more repos
- Make a push to put release notes in AppStream metadata
- Improve our AppStream CI job to require or recommend more things
- Make a CI job to enforce as much of the onboarding/new repo checklist 
as possible, and make enabling it be a part of the process


These are just ideas; the folks who attend will be the ones who guide 
the agenda.


Let me know if you're interested so I can get a sense of the level of 
attendance!



Nate

Post-MegaRelease projects

[Nate Graham]

Hello everyone,

Congrats to the entire KDE community on the impending launch of the KDE 
6 MegaRelease! I'm so impressed with how folks came together to make it 
amazing. It's a very impressive release and I think people are gonna 
love it.


I've started pondering post-megarelease projects. We've spent so long on 
porting and bugfixing that I think it might be useful to shift gears to 
feature work, and I'd like to brainstorm potential large-scale projects 
and gauge the level of interest in putting resources into them soon.


Here are some ideas of mine to get the creative juices started:

* David's input method playground stuff [1] is amazing and needs to be 
developed and productized
* GNOME's Libadwaita app platform has been a runaway success for them; 
evaluate our offerings in comparison and see what we can do better

* Unified theming infrastructure for KDE apps, GTK apps, and Plasma.
** Relatedly: QML/JS in themes is dangerous; move away from it
* Start adding release notes to our apps' AppStream metadata [2]
* Finish up and ship the new Breeze icons
* HIG is outdated and mostly ignored, and needs an overhaul to make it 
useful

* Telemetry system has not proved to be very useful and needs an overhaul
* store.kde.org is full of low-quality or broken content; make a push 
for KDE people to take ownership of content moderation, QA, etc. Also 
any relevant and needed tech improvements

* Our virtual keyboard situation is not great and needs focused work
* KWallet needs an overhaul
* Have KWin (optionally) remember window positions on Wayland
* Build a "System misconfiguration detection hub" app [3]

Feel free to discuss, and propose your own!

Nate



[1] 
https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods/

[2] https://github.com/ximion/appstream/issues/354
[3] https://invent.kde.org/plasma/plasma-workspace/-/issues/64

kio-gdrive changes needed to conform to new Google requirements

[Nate Graham]

Hello folks,
The KDE e.V. board received an email from Google about changes required 
for kio-gdrive. I've opened an Issue about it at 
https://invent.kde.org/network/kio-gdrive/-/issues/1 with more details. 
To my knowledge, kio-gdrive is maintainerless, so we're in need of a 
kind soul who will volunteer to make any needed changes to the software. 
:) Any takers?


Nate

Re: Defining a developer name for our applications metadata

[Nate Graham]

Sounds good! Thanks for tackling this, Timothée.

Nate



On 2/2/24 08:55, Timothée Ravier wrote:

Hi everyone,

Following suggestions in the thread, I'll start updating our AppStream 
metadata with:


```
KDE
```

Thanks
--

Timothée Ravier

CoreOS co-Team Lead

Red Hat

trav...@redhat.com 

Automation & Systematization sprint in Berlin in late April

[Nate Graham]

Hello folks!

I'd like to gauge interest in an in-person sprint supporting the 
Automation & Systematization goal. Right now we are targeting Berlin on 
April 19th - April 24th. KDE e.V. has budget available to help with 
travel and lodging costs.


This will be a triple-threat sprint, with the Accessibility and 
Sustainability sprints co-located. People interested in multiple topics 
will be able to jump between them if they want.


Topics for the Automation & Systematization sprint might include:
- Writing tests
- Fixing failing tests
- Making tests mandatory to pass
- Documenting how to write good tests
- Updating outdated documentation
- Transition documentation to code (e.g. making kdesrc-build or the new 
kde-builder tool do more itself, so we don't have to write so much about 
it in our documentation)

- Make a push for enabling clang-format for more repos
- Make a push to put release notes in AppStream metadata
- Improve our AppStream CI job to require or recommend more things
- Make a CI job to enforce as much of the onboarding/new repo checklist 
as possible, and make enabling it be a part of the process


These are just ideas; the folks who attend will be the ones who guide 
the agenda.


Let me know if you're interested so I can get a sense of the level of 
attendance!



Nate

Re: Defining a developer name for our applications metadata

[Nate Graham]

What sprang immediately to my mind was simply "KDE". Short and sweet.

Nate



On 1/30/24 10:34, Timothée Ravier wrote:

Hi folks,

Flathub is now requiring that applications define a "developer_name" tag 
in their metadata (see [1], [2]).


What do folks think would be a good value for our application there?

Based on the suggestion in the documentation [3], I started making PRs 
[4] [5] [6] [7] for our KDE Apps with "The KDE Community" as the 
"developer_name" tag.


I'm open to suggestions.

Thanks,

[1] 
https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/#name-summary-and-developer-name 
[2] 
https://docs.flathub.org/docs/for-app-authors/linter/#appstream-missing-developer-name 
[3] 
https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer 
[4] https://invent.kde.org/graphics/gwenview/-/merge_requests/249 

[5] https://invent.kde.org/system/dolphin/-/merge_requests/708 

[6] https://invent.kde.org/multimedia/kdenlive/-/merge_requests/465 

[7] https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/531 



--

Timothée Ravier

CoreOS co-Team Lead

Red Hat

trav...@redhat.com 

Re: Exception request: High contrast frames and separators

[Nate Graham]

The underlying work is already there, and this doesn't seem to add much 
new code, just some UI changes and new strings (which will also need a 
string freeze exception). In light of the Accessibility Goal, I support 
an exception here. +1.


Nate



On 12/31/23 10:59, Akseli Lahtinen wrote:

Hi!

I have made an accessibility feature that allows to set high-contrast mode for
any outlines and frames Breeze style has.

Here is the original merge request:
https://invent.kde.org/plasma/breeze/-/merge_requests/393

Do note that it's been split to three separate merge requests!
However, the above linked MR has still all the relevant info.

The feature exception request is for both style and window deco.
For style, it adds the checkbox toggle that sets the frame either
default color or high contrast color.

In window deco, we just remove the unnecessary settings,
and only have three settings: Off, Default, High Contrast

I do think this would be good to get in ASAP, since it is an accessibility
feature and will be genuinely helpful for many who need high contrast
colors in their setups.

Best regards and happy new year,
Akseli Lahtinen

Re: Spacing in our apps

[Nate Graham]

This is an important topic, so I appreciate you bringing it up, Carl. 
It's been on my mind recently as well.


For some background, the reason why we have multiple spacing values in 
Kirigami and Plasma (e.g. SmallSpacing, LargeSpacing, GridUnit, etc) is 
because in the past we didn't want developers multiplying standard 
spacing values by "random numbers." The idea was that developers would 
choose the perfect spacing value for each situation and use it directly, 
without having to multiply it by anything.


Unfortunately, we failed to make it obvious what situation merited what 
spacing value. So in practice individual developers ended up using 
whichever spacing values felt best to them, and as we know, opinions 
differ on the topic of padding vs density in UI layouts. The result is 
inconsistent spacings in many places.


In addition, people end up multiplying the standard spacings by random 
numbers anyway, because most of them are quite small and sometimes you 
do need big spacing.


Finally, until Noah added MediumSpacing fairly recently, none of the 
standard spacing values matched the default spacing value in Breeze of 
6px. Even then the spacings may not remain a perfect match because the 
Kirigami/Plasma spacing values adjust with the font size, while the 
Breeze one does not.


I think we can unfortunately conclude that this design system was not a 
success, and in fact worsened the consistency of our spacings in 
QtQuick-based software compared to QtWidgets-based software while 
confusing developers.


As such, I support *proposal A*, which I feel is the simplest and most 
comprehensible one.


I could accept "A bis", but I think having two standard values that get 
defined to the same underlying value in Breeze is recipe for continuing 
the confusion, just in a different form. What's the difference between a 
spacing and a margin, anyway? We might want to move away from continuing 
this distinction in our QStyle too, seeing as we define both values to 
the same thing.



Nate




On 12/17/23 05:21, Carl Schwan wrote:

Hi,

I'm been trying to unify a bit the usage of spacing in our apps and I'm
noticing a difference between how we do it in QWidgets apps and QML apps.

In QtWidgets apps, we use

- pixelMetric(QStyle::PM_Layout{Left,Right,Top,Bottom}Margin) for the margins
- pixelMetric(QStyle::PM_Layout{Vertical,Horizontal}Margin) for the spacing
between items in layout

In practice all these pixel metrics are equal to 6 pixels with Fusion, Oxygen
and Breeze. These means that in some cases, some apps are even hardcoding
these values in their .ui files, which is bad and we should try to avoid this.

In Kirigami apps, we use:

- Kirigami.Units.smallSpacing = 4 pixels
- Kirigami.Units.mediumSpacing = 6 pixels
- Kirigami.Units.largeSpacing = 8 pixels

In most cases, smallSpacing and largeSpacing are used as mediumSpacing was
introduced later on, so it doesn't match the values from QtWidgets apps. Worse
we don't really have clear guidelines when to use small or large spacing, so
it's mostly done arbitrarely and not consistantly :(

Also having 3 different Kirigami.Units.*Spacing values that are each only 2
pixels appart doesn't sounds like a great idea as it's hard to see a
difference between these values taken side by side.

I see three ways to move forward with this issue:

a) Remove smallSpacing and largeSpacing from Kirigami, and rename
mediumSpacing to just spacing. This unified spacing value would be defined in
qqc2-desktop-style to use whatever value is defined in the current QStyle.

a bis) Instead of creating only a generic "spacing" property, we create a
"Kirigami.Units.margins" or "Kirigami.Units.paddings" property to use for
paddings of QtQuick Controls and mapped to the Layout*Margin pixel metrics and
a "Kirigami.Units.spacing" property mapped to the Layout*Spacing pixel
metrics. For Breeze and Oxygen, both value would map to 6 pixels anyway, but
it might make it easier to switch to other values in the future as well as
make the usage of Units value more explit.

b) Use 4 pixels as standard spacing in our QtWidgets apps and add a "margins"
and "largeMargin" helper methods in KWidgetsAddons or QStyle similar to this

QMargins QStyle::largeMargins() const
{
 return QMargins{
 pixelMetric(QStyle::PM_LayoutLeftMargin),
 pixelMetric(QStyle::PM_LayoutTopMargin),
 pixelMetric(QStyle::PM_LayoutRightMargin),
 pixelMetric(QStyle::PM_LayoutBottomMargin)
 }
}

QMargins QStyle::largeMargins() const
{
 return QMargins{
 pixelMetric(QStyle::PM_LayoutLeftMargin) * 2,
 pixelMetric(QStyle::PM_LayoutTopMargin) * 2,
 pixelMetric(QStyle::PM_LayoutRightMargin) * 2,
 pixelMetric(QStyle::PM_LayoutBottomMargin) * 2
 }
}

then we can remove mediumSpacing from Kirigami and ensure that in both our
Kirigami and QtWidgets apps, we use small or large only no spacing at all. We
should still try to define some guidelines when to use large 

Re: Ark Qt Version

[Nate Graham]

I'm not a heavy user of Ark, but I haven't noticed any glaring defects 
in its Qt 6 version over the past few months. FWIW. I vote for adding it 
to the list to encourage wider testing.


Nate



On 12/11/23 04:07, Jonathan Riddell wrote:

I'm e-mailing everyone who has committed to Ark in the last year.

It's not on our list of KDE Gear apps which have been ported to Qt 6.  
But many distros are building it for Qt 6 and reporting it works fine.  
If it's not built for Qt 6 then people miss plugins in Dolphin and 
elsewhere.


Should we add it to the list of apps we recommend distros build with Qt 
6?  This is for the currently in beta KDE Gear 24.02 version.


Jonathan

Unified internal communications channel

[Nate Graham]

Hello everyone,

There have been a couple instances of drama this week caused by 
decisions being made without some of the relevant stakeholders knowing 
about them. In all cases, the decisions were announced, but either not 
announced in the places where all the stakeholders saw it, or not all 
stakeholders were able to notice the announcement in a place where they 
do generally pay attention.


It makes me think that maybe the KDE development community has grown so 
large that we can't reasonably expect everyone to be paying attention to 
everything, or for everyone with something to announce to know exactly 
where the people who need to know it expect to find those messages.


So perhaps this could be addressed at the source by creating a single 
unified "internal announcements" place that everyone can pay attention 
to without fear of being spammed with too many messages. In theory the 
kde-devel mailing list is one such place, but it's got more than just 
announcements, and also mailing lists aren't very accessible for a lot 
of newer contributors who didn't grow up with them.


What I'm proposing is some kind of place that *only* has internal 
announcements and is very log signal-to-noise such that we can 
fearlessly recommend that *everybody* subscribe to it. In addition, 
ideally those who want to subscribe via mailing list could do so, but 
its content would automatically appear in other places too, such as 
discuss.kde.org and an invent.kde.org project. That way people can 
subscribe by whatever means is most comfortable to them.


Thoughts?

Nate

Re: per-issue notifications from sentry

[Nate Graham]

I have personally disabled this functionality for my account already as 
I found them useless.


Nate



On 11/26/23 07:38, Harald Sitter wrote:

does anyone else find the emails from sentry when a new issue appears
to be rather useless? they are very noisy and often times not
interesting since a single crash often doesn't have enough context to
act on anyway.

should I look into disabling them?

HS

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

[Nate Graham]

On 11/5/23 07:42, Kevin Ottens wrote:

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.


Yes, Elisa also includes an internal indexer, for use on Windows and 
Android, or on *Nix when Baloo isn't installed or is disabled.


I think the original idea for the app was to delegate all the indexing 
heavy lifting to Baloo to avoid internal complication, but clearly this 
has not worked out in practice, since to be truly cross-platform, it 
can't assume that Baloo is present and active and does need its own 
indexer. So maybe the best course of action is actually to remove Baloo 
support entirely and always use the internal indexer, so that we don't 
have two different code paths.


Nate

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

[Nate Graham]

On 11/5/23 07:09, christ...@cullmann.io wrote:

On 2023-11-05 12:59, Friedrich W. H. Kossebau wrote:

Hi,

with plasma-framework, kactivities and kactivities entering the Plasma 
product

bundle, I assume they also will adapt to Plasma versioning.


Hi,

if we are atm moving stuff, might it make sense to move Baloo, too, 
given it only

is usable with the daemon inside Plasma more or less, too?

Greetings
Christoph


Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make 
them haul in Plasma stuff.


Nate

Re: Bug Safari Project

[Nate Graham]

Very nice! I'm happy with it.

Nate



On 10/27/23 03:00, Ben Bonacci wrote:
The new room is now ready and can be accessed with the following URL: 
https://go.kde.org/matrix/#/#bugsafari-plasma:kde.org


Also, I'm aware that the deltas are incorrectly inverted which I will 
fix soon.


Regards,

Ben

On 29/8/23 21:32, Ben Bonacci wrote:
I filed a sysadmin request a while ago about setting up a Matrix 
account on KDE's homeserver for the script to run from as well as 
making a room for this test however I have not received further 
details yet.


Until then, I'll use my homeserver to test it out more formally. I've 
created a public room where the script will generate reports for 
Plasma bugs. The room URL is as follows: 
https://go.benbonacci.com/bug-safari-demo-room


As soon as the Matrix setup is ready on KDE's homeserver, the test 
room and account will be migrated there and I'll continue to manage 
the script itself during that time too. Then if the testing goes well 
it should be fairly easy to move reports into the Plasma room and find 
someone to manage the script full-time.


Regards,

Ben

On 15/8/23 10:39, Nate Graham wrote:

+Justin

Very cool. Can we see it in action anywhere? Maybe we could test 
rolling it out somewhere?


Nate



On 8/11/23 20:03, Ben Bonacci wrote:
Thanks for the list of suggestions! I've now made all those changes 
with an exception for the emoticons which I may revisit later.


And to add onto the first suggestion, the script still works with 
non-Plasma bugs if other teams want to use it by modifying 
bug_lists.json but the bug report name can be set to show what the 
bugs are for.


Regards,

Ben

On 29/7/23 04:07, Nate Graham wrote:
Thanks, looks like a great start! Can we get the following changes 
(Justin's bot already does these things):

- Clarify in the announcement text that this is for Plasma only
- Make the text into clickable links so people can find the bugs 
and go fix them
- Fix the "VHI priority bugs" query; that seems wrong and it should 
be [1]

- Mention the delta from yesterday's numbers in parentheses
- Optional: add emojis to each one for a bit of fun; see Justin's 
script for details


Thanks again for working on this!

Nate



[1] 
https://bugs.kde.org/buglist.cgi?bug_severity=critical_severity=grave_severity=major_severity=crash_severity=normal_severity=minor_severity=task_status=UNCONFIRMED_status=CONFIRMED_status=ASSIGNED_status=REOPENED_name=VHI-priority%20Plasma%20bugs_id=2429682=VHI=Bluedevil=Breeze=Discover=drkonqi=frameworks-kirigami=frameworks-plasma=frameworks-qqc2-desktop-style=kactivitymanagerd=kde-gtk-config=kdeplasma-addons=khelpcenter=kinfocenter=klipper=kmenuedit=krunner=KScreen=kscreenlocker=ksmserver=ksysguard=KSystemLog=kwin=Plasma%20SDK=Plasma%20Vault=Plasma%20Workspace%20Wallpapers=plasma-integration=plasma-nm=plasma-pa=plasma-simplemenu=plasmashell=policykit-kde-agent-1=Powerdevil=print-manager=printer-applet=pulseaudio-qt=systemsettings=Touchpad-KCM=user-manager=xdg-desktop-portal-kde_based_on=VHI-priority%20Plasma%20bugs_format=advanced




On 7/24/23 05:00, Ben Bonacci wrote:

Hi Nate,

I've recorded the script in action which can be accessed with this 
link: https://benbonacci.com/files/shares/1w-bug-safari-demo.mp4 
(Expires in 1 week)


Regards,

Ben

On 23/7/23 23:43, Nate Graham wrote:

Very cool stuff. Can we see it in action anywhere?

Nate


On 7/23/23 01:38, Ben Bonacci wrote:

Hi Ben,

Thanks for the suggestion! Now after each request the script 
will wait 1-5 seconds before making the next request.


Regards,

Ben

On 22/7/23 22:30, Ben Cooksley wrote:
On Sun, Jul 23, 2023 at 12:18 AM Ben Bonacci 
 wrote:


    Hi everyone!


Hi Ben,


    For the past few days I've been working on Bug Safari, 
which is a

    Python
    script that gets statistics for Plasma bugs and sends a 
report to the
    #plasma room on Matrix, which is one of the dot points for 
KDE's

    Automation goal.

    I've now got the script uploaded to Invent at
https://invent.kde.org/bbonacci/bug-safari for anyone to look
    over, make
    improvements or implement.


Thanks for this, I have just had a quick look over the code and 
it overall looks pretty reasonable, and also follows best 
practice of setting it's own user agent.


One small suggestion would be to add some small sleeps in to 
ensure that the server endpoints don't get hammered by your 
requests.
While the script by itself is fairly innocent, if similar 
scripts were added for a series of other channels and they all 
ran at the same time, this could result in a rush on the server 
that could make it inaccessible to normal users (or at the very 
least impact responsiveness).


Adding some sleeps (ideally for a random number of seconds as 
people tend to pick the same cron times to run stuff on) will 
ensure this doesn't become an issue.



    Regards,

    Ben


Cheers,
Ben


    --     Ben Bonacci
https://benbonacci.com
    C0A9 E67F 8CDC B1A1 0860 1807 E018 065C

Retroactive kdereview: ocean-sound-theme

[Nate Graham]

Hello kde-core-devel folks,

We did the KDE Review process for ocean-sound-theme a bit wrong and 
forgot to email this mailing list before moving it to its final home. So 
I'm retroactively submitting it for review in case folks see anything 
wrong that needs to be corrected.


See https://invent.kde.org/plasma/ocean-sound-theme/-/issues/7.

Nate

Re: KDE Review: Hash-o-Matic

[Nate Graham]

On 10/2/23 13:53, Albert Astals Cid wrote:

El diumenge, 1 d’octubre de 2023, a les 21:49:36 (CEST), Carl Schwan va
Who checked all those marks? There's no way to know.


If you scroll down to "Activity", it says who checked them after the 
issue was opened.


I agree that the person who opened the Issue should not check anything 
themselves before opening the Issue up, though. This seems like a 
sensible policy.


Nate

Re: Do you use votes on Bugzilla tickets to help you make decisions?

[Nate Graham]

Yes, I botched the communication on this, my apologies about that.

Voting has now been disabled on Bugzilla. We are investigating ways to 
make the CC count affect the bug janitor's automatic priority 
categorization in its stead.


Nate



On 9/3/23 15:45, Elvis Stansvik wrote:

I noticed today that my votes on some bugs had been removed. Visiting
the bugs I see there's no longer any way to vote.

So I guess as a result of this discussion, voting was disabled on some products?

No problem with me, but would have been nice with some sort of
announcement (sorry if I missed it!)

Elvis

Den fre 4 aug. 2023 kl 23:55 skrev Harald Sitter :


Never looked at them. Never seen the benefit.

On Fri, Aug 4, 2023 at 3:53 PM Nate Graham  wrote:


Hello folks!

I often find myself explaining to users that votes on Bugzilla tickets
are generally meaningless and not used by most developers to help
prioritize work. After I explain this, they generally express surprise,
as it's not obvious.

I find myself wondering whether it would make sense to disable the
voting feature by default to avoid giving our users this false impression.

So if you *do* take user votes into consideration when determining what
tickets to prioritize, I'd like to hear from you!


Nate

Re: drkonqi's many debuggers

[Nate Graham]

On 8/28/23 22:25, Thiago Macieira wrote:

It does because it might be missing in the system far more often than gdb.
We'd get more backtraces and therefore more data if we focused on gdb

Another point is that Linux distributions have been shipping gdb with
debuginfod support for a year or two. lldb support for it is still pending:
https://github.com/llvm/llvm-project/issues/52732

Therefore, I repeat: if there's room for only one, it's gdb.

If we do support both, then on Linux gdb must be used in preference.



DrKonqi itself could declare a required build dependency on lldb, and 
then we would know it's present on the system. Distros that don't 
package it would then have to omit DrKonqi, or start packaging it.


Nate

Re: Planning the final 6 release timeframes

[Nate Graham]

Thanks for organizing this, David. Where and how will the meeting be held?

Nate



On 8/22/23 09:22, David Edmundson wrote:

A time has been chosen on the poll with a clear winner:
4th September 18:00 CEST

See you all there

David Edmundson

Re: Planning the final 6 release timeframes

[Nate Graham]

Thanks for organizing this, David. Where and how will the meeting be held?

Nate



On 8/22/23 09:22, David Edmundson wrote:

A time has been chosen on the poll with a clear winner:
4th September 18:00 CEST

See you all there

David Edmundson

Re: Per project repository snapcraft files?

[Nate Graham]

On 8/19/23 18:42, Scarlett Moore wrote:
Only on release! We will not be building from master! We don't want 
unstable snaps.

Thanks,
Scarlett


Aha! Sounds fine, then. In fact I believe this is the direction we want 
to go in with FlatHub too: triggering the remote builds from spec files 
located on our own infrastructure.


Nate

Re: Per project repository snapcraft files?

[Nate Graham]

On 8/19/23 15:45, Scarlett Moore wrote:
No. It will be telling launchpad to build them via API. Launchpad will  
upload to store its own artifacts. Our current setup has launchpad 
sending the snaps back to our server and we upload to store. This new 
proposal would be significantly less data going back and forth. Also, do 
the stable branches really have many commits? I thought once branched to 
stable release branch it was done... I reiterate that launchpad is doing 
all the heavy lifting including store uploads. Do users download 
flatpaks from kde servers? The button says flathub. How do they get there?

Scarlet
If Launchpad needs to build our Snaps as a part of the release process, 
that's something that will need to happen only a few times a year. Apps 
on FlatHub are similarly built for us by FlatHib infrastructure. It's fine.


But asking Launchpad to build us a Snap for every commit is another 
matter. KDE apps get at least one commit per day just due to 
translations, and popular apps may get many commits per day and many 
merge requests. I can think of a large variety of issues that could be 
caused by asking Launchpad to build Snaps at this much higher frequency 
level.


So can we clarify the proposal? Are you asking to have Launchpad build 
Snaps as a part of the CI process, for every commit and merge request? 
Or just as a part of the release process that happens a few times a year?


Nate

Re: Per project repository snapcraft files?

[Nate Graham]

So are these proposed CI jobs really intended to *release* the Snaps on 
the store? Is there any way to just build the Snaps locally?


I ask because CI jobs run on every commit, so what we need them to test 
is that a proposed change hasn't broken Snap generation. We don't want 
to upload something to a remote server on every commit! It would be 
quite bad if KDE developers were unable to merge merge requests because 
an external server is down or overloaded.


Nate


On 8/19/23 09:16, Scarlett Moore wrote:



On Sat, Aug 19, 2023, 7:48 AM Nate Graham <mailto:n...@kde.org>> wrote:


Right now, our Flatpak CI jobs are self-contained; they generate a
Flatpak without the need for any external servers. They're not
uploading
anything to FlatHub or elsewhere.

I might be misunderstanding something, but it seems like these proposed
Snap CI jobs will be interacting with an external server in some way.
Can you clarify that situation?

Nate


Yes, launchpad ( we already do this ) , however this time will be much 
less as launchpad will build and upload the snaps to the store. Current 
setup launchpad send back the snaps and we upload to the store.. also we 
have issues getting logs for failures as these are temp jobs and 
disappear quickly. Doing it the correct way with per repo snapcraft 
files will solve many issues.

Thanks for your consideration,
Scarlett

Re: Per project repository snapcraft files?

[Nate Graham]

Right now, our Flatpak CI jobs are self-contained; they generate a 
Flatpak without the need for any external servers. They're not uploading 
anything to FlatHub or elsewhere.


I might be misunderstanding something, but it seems like these proposed 
Snap CI jobs will be interacting with an external server in some way. 
Can you clarify that situation?


Nate

Re: Bug Safari Project

[Nate Graham]

+Justin

Very cool. Can we see it in action anywhere? Maybe we could test rolling 
it out somewhere?


Nate



On 8/11/23 20:03, Ben Bonacci wrote:
Thanks for the list of suggestions! I've now made all those changes with 
an exception for the emoticons which I may revisit later.


And to add onto the first suggestion, the script still works with 
non-Plasma bugs if other teams want to use it by modifying 
bug_lists.json but the bug report name can be set to show what the bugs 
are for.


Regards,

Ben

On 29/7/23 04:07, Nate Graham wrote:
Thanks, looks like a great start! Can we get the following changes 
(Justin's bot already does these things):

- Clarify in the announcement text that this is for Plasma only
- Make the text into clickable links so people can find the bugs and 
go fix them
- Fix the "VHI priority bugs" query; that seems wrong and it should be 
[1]

- Mention the delta from yesterday's numbers in parentheses
- Optional: add emojis to each one for a bit of fun; see Justin's 
script for details


Thanks again for working on this!

Nate



[1] 
https://bugs.kde.org/buglist.cgi?bug_severity=critical_severity=grave_severity=major_severity=crash_severity=normal_severity=minor_severity=task_status=UNCONFIRMED_status=CONFIRMED_status=ASSIGNED_status=REOPENED_name=VHI-priority%20Plasma%20bugs_id=2429682=VHI=Bluedevil=Breeze=Discover=drkonqi=frameworks-kirigami=frameworks-plasma=frameworks-qqc2-desktop-style=kactivitymanagerd=kde-gtk-config=kdeplasma-addons=khelpcenter=kinfocenter=klipper=kmenuedit=krunner=KScreen=kscreenlocker=ksmserver=ksysguard=KSystemLog=kwin=Plasma%20SDK=Plasma%20Vault=Plasma%20Workspace%20Wallpapers=plasma-integration=plasma-nm=plasma-pa=plasma-simplemenu=plasmashell=policykit-kde-agent-1=Powerdevil=print-manager=printer-applet=pulseaudio-qt=systemsettings=Touchpad-KCM=user-manager=xdg-desktop-portal-kde_based_on=VHI-priority%20Plasma%20bugs_format=advanced




On 7/24/23 05:00, Ben Bonacci wrote:

Hi Nate,

I've recorded the script in action which can be accessed with this 
link: https://benbonacci.com/files/shares/1w-bug-safari-demo.mp4 
(Expires in 1 week)


Regards,

Ben

On 23/7/23 23:43, Nate Graham wrote:

Very cool stuff. Can we see it in action anywhere?

Nate


On 7/23/23 01:38, Ben Bonacci wrote:

Hi Ben,

Thanks for the suggestion! Now after each request the script will 
wait 1-5 seconds before making the next request.


Regards,

Ben

On 22/7/23 22:30, Ben Cooksley wrote:
On Sun, Jul 23, 2023 at 12:18 AM Ben Bonacci  
wrote:


    Hi everyone!


Hi Ben,


    For the past few days I've been working on Bug Safari, which is a
    Python
    script that gets statistics for Plasma bugs and sends a report 
to the

    #plasma room on Matrix, which is one of the dot points for KDE's
    Automation goal.

    I've now got the script uploaded to Invent at
https://invent.kde.org/bbonacci/bug-safari for anyone to look
    over, make
    improvements or implement.


Thanks for this, I have just had a quick look over the code and it 
overall looks pretty reasonable, and also follows best practice of 
setting it's own user agent.


One small suggestion would be to add some small sleeps in to 
ensure that the server endpoints don't get hammered by your requests.
While the script by itself is fairly innocent, if similar scripts 
were added for a series of other channels and they all ran at the 
same time, this could result in a rush on the server that could 
make it inaccessible to normal users (or at the very least impact 
responsiveness).


Adding some sleeps (ideally for a random number of seconds as 
people tend to pick the same cron times to run stuff on) will 
ensure this doesn't become an issue.



    Regards,

    Ben


Cheers,
Ben


    --     Ben Bonacci
https://benbonacci.com
    C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

    Quote of the Day: "What's the good of living if you don't try a
    few things?" - Charles M. Schulz


--
Ben Bonacci
https://benbonacci.com
C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

Quote of the Day: "If you only read the books that everyone else is 
reading, you can only think what everyone else is thinking." - 
Haruki Murakami



--
Ben Bonacci
https://benbonacci.com
C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

Quote of the Day: "It does not matter how slowly you go as long as 
you do not stop." - Confucius

Re: Request for relicensing of CMakeLists.txt files in plasma-welcome from GPL to BSD-2-Clause

[Nate Graham]

On 8/13/23 20:08, Aaron Rainbolt wrote> It's called Karton - it's 
intended to be a KDE-centric libvirt frontend
that will eventually be able to replace GNOME-based tools like 
virt-manager and GNOME Boxes. It will be written using Qt Quick and 
Kirigami. Justin made a Matrix room for it at #karton:kde.org. So far we 
have a working VNC widget for Kirigami based on KRDC's code, and a 
minimal (and very rudimentary and not-yet-published) proof-of-concept 
for using this widget to connect to libvirt VMs. Most of our progress is 
at https://invent.kde.org/arraybolt/qml-vnc, which is a simple app that 
wraps the VNC widget and allows it to be tested.


As the CMake code was mostly taken from KRDC (which doesn't have license 
headers in its CMake code and therefore I believe defaults to 
BSD-2-Clause), the GPL code of plasma-welcome's CMake files prohibited 
inclusion of CMake code from there. I wanted to look at it in order to 
see what packages and libraries I needed in order to get 
localization-related features to be available in QML. I could just look 
at the code from some other project for that (and may end up doing so), 
but I thought this was something good to mention anyway.



Sounds like an exciting project!

Re: Request for relicensing of CMakeLists.txt files in plasma-welcome from GPL to BSD-2-Clause

[Nate Graham]

I give my permission.

P.S. what's the project?

Nate



On 8/13/23 18:12, Aaron Rainbolt wrote:

Hello, and thanks for your time.

As per the KDE Licensing Policy at 
https://community.kde.org/Policies/Licensing_Policy, all CMake code in 
KDE must be licensed under BSD-2-Clause. However, several CMake files in 
plasma-welcome are licensed under GPL-2.0-only OR GPL-3.0-only OR 
LicenseRef-KDE-Accepted-GPL. As this interferes with the reuse of CMake 
code elsewhere in KDE and in other projects (in particular, I can't use 
this code in a project I'm working on :P), I would like to request that 
the following files be relicensed under BSD-2-Clause:


plasma-welcome/CMakeLists.txt
plasma-welcome/src/CMakeLists.txt

Thanks for your help!|
|

Do you use votes on Bugzilla tickets to help you make decisions?

[Nate Graham]

Hello folks!

I often find myself explaining to users that votes on Bugzilla tickets 
are generally meaningless and not used by most developers to help 
prioritize work. After I explain this, they generally express surprise, 
as it's not obvious.


I find myself wondering whether it would make sense to disable the 
voting feature by default to avoid giving our users this false impression.


So if you *do* take user votes into consideration when determining what 
tickets to prioritize, I'd like to hear from you!



Nate

Re: Bug Safari Project

[Nate Graham]

Thanks, looks like a great start! Can we get the following changes 
(Justin's bot already does these things):

- Clarify in the announcement text that this is for Plasma only
- Make the text into clickable links so people can find the bugs and go 
fix them

- Fix the "VHI priority bugs" query; that seems wrong and it should be [1]
- Mention the delta from yesterday's numbers in parentheses
- Optional: add emojis to each one for a bit of fun; see Justin's script 
for details


Thanks again for working on this!

Nate



[1] 
https://bugs.kde.org/buglist.cgi?bug_severity=critical_severity=grave_severity=major_severity=crash_severity=normal_severity=minor_severity=task_status=UNCONFIRMED_status=CONFIRMED_status=ASSIGNED_status=REOPENED_name=VHI-priority%20Plasma%20bugs_id=2429682=VHI=Bluedevil=Breeze=Discover=drkonqi=frameworks-kirigami=frameworks-plasma=frameworks-qqc2-desktop-style=kactivitymanagerd=kde-gtk-config=kdeplasma-addons=khelpcenter=kinfocenter=klipper=kmenuedit=krunner=KScreen=kscreenlocker=ksmserver=ksysguard=KSystemLog=kwin=Plasma%20SDK=Plasma%20Vault=Plasma%20Workspace%20Wallpapers=plasma-integration=plasma-nm=plasma-pa=plasma-simplemenu=plasmashell=policykit-kde-agent-1=Powerdevil=print-manager=printer-applet=pulseaudio-qt=systemsettings=Touchpad-KCM=user-manager=xdg-desktop-portal-kde_based_on=VHI-priority%20Plasma%20bugs_format=advanced




On 7/24/23 05:00, Ben Bonacci wrote:

Hi Nate,

I've recorded the script in action which can be accessed with this link: 
https://benbonacci.com/files/shares/1w-bug-safari-demo.mp4 (Expires in 1 
week)


Regards,

Ben

On 23/7/23 23:43, Nate Graham wrote:

Very cool stuff. Can we see it in action anywhere?

Nate


On 7/23/23 01:38, Ben Bonacci wrote:

Hi Ben,

Thanks for the suggestion! Now after each request the script will 
wait 1-5 seconds before making the next request.


Regards,

Ben

On 22/7/23 22:30, Ben Cooksley wrote:
On Sun, Jul 23, 2023 at 12:18 AM Ben Bonacci  
wrote:


    Hi everyone!


Hi Ben,


    For the past few days I've been working on Bug Safari, which is a
    Python
    script that gets statistics for Plasma bugs and sends a report 
to the

    #plasma room on Matrix, which is one of the dot points for KDE's
    Automation goal.

    I've now got the script uploaded to Invent at
https://invent.kde.org/bbonacci/bug-safari for anyone to look
    over, make
    improvements or implement.


Thanks for this, I have just had a quick look over the code and it 
overall looks pretty reasonable, and also follows best practice of 
setting it's own user agent.


One small suggestion would be to add some small sleeps in to ensure 
that the server endpoints don't get hammered by your requests.
While the script by itself is fairly innocent, if similar scripts 
were added for a series of other channels and they all ran at the 
same time, this could result in a rush on the server that could make 
it inaccessible to normal users (or at the very least impact 
responsiveness).


Adding some sleeps (ideally for a random number of seconds as people 
tend to pick the same cron times to run stuff on) will ensure this 
doesn't become an issue.



    Regards,

    Ben


Cheers,
Ben


    --     Ben Bonacci
https://benbonacci.com
    C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

    Quote of the Day: "What's the good of living if you don't try a
    few things?" - Charles M. Schulz


--
Ben Bonacci
https://benbonacci.com
C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

Quote of the Day: "If you only read the books that everyone else is 
reading, you can only think what everyone else is thinking." - Haruki 
Murakami



--
Ben Bonacci
https://benbonacci.com
C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

Quote of the Day: "It does not matter how slowly you go as long as you do not 
stop." - Confucius

Re: Bug Safari Project

[Nate Graham]

Very cool stuff. Can we see it in action anywhere?

Nate


On 7/23/23 01:38, Ben Bonacci wrote:

Hi Ben,

Thanks for the suggestion! Now after each request the script will wait 
1-5 seconds before making the next request.


Regards,

Ben

On 22/7/23 22:30, Ben Cooksley wrote:

On Sun, Jul 23, 2023 at 12:18 AM Ben Bonacci  wrote:

Hi everyone!


Hi Ben,


For the past few days I've been working on Bug Safari, which is a
Python
script that gets statistics for Plasma bugs and sends a report to the
#plasma room on Matrix, which is one of the dot points for KDE's
Automation goal.

I've now got the script uploaded to Invent at
https://invent.kde.org/bbonacci/bug-safari for anyone to look
over, make
improvements or implement.


Thanks for this, I have just had a quick look over the code and it 
overall looks pretty reasonable, and also follows best practice of 
setting it's own user agent.


One small suggestion would be to add some small sleeps in to ensure 
that the server endpoints don't get hammered by your requests.
While the script by itself is fairly innocent, if similar scripts were 
added for a series of other channels and they all ran at the same 
time, this could result in a rush on the server that could make it 
inaccessible to normal users (or at the very least impact responsiveness).


Adding some sleeps (ideally for a random number of seconds as people 
tend to pick the same cron times to run stuff on) will ensure this 
doesn't become an issue.



Regards,

Ben


Cheers,
Ben


-- 
Ben Bonacci

https://benbonacci.com
C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

Quote of the Day: "What's the good of living if you don't try a
few things?" - Charles M. Schulz


--
Ben Bonacci
https://benbonacci.com
C0A9 E67F 8CDC B1A1 0860 1807 E018 065C C7DF 3976

Quote of the Day: "If you only read the books that everyone else is reading, you can 
only think what everyone else is thinking." - Haruki Murakami

Re: KSvg in kdereview

[Nate Graham]

FWIW the code itself is almost entirely just moved verbatim from 
plasma-framework, which is already a framework.


Nate


On 6/21/23 12:41, Friedrich W. H. Kossebau wrote:

Am Mittwoch, 21. Juni 2023, 12:23:55 CEST schrieb Ben Cooksley:

On Wed, Jun 21, 2023 at 10:12 PM Harald Sitter  wrote:

LGTM now +2

On Wed, Jun 21, 2023 at 10:04 AM Marco Martin  wrote:

I fixed CI, passes now


Thanks for correcting that.

As Friedrich raised the initial concerns it would be nice to have him
confirm that the code quality issues he found have all been corrected.


Fear I had just superficially looked at things, given I am currently not a
stakeholder in this library, no API consumer or contributor. The cmake issues
I saw at the time I had fixed directly, anything C++ etc. I had not really
looked at, just saw the TODOs and skipped ;) So cannot compare and would have
no time reserved here to take a closer look now, others have I assume :)
The other thing that stood out was the outdated docs, but that seems to have
been fixed/improved on a quick glance +1

The other comment was about the name, but naming, the joy :) ... and people
using it/working on it seem fine with the current one, so...

Cheers
Friedrich

Re: sentry evaluation

[Nate Graham]

To be honest, I haven't found Sentry to be that useful in its current 
implementation. The primary issue is that it represents a second source 
of truth for where crash reports live. As a result, developers who 
already struggle to notice Bugzilla-based crash reports have to look in 
a second place, further diving their scarce attention. I haven't seen 
evidence of people regularly interacting with it or looking at its 
crashes beyond the excitement of the initial rollout, so now it's 
largely just a new graveyard of issues being ignored due to insufficient 
developer time.


I think Sentry could make sense to keep if it was implemented for us 
more as a kind of automatic symbolication service that can take a bad 
backtrace, add debug symbols, retrace it, and then pass *that* off to 
DrKonqi so that the resulting Bugzilla ticket is guaranteed to have a 
*good* backtrace in it. That's a real problem we currently have that 
could benefit from being solved in a targeted way.


If we can't or don't want to do that, then Sentry might make sense if it 
were possible for us to bypass the "multiple sources of crash truth" 
issue by completely disabling Bugzilla for crash reports and migrating 
old Bugzilla crashes into sentry. But Then we'd run into the new issue 
that Sentry doesn't permit discussion with the person experiencing the 
crash to ask for more details if needed. This isn't always needed, but 
it sometimes is. Sentry also isn't integrated into our issue priority 
tracking system in Bugzilla, but that's a more minor issue.


Nate



On 6/1/23 04:35, Harald Sitter wrote:

Hey,

We've had almost a year, albeit in a super limited capacity for git
builds, with sentry (https://errors-eval.kde.org) and we should
probably render a final verdict on the evaluation.

Did you like it?
What could be improved?
Should we move ahead with a more permanent setup?

The overall game plan would be to have drkonqi ask the user to opt
into automatic crash submission when they open drkonqi so we get close
to all crashes (the ones caught by kcrash) automatically filed into
sentry from then on out. To increase exposure of this feature I'd also
like to glue it into the feedback KCM but I'm not yet sure if it
should be a separate setting or linked to the regular feedback
categories, the former sounds more accessible. The current bugzilla
based workflow would still be available for when the user actually
wants to write a description.

(previous discussion: https://markmail.org/thread/6y5paczdposz3aoj)

HS

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Nate Graham]

On 5/23/23 03:48, Ben Cooksley wrote:> Also, in Phabricator, Tasks 
have no real "home"; they just have project

tags, and they can have multiple such tags to be able to belong to
multiple projects. For example "VDG" and also "Plasma". Such a Task
shows up in both projects' workboards. But in GitLab, Issues need to
live in one place and only one place. So for such Phab tasks, we would
need a way to determine the single new home of the Task in GitLab, and
perhaps tag them with global-scope labels or something?


Yes, we would need to do a deconflicting process there.
Any thoughts on the best approach to that?


At least in the case where a Task is tagged with VDG and also something 
else, it probably makes sense to have it live on GitLab in the 
"something else" project/group/etc. Back in the Phab days, we used to 
tag everything VDG-relevant with the VDG tag, but on Gitlab it probably 
makes more sense to just CC the "@teams/vdg" group instead.


Nate

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Nate Graham]

Great, this will be a good thing to have behind us.

Because workboards in GitLab are Label-driven via automation, I think we 
would have to make each workboard column in Phabricator transform into a 
custom label in GitLab so that Tasks' positions in workboards can be 
preserved when they move to GitLab.


Also, in Phabricator, Tasks have no real "home"; they just have project 
tags, and they can have multiple such tags to be able to belong to 
multiple projects. For example "VDG" and also "Plasma". Such a Task 
shows up in both projects' workboards. But in GitLab, Issues need to 
live in one place and only one place. So for such Phab tasks, we would 
need a way to determine the single new home of the Task in GitLab, and 
perhaps tag them with global-scope labels or something?


In Gitlab, it's Labels all the way down...

Nate


On 5/21/23 03:14, Ben Cooksley wrote:

Hi all,

As many of you will undoubtedly be aware, we currently have a bit of a 
hybrid approach with our use of GitLab, with some projects/areas still 
making use of Phabricator as they await the final import of these tasks 
across to GitLab.


That time has now arrived, as Phabricator is long since unmaintained and 
needs to be retired.


The only question is how this is best structured.

My thinking on this had been to establish a mapping of Phabricator 
project to Gitlab project (with some Gitlab projects possibly receiving 
multiple Phabricator projects). Where necessary we would create 
groups/projects under teams/ on invent.kde.org  
to house these, otherwise they'd be imported into the mainline projects.


For those projects currently using GitLab as a task tracking tool, any 
feedback you have on this would also be welcome.


In terms of the migration, we'd be looking to retain as much information 
as possible, however things like the precise column a task has on a 
workboard would likely be lost. The actual content of the task including 
details such as time and authorship, along with any comments would be 
retained though.


Thoughts?

Thanks,
Ben

KDE scanning apps (From: Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure) )

[Nate Graham]

On 5/8/23 10:12, Martin Steigerwald wrote:

As for your ideas for Skanpage: I like them! At the moment I find myself
using either Skanpage or Skanlite depending on use case. I'd love to
have it all in one app, but that may not be feasible.


Unrelated to the original subject of this email, but Skanpage just 
gained the ability to preview scans and select multiple areas of a 
preview, just like Skanlite has. So you may in fact be able to use 
Skanpage for everything! I've fully migrated myself at this point.


Nate

Re: developer account set up

[Nate Graham]

There's also no reason anymore why they need to use a work branch in the 
main repo; a fork works just fine. I do nearly all of my development 
using personal forks; it's a 100% supported first-class citizen experience.


Nate

On 5/7/23 17:06, Joshua Goins wrote:

We usually recommend contributors to create branches in the main repository
(work/gsoc/...). Is it possible without a developer account?

Johnny


It doesn't have to be the GSoc student that creates the branches, only that
they are the ones putting commits in it. Something I've seen done is the
mentor creates the work branch (work/gsoc/student) and the student creates MRs
to merge their work into the branch instead of targetting master.

Re: developer account set up

[Nate Graham]

-Utarsh

It might be worth re-thinking this policy now that we use GitLab. People 
don't need a developer account to fully contribute anymore.


Nate


On 5/7/23 09:41, Johnny Jazeix wrote:



Le sam. 6 mai 2023 à 23:31, Nate Graham <mailto:n...@kde.org>> a écrit :


Hello Utkarsh,

You don't need a developer *account* to start contributing, and in fact
you can't have one until you've made a number of contributions
already. :)

If you're looking for information about starting the process of
contributing with code, we have a bunch of documentation at
https://community.kde.org/Get_Involved/development
<https://community.kde.org/Get_Involved/development>.


Best of luck!

Nate


On 5/6/23 20:42, Utkarsh Kumar wrote:
 > Hlw, I am Utkarsh Kumar and I want to need help creating a developer
 > account setup. so please can someone suggest to me the steps I
need to
 > follow to create a developer account?


Hi Nate,
Utkarsh has been selected for GSoC to work on digiKam and it's a 
prerequisite to create a developer account do in the community bonding 
period.

Cheers,

Johnny

Re: developer account set up

[Nate Graham]

Hello Utkarsh,

You don't need a developer *account* to start contributing, and in fact 
you can't have one until you've made a number of contributions already. :)


If you're looking for information about starting the process of 
contributing with code, we have a bunch of documentation at 
https://community.kde.org/Get_Involved/development.



Best of luck!

Nate


On 5/6/23 20:42, Utkarsh Kumar wrote:
Hlw, I am Utkarsh Kumar and I want to need help creating a developer 
account setup. so please can someone suggest to me the steps I need to 
follow to create a developer account?

Re: Ask about new KDE functionnalities.

[Nate Graham]

On 4/28/23 04:14, Nicolas Lécureuil wrote:

Hello,

i don't know if i post on the good ML but i have a friend searching for 
developpers to mostly integrate ChatGPT into KDE. He accepts to 
contribute financially.


"
     I don't know if it's possible, but for example, I would like to 
allow the generation and saving of configuration files from the UI.
     integrate "a chatGPT" to enable script generation within the 
graphical environment and thus execute these scripts: for example, read 
the headers of a message and its attachments and suggest saving the 
email "in a hard copy" (.eml) to the hard drive with the attachments, 
with the help of voice and multiple choice help bubbles.


Not sure now ChatGPT could help with either of these ideas, and it's 
already possible for someone to develop such features without ChatGPT.


Can you help explain what ChatGPT would be bringing to the table here?

Nate

Re: Proposal to deprecate KFloppy

[Nate Graham]

Does it work for *anyone* with a modern distro? If not, then I think 
archiving it makes sense. Time marches on. :)


If it does work for *someone* with a modern distro then at the very 
least the UI needs to detect when it will be broken and tell this to the 
user in advance to prevent frustration.


Nate


On 4/28/23 06:49, Jonathan Riddell wrote:
KFloppy is an old tool to format your floppy diskettes.  We packaged 
KFloppy for the Snap store but it doesn't work, neither does it work for 
the apt packages.  The code depends on features of Linux that do not 
seem to exist any more, expecting /dev/fd0 and other nodes in /dev.  It 
also depends on having tools like fdformat around which are not packages 
for Ubuntu any more.  I tested it with an external USB floppy drive.  
The most recent maintainer seems to be Wolfgang Bauer.  Can we agree to 
archive it and stop releases?


Jonathan

Re: About automatic day/night theme changing feature.

[Nate Graham]

Hello Hakan,

You can CC yourself on https://bugs.kde.org/show_bug.cgi?id=408563 to be 
notified once the feature is implemented implemented. Work has begun 
already; see 
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2567. 
Plasma 6.0 is the release targeted for it.


Nate


On 3/20/23 06:06, Hakan Bayındır wrote:
Sent this mail to KDE mailing list last week[6], but got no replies, so 
re-sending here. Sorry for the noise.


Hello all,

I have been reading an issue in Koi (a tool which enables light/dark 
theme transitions based on sunrise/sunset)'s issue tracker[0].


The tracker claimed that a similar feature is already in development[1], 
and Koi will sunset when the feature ships.


I have looked to relevant phabricator panels [2][3], yet failed to find 
the feature, or its telltale signs of development. If I understood 
correctly, KDE 5.x series won't have any new features and has officially 
entered LTS state [4].


Is such feature in development, if yes, where can I track the progress, 
if not, where should I file a bug? KDE Bugtracker [5]?


Thanks in advance for all the help,

Cheers,

H.

[0]: https://github.com/baduhai/Koi/issues/67
[1]: https://github.com/baduhai/Koi/issues/67#issuecomment-1436076294
[2]: https://phabricator.kde.org/project/board/310/
[3]: https://phabricator.kde.org/project/view/316/
[4]: 
https://community.kde.org/Schedules/Plasma_5#Support_status_by_Release_Series

[5]: https://bugs.kde.org/
[6]: https://mail.kde.org/pipermail/kde/2023-March/029863.html

Re: Update | BE4FOSS project coming to an end, KDE Eco continues to grow

[Nate Graham]

Thank you so much for your work to organize and push forward this 
initiative, Joseph! It's great to see how the ethos of energy efficiency 
has taken root in the community.


Nate



On 3/22/23 09:54, Joseph P. De Veaugh-Geiss wrote:

Dear KDE community,

I am sad to inform you that next week on 31 March funding for the KDE 
Eco "Blauer Engel 4 FOSS" (BE4FOSS) project will end. This means my role 
as Community and Project Manager for the project will also end.


This does not mean that the KDE Eco project is ending, not at all, but 
we may feel a shift in gears as the community transitions into the next 
phase. I will continue to be involved with the eco projects going 
forward, though at a reduced capacity as I take on a new role at KDE and 
thus new responsibilities (more info about this will be sent in the 
coming weeks).


KDE Eco continues to grow. Beyond "Blauer Engel 4 FOSS", there are many 
ongoing sustainability and efficiency projects at KDE, including the 
Sustainable Software goal, and more are coming. See the end of this 
email for some information and links.


These projects need your enthusiasm and energy (!) to stay alive and 
healthy. If you have thought to yourself, "I would like to contribute to 
the exciting work of the KDE Eco initiative", now is a great time to get 
involved. Please be in touch with me directly or the larger KDE Eco 
community via the mailing list and Matrix room:


   https://eco.kde.org/get-involved/

Or check out the Sustainable Software goal workboard:

   https://invent.kde.org/teams/eco/sustainable-software-goal/-/boards

Your involvement, no matter how big or small, is what makes success 
possible. And if you are already contributing to the KDE Eco initiative, 
thank you for your great work. I look forward to continuing what we have 
started!


We are in the process of applying for further external funding for KDE 
Eco projects, and I hope we can announce new funding in the very near 
future.


It has been truly a pleasure to work with the KDE community in the 
BE4FOSS project. I look forward to what comes next in making KDE and 
Free & Open Source Software the most sustainable and energy-efficient 
software.


In many ways, this pioneering work has only just begun!

Cheers,
Joseph

Here are just some of the ongoing KDE Eco projects:

  - The many objectives of the Sustainable Software goal, which you can 
read more about here:


     https://community.kde.org/Goals/Sustainable_Software

  - The three Season of KDE 2023 projects for scripting usage scenarios 
to measure the energy consumption of KDE apps. Read progress updates 
(with links to blog posts) for the excellent mentees Mohamed Ibrahim 
(KDE Eco Tester project), Nitin Tejuja (Selenium project), and Rudraksh 
Karpe (Blue Angel Preparation project) here:


    https://community.kde.org/SoK/2023/StatusReport

  - The energy measurement lab at KDAB Berlin as well as the Google 
Summer of Code proposal building an online portal for remote access to 
the lab (and possible CI-integration):



https://community.kde.org/GSoC/2023/Ideas#Project:_Measuring_Energy_Usage_Remotely_with_Online_Portal

Re: Proposal for using gitlab for kdereview process

[Nate Graham]

Overall I think it makes sense. The key players are all already on 
GitLab and it's where we do code review for established projects.


Nate


On 2/22/23 00:59, David Redondo wrote:

Am Samstag, 18. Februar 2023, 12:02:38 CET schrieben Sie:


I'm not convinced more paper work is going to help us increase the number of
participants in the review process (which is imho the big issue),


Hi Albert, I don't think it's will be paperwork, usually the mentioned
checklist was the first thing Harald links to people and is already mentioned
on the kdereview wiki page as things people will look at.


but if you're willing to document all this properly I'm happy to give it a

try and  be proven wrong :)


I will try to write something then for the wiki if noone objects.

David

Re: Question about the source code

[Nate Graham]

That's a harder question as the behaviors are a mix of KDE code and Qt 
code. I'd suggest starting in the KDE code and tracing it down the stack.


Nate


On 2/11/23 08:34, rubisetcie wrote:

Hello Nate, thank you very much for your response!

As far as I have looked at the Qt source code, there seem to be an 
obscure flag in /QPlatformTheme/ called "/ContextMenuOnMouseRelease/", 
which I believe is about this behavior.

If so, it may be easier to change it than I thought...

I would like to ask one last question: would you tell me -at the current 
state of stable Plasma- which of the following behaviors are actually 
implemented in *KDE* and which are in the *Qt* frameworks?


  * The desktop / Dolphin selection rectangle when holding left click,
to select files, etc.
  * The drag and drop of files on the desktop / Dolphin.

Thank you again for your time, I wish you a good continuation for your 
amazing work.


Regards,
Matthieu 'Rubisetcie' Carteron

Le ven. 10 févr. 2023 à 21:27, Nate Graham <mailto:n...@kde.org>> a écrit :


Hello Matthieu,

This behavior comes from Qt, not any KDE code. You might try looking at
the source code for QMenu.

Good luck!

Nate


On 2/10/23 06:00, rubisetcie wrote:
 > Hello KDE core developer team, I hope you're having a good day.
 >
 > I have a question about the KDE source code : I would like to
edit the
 > global *context menu behavior*, to make it appears when you
*release*
 > the right mouse button instead of pressing it.
 >
 > This is a tweak I'm trying to make to the whole desktop
environment, in
 > order to make me more comfortable using it (as far as I know,
 > recompiling a modified source code is the only way to accomplish
this)...
 >
 > Would you kindly help me figuring out /where exactly this context
menu
 > behavior is handled in the source code/?
 >
 > Thank you in advance, I wish you a good continuation for your work.
 >
 > Regards,
 > Matthieu 'Rubisetcie' Carteron

Re: Question about the source code

[Nate Graham]

Hello Matthieu,

This behavior comes from Qt, not any KDE code. You might try looking at 
the source code for QMenu.


Good luck!

Nate


On 2/10/23 06:00, rubisetcie wrote:

Hello KDE core developer team, I hope you're having a good day.

I have a question about the KDE source code : I would like to edit the 
global *context menu behavior*, to make it appears when you *release* 
the right mouse button instead of pressing it.


This is a tweak I'm trying to make to the whole desktop environment, in 
order to make me more comfortable using it (as far as I know, 
recompiling a modified source code is the only way to accomplish this)...


Would you kindly help me figuring out /where exactly this context menu 
behavior is handled in the source code/?


Thank you in advance, I wish you a good continuation for your work.

Regards,
Matthieu 'Rubisetcie' Carteron

Re: New repo in kdereview: kclock

[Nate Graham]

I'm happy with KClock now, FWIW. I'm going to start sending merge 
requests for some of the little tiny UI things I notice that I don't 
think are worth prolonging KDEReview over.


Nate


On 2/2/23 21:11, Devin wrote:

Hi everyone,

Is there any feedback left for KClock? If not, I will consider it to
have passed kdereview.

Thanks,
Devin

On Fri, Dec 30, 2022 at 2:27 AM Justin  wrote:


Thanks for the quick reply Albert. I'm not a developer but I've gone
over much of the comments from previous:

Tested on 22.11

  > New Timer doesn't work? Ah it's because it needs kclockd running for
that, would it be very hard to give a warning if it isn't running?

Seems kclockd is now running automatically. If it is not automatically
running that would (in my opinion) be a packaging issue on the distro side.

  > Is that kirigamiaddons thing released? Seems to be the reason i can't
add new Alarms

Kirigami Addons has now passed KDE review and has stable releases

  > Not an expert in UI but for stopwatch having Start/Pause on the top
left feels a bit unnatural, maybe would make sense swapping reset and
Start? Ask the VDG i guess.

In the version I'm running it's centered nicely and I think works well.
If you can check this against latest git master to confirm the UI is
still the same.

  > Also in stopwatch for me it'd make a lot of sense if pressing the
time starts/pauses, what do you think?

This is functioning now.

  > Silence Alarm After shows an horizontal scrollbar that doesn't to be
very useful https://i.imgur.com/7O8DBJc.png

This is now called Ring Duration and has no horizontal scroll bar even
at the minimum window width.

  > It's even worse in Alarm Snooze Length where it goes over existing text

Same as above, now fixed.

  > You're missing Messages.sh in kclockd

I see this now in the kclockd folder

  > Please check i18n in your qml files, these seem like need i18n
  > ...

Lots of this i18n stuff appears to have been moved and will need a new
review


Justin

On 30/12/22 20:44, Albert Astals Cid wrote:

El divendres, 30 de desembre de 2022, a les 8:46:56 (CET), Justin va escriure:

Hey Team,

This was last posted about on October 18 2021. I looked at the three
items that were needed for kirigami-addons:

* Missing is REUSE compliance:
https://invent.kde.org/libraries/kirigami-addons/-/merge_requests/13
* Hanyoung is working on a better time picker:
https://invent.kde.org/libraries/kirigami-addons/-/merge_requests/17
* And Clau is working on a better date picker:
https://invent.kde.org/libraries/kirigami-addons/-/merge_requests/20

They have all now been merged. Can we resume the review on
kirigami-addons so we can continue on kclock?

Thanks everyone and have a enjoyable and safe holiday!

I gave a long list of comments back in the day that were never answered, do
that first and maybe i give it another look.

Cheers,
Albert


Justin

Re: "Gardening" old bugreports

[Nate Graham]

We can turn it off for bugs reported by you, but I'm not sure "I'm 
getting too many emails" is a good reason to turn it off for whole 
products. These products aren't owned by you; they're community property 
and it's important for them to get triaged for the benefit of everyone. 
Nobody wins when Bugzilla fails to reflect an accurate state of reality.


If those products are being actively triaged by you or someone else, 
that's a good reason. But if they're not, and stale bug reports and 
merge requests are piling up, that's a problem that needs to be fixed, 
and ignoring emails or preventing the Gardening team from doing part of 
their job isn't going to fix it.


Nate


On 1/29/23 02:23, Carl Schwan wrote:

Please exclude from the bug report reminder:

koko
tokodon
kalendar
kde.org
planet.kde.org
www.kde.org
season.kde.org
KDE Mediawiki
and any bug reported by myself

as well as the following projects for the MR reminder:

koko
tokodon
kalendar
arianna
vail
arkade
basically everything in the websites namespace
and any MR created by myself

I'm getting already way too many emails and I have an hard time keeping up
with them so if I can avoid getting more of them, that would be good.

Cheers,
Carl

--- Original Message ---
Le vendredi 27 janvier 2023 à 10:56 PM, Justin Zobel  a 
écrit :



Thanks for the feedback, everyone.

Given the distribution of positive vs negative feedback, we plan to
resume automatic bug triage of old non-wishlist bugs that have not
been updated in over 2 years. If you would like to opt your product
out of this initiative because you're able to keep on top of the
manual bug triage work, please let us know and we'll be happy to
accommodate you.

Exclusions so far:
- okteta
- krita
- any bug reported by sit...@kde.org

Thanks again for the feedback!

On Sun, Jan 22, 2023 at 6:10 PM Thomas Baumgart t...@net-bembel.de wrote:


On Donnerstag, 19. Januar 2023 22:39:45 CET Johannes Zarl-Zierl wrote:


Hi,

Am Donnerstag, 19. Jänner 2023, 12:26:08 CET schrieb Nicolas Fella:


Am 19.01.23 um 04:04 schrieb Justin:


The gardening team aims to find out if the bug reports are still
relevant by involving the users who reported them in determining if
they are still valid. This increases community involvement and helps
KDE as there isn't anywhere near enough manpower to review the
thousands upon thousands of bugs that haven't been touched in years.


Anecdotally many people don't like such automated changes being done to
their bugreports that don't actually engage with the content of the report.


Well, anecdotally you will mostly get feedback from people who don't like it.
Unless something is exceptionally great, few people will take the time to
speak out in favor of something that is already happening.


The bugs that we are interacting with are ones that have not had any
activity for over 2 years. We are simply trying to reinvigorate
discussion on those bugs to see if they are still valid. If the user
does not reply within the standard 30 day period after a bug is set to
NEEDSINFO, it is automatically closed by the Bug Janitor.

I am not simply closing bugs, so I do take offense that care is not
applied.


Properly "triaging" old reports requires at least some level of
understanding of the project, codebase etc. I'm afraid there is no
simple solution to that and rule-based approaches aren't good enough.
Even taking things like CONFIRMED status or wishlist priority into
account assumes that these have actually been consistently applied.


As a maintainer on a small project, I'm quite happy to get an occasional nudge
on old reports. Yes, I do occasionally go over old reports to see if they are
still valid, but having somebody else doing this methodically makes sure I
don't gloss over some bug that could be closed or fixed.

Having this done by someone else without too much internal knowledge is an
absolute plus in my opinion. After all, if you want to clean up your attic,
you try to find a helper who does not have the same emotional attachment as
yourself.


I will halt it until it is approved by more developers. However if it
is decided that it isn't wanted then the KDE as a whole will need to
entice more people in sorting old bugs individually as it is clearly
not a priority right now for the majority.


Speaking for KPhotoAlbum, I really appreciate the bugzilla gardening. Thank
you for doing it!


I can second that for the KMyMoney project. An occasional poke and the
automated cleanup when no response arrives where it is needed helps a lot.

--

Regards

Thomas Baumgart

-
With every day I come closer to the grave and learn something new.
It all happens because I have wandered around too much and stumbled into
the Linux world - which is a fantastic place to be! (Algis Kabaila †)
-

Re: VDG application design sprint?

[Nate Graham]

On 1/24/23 09:42, Vinzenz Vietzke wrote:> Hey there,


Just to have it said: if you want to make it a in person sprint we 
(TUXEDO) can offer rooms, network, food etc. at our office in Augsburg.


Cheers,
vinz.



That is super generous, thanks so much for the offer, Vinzenz!

Nate

Re: VDG application design sprint?

[Nate Graham]

Very interested!

Ever since the GNOME folks created Libadwaita, I feel like their 
3rd-party app ecosystem has really taken off, and it seems like 
something they put a lot of planning and foresight into making happen. 
In KDE land we have a lot of 1st-party apps but not as much on the 
3rd-party side, and I'd like for us to have an equally compelling story 
there. I think the design, HIG, and UX perspectives--both user and 
developer--are key to making this happen, and a VDG sprint would be the 
perfect place to discuss those topics.


Nate



On 1/23/23 16:43, Nicolas Fella wrote:

Hi,

I think it would make sense for us to have a VDG sprint of sorts in the
near-ish future. This would allow to discuss some larger design topics
and set a vision for the longer-term future. I believe this is important
for us to be able to work together effectively.

I'd suggest to focus on application design topics, like layout,
structure, and arrangement of apps, and less on things like Plasma and
styles/themes. I'd also suggest to approach this more from a design/UX
PoV and don't let us be driven by implementation details. But these are
just my suggestions that are subject to debate.

Time/place/modality is all to be discussed, I'm mainly writing this to
gauge interest, so if you are interested let me know.

Cheers

Nicolas

Re: "Gardening" old bugreports

[Nate Graham]

Hello folks,

I did approve this initiative and I do think there's value to it, but of 
course we can definitely have this discussion in the open and tweak its 
parameters, or end it if we think it's destroying more value than it's 
creating.


I totally agree with Nicolas that in an ideal world, all bug triaging 
would be done on a bug-by-bug-basis, and this is what I personally do 
with products I'm familiar with and have some technical knowledge about. 
But I also can't blame anyone else who doesn't do this, because manual 
bug triaging is a tedious, laborious, time-consuming, energy-draining 
task. It's hard enough for new bugs, and for old bugs which were 
poorly-handled in the past, lack key information, or are full of angry 
users, it can be even more unpleasant.


In my experience mentoring volunteer bug triagers over the past 5 years, 
few stick around for manual bug triage longer than about 3 months. It's 
not fun and it feels like work. It's hard enough even to get maintainers 
to do it consistently, for the same completely justifiable reasons. I 
have tremendous respect for those who grit their teeth and do it anyway.


But it's currently not enough to handle the volume of bug reports we get 
daily, or reduce the backlog of old un-handled bugs. This causes 
Bugzilla's signal-to-noise ratio to worsen over time. The automatic bug 
triage initiative emerged to try to address that. If our consensus ends 
up being to terminate it, I'd like it to be because more folks are 
stepping up to make manual bug triage a part of their daily routine--and 
not just for new bugs, but for old ones too. And on a consistent basis, 
not just once or twice. The more human labor we get consistently working 
on the problem, the less drive there will be for machines to do it.


Here's our documentation on how to do it: 
https://community.kde.org/index.php?title=Guidelines_and_HOWTOs/Bug_triaging


If that doesn't happen, I think we need to consider other options for 
bug management, such as doing it automatically or hiring more people to 
do it manually.


Let me know your thoughts!


Nate

Re: Unknown protocol "konq"

[Nate Graham]

On 12/27/22 11:26, Reindl Harald wrote:
but given i use konqueror only as filemanager because dolphin with the 
lack of bookmarks is a joke


Dolphin has bookmarks, FWIW: https://i.imgur.com/ylXHTBf.jpg

Nate

Re: New repo in kdereview: KRecorder

[Nate Graham]

Thanks for all the hard work, Devin. Looks great now! +1 from me.

Nate




On 12/7/22 22:21, Devin wrote:

Here are my audio settings: https://i.imgur.com/8YqR82x.jpg


I've adjusted the settings for vorbis visualization which *should* be
better now. I think the way the visualization is calculated probably
needs to be more sophisticated eventually to be smoother.


I think I found the problem; I use 11pt Noto Sans font. I can't reproduce the 
issue with the default 10pt. This probably points to some width value somewhere 
being a hardcoded number rather than a multiple of Kirigami.Units.GridUnit, 
which hopefully should be easy to fix.


I've changed it to be based on gridUnit.

On Mon, Dec 5, 2022 at 4:55 PM Nate Graham  wrote:


On 12/4/22 16:47, Devin wrote:

I can reproduce it in the following way on Desktop:


Hmm, I'm on Kirigami from master and still can't reproduce it, see the
attached video.


I think I found the problem; I use 11pt Noto Sans font. I can't
reproduce the issue with the default 10pt. This probably points to some
width value somewhere being a hardcoded number rather than a multiple of
Kirigami.Units.GridUnit, which hopefully should be easy to fix.

For example:

src/contents/ui/main.qml:25:width: Kirigami.Settings.isMobile ? 400
: 800
src/contents/ui/main.qml:28:property bool isWidescreen:
(appwindow.width >= 700) && appwindow.wideScreen // prevent being
widescreen at first launch




I found one new issue that wasn't present the last time I tested: while 
recording, the volume level indicator always indicates that it's recording at 
max volume, even when I'm just, like, whispering:


This is a hard issue to solve because different combinations of
formats and containers produce varying audio levels, so I can't figure
out a way to produce them properly. Perhaps once Qt 6 comes around I
can look at the issue again since the formats will be reworked but
perhaps what I can do is hardcode them for preset formats (currently
all audio formats have the maximum hardcoded to 1000, which gets
higher if the audio level exceeds that)


Here are my audio settings: https://i.imgur.com/8YqR82x.jpg

Like I said, this just started happening between the last time I
reviewed the app and the time before that. I didn't change any audio
settings between those times.


Nate

Re: New repo in kdereview: KRecorder

[Nate Graham]

On 12/4/22 16:47, Devin wrote:

I can reproduce it in the following way on Desktop:


Hmm, I'm on Kirigami from master and still can't reproduce it, see the
attached video.


I think I found the problem; I use 11pt Noto Sans font. I can't 
reproduce the issue with the default 10pt. This probably points to some 
width value somewhere being a hardcoded number rather than a multiple of 
Kirigami.Units.GridUnit, which hopefully should be easy to fix.


For example:

src/contents/ui/main.qml:25:width: Kirigami.Settings.isMobile ? 400 
: 800
src/contents/ui/main.qml:28:property bool isWidescreen: 
(appwindow.width >= 700) && appwindow.wideScreen // prevent being 
widescreen at first launch





I found one new issue that wasn't present the last time I tested: while 
recording, the volume level indicator always indicates that it's recording at 
max volume, even when I'm just, like, whispering:


This is a hard issue to solve because different combinations of
formats and containers produce varying audio levels, so I can't figure
out a way to produce them properly. Perhaps once Qt 6 comes around I
can look at the issue again since the formats will be reworked but
perhaps what I can do is hardcode them for preset formats (currently
all audio formats have the maximum hardcoded to 1000, which gets
higher if the audio level exceeds that)


Here are my audio settings: https://i.imgur.com/8YqR82x.jpg

Like I said, this just started happening between the last time I 
reviewed the app and the time before that. I didn't change any audio 
settings between those times.



Nate

Re: New repo in kdereview: KWeather

[Nate Graham]

This happens on X11 when using QtDialogs for reasons I don't understand. 
See 
https://invent.kde.org/frameworks/knewstuff/-/commit/ea19fa6e824650f3257e8047d6f90e01899b2e03.


Nate


On 11/29/22 16:48, Devin wrote:

Hmm, I have no idea why the behaviour is different for you, but I get:
https://i.imgur.com/CvGD8HS.png

If you removed the "Qt.Dialog" flag here:
https://invent.kde.org/plasma-mobile/kweather/-/blob/master/src/qml/settings/SettingsWindow.qml#L14,
does it still have the issue?

Thanks,
Devin

On Tue, Nov 29, 2022 at 6:44 PM Albert Astals Cid  wrote:


El dimecres, 30 de novembre de 2022, a les 0:33:39 (CET), Devin va escriure:

Ok, now that i updated kirigami-addons, the Settings dialog shows, but
it's uncloseable, any idea why that would be?

That's very strange, it should be showing up as a regular window, does
pressing the close button on the window decoration not work?


Which close button?

https://i.imgur.com/2jX2yUS.png

Cheers,
   Albert



Thanks,
Devin

On Tue, Nov 29, 2022 at 6:23 PM Albert Astals Cid  wrote:

El dilluns, 28 de novembre de 2022, a les 17:15:57 (CET), Albert Astals
Cid va>
escriure:

El divendres, 25 de novembre de 2022, a les 4:46:40 (CET), Devin va


escriure:

There's potentially overlapping text.


I have fixed text wrapping in the weather delegates so it should wrap
properly now.


Here settingsModel.forecastStyle is not i18n'ed


I have fixed it now (it converts to i18n'd dedicated strings in the
QML)


FWIW i can't open settings anymore

qrc:/qml/settings/SettingsWindow.qml:56:13: Type SettingsComponent
unavailable qrc:/qml/settings/SettingsComponent.qml:61:17: Cannot assign
to
non-existent property "onActivated" qrc:/qml/main.qml:136: TypeError:
Cannot call method 'close' of null


Ok, now that i updated kirigami-addons, the Settings dialog shows, but
it's
uncloseable, any idea why that would be?

Cheers,

   Albert


Cheers,

   Albert


On Mon, Nov 14, 2022 at 5:10 PM Albert Astals Cid 

wrote:

El dimecres, 9 de novembre de 2022, a les 23:00:13 (CET), Devin va


escriure:

Hi everyone,

I would like to put kweather through kdereview:

https://invent.kde.org/plasma-mobile/kweather

KWeather is an application that can give simple weather
information
for different weather locations. Please note that KWeatherCore
(the
library the app depends on) has already passed kdereview.


There's potentially overlapping text.

See https://i.imgur.com/BrOgi3A.png

The settings show untranslateable text, i.e.

MobileForm.FormComboBoxDelegate {

 id: forecastStyleDropdown
 text: i18n("Forecast Style")
 currentValue: settingsModel.forecastStyle

Here settingsModel.forecastStyle is not i18n'ed

Not KWeather's fault but i just realized that Kirigami's about page
doesn't
properly credit translators :/

Cheers,

   Albert


Thanks,
Devin

Re: New repo in kdereview: KRecorder

[Nate Graham]

On 11/24/22 16:32, Devin wrote:

I can still see this: https://i.imgur.com/MrrwyAo.jpg


No matter how I try to resize the window, I can't seem to reproduce
the issue... weird


I can reproduce it in the following way on Desktop:
1. Start with the window in a wide state, in two-pane view
2. Resize it to be narrower, so it moves into one-pane view
3. Without stopping resizing (i.e. don't release your fingers from the 
mouse or touchpad) make the window wider again so it returns to 
two-column view

4. Now make it narrower again



I found a new issue: when dragging the window, the view backgrounds become 
partially transparent  during the drag, as if I had the Translucency KWin 
effect active--but I do not. In addition, after the window id dropped, its 
background flickers a bit. None of my other windows do this, and KRecorder 
didn't do this the last time I did it.


This is strange, I did add a blur behind the window a month back, but
it shouldn't be making the window transparent during drag... I don't
currently experience this


I'm on Wayland with 200% scale using a 10th generation Intel iGPU FWIW.

But... This problem shouldn't be able to happen in the first place 
because the window should have transparency and blur at all. We don't do 
this in any other apps and we shouldn't do it here. If this is a thing 
we want, we should do it in Breeze, or maaybe in Kirigami for PlaMo 
apps, but definitely not just in this one random app.





I found one new issue that wasn't present the last time I tested: while 
recording, the volume level indicator always indicates that it's 
recording at max volume, even when I'm just, like, whispering:


https://i.imgur.com/FjytzJa.jpg


Nate




Maybe when we're in widescreen mode and there are no recordings, the right pane's placeholder message could have no 
action and simply say "Click the "Record" button to make a new recording". It can probably remove 
the "Record a new recording" action even when there are any recordings, since the left pane always has a 
"Record" action in its header.


Added

On Mon, Nov 14, 2022 at 7:22 PM Nate Graham  wrote:


Much better! Most issues are fixed now. I feel like we're close. See a
few remaining comments:



The left pane's placeholder message is off-center with narrow windows.


Fixed.


I can still see this: https://i.imgur.com/MrrwyAo.jpg




On the recording page, the "stop recording" button is red which is typically our 
"destructive action" color.


I've attempted to use other colours, as well as the selection colour,
but they either don't contrast when flat, or don't really seem like
buttons.

I would argue that this is a destructive action, because it stops the
recording without any way of going back. This colour is also typically
used for stop buttons on other platforms, so I would not say that it
is particularly out of place, in my opinion.


When I look at other platforms, what I see is that it's common and
traditional for the *record* button to be a red circle, but the stop
button is always a black square. And stopping the recording isn't
destructive; *deleting* the recording is destructive.

Furthermore it's inconsistent with the stop button on the playback view,
which is black: https://i.imgur.com/3u1Ogjy.jpg




Playback buttons can get cut off with short windows:


Fixed.


I can still see this:
- https://i.imgur.com/UH9Ik8Z.jpg
- https://i.imgur.com/AnTyYyb.jpg



I found a new issue: when dragging the window, the view backgrounds
become partially transparent  during the drag, as if I had the
Translucency KWin effect active--but I do not. In addition, after the
window id dropped, its background flickers a bit. None of my other
windows do this, and KRecorder didn't do this the last time I did it.

https://imgur.com/a/ZT5zJsD



I continue to think the two-column view is a bit awkward when there are
no recordings, and now it results in two record actions shown at the
same time, but with different text: https://i.imgur.com/cupborn.jpg

Maybe when we're in widescreen mode and there are no recordings, the
right pane's placeholder message could have no action and simply say
"Click the "Record" button to make a new recording". It can probably
remove the "Record a new recording" action even when there are any
recordings, since the left pane always has a "Record" action in its header.


Nate

Re: New

[Nate Graham]

On 11/17/22 02:08, David Faure wrote> Done:


kconfig v5.100.1
f4dcf631e9f22e25c768c323762672716ddbdd02
8bbb7951d74e8e289f7b0599887ef328b2726fdbdaae18effda2c9d7f18a82da  
sources/kconfig-5.100.1.tar.xz

plasma-framework v5.100.1
0435ec52c76092bc8a8e2703fa0acbbb63484dfe
53940a920773a105df0af9dd3dbf7afcebc6e1eb66404cc77f46c80563b4ada1  
sources/plasma-framework-5.100.1.tar.xz

Linux/BSD packagers: you can skip kconfig-5.100.1, that fix is Windows-only 
anyway.



Thanks a lot, David!

Nate

New

[Nate Graham]

Hello frameworks and release folks,

We had a few major regressions in the 5.100 release that have already 
been fixed; see:

- https://invent.kde.org/frameworks/kconfig/-/merge_requests/148
- https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/652

These are significant enough that I'd like to recommend we make new 
releases of the kconfig and plasma-framework frameworks so we can get 
the fixes to users as quickly as possible.


Would that be possible to do?

Nate

Re: New repo in kdereview: KWeather

[Nate Graham]

Really great app. I have just a few minor UX comments, in order of how 
strongly I feel about them:



The main page has no scrollbars, so it's not obvious that the view is 
scrollable, especially because with various window sizes, nothing looks 
visibly cut off on the bottom to suggest scrollability, which is the 
typical metaphor on mobile: https://i.imgur.com/mN7AD09.jpg


I would recommend using the standard style Kirigami scrollbars which are 
always visible in desktop mode, and semi-auto-hide in mobile mode.




Like KRecorder, the config dialog should be a separate window on desktop 
mode (and a full-window page on mobile mode, which it already does, so 
+1 for that).




I can swipe left and right to switch which city's weather is being 
displayed, but this isn't visually obvious. Maybe add subtle left- and 
rightward-pointing arrows on the sides of the view to suggest that 
there's more than, and that can also be tapped/clicked to change the view.






In the "Add Location" sheet, the "Add Current Location" button should 
probably use the "mark-location" icon, which is more visually appropriate.




In the "Add Location" sheet, the search button should be disabled when 
the search field has no text in it. Also... is that button even needed 
at all? The search field seems to start searching immediately after I 
finish typing, so maybe the button can be removed.




The Locations button in the top-right corner of the main page should 
maybe use the "find-location" icon which is slightly more visually 
appropriate. Also its tooltip needs to start with an action verb and say 
something like "Choose locations".











On 11/9/22 15:00, Devin wrote:

Hi everyone,

I would like to put kweather through kdereview:

https://invent.kde.org/plasma-mobile/kweather

KWeather is an application that can give simple weather information
for different weather locations. Please note that KWeatherCore (the
library the app depends on) has already passed kdereview.

Thanks,
Devin

Re: New repo in kdereview: KRecorder

[Nate Graham]

Much better! Most issues are fixed now. I feel like we're close. See a 
few remaining comments:




The left pane's placeholder message is off-center with narrow windows.


Fixed.


I can still see this: https://i.imgur.com/MrrwyAo.jpg




On the recording page, the "stop recording" button is red which is typically our 
"destructive action" color.


I've attempted to use other colours, as well as the selection colour,
but they either don't contrast when flat, or don't really seem like
buttons.

I would argue that this is a destructive action, because it stops the
recording without any way of going back. This colour is also typically
used for stop buttons on other platforms, so I would not say that it
is particularly out of place, in my opinion.


When I look at other platforms, what I see is that it's common and 
traditional for the *record* button to be a red circle, but the stop 
button is always a black square. And stopping the recording isn't 
destructive; *deleting* the recording is destructive.


Furthermore it's inconsistent with the stop button on the playback view, 
which is black: https://i.imgur.com/3u1Ogjy.jpg





Playback buttons can get cut off with short windows:


Fixed.


I can still see this:
- https://i.imgur.com/UH9Ik8Z.jpg
- https://i.imgur.com/AnTyYyb.jpg



I found a new issue: when dragging the window, the view backgrounds 
become partially transparent  during the drag, as if I had the 
Translucency KWin effect active--but I do not. In addition, after the 
window id dropped, its background flickers a bit. None of my other 
windows do this, and KRecorder didn't do this the last time I did it.


https://imgur.com/a/ZT5zJsD



I continue to think the two-column view is a bit awkward when there are 
no recordings, and now it results in two record actions shown at the 
same time, but with different text: https://i.imgur.com/cupborn.jpg


Maybe when we're in widescreen mode and there are no recordings, the 
right pane's placeholder message could have no action and simply say 
"Click the "Record" button to make a new recording". It can probably 
remove the "Record a new recording" action even when there are any 
recordings, since the left pane always has a "Record" action in its header.



Nate

Re: Would Scandoc be somthing for Extragear?

[Nate Graham]

Hello TObias,

Have you checked out Skanpage? It does PDF scanning, including creating 
multi-page PDF documents out of the scanned files. It also integrates 
with the Purpose framework to offer a simple "Share" menu that lets you 
email scanned documents very quickly.


Nate


On 11/9/22 06:32, Tobias Leupold wrote:

Hi all!

Nowadays, sending PDFs of scanned documents via email or uploading them
somewhere has become a recurring task. For years, I was using shell scripts to
kind-of automate scanning, doing some post-processing and conversion -- after
a fashion. But I thought that there should be some more straightforward tool
for this.

The known general-purpose scanning applications we have didn't do what I
wanted to. So, at the beginning of the year, I started to write a quite
specialized scanning program whose only purpose is to make scanning documents
and turning them into a PDF file as easy as possible.

The result is Scandoc. It currently lives at
https://invent.kde.org/tleupold/scandoc

The Readme contains a description of what it is. It uses KSaneCore to access a
scanner and runs (by default well-known) helper programs to post-process the
scanned pages and save them as a PDF file. By default, ImageMagick's convert
tool is invoked for the colour/sharpness/gamma post-processing and TeX Live's
pdfjam is used for the PDF conversion. However one can use any CLI helper
program or script for those tasks. E.g. the repository contains an example
script to output searchable PDFs by using the Tesseract OCR engine.

Scandoc has been used for half a year in production now in my (dentist's)
office, and -- from what I heard from the (of course by now only few) users --
it makes this very task of creating PDF files from documents a lot easier and
can be used quite conveniently.

I thus wondered if this would be something we could need in Extragear.
At least, I wanted to share this with you, maybe, someone may find this useful
:-)

Cheers, Tobias

Funding opportunity for your projects

[Nate Graham]

Hello KDE community members and developers!

I'm writing to everyone about something very exciting: the NLnet 
Foundation (https://nlnet.nl) has made us aware that they have 
substantial quantities of funds available for FOSS projects that KDE is 
eligible for: up to 5€ per project. If you have an idea for a big 
project or feature you've always wanted to do but lacked the funding 
for, here's your chance!


If you're worried that your idea doesn't meet the criteria, don't be; 
practically everything KDE does is eligible for funds in the Open Call 
(https://nlnet.nl/news/2022/20221001-call.html) which ends on December 
1st, so there's still plenty of time for you to apply to get your 
project funded. Click that link for details.


Remember: what KDE does is good for the digital world. So if it's good 
for KDE and you can articulate its benefits, it's a worthy project!


If the process seems intimidating, you'd like someone to review your 
grant proposal, or you need guidance or assistance for any other reason, 
the KDE e.V. stands ready to help your grant proposal succeed. Email 
kde-ev-bo...@kde.org and we can help!



Nate



P.S. This information can also be found on 
https://community.kde.org/Make_A_Living

Re: New repo in kdereview: KRecorder

[Nate Graham]

Pretty nice app.


The app should have a Bugzilla component and its "Report a bug" button 
should take users there, as we have been migrating towards for other 
mobile apps recently.



Some UI review now:


When I open the app for the first time on the desktop, I get a 
mobile-specific floating action button at the bottom of the view which 
doesn't make it clear how I can record something:


https://i.imgur.com/1xSDJkC.jpg

On the desktop, we should not show the FAB, give the placeholder message 
a "Make New Recording" action button, and then when the placeholder 
message isn't visible, show a button for that action on the toolbar.


(and IMO that would be better for mobile too)



When there are no recordings, the right pane is superfluous, and its 
message refers to things that don't exist.




The left pane's placeholder message is off-center with narrow windows.



When I click on the Settings button, instead of the settings view 
appearing as either a standalone window (as I would expect for a desktop 
app) or an embedded page (as I would expect for a mobile app), it opens 
as a view within a Kirigami.OverlaySheet, which is weird. Also, the use 
of the new Kirigami mofile form components creates a "frames within 
frames" effect that I find slightly offputting:


https://i.imgur.com/5LN7cBJ.jpg

When I click on any of the settings, they open in *new* OverlaySheets 
which feels quite weird. And the About page does open as a real page, 
but when I click the back button it doesn't take be back to where I was 
before; it closes the OverlaySheet I was looking at amd I'm back on the 
main view


Overall I would recommend using full-window pages (or a standalone 
window on desktop) here, rather than an OverlaySheet.




The "Audio Quality" setting doesn't give any mention of a trade-off 
between quality and file size (which I assume it at play here), leaving 
me to wonder why I wouldn't always make it the highest value, and why it 
doesn't default to that itself.




On the recording page, the "stop recording" button is red which is 
typically our "destructive action" color.




The default filename for all recordings is "clip_0001", even if a file 
of that name already exists.




The UI does not make it clear where files get saved to during the save 
process. I took a guess and checked in ~/Music, which was correct but 
that's a weird place for voice recordings which are clearly not music.


I found the actual file path on the edit dialog, but we should show the 
full file path elsewhere too, at least on the desktop where users are 
more likely to care about the exact location of where files live.




The "Edit" action for the individual list items should probably be 
renamed to "Rename" since that's all you can do there. Same for the 
title of the OverlaySheet it spawns




On the "Editing [name]" OverlaySheet, the filename field's label is 
"Audio Input:" which seems inappropriate.




Playback buttons can get cut off with short windows:

https://i.imgur.com/Fl0oIUf.jpg

None of the icons-only buttons on the recording or playback pages have 
tooltips.







On 10/26/22 09:08, Devin wrote:

Any other comments or issues to address?

Thanks,
Devin

On Fri, Oct 21, 2022 at 6:21 PM Albert Astals Cid  wrote:


El divendres, 21 d’octubre de 2022, a les 23:55:28 (CEST), Devin va escriure:

make install doesn't install any icon for me with the current master.


I just checked and indeed, the method I changed to using
ecm_install_icons doesn't seem to have the behaviour I thought it did.
I hadn't verified it properly because the icon was already
preinstalled for me.

I reverted to the prior commit which installed the icon fine (it
should be installing to
/usr/share/icons/hicolor/scalable/apps/krecorder.svg), does this not
work for you on X11? I double checked and the application icon shows
for me.


https://invent.kde.org/plasma-mobile/krecorder/-/merge_requests/17

Makes it work for me (when starting from the terminal)

Cheers,
   Albert



Thanks,
Devin

On Fri, Oct 21, 2022 at 5:08 PM Albert Astals Cid  wrote:

El divendres, 21 d’octubre de 2022, a les 23:00:46 (CEST), Devin va

escriure:

The app doesn't have an icon when run in X11


Hmm, the location the icon installed to might be non-standard. I think
I've fixed it on master now by copying the way other KDE apps install
the icon.


make install doesn't install any icon for me with the current master.

Cheers,

   Albert

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

I know about that page, but I haven't memorized every detail of it, or 
been able to always recall it as the location for the exact piece of 
information I was looking for.


If you have, I'm impressed!

Nate



On 10/25/22 02:01, Ingo Klöcker wrote:

On Montag, 24. Oktober 2022 23:16:50 CEST Nate Graham wrote:

OK great, thanks! Good to notify people when doing it. :)

Where does that YAML file live?


The whole review process including the location of the YAML file is described
at https://community.kde.org/Policies/Application_Lifecycle .

I'm wondering how you manage to pass the review process seemingly without
knowing about this page. :-)

Regards,
Ingo

Re: Archiving KDE Telepathy?

[Nate Graham]

+1 for the reasons you provided.

Nate


On 10/25/22 11:08, Nicolas Fella wrote:

Hi,

there various KTP modules have seen very little development over the
last years. Most of the activity that did happen was either release
housekeeping stuff like version bumps or general code cleanup (i.e. the
kind of cleanup that some people do across the whole KDE codebase and
not necessarily out of a genuine interest in KTP). There is also no
significant activity around it on bugs.kde.org.

While certainly amazing in its vision it anecdotally never fully made
use of that potential, partly because it's just trying to solve a
problem that is really hard to solve.

Most of the activity I see around KTP is from people trying to use it
out of curiosity but finding it broken/unpolished or not what they
expected it to be. We like to say that "Everything in KDE Gear is
maintained". I'd argue that from this follows that if it isn't actually
maintained we should drop it from the Gear releases.  We are doing our
users a disservice by pretending something is maintained when it
actually isn't. We are also doing ourselves a disservice since
unpolished software "leaking" into the desktop experience is going to
make the whole product appear unpolished.

Furthermore, with the transition to Qt6 very soon now we should make a
decision: Either we invest a non-trivial amount of work into making it
work against Qt6/KF6, or we pronounce it dead. Having it "alive" but
unported isn't helping anyone in the long term.

Therefore I propose that we stop releasing the various ktp- modules with
KDE Gear and archive the repositories after the last relevant KDE Gear
cycle finished.

Cheers

Nico

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

Well that's embarrassing. Looks like my email was slow today, and I just 
now got the message from Jonathan which even lists the commit that 
changed it!


Thanks everyone.

Nate


On 10/24/22 11:54, Ben Cooksley wrote:
On Tue, Oct 25, 2022 at 4:30 AM Nate Graham <mailto:n...@kde.org>> wrote:


Since it seems there are no more objections, I'd like to consider
plasma-welcome to have graduated form kdereview.

Sysadmins, can we get it moved out of Playground and into Plasma?


This was already done by Jonathan about 24 hours or so ago.
(The placement of projects in playground / KDE Review / etc is just a 
single line in a YAML file which anyone can commit to)



Nate


Cheers,
Ben



On 10/21/22 12:19, Nate Graham wrote:
 > Any more concerns or objections?
 >
 > Nate
 >
 >
 >
     > On 10/19/22 11:56, Nate Graham wrote:
 >>
 >>
 >> On 10/19/22 10:03, Albert Astals Cid wrote:
 >>> El dimecres, 19 d’octubre de 2022, a les 5:22:09 (CEST), Nate
Graham va
 >>> escriure:
 >>>> Ping; if there are no objections I'd consider it approved.
 >>>
 >>> I can't still see the toolbar :/
 >>
 >> Thanks to Albert's
 >> https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/19
<https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/19>,
this
 >> is working now.
 >>
 >> Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

OK great, thanks! Good to notify people when doing it. :)

Where does that YAML file live?

Nate


On 10/24/22 11:54, Ben Cooksley wrote:
On Tue, Oct 25, 2022 at 4:30 AM Nate Graham <mailto:n...@kde.org>> wrote:


Since it seems there are no more objections, I'd like to consider
plasma-welcome to have graduated form kdereview.

Sysadmins, can we get it moved out of Playground and into Plasma?


This was already done by Jonathan about 24 hours or so ago.
(The placement of projects in playground / KDE Review / etc is just a 
single line in a YAML file which anyone can commit to)



Nate


Cheers,
Ben



On 10/21/22 12:19, Nate Graham wrote:
 > Any more concerns or objections?
 >
 > Nate
 >
 >
 >
     > On 10/19/22 11:56, Nate Graham wrote:
 >>
 >>
 >> On 10/19/22 10:03, Albert Astals Cid wrote:
 >>> El dimecres, 19 d’octubre de 2022, a les 5:22:09 (CEST), Nate
Graham va
 >>> escriure:
 >>>> Ping; if there are no objections I'd consider it approved.
 >>>
 >>> I can't still see the toolbar :/
 >>
 >> Thanks to Albert's
 >> https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/19
<https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/19>,
this
 >> is working now.
 >>
 >> Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

Since it seems there are no more objections, I'd like to consider 
plasma-welcome to have graduated form kdereview.


Sysadmins, can we get it moved out of Playground and into Plasma?

Nate


On 10/21/22 12:19, Nate Graham wrote:

Any more concerns or objections?

Nate



On 10/19/22 11:56, Nate Graham wrote:



On 10/19/22 10:03, Albert Astals Cid wrote:

El dimecres, 19 d’octubre de 2022, a les 5:22:09 (CEST), Nate Graham va
escriure:

Ping; if there are no objections I'd consider it approved.


I can't still see the toolbar :/


Thanks to Albert's 
https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/19, this 
is working now.


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

Any more concerns or objections?

Nate



On 10/19/22 11:56, Nate Graham wrote:



On 10/19/22 10:03, Albert Astals Cid wrote:

El dimecres, 19 d’octubre de 2022, a les 5:22:09 (CEST), Nate Graham va
escriure:

Ping; if there are no objections I'd consider it approved.


I can't still see the toolbar :/


Thanks to Albert's 
https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/19, this 
is working now.


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

On 10/19/22 10:03, Albert Astals Cid wrote:

El dimecres, 19 d’octubre de 2022, a les 5:22:09 (CEST), Nate Graham va
escriure:

Ping; if there are no objections I'd consider it approved.


I can't still see the toolbar :/


Thanks to Albert's 
https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/19, this 
is working now.


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

There have been no additional comments or objections for two weeks; can 
everything brought up in this thread be considered resolved now?


Nate



On 9/23/22 23:34, Nate Graham wrote:
Thanks for your help, everyone. Fixed now with 
https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/12.


Nate


On 9/18/22 11:03, Harald Sitter wrote:

Not all code is licensing policy compliant (e.g. appdata is missing
spdx tags). I'd suggest enabling the reuse linter pipeline.

On Fri, Sep 16, 2022 at 6:00 PM Nate Graham  wrote:


Hello folks!

I've been working with Aleix on an onboarding wizard for Plasma, based
on work originally started by Felipe Kinoshita last year.

You can see some screenshots at
https://invent.kde.org/websites/product-screenshots/-/commit/e300be66e62263c63d8a85ba391bbcc1de691148.

I'd like to target Plasma 5.27 for release and am submitting it for
KDEReview. The repo is at https://invent.kde.org/plasma/welcome-app.


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

Thanks for your help, everyone. Fixed now with 
https://invent.kde.org/plasma/plasma-welcome/-/merge_requests/12.


Nate


On 9/18/22 11:03, Harald Sitter wrote:

Not all code is licensing policy compliant (e.g. appdata is missing
spdx tags). I'd suggest enabling the reuse linter pipeline.

On Fri, Sep 16, 2022 at 6:00 PM Nate Graham  wrote:


Hello folks!

I've been working with Aleix on an onboarding wizard for Plasma, based
on work originally started by Felipe Kinoshita last year.

You can see some screenshots at
https://invent.kde.org/websites/product-screenshots/-/commit/e300be66e62263c63d8a85ba391bbcc1de691148.

I'd like to target Plasma 5.27 for release and am submitting it for
KDEReview. The repo is at https://invent.kde.org/plasma/welcome-app.


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

On 9/18/22 11:03, Harald Sitter wrote:

Not all code is licensing policy compliant (e.g. appdata is missing
spdx tags). I'd suggest enabling the reuse linter pipeline.


How do I do this? Is there an example I can copy from elsewhere (which 
in case people haven't noticed, is basically how I do everything)?


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

On 9/19/22 01:42, Ingo Klöcker wrote:

Please try to keep in mind that there are people who cannot see screenshots.
They may not need captions, but they do need a textual description of the
screenshot.


That's an excellent point, and thanks for the reminder. Captions added.

Nate

Re: Product organization in Bugzilla

[Nate Graham]

On 9/19/22 15:33, Johannes Zarl-Zierl wrote:

To end my rant on a productive note: Yes, sure - hide internal components as
you see fit (maybe hide archived/unmaintained components as well, while you're
at it). But IMO the main problem is that users have to search on bugzilla
instead of clicking a link inside the actual software component that they use.



Exactly. See https://bugs.kde.org/show_bug.cgi?id=370195 and 
https://bugs.kde.org/show_bug.cgi?id=204364.


That said, I don't expect implementing these features to fully resolve 
the issue, though I agree with you that it would help a lot.


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

On 9/18/22 11:44, Nicolas Fella wrote:

Hi,

- I'd suggest to rename the repository to plasma-welcome to be
consistent with the internal name and also other Plasma repos


Requested with https://phabricator.kde.org/T15840



- The version number in KAboutData says "1.0", this should follow the
Plasma version


Fixed.



- There's no Qt6 build yet, please look into that


Done.



- Some distributions have their own welcome apps, please coordinate with
them so that we don't end up greeting the user with two welcome apps


That's a good idea. Will do.



- The appstream id ends with .desktop, which I understand is deprecated


Fixed.



- appstreamcli validate --pedantic org.kde.plasma-welcome.appdata.xml
has some warnings:

P: org.kde.plasma-welcome.desktop:12: screenshot-no-caption
P: org.kde.plasma-welcome.desktop:~: releases-info-missing
I: org.kde.plasma-welcome.desktop:3: cid-contains-hyphen
org.kde.plasma-welcome.desktop
P: org.kde.plasma-welcome.desktop:15: screenshot-no-caption


I don't think these are real issues. There are no releases yet, the 
screenshots not having captions is intentional (their content seems 
totally obvious to me), and the ID having a hyphen seems like it's not 
actually a problem.




- There's a stray .directory file in src/


Fixed.



- Please add the ECM clang-format target and commit hook


https://invent.kde.org/plasma/welcome-app/-/merge_requests/11


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

On 9/17/22 02:16, Albert Astals Cid wrote:

Understanding that this is a standalone app and none of its contents are
reused to be shown in other apps a
   KLocalizedString::setApplicationDomain("welcomecenter");
call in its main.cpp will do.

Sidenote, given the name of the app is plasma-welcome i'd really suggest
changing the catalog name to plasma-welcome too instead of welcomecenter.


Done.



It's a kirigami app, sadly this means it has too many warnings
https://pst.klgrth.io/paste/ydbmz


A few of those are already fixed in git master. For the others, I've 
tried to clean this up a bit by fixing warnings where I can, or at least 
filing bug reports:

- https://invent.kde.org/frameworks/kirigami/-/merge_requests/748
- https://invent.kde.org/network/kaccounts-integration/-/merge_requests/42
https://invent.kde.org/plasma/welcome-app/-/merge_requests/8
- https://bugs.kde.org/show_bug.cgi?id=459283
- https://bugs.kde.org/show_bug.cgi?id=459284



When run on my computer i can't see any buttons on the top "toolbar" (they
are there since generally clicking where they should be gets the thing to
go next/ prev). What dependency version are you interested in knowing
that may be causing this?


This is weird. I don't understand how the toolbar can be invisible but 
interactive for you. I'm at a loss here. Does anyone else have any ideas?



Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

On 9/16/22 15:46, Nicolas Fella wrote:

Am 16.09.22 um 23:40 schrieb Nate Graham:

On 9/16/22 15:31, Albert Astals Cid wrote:

Those screenshots show me the Wayland icon, please fix.


Sure, how do I fix that exactly?


Either

- Fix the first argument to KAboutData to be the same as the base name
in the desktop file. The desktop file name is org.kde.welcomecenter, so
you would need to pass "welcomecenter" instead of "plasma-welcome" to
KAboutData

- Use KAboutData::setDesktopFileName("org.kde.welcomecenter")



Thanks! Tobias pointed me to 
https://nicolasfella.de/posts/fixing-wayland-taskbar-icons/ and I've 
fixed it now. I'll push new screenshots soon.


Nate

Re: Plasma Welcome Center on KDEReview

[Nate Graham]

On 9/16/22 15:31, Albert Astals Cid wrote:

Those screenshots show me the Wayland icon, please fix.


Sure, how do I fix that exactly?



I see the app has a Messages.sh but I remain unconvinced that the generated
welcomecenter.po generated file is used.


Is there something that needs to be changed here? I'm not very familiar 
with how localization is set up, so any tips would be helpful.





When run on my computer i can't see any buttons on the top "toolbar" (they are
there since generally clicking where they should be gets the thing to go next/
prev). What dependency version are you interested in knowing that may be
causing this?


Can you share a screenshot of how it looks for you?

Some shots in the dark?
- Are there any relevant-looking errors printed to the console if you 
run it in a terminal window?

- Do you have the qqc2-desktop-style framework installed?
- Do you have qt5ct installed?


Nate

Re: KDE on Linux Unplugged this week

[Nate Graham]

An interesting listen.

Here's the tl;dl regarding Brent's complaints:
- Kubuntu 22.04 seemed buggier than 20.04
- Kubuntu repo management password bug stayed unfixed for too long
- Plasma 5.25 on other distros seemed buggier than usual too, specifically:
-- Multimonitor was a pain
-- Activities were clunky and didn't work well
- In general he felt like Plasma's implementations on various distro 
aren't ideal

- He tried switching to GNOME on Fedora and found it to be much worse


Multimonitor and activities issues are known and being worked on, but 
overall it fels like most of his complaints were with how distros are 
packaging and implementing Plasma--especially Kubuntu. Food for thought.


I contacted them and offered to be a gust for a future show so I can add 
some perspective.


Nate


On 9/11/22 23:54, Luna Jernberg wrote:

https://linuxunplugged.com/475 KDE Talk in this weeks LUP

Plasma Welcome Center on KDEReview

[Nate Graham]

Hello folks!

I've been working with Aleix on an onboarding wizard for Plasma, based 
on work originally started by Felipe Kinoshita last year.


You can see some screenshots at 
https://invent.kde.org/websites/product-screenshots/-/commit/e300be66e62263c63d8a85ba391bbcc1de691148.


I'd like to target Plasma 5.27 for release and am submitting it for 
KDEReview. The repo is at https://invent.kde.org/plasma/welcome-app.



Nate

Re: KDE Goal Project specific issue: Automate and systematize internal processes

[Nate Graham]

[Apologies for the delayed reply; your email was erroneously sorted into 
my spam folder and I missed it until now.]


All of these proposals are just proposals. Nothing mandatory, required, 
or burdened with rules. Just something that overall, would probably 
improve thing such that I would hope that projects would want to opt in.


You can insert tags into the code to make clang-format ignore parts of 
it, which could be uses in the example you've mentioned.


Nate


On 9/10/22 13:34, Michael Reeves wrote:

I  just  read this in the Automate and systematize internal processes Goal

Move clang-format from a git hookscript to pre-commit CI so that merge 
requests will show a CI failure when badly-formatted changes exist, and 
people can see this in a nice UI and fix them


https://phabricator.kde.org/T15627 

For kdiff3 this likely to create un-needed noise due the code base not 
perfectly aligning to the .clang-format format file provided. This comes 
both from headers whose format is untouched a aumber of spaceing quirks 
that I cann't teach clang-format to either ignore or due itself. Is the 
above proposal to  be opt-in like the current system or automatic for 
all projects?

Product organization in Bugzilla

[Nate Graham]

Hello folks,

We often get feedback from bug reporters that it's hard to find the 
right product in https://bugs.kde.org/enter_bug.cgi because it contains 
just a giant intimidating list.


Yes, people can use their browser's search function, and yes, if a bug 
is files in the wrong place, it will be moved to the right place. Still, 
I can't help but admit that this page is quite intimidating, and that 
intimidation may be a barrier to even trying. See 
https://bugs.kde.org/show_bug.cgi?id=340420.


With this in mind, I'd like to propose that we add some grouping on this 
page. Bugzilla provides this feature natively and other FOSS projects' 
Bugzilla instances make use it; see for example:

- https://bugs.documentfoundation.org/enter_bug.cgi
- https://bugzilla.redhat.com/enter_bug.cgi

We could do the same, providing a few user-friendly groups for common 
software people use:


- KDE apps
- KDE Plasma Desktop
- KDE Plasma Mobile
- KDE Frameworks
- KDE Neon
- Something else (which would contain everything not in any of those groups)
- Unknown (which would lead to the generic "kde" component

(note: this suggestion is not a formal proposal set in stone, it's just 
an example of a system of grouping we could use)


Thoughts?

Nate

Re: New releases for bugfixes

[Nate Graham]

On 9/8/22 05:51, Nicolas Fella wrote:

Hi,

I don't think Nate or anyone wants to propose a strict policy that when
X then Y has to happen. That's just not how we operate in KDE. I do
think it is valuable though to discuss and create some guidelines/shared
understanding/soft policy that maintainers can use as a reference when
making decisions. That would match very well how decisions and policies
are made in KDE.


Correct. My suggestion for a basic set of criteria was designed to be a 
suggestion, not an iron straitjacket. :) Things in KDE are not so rigid 
that we need to bind ourselves with strict rules that we never deviate from.


Nate

Re: New releases for bugfixes

[Nate Graham]

To revive this thread, I think the issue is that it feels sort of 
subjective what kind of bugs are bad enough that we think like a new 
release is worth it. So maybe we can try to get specific and say that we 
should make a new release for fixes of Bugzilla bug reports where:

- Priority is VHI or HI
- Severity is critical, grave, or major
- Possibly also the "crash" severity?

What do people think about that?

Nate

Re: New releases for bugfixes

[Nate Graham]

On 8/25/22 22:59, Albert Astals Cid wrote:

c) Who decides which bugs "are important" because for every bug, there's
always a person out there that thinks it's the most important bug ever.

d) What do we release? i.e. imagine we find one of those "important bugs" in
dolphin and we have to release 22.08.0.1. Do we just release the 22.08 branch
with any changes it may have had since the 22.08.0 release or do we create a
special branch that only contains the new patch and release that?


It's always subjective, but I was specifically thinking of bugs like 
https://bugs.kde.org/show_bug.cgi?id=458099 in which we accidentally 
introduced an API break and then fixed it.


I was going to send out a patch request, but something like this really 
deserves a new release IMO, just in the interest of our API 
compatibility promise.


Nate

New releases for bugfixes

[Nate Graham]

Hello everyone,
Right now when we fix a significant bug in our software that may take a 
while to reach users to to the release schedule of its repo, we contact 
distros and ask them to backport it. This puts the burden on distros to 
react to us. I'm wondering how people feel about KDE instead making 
immediate point releases ourselves. Thus we would take responsibility 
for releasing fixes for our own regressions, and distros that monitor 
KDE infrastructure for new tarballs could be notified automatically.


Thoughts?

Nate

Re: Missing product versions in Bugzilla

[Nate Graham]

IIRC, the release team takes care of updating product-versions of apps 
on Bugzilla using a script. CCing them.


Nate



On 7/23/22 16:10, Glen Ditchfield wrote:
Phabricator has a task T2373: Make sure Bugzilla versions of our 
products are updated.  I've noticed an assortment of missing versions 
for different products:



|kontact | 5.20.1 5.17.2 5.16.2   |

|kmail2  | 5.20.1 5.18.3 5.18.2 5.18.1 5.18.0 |

|    | 5.17.3 5.17.2 5.17.1 5.17.0    |

|korganizer  | 5.20.1 5.17.2 5.16.2   |

|reminder daemon | 5.20.1 5.20.0  |


... and that's all I looked at.


Can I fix this myself, or is there someone to gently encourage?

Re: Telemetry in Plasma and Discover

[Nate Graham]

+Fabian Vogt and Luca Beltrame specifically

Thanks, that's a relief! Does this looks legit enough for openSUSE to 
stop patching out the KUSerFeedback integration?


Nate


On 7/11/22 18:50, Aleix Pol wrote:

It was discussed here:
https://mail.kde.org/pipermail/kde-core-devel/2020-November/091049.html

Aleix

On Tue, Jul 12, 2022 at 1:53 AM Nate Graham  wrote:


Hello all,

It's come to my attention that Plasma and Discover implemented support
for opt-in-telemetry without complying with the requirements listed at
https://community.kde.org/Policies/Telemetry_Policy#Compliance. The
Request for review was done solely in a merge request, not also on these
mailing lists.

I am retroactively emailing the kde-core-devel and kde-community mailing
lists to request review of the telemetry support in these KDE products
so that we can be in compliance with our own policies, should the review
be positive and use of opt-in telemetry continues.

Relevant commits:
-
https://invent.kde.org/plasma/plasma-workspace/-/commit/15dd744a3ba42cecc04f3e7a51148e9be3345c6d
-
https://invent.kde.org/plasma/discover/-/commit/f1f1597f4f2ea3870456a2f2ed184f9ebfc62bc3
- https://phabricator.kde.org/D5961

Nate

Telemetry in Plasma and Discover

[Nate Graham]

Hello all,

It's come to my attention that Plasma and Discover implemented support 
for opt-in-telemetry without complying with the requirements listed at 
https://community.kde.org/Policies/Telemetry_Policy#Compliance. The 
Request for review was done solely in a merge request, not also on these 
mailing lists.


I am retroactively emailing the kde-core-devel and kde-community mailing 
lists to request review of the telemetry support in these KDE products 
so that we can be in compliance with our own policies, should the review 
be positive and use of opt-in telemetry continues.


Relevant commits:
- 
https://invent.kde.org/plasma/plasma-workspace/-/commit/15dd744a3ba42cecc04f3e7a51148e9be3345c6d
- 
https://invent.kde.org/plasma/discover/-/commit/f1f1597f4f2ea3870456a2f2ed184f9ebfc62bc3

- https://phabricator.kde.org/D5961

Nate

Re: Eloquens now on KDEREVIEW

[Nate Graham]

On 6/21/22 13:24, Harald Sitter wrote:

some desktop file validation: (the last point is because
SingleMainWindow isn't actually a valid key, you should remove it I
guess)

org.kde.eloquens.desktop: hint: value "Qt;KDE;Development;Utility;"
for key "Categories" in group "Desktop Entry" contains more than one
ma
in category; application might appear more than once in the application menu
org.kde.eloquens.desktop: error: file contains key "SingleMainWindow"
in group "Desktop Entry", but keys extending the format should start
with "X-"


SingleMainWindow is a valid key, but handling it property requires a 
version of desktop-file-utils that was updated recently enough to notice.


Nate

Re: KF 5.95-rc1 delayed

[Nate Graham]

On 6/9/22 11:18, Nate Graham wrote:

Both are merged now. I think that should be everything.


...One more regression was found which is fixed with 
https://invent.kde.org/frameworks/plasma-framework/-/commit/1fb2198fcee0ec909fed2f1cb6f2d16f27513d57.


Can you please add that to the 5.25 tarball? Thanks! :)

with that included, I think we'll finally be done from the 
plasma-framework perspective.


Nate

Re: Asking for a new project

[Nate Graham]

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


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


Nate



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


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


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



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


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


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

Best,
Aleix


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

Re: Approval request for feature idea

[Nate Graham]

Hello Samuel,

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


Nate

Re: Asking for a new project

[Nate Graham]

Indeed, I would recommend working with them on a plan to make sure your 
changes are mergeable and eventually merged into the main repo. If that 
doesn't end up happening, all your hard work will have been wasted.


Nate


On 5/31/22 18:45, Aleix Pol wrote:

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

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

Best,
Aleix


On Tue, May 31, 2022 at 9:10 AM Bourumir Wyngs  wrote:


Hello, KDE team,

I would like to create the independent fork of Krita that would allow to use 
all modern features of C++, up till that is supported by the latest GCC 
release, 12.1 at the time of writing.

The current Krita development rules are capped by C++11 that is now the ten 
years old standard. Even that is limited by the lengthy list of restrictions. 
The rules also require using deprecated features of the Qt framework like 
Q_FOREACH. I understand the care of the community not to spoil anything and to 
preserve the beauty of the existing code. This means, radical changes should be 
done in a form.

I tried to setup the project on KDE myself 
(https://invent.kde.org/bourumir/kreed) but for some reason was not able to 
push Krita code (about 1 Gb) into repository - hangs at the end of the push. It 
may have something to do with quotas or things the like. It may be that I need 
more assistance from your side to setup the project. I decided to contact you 
first before starting the work on GitHub or independent server instead.

I, the project initiator, am currently 54 year old. I am robotic engineer with 
very long programming experience, including significant industrial experience 
with C++. In the past I made notable contribution to GNU Classpath project, 
providing them a fully functional and interoperable implementation of CORBA. It 
is obviously sad there are no other contributors so far but I expect some 
people to come. I also made several contributions for Krita so have some 
understanding about code base and architecture of this project. My real name is 
Audrius Meskauskas.