Re: KDE and Google Summer of Code 2018

[Nate Graham]

I've submitted an idea for System Settings: Improve handling for 
touchpads and mice with Libinput


https://community.kde.org/GSoC/2018/Ideas#Improve_handling_for_touchpads_and_mice_with_Libinput

This is pretty important going forward since most distros are shipping 
with Libinput now, but our users aren't able to configure their devices 
without resorting to editing xorg config files using a different driver.


Nate


On 01/15/2018 06:13 AM, Dmitry Kazakov wrote:

Hi, Valorie!

I have just edited the list of Krita ideas, now we have 8 ideas, 4 of 
which are low-hanging fruits with localized optimizations of the code. I 
hope that will help people who do not want to learn all half-million 
lines of Krita code.


Speaking truly, I think I understand why there is so little effort from 
people with the ideas. Since the last year Google forbids students to 
apply more than 2 times, it means that most of the applicants will be 
newcomers and, most probably, they will not be able to prepare some 
extensive proposal/design for a project. It is just too difficult to 
prepare a good proposal for a project so big in size. So it might be 
that the quality of last year proposals discouraged people from doing 
this work again.


The only way how we can solve the issue is to prepare very scope-limited 
tasks, such that the students would not need to learn all the code (in 
our case we just added AVX optimizations, which are limited to a scope 
of a couple of classes). But that is not always possible or makes sense 
for the some projects.



On 15.01.2018 03:39, Valorie Zimmerman wrote:
I'm very discouraged to see so little movement on this. After skipping 
GCi this past fall, are we now also considering skipping GSoC? Or 
downsizing the number of students we are mentoring?


Without Ideas we will not get students. More important, we must 
complete the Org application soon, and the Ideas page is the core of 
that application.


This is good for your team and your project, in the long run. It 
brings in new contributors and fresh ideas.


If you need some guidance, please read 
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html


I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman 
mailto:valorie.zimmer...@gmail.com>> wrote:



Hello GSoC mentors, and teams supporting mentors,

TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas
; read
https://community.kde.org/GSoC. Now.

Every year, we've asked for more time to get ramped up for GSoC,
and so now is the time for organizations to apply[1]. We have
begun to write our application, and  that means that our Ideas
page needs to be filled NOW, because that is the prime
consideration for the GSoC team once the Org Applications deadline
has passed.

The quality of our ideas and the guidance they give our students
are the most important part of our application. Please begin
filling in your ideas now if you have not already, and ensure that
that page is comprehensive, accurate and attractive. Including
screenshots and other images is allowed, if it enriches the idea
for a project. *Please ensure complete information about how to
contact the team*; this is crucial.

Also, take a look at the landing page
https://community.kde.org/GSoC. Experienced mentors agree that:

1. commits must be made before the student proposal is submitted,
and linked on that proposal, and

2. that regular communication from the student must be initiated
by the student at least weekly, and we expect daily or nearly
daily communication with the team in a more informal way.

Be sure to point students to that information, as this should
lower the number of proposals, while raising the quality.

1. https://developers.google.com/open-source/gsoc/timeline


PS: If your team has an Idea, ensure that you have mentors for it,
and that those mentors are subscribe to KDE-Soc-Mentor list.
Remove any ideas without mentors available, please. Now, before
you forget!

Valorie



--
http://about.me/valoriez


--
Dmitry Kazakov

Re: CI system maintainability

[Nate Graham]

With regards to the discussion about mandatory code review, I think it's 
important to avoid immediately rushing to create new policy as a result of a 
particular event or abuse. It's always tempting to try to put in place a rule 
that would have avoided the problem if it had existed and was being followed, 
but usually in these circumstances, existing rules or conventions were already 
being violated. So adding new ones usually doesn't help as much as people would 
want because they don't address the underlying issue of why rules are being 
broken in the first place.

In this case, it seems like the problem is that there are certain individuals 
or teams that are pushing risky, breaking changes without code review, and then 
ignoring failures in the CI. I think we might do well to try to answer the 
question of why that's happening before we create a new rule aimed at stopping 
it.

Nate

Re: Review Request: plasma-thunderbolt

[Nate Graham]

+1 from me; the original was good and this looks good too.

One minor thing that I don't think should be a blocker: Could we copy 
FindBolt.cmake into ECM with an eye towards not needing it here in a 
future release?


Nate


On 5/15/19 7:27 AM, Daniel Vrátil wrote:

Hi all,

plasma-thunderbolt is a new repo containing, you guessed it, Thunderbolt KCM
for Plasma. I initially submitted the code as a patch against plasma-desktop
[0], where it got reviewed, but it was ultimately decided to better put it
into a separate repository, since it's not just a KCM but also a library and a
KDED module. I have backported all the changes from the Phabricator review
back to the repository, so the code in the repo is identical to the one in the
Phab review (minus buildsystem changes and a small build fix for clang).

However, since this is still a new code, it must formally pass through
kdereview before I can submit it into Plasma as a new module.

Thus I'd kindly ask you to take one more look at the codebase [1] and let me
know if there are any more issues to fix, or if we can proceed to include this
in the next Plasma release.

Thanks,
- Dan

[0] https://phabricator.kde.org/D19011
[1] https://cgit.kde.org/plasma-thunderbolt.git

Re: ksnapshot to unmaintained

[Nate Graham]

+1, clearly it is unmaintained, and in fact development has been 
abandoned given Spectacle's existence.


Nate



On 5/9/19 5:06 PM, Jonathan Riddell wrote:

One would think so, but one would be wrong, at least on the labelling :)
https://projects.kde.org/api/v1/projects/extragear/graphics

Jonathan


On Fri, 10 May 2019 at 00:00, Boudhayan Gupta > wrote:


I thought it was already unmaintained as of the first release of
Spectacle.

On Fri, 10 May 2019 at 00:48, Albert Astals Cid mailto:aa...@kde.org>> wrote:

Weakly suggest emailing kde-graphics-devel mailing list about this.

Cheers,
   Albert

El divendres, 10 de maig de 2019, a les 0:09:29 CEST, Jonathan
Riddell va escriure:
 > I'd like to propose moving ksnapshot to unmaintained, it's
had no code
 > commits since 2017 and still uses KDElibs4 and the
functionality is
 > replaced by Spectacle.
 >
 > Jonathan
 >

Re: kaudiocreator to unmaintained

[Nate Graham]

On 5/21/19 10:48 AM, Kevin Ottens wrote:

I'd like it to be part of KDE Applications. Unlike Zanshin I'd rather have
this one tied to the Applications release cycle. That being said, it's been
eons since I had anything in the regular applications collection. Could
someone refresh me on what it entails to "make release"? Back in the day it
was fairly transparent, if that's still so low on work I can easily say yes...
if not I'll have to evaluate.


If it's a part of KDE Applications, the apps release team will take care 
of that for you. :)


Sounds good, let's get kaudiocreator added to the bundle.

Nate

Re: What means having an application in "KDE Applications"

[Nate Graham]

On 6/16/19 3:41 PM, Luigi Toscano wrote:

Jonathan Riddell ha scritto:

On Fri, Jun 07, 2019 at 12:09:27AM +0200, Albert Astals Cid wrote:

Can we please discuss what being in KDE Applications is first?

You're telling apps they can join KDE Applications if they want, so to you it's just 
"release as a service".

I disagree, to me it's a "we as a community vouch to try to maintain this to the 
best of our ability/time".

So [to me] adding more things to KDE Applications needs at least a vague 
consensus that it's worth making that kind of promise.


I think KDE should offer services to apps which want to be part of the
apps bundled release along with making the tars such as recommending
version number, promo, maybe helping out with packaging for Snaps and
Flatpaks and Appimage if there's teams happy to do that.


I think that you are conflating the "help with the release" with the need for
applications to be part of the bundle.

My dream is an automated server-side tarball generation, in a way that
developers can simply ask to release from a specific tag and don't care about
uploading the file to the right place on the incoming ftp/ssh server. But that
service could exist independently from the bundle.


Can we please not turn every discussion about adding, removing, or 
modifying apps in or to the bundle into into a discussion about the 
bundle's nature and future? Every time we do this, it seems like nobody 
can agree on what we should turn it into and nothing changes. If we're 
stuck with the status quo, IMO let's just embrace it and use it.


I support adding things to the bundle that are currently being neglected 
in terms of both development and release resources. Putting them into 
the bundle seems like a good way to improve these things, rather than 
prerequisites to doing it.


Nate

Re: What means having an application in "KDE Applications"

[Nate Graham]

On 6/19/19 3:57 PM, Luigi Toscano wrote:

My point is that that if the main driver for the inclusion is raising the
awareness about a certain project and attracting new developers, given that no
data support this correlation, then maybe the inclusion itself should be
questioned.


While I agree that inclusion doesn't guarantee higher awareness, the 
inverse seems more likely to me, for maintainerless apps at least: with 
no maintainer to request and coordinate releases, apps not in KDE 
Applications don't get released, so their awareness gradually drops to 
zero over time. Inclusion in the KDE Applications bundle may not be a 
panacea, but how else are maintainerless/community-maintained apps 
supposed to get released?


Nate

Re: Tipping the apple cart?

[Nate Graham]

On 7/2/19 3:53 PM, Valorie Zimmerman wrote:
Please lets keep in mind that this is not a thread to complain about 
Gitlab. No platform is perfect, and we're not yet on production machines.


This thread is about how to make our review process great for both 
newbies and experienced developers, *and reviewers* - on Gitlab.


Unfortunately the original topic is intertwined with current GitLab 
deficiencies. The ease of merging patches with one click in the web UI 
is a significant improvement over Phabricator, but from a reviewer & 
project management perspective, I must admit that I have not had a 
pleasant experience with GitLab so far.




For the originally-discussed topic regarding automatically adding 
reviewers to Phabricator patches, it's not even applicable because our 
GitLab instance doesn't have the "Merge Request Reviewers" features. So 
compared to with Phabricator, it is not as clear when a patch is 
actually ready to land or when specific changes are required.


Regarding the topic of how to encourage people to pay more attention to 
submitted patches rather than filtering/deleting/ignoring the 
notification emails, GitLab seems much worse. Like Phabricator, it 
adopts the deficient "one notification per action" approach, rather than 
the far superior GitHub-style "one notification per issue/pull request" 
approach. I also haven't found a way to turn off emails and instead 
receive notifications only via a built-in "notification center" page in 
the website, as I can with both Phabricator and GitHub. As a result, 
when 10 issues or patches on GitLab receive 10 comments each, I get 100 
emails.


This is compounded by the problem of inline comments in patch reviews 
generating one email per comment. For merge requests with many inline 
comments, I get a flood of 10 or 20 emails over a short period of time. 
The email overload problem is therefore worse than it is currently for 
Phabricator projects, and hugely worse than it is for the GitHub-hosted 
projects that I follow.




While we're on the subject of things that impact the patch reviewing 
usability, when an inline comment is marked as resolved, the context 
surrounding it does not change and it continues to show the old diff 
rather than the latest diff, so it's impossible to tell what changes 
were made to mark the comment as resolved. This is also a regression 
compared to Phabricator.


I'm also disappointed by the impending loss of Phabricator Tasks, which 
I use extensively on Phabricator for project planning and tracking. 
GitLab doesn't have a "Task" feature at all, so you need to use Issues 
for developer task discussions. If we ever migrate Bugzilla to GitLab 
Issues, this will result in zero separation between developer 
discussions and user-submitted issues, which will become very 
disruptive. Issue/Kanban Boards are not really a replacement because 
they're just an organized collection of existing Issues. There's only 
one of them per project, they aren't cross-project, and there's nowhere 
you can discuss an overarching goal. I have no idea how I would use 
GitLab to do something like https://phabricator.kde.org/T10891, with its 
task graph and centralized discussion.




And yes, I did bring up all these issues during the initial evaluation 
etherpad document: https://notes.kde.org/p/gitlab-evaluation-notes


I hope these issues can be resolved prior to the full changeover.



Nate

Re: Tipping the apple cart?

[Nate Graham]

Am 01.07.19 um 15:37 schrieb James Ramsay:
Is it primarily the previous discussions so that you can better 
respond directly via email? If so, this proposal to include entire 
discussion thread in email notifications 
(https://gitlab.com/gitlab-org/gitlab-ce/issues/40557) which Zsolt is 
looking at might meet your needs. What do you think?


GitLab does support leaving review comments in bulk rather than one at 
a time but it is currently in the GitLab Premium tier. There is a 
proposal (https://gitlab.com/gitlab-org/gitlab-ce/issues/60690) to 
move it to the Core tier (free, GitLab CE) being considered.


Do you have any other feedback about GitLab? I would be very 
interested to organize a video call to hear any wide ranging thoughts 
on what it would take to make GitLab code review better than 
Phabricator and Reviewboard for your needs if you can spare the time.


Best,
James


Thanks for being willing to engage, James! It's very much appreciated.

Backporting the Merge Request Reviews feature [1] will be a big 
improvement to address email overload and I look forward to that.


In my own trial use of KDE's GitLab instance, the other source of email 
overload is the fact that it sends one email per action, rather than 
offering a web-based notification center capable of batching up 
notifications that all pertain to the same Issue or Merge Request 
(proposed here: [2]).


The problem with the "one email per action" approach is that it 
implicitly assumes a workflow where everyone is sitting at their 
computers all day waiting for emails to come in, and triaging them 
accordingly [3].


This doesn't describe most members of the KDE community. The vast 
majority of KDE contributors are volunteers who can devote a few hours a 
week to the project, and are virtually never sitting in front of a 
computer all day handling KDE-related emails in real time as they come 
in. Even those who can are generally developers who find handling email 
a distraction during periods of time when they're trying to write code. 
We already have a problem with people filtering, auto-deleting, or 
ignoring emails. The more emails people get, the more acute this issue 
becomes.


Some implementation of what's proposed in [3] would be hugely helpful to 
remedy the issue originally described in this thread, and would be a big 
step up from Phabricator rather than a downgrade or side-grade.


Nate


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/60690
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/64183
[3] https://gitlab.com/gitlab-org/gitlab-ce/issues/29488#note_25414909

Re: rekonq to unmaintained

[Nate Graham]

On 9/12/19 3:55 PM, Kevin Kofler wrote:

Harald Sitter wrote:

Its master branch is still kdelibs4, the frameworks branch hasn't seen
any progress in 21 months. Hasn't had a release in years. Very
unmaintained all in all.


And there is also a working, maintained successor (Falkon).

 Kevin Kofler


+1

Nate

Re: KIOFuse in kdereview

[Nate Graham]

+1, this is great stuff.

Nate


On 11/4/19 3:08 PM, Alexander Saoutkin wrote:

Hi everyone,


KIOFuse (https://invent.kde.org/kde/kio-fuse) has been moved to kdereview.


KIOFuse is a project started by Fabian Vogt that allows the possibility 
to mount KIO filesystems in the local system; therefore exposing them to 
POSIX-compliant applications such as Firefox and LibreOffice. KIOSlaves 
are a powerful feature within the KIO framework, allowing KIO-aware 
applications such as Dolphin to interact with services out of the local 
filesystem over URLs such as fish:// and smb://. However, KIO-unaware 
applications are unable to interact seamlessly with KIO Slaves. For 
example, editing a docx file in gdrive:/ in LibreOffice will not save 
changes to your Google Drive seamlessly. KIOExec is one of the fallbacks 
that is used, but is not desirable. One potential solution is to make 
use of FUSE, which is an interface provided by the Linux kernel, which 
allows userspace processes to provide a filesystem which can be mounted 
and accessed by regular applications. KIOFuse is a feature that has been 
requested many times before, case in point this very active 15 year-old 
bugzilla bug report [0] and several reddit threads [1] [2] [3] [4]. The 
project was further developed by me as a GSoC project [5], and both me 
and Fabian are happy to see KIOFuse go through the kdereview process now.



KIOFuse can be used standalone, but there is also work to integrate 
KIOFuse closer with KIO [6], allowing seamless “integration” between the 
two.



Currently, KIOFuse has been tested to work on Linux, although there are 
no technical reasons why it can’t work on FreeBSD. It can potentially 
work on macOS [7], and we’d be happy for people to test this for us if 
there is demand for it. KIOFuse currently uses the low-level libfuse 
API, but there is a Windows-based library that has a compatibility layer 
with the high-level libfuse API [8]. If one would like KIOFuse to work 
on Windows, one could explore the creation of a low-level libfuse API 
compatibility layer; it would probably also require a bit of a refactor 
of the KIOFuse code.



The ideal destination is extragear, due to KIOFuse being written for 
C++17, and frameworks requiring to be compiled on C++11-compliant 
compilers or newer. A move to KF6 in the future could be desirable.



Kind regards,

Alexander Saoutkin (feverfew)


[0]: https://bugs.kde.org/show_bug.cgi?id=75324

[1]: 
https://www.reddit.com/r/kde/comments/a5a0zq/is_kiofuse_ever_going_to_be_a_thing/


[2]: 
https://www.reddit.com/r/kde/comments/9exqqu/imo_everything_about_kde_is_the_best_except_one/


[3]: 
https://www.reddit.com/r/kde/comments/9i3ml8/mpv_does_not_want_to_open_video_files/


[4]: 
https://www.reddit.com/r/kde/comments/77ekkm/plasma_511_review_keep_the_momentum_going/


[5]: 
https://summerofcode.withgoogle.com/archive/2019/projects/4621805883490304/


[6]: https://phabricator.kde.org/D23384

[7]: https://osxfuse.github.io/

[8]: https://github.com/billziss-gh/winfsp

Re: Quick Charts in KDE Review

[Nate Graham]

On 11/7/19 7:34 AM, Friedrich W. H. Kossebau wrote:

Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra:

Hi,

Quick Charts has been moved to KDE review. The intent is to make it a
Tier 1 framework.


Any chance the official name can be "KQuickCharts"? "Quick Charts" is a
generic name which only asks for being misunderstood, is hard to google etc..
  

Quick Charts is a QML module that implements a set of high-performance,
GPU accelerated
charts. Currently the main user of it is a new KSysGuard UI I have been
working on, but
once it is part of Frameworks I also hope to convert several bits of
Plasma to using it.


If there is only one user currently, might it perhaps be a better idea to do
some independent releases for a while to get more feedback on the API, before
settling to the API freeze by being part of KDE Frameworks? It will be at
least a year until KF6 is there to properly fix up any potential API
inconveniences which users might find.
I would at least recommend to first get some API shaping by real-world
exposure.


Seems like a chicken-egg problem: more exposure would be provided by 
getting it through the review process, no? I can see us porting the 
graphs in KInfoCenter to use this, for example. But since that's 
shipping code, we might not want to do that until it's formally a framework.


+1 for making it a framework sooner rather than later.

Nate

Re: Update on Status of Gitlab Migration

[Nate Graham]

On 4/13/20 6:59 PM, Ben Cooksley wrote:

Why do we need to mimic them?

If you Google "KDE Gitlab" then the first hit is invent.kde.org 
.


To flip it around: why do we need to do something different? I don't 
think it's about mimicking anyone else, but rather using the most 
intuitively obvious domain name rather than some arbitrarily different one.


No matter what, we're all going to be talking about "KDE GitLab" or 
"KDE's GitLab instance". The title of the relevant documentation page is 
"GitLab" (much as the Phabricator documentation page was named 
"Phabricator"). And when the migration is complete, we're all going to 
announce that "KDE is now using GitLab!" So the cat's out of the bag on 
using the word "GitLab" and avoiding some number of people looking for 
our stuff at gitlab.com and not finding it there. invent.kde.org doesn't 
avoid that at all.


Given that, which is more confusing: explaining to people that we have a 
GitLab instance at invent.kde.org, or explaining to people that we have 
a GitLab instance at gitlab.kde.org?


I know that over the next few years I'm going to be directing hundreds 
of people towards our infrastructure, and I would rather be able to say 
"please submit a pull request at gitlab.kde.org" rather than "please 
submit a pull request at KDE's GitLab instance at invent.kde.org."


I know this probably feels like annoyingly extreme bikeshedding, but, I 
dunno, names are important.


Nate

Re: Update on Status of Gitlab Migration

[Nate Graham]

On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:

Regarding this: is the subdomain going to stay invent.kde.org once we
have officially moved? I find it's a bit confusing to use that instead
of gitlab.kde.org


I agree. gitlab.kde.org would make more sense to me, mirroring 
phabricator.kde.org.


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 4:38 AM, Aleix Pol wrote:

Does this mean that to clone it we'll have to go "git clone
kde:games/knetwalk" or something along the lines?

If that's the case I'd much prefer if we didn't do this, at the moment
it's already uncomfortable for me to remember the URL for some of the
repos (e.g. is it sysadmin/ or not?), this will only increase the
problem and I personally don't see the advantage.

e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
krita graphics or its own thing?


Trying to categorize everything into a single group cannot succeed 
because many projects could logically belong to multiple groups (e.g 
plasma-framework is a framework that's a part of Plasma; Discover is an 
app that's a part of Plasma; kdenetwork-filesharing and kio-extras are 
libraries that are distributed via the apps release service). I foresee 
endless pointless arguments about the best group for something to live in.


Let's step back: do we have to put every repo inside a group in the 
first place? Is it solely so you can look at a nice list of all open 
merge requests for PIM/Frameworks/etc? If so, perhaps this workflow 
could be approximated with tags instead or group assignments instead


We create many very granular groups for the purposes of organizing teams 
and and performing code review (e.g. Plasma, KWin, Frameworks, PIM, 
Krita, Dolphin, Okular, VDG, etc.) and then every new merge request 
could receive a tag or assignee corresponding to its relevant code 
review groups (e.g. merge requests for kio and kio-extras could get get 
tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs 
could get tagged with both "Plasma" and "Frameworks", and so on).


So +1 for a single top-level group I suppose.

Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde to all)
and then have every subcommunity decide for themselves which repos they want
to see in their group.


If this is possible, it seems like the best solution to me.

Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 7:52 AM, Nate Graham wrote:

On 4/27/20 7:46 AM, Ingo Klöcker wrote:

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.


Great. So we could put all repos into an "all" group (e.g. rename kde 
to all)
and then have every subcommunity decide for themselves which repos 
they want

to see in their group.


If this is possible, it seems like the best solution to me.



I've just been informed that it's possible to have a project appear in 
multiple groups such that I could find plasma-frameworks in both the 
Frameworks and Plasma top-level groups.


Therefore I rescind my objection and endorse having many top-level 
groups instead of a single flat top-level namespace, provided that we do 
put projects that are related to multiple groups into those multiple groups.


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

If I'm understanding things, we have solutions to most or all of the 
objections raised so far:


- Projects will be allowed to live in--or at least appear in--multiple 
top-level groups (e.g. plasma-framework could appear in both the 
Frameworks top-level group and also the Plasma top-level group)


- kdesrc-build and other scripts can be updated to allow people to 
easily check out repos using git prefixes (e.g. so that something like 
`git clone kde:dolphin` will still work regardlyss of a project's 
underlying group)


- cgit will continue to exist for three weeks to provide some transition 
time


- Each repo can have its own workboard in addition to the single 
group-level workboard


If the above are accurate, then I firmly support the proposal.

As for the actual grouping, I think it makes sense to have top-level 
groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can 
support putting apps into category-specific groups (e.g. Multimedia, 
Office, Graphics, Games, etc) as long as apps could appear in multiple 
groups if needed for the case of apps that logically span boundaries 
(e.g. repos for PlaMo apps could appear in both the Plasma Mobile 
top-level group and also the relevant app group).



Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 11:43 AM, Aleix Pol wrote:

IMHO needing tools ad-hoc to KDE development can be a barrier of entrance.
I feel like these things make us look distant, it's important that
people's skills translate automatically when they want to get started.


True, but if you're a new contributor, presumably our infrastructure 
would do the right thing the first time and you wouldn't need to use any 
migration script, right?


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 5:59 PM, Aleix Pol wrote:

El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid

Am I the only person that just has all the repos on the same folder? I thought 
it was the common thing to do :?


I do too


Same here. kdesrc-build's default settings do this, and download all 
repos into ~/kde/src without any of the levels of hierarchy. This would 
seem to require unique repo names, no?


The group categorization we've been discussing may be useful on the web 
UI for newcomers, but it has no value for your source checkout folder 
IMO, where it just makes it slightly more annoying to navigate from one 
repo to another.


Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

Thanks for the clarifications, Ben. Then I think the original proposal 
is perfectly reasonable and I fully support it.


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 11:17 PM, Ben Cooksley wrote:

Not necessarily.

Git allows you to override the name that the local folder is called
when cloning, so there is no reason why we can't specify something in
the metadata to override the local name that the folder gets called in
your local checkout folder.
This would allow for example:

- frameworks/kcoreaddons on Gitlab continues to be called
'kcoreaddons' in your local checkout folder
- maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder

This allows for the URLs on Gitlab to make sense, while simultaneously
allowing your local source checkout folders to continue to work in the
manner in which they do currently.
Note that we do not expect people to hit this in many cases - this is
about giving us the flexibility for the long term without imposing
unnecessary bureaucracy and limits on projects within the KDE
umbrella.

Automated tooling such as kdesrc-build and the proposed clone script
(that searches in namespaces) should be able to handle this without
much issue.
In the case of manually done clones, it is reasonable to expect people
to know what they're doing with their clones, and name them
appropriately in the event they have a collision.

Does this sound acceptable?


A little weird, but probably acceptable. I suppose it's no worse than 
having discover build an executable called "plasma-discover", which 
trips me up like five times a day :)


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 5/1/20 9:02 AM, Johan Ouwerkerk wrote:

No, that is not the default.


Actually, it is: 
https://invent.kde.org/kde/kdesrc-build/-/blob/master/kdesrc-build-setup#L389




and download all
repos into ~/kde/src without any of the levels of hierarchy.



But it is sufficiently common that there is a dedicated setting for
it: `ignore-kde-structure`. Kinda does what it says on the tin ;)


Yes, and this setting is set by default. :)

Nate

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

On 5/1/20 2:09 PM, Ben Cooksley wrote:

Unfortunately sharing of projects/repositories across groups does not
impact on tasks and reviews.
This means that merge requests for Planet (which is currently shared
with "KDE") do not show up in the list of merge requests for "KDE".

Sharing repositories allows for a global listing only.
Are you saying that if we put plasma-framework in Plasma and share it 
with the Plasma group, then its MRs won't show up in the Plasma group's 
MR list? And that if we put it in the Plasma group and share it with the 
Frameworks group, then its MRs won't show up in the Frameworks group's 
MR list?


If so, that seems like it defeats one of the points of sharing a 
project/repo across groups. :(


Is this fixed in EE, or is it just a bug affecting all versions?

Nate

Re: Move Koko to KDEReview

[Nate Graham]

+1, I've been using Koko and find it quite pleasant.

Nate


On 6/9/20 5:30 AM, Carl Schwan wrote:

Hi,

I would like to move Koko, a convergent image viewer, to KDEReview.
Koko is already shipped in the base Plasma mobile image and I was
surprised that it was still in playground. The current devs are mostly
Nicolas, Marco and me.

Koko is following the KDE HIG and is build using QtQuick and the
Kirigami framework.

The repo is located here: https://invent.kde.org/plasma-mobile/koko/.
There is only one know big issue, but it is in the progress of
being resolved[1].

In the future, I plan to add a simple image editor that is currently
being developed as a separate and reusable library. More info about
it is available in my latest blog post[2].

I would be happy if it could be reviewed and my goal is to move it to
the release service, I hope in time for 20.08.

 From the release sanity checklist:

* licensing should be ok (LGPL-2.1-only or LGPL-3.0-only or
LicenseRef-KDE-Accepted-LGPL), but some headers are missing in the
CMake files :/
* A Messages.sh file is missing and help would be welcome to figure
out if Koko need one since translations are regularly being pushed by
scripty.
* Screenshot is missing but I plan to add one before the release.
* CI works and there is a .gitlab-ci.yml file.
* There is an AppStream file.
* There is some documentation on userbase: https://userbase.kde.org/Koko
I plan to also update it before the next release.

Carl Schwan
https://carlschwan.eu

[1]: https://invent.kde.org/plasma-mobile/koko/-/merge_requests/20
[2]: https://carlschwan.eu/2020/06/06/koko-desktop.html

Re: Gitlab Turn-off Issues

[Nate Graham]

On 6/28/20 12:28 PM, Ben Cooksley wrote:

On Mon, Jun 29, 2020 at 4:28 AM Allen Winter  wrote:


Can we remove the Issues feature on all invent projects?
We're starting to see more and more people adding Issues.

For KOrganizer, bshah replaced Issues with Bugzilla.

I very much doubt we want or are ready to replace Bugzilla.


As has been discussed *far too many times* already, we have NO
INTENTION to replace Bugzilla at this stage.
This matter has been discussed on many threads, including on this list
in the past.

Issues on Gitlab is intended to be the replacement for Phabricator Tasks.
Disabling them would leave projects with no developer task management
functionality, which would be highly undesirable as they are heavily
used by a number of projects.

Your request to disable them for all KDE projects is therefore declined.


The problem with this approach is that users familiar with GitHub or 
GitLab in other projects will not stop submitting bug reports using 
GitLab issues as long as it's turned on in its current form, because how 
we're proposing to use GitLab issues does not match the typical usage of 
the feature. I could see this situation being improved if we could 
rename "Issues" to "Developer Tasks" or something like that in the UI, 
and additionally deploy a template to every repo with a warning to 
submit bug reports using Bugzilla.


However the issue (har har) of users submitting bug reports and feature 
requests using GitLab issues is not likely to disappear without some 
kind of change.



Nate

Re: Gitlab Turn-off Issues

[Nate Graham]

On 6/28/20 2:29 PM, Nicolás Alvarez wrote:
> El dom., 28 de jun. de 2020 a la(s) 16:47, Nate Graham (n...@kde.org) 
> escribió:
>>
>> On 6/28/20 12:28 PM, Ben Cooksley wrote:
>>> On Mon, Jun 29, 2020 at 4:28 AM Allen Winter  wrote:
>>>>
>>>> Can we remove the Issues feature on all invent projects?
>>>> We're starting to see more and more people adding Issues.
>>>>
>>>> For KOrganizer, bshah replaced Issues with Bugzilla.
>>>>
>>>> I very much doubt we want or are ready to replace Bugzilla.
>>>
>>> As has been discussed *far too many times* already, we have NO
>>> INTENTION to replace Bugzilla at this stage.
>>> This matter has been discussed on many threads, including on this list
>>> in the past.
>>>
>>> Issues on Gitlab is intended to be the replacement for Phabricator Tasks.
>>> Disabling them would leave projects with no developer task management
>>> functionality, which would be highly undesirable as they are heavily
>>> used by a number of projects.
>>>
>>> Your request to disable them for all KDE projects is therefore declined.
>>
>> The problem with this approach is that users familiar with GitHub or
>> GitLab in other projects will not stop submitting bug reports using
>> GitLab issues as long as it's turned on in its current form
> 
> Hmm... Users familiar with GitHub in other projects will not stop
> submitting pull requests on the KDE GitHub mirror as long as that's
> turned on, and GitHub doesn't even let us turn off pull requests.
> Should we get rid of the GitHub mirror? Or should we keep closing pull
> requests and telling people to send their patches to Invent instead?
> (This is only half-rhetoric, I actually wouldn't mind getting rid of
> the GitHub mirror :P)

Personally I wouldn't object, if we really can't turn off the pull 
request feature. I don't see what the GitHub mirror is accomplishing, 
other than confusing potential new contributors and wasting the time of 
actual contributors who have to perform maintenance and close pull requests.

>> However the issue (har har) of users submitting bug reports and feature
>> requests using GitLab issues is not likely to disappear without some
>> kind of change.
> 
> We can't easily change the label of the sidebar button. But what about
> a banner like this:
> https://invent.kde.org/games/kbounce/-/issues/new
> 
> Do you think this would help?

Yes, I think it definitely would! Could we also customize the banner 
per-project so that it pointed to the correct Bugzilla URL for that project?
That would be rad.

Nate

Re: KDEReview for Kontrast

[Nate Graham]

Hello Carl,
This looks very useful! Overall I'd say the UI is good. One thing I find 
myself missing while playing around is the ability to test system 
colorschemes though. That would be a really nice addition.


Nate


On 7/30/20 3:16 AM, Carl Schwan wrote:

Hi,
I would like to move Kontrast, a contrast checker application, to KDEReview. 
Kontrast can check if two colors pass the WCAG 2.0 specification and save some 
user's favorite color combinations.

Some screenshots of the application and a design review from the VSG is 
available here: https://invent.kde.org/accessibility/kontrast/-/issues/1

 From a code point of view, the application is very simple, but I still would 
appreciate a general code review on it (it's my first Qt app written from 
scratch). The code is available here: 
https://invent.kde.org/accessibility/kontrast

I don't plan to add new features and would like after the KDEReview, to release 
a first version of the application, and then move it to the release service so 
that the application gets regularly translations improvement.

Thanks
Carl

Re: KDEReview for Kontrast

[Nate Graham]

On 8/2/20 8:29 PM, Carl Schwan wrote:

Le dimanche, août 2, 2020 2:58 PM, Nate Graham  a écrit :


Hello Carl,
This looks very useful! Overall I'd say the UI is good. One thing I find
myself missing while playing around is the ability to test system
colorschemes though. That would be a really nice addition.


I'm not sure this feature would make sense in Kontrast, but maybe this
functionality should be integrated into the new color scheme editor Noah
is building. The actual logic for calculating the contrast is very small.

What do you think?


Yeah that could work!

Nate

Re: Git merge workflow: reverse it?

[Nate Graham]

FWIW I'm a +1 too. Having done both, I solidly prefer the cherry-pick 
workflow. It's so much less error-prone, and you don't need to deal with 
the hassle of switching branch targets and rebasing prior to merging.


Nate



On 8/14/20 2:31 PM, Johan Ouwerkerk wrote:

On Mon, Aug 3, 2020 at 11:50 PM Albert Astals Cid  wrote:


El dimecres, 29 de juliol de 2020, a les 14:01:07 CEST, Bhushan Shah va 
escriure:

At plasma, we are experimenting with new workflow regarding how bugfixes
are put on the stable branch [1].

# Current workflow

- Proposed workflow is to instead commit all changes in master, and
   cherry-pick related changes in the stable branch as needed
- We had been using this workflow for about 1 month now and I'd say it
   is working nicely for us.



The conflicts are still going to be there, if your change has conflicts going 
up, it'll have conflicts going down.



I guess it's mostly about who is doing the merging and committing in
this: the hopefully more seasoned people who know the code well
because they've been maintaining it for a while or the casual
contributor who might not be fully aware of what master might have
moved away from that is still in stable (or the reverse).

It might also be slightly easier to realise that it turns out you have
to backport a bit more, than it is to future proof your code coming
from the deep past to minimise the merge conflicts, as it were.



One improvement I think you didn't mention is:
  - "Non-core" people don't know what's the stable branch. I see that in Okular, most 
drive-by Merge Requests are against master, because that's the easy thing to do, for a 
"newbie" it's hard to figure out if something should go to the stable branch or not (is 
it a bugfix? a feature?), and if so, which is the stable branch if there's one, etc.



I think this one thing alone is the main reason to just do it. People
who maintain stable branches know what they signed up for and
generally have a pretty good understanding of what they're doing. Even
seasoned KDE contributors are going to find a workflow with a single
target branch (always master) to be slightly easier to remember than
"whatever the stable branch happens to be".


Proposal is to probably adapt this policy kde-wise if people feel that
advantages are worth it.


I'd lean towards +1

Regards,

- Johan

Re: Announcing MyKDE

[Nate Graham]

Super cool stuff! Great work, Carl.

Nate



On 10/3/20 3:56 AM, Carl Schwan wrote:

Hello folks,
I'm happy to announce the successful deployment of the new identity system
in KDE, codename MyKDE. The new identity system is now available in
https://my.kde.org. You should be able to login into the my.kde.org website
with your normal KDE credential.

For the moment, only the wikis are using MyKDE but in the comming months
this should change with more and more services switching to MyKDE. I will
let you all know of the progress of the migration.


FAQ:


Why the move?
-

identity.kde.org is using OpenLDAP for user management with a small PHP
frontend allowing the account creation. And we had the following problems
with it:

* Account removal is hard, requiring significant manual intervention and
effort (several hours work in some instances)
* Account registration takes 30 seconds or more to complete, creating a poor
user experience
* Groups don't scale effectively
* Anti-spam measures are too crude

More on that in https://phabricator.kde.org/T8449

Will my data be migrated?
-

Yes, your data are migrated just by login into MyKDE once. This will migrate
all your group membership (KDE developer, Akademy Team, ...), personal
data and password.

For users who didn't log into MyKDE during the migration period. If you are
a KDE developer or KDE e.V. member, your account will be imported as a
disabled account and you will need to ask sysadmins to enabled it. For the
rest of the users of identity.kde.org who don't have a membership to groups,
your account will be removed. We think this is the best solution because there
is no need to store personal information that we don't need from users who
don't use the system anymore. If you want to conserve your account (and
username), please log at least once. We will send periodic emails reminding
you of migrating your account.

How do I register a new account in MyKDE?
-

For the moment the possibility of registering a new account is disabled in
MyKDE and the only possibility is to create an identity.kde.org account and
then migrate your account. This is due to the fact we don't want some
accounts existing only in MyKDE. This will naturally change when we migrate
fully to MyKDE.

How to I collect a badge?
-

MyKDE has the possibility to grant badges to users. For the moment there is
only one badge enabled: KDE developer. This badge is given to every KDE
developer and is displayed on their public profile (if enabled). When the
new Season of KDE website will be deployed, it will be also possible to have
an SoK mentor and SoK mentee badge.

I'm interested in ideas of new badges (and badge designs), so please let me
know if you have a genius idea that doesn't gamify KDE contribution (e.g no made
100/1000/10 000 commits badge).

Note that you are in control of that badge get displayed.

What is the public profile functionality?
-

One of the new features of MyKDE is the possibility to have a public profile.
This public profile is opt-in, so you need to explicitly enable it to make
it work and it can display a small bio, your avatar, name, username, social
network account, Liberapay account, and badges earned.

This is for example how it looks for me: https://my.kde.org/user/carlschwan/

Can I contribute to MyKDE?
--

Yes, the source code is hosted in https://invent.kde.org/websites/my-kde-org
and all the deployment information can be found here:
https://sysadmin-docs.kde.org/services/mykde.html

Cheers,
Carl Schwan
https://carlschwan.eu

Re: Windows CI Updated to Qt 5.15 - Temporarily KO due to Breeze Icons Breakage

[Nate Graham]

We are trying to fix the test failure. See 
https://invent.kde.org/frameworks/breeze-icons/-/commit/8fce580335ef86f19df2238f00270820ac74c9f4#note_115164 
for the current status.


Or was the regression caused by something else?

Nate



On 10/6/20 3:59 AM, Ben Cooksley wrote:

Hi all,

This evening i've completed updates to the Windows CI system, bringing 
it from the previous Qt 5.14 setup it was using up to the more recent Qt 
5.15. As part of this various other libraries will have also been updated.


This update was prompted by an unannounced dependency change within 
Breeze Icons. As a reminder to all developers, it is imperative that any 
change to your dependencies on a non-KDE project be announced two weeks 
or more in advance.


Unfortunately due to regressions within Breeze Icons, it is not possible 
for the Dependency Builds to complete at this time, meaning Windows CI 
functionality will be generally unavailable until this is corrected.


The failure log can be found at 
https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20WindowsMSVCQt5.15/lastFailedBuild/console


Once the Breeze Icons failure has been corrected, we expect to be able 
to resume normal CI service for Windows.


Regards,
Ben Cooksley
KDE Sysadmin

Re: Windows CI Updated to Qt 5.15 - Temporarily KO due to Breeze Icons Breakage

[Nate Graham]

Noah, could yo take a look? Seems related to porting the autogenerated 
24px icon script to Python.


Nate


On 10/6/20 11:26 AM, Ben Cooksley wrote:
On Wed, Oct 7, 2020 at 4:49 AM Nate Graham <mailto:n...@kde.org>> wrote:


We are trying to fix the test failure. See

https://invent.kde.org/frameworks/breeze-icons/-/commit/8fce580335ef86f19df2238f00270820ac74c9f4#note_115164

for the current status.


This is a complete build failure, rather than just a test failure - as 
noted in the log above.


I'm not sure what the script in question is trying to achieve though?


Or was the regression caused by something else?

Nate


Cheers,
Ben




On 10/6/20 3:59 AM, Ben Cooksley wrote:
 > Hi all,
 >
 > This evening i've completed updates to the Windows CI system,
bringing
 > it from the previous Qt 5.14 setup it was using up to the more
recent Qt
 > 5.15. As part of this various other libraries will have also been
updated.
 >
 > This update was prompted by an unannounced dependency change within
 > Breeze Icons. As a reminder to all developers, it is imperative
that any
 > change to your dependencies on a non-KDE project be announced two
weeks
 > or more in advance.
 >
 > Unfortunately due to regressions within Breeze Icons, it is not
possible
 > for the Dependency Builds to complete at this time, meaning
Windows CI
 > functionality will be generally unavailable until this is corrected.
 >
 > The failure log can be found at
 >

https://build.kde.org/job/Administration/job/Dependency%20Build%20Extragear%20stable-kf5-qt5%20WindowsMSVCQt5.15/lastFailedBuild/console
 >
 > Once the Breeze Icons failure has been corrected, we expect to be
able
 > to resume normal CI service for Windows.
 >
 > Regards,
 > Ben Cooksley
 > KDE Sysadmin

Re: Retiring

[Nate Graham]

On 1/13/21 1:57 PM, Christoph Feck wrote:

Hello developers,

my personal situation allows for much less time for KDE
related work, at least during the Corona times.

I would like to retire as soon as possible from these
responsibilities:
- bug triaging
- release service
- KIconTheme maintainer
- KPlotting maintainer
- KWidgetAddons maintainer

For bugzilla, I see many new and old contributors doing awesome
work with triaging, so departing here shouldn't be a big issue.
I hope someone can continue checking responses to NEEDINFO bugs
and REPORTED bugs that didn't get a reply within about two weeks.

Regarding the release service work, I have made sure the load
isn't all back to Albert. For future release work, Heiko Becker
volunteered to help, but maybe another hand would be awesome, too.

For the frameworks modules, I initially assumed each module
must have a separate maintainer, so I volunteered. Today I
see many modules still just community-maintained, and I hope
the community can take over maintainance. Not that I did any
relevant work here in the recent years...

I might eventually continue to prepare some patches, so please
keep all my accounts intact, but only de-list me as the maintainer.


Thank you very much Christoph for your tireless work for KDE. I have 
learned a great deal from you, and I hope my bug triaging efforts are 
able to compare with yours!


Nate

Re: Koko in KDEReview

[Nate Graham]

On 3/13/21 4:22 PM, Albert Astals Cid wrote:

I would really like if we had a kxmlgui equivalent for QtQuick that gave me the 
"configure shortcuts" and stuff functionality, but that's unrelated to koko :)


+100

See also https://phabricator.kde.org/T13770

Nate

Re: Is there (going to be) an auto-retracer service for KDE?

[Nate Graham]

Hello Lyubomir,

Automatic symbolication services are great, but they need to be run by 
distros, because distros are the ones who build their own binaries.


The problem with apport is that it reports bugs to Ubuntu, not to us. 
Some of these bug reports get forwarded to us, but most don't. As a 
result they mostly don't help us. Our own crash reporting tool is 
generic and cross-distro, but as a consequence, it isn't hooked into 
distro-specific remote symbolication services. It does however have 
facilities to automatically fetch symbols when needed. Sometimes this 
doesn't work as well as it should, but the feature is there.


Nate


On 4/25/21 3:55 PM, Lyubomir Parvanov wrote:
I'm not much into KDE bug reporting and also not much into Apport. I'm 
simply a user.


However, what i know is that as a previous Gnome user i never saw a 
"Gnome reporter" piece of software. As a KDE user now I frequently see 
the specific "KDE bug reporter" piece of software, and it never ever 
reported a crash because it misses symbols. I know that Linux users are 
supposed to know their way around the terminal, but still...


Also I know that as KDE developers you can register at 
https://errors.ubuntu.com/  via the form.
I also know about THIS  video which 
although it is old is still relevant.


KDE doesn't run only on Ubuntu and Apport might be an Ubuntu software, 
but surely it can be configured by default to be used on Ubuntu, can't it?


This thread was meant as a question and/or discussion, mainly fuelled by 
my thoughts and experiences with Apport which seems to be a more 
convenient way of error collection.

Re: Kirigami Addons in KDEReview

[Nate Graham]

On 4/30/21 7:51 AM, Carl Schwan wrote:

Hello folks,

I would like to put request a KDE review on the Kirigami Addons
project. This repository contains for the moment 2 plugins:

* A TreeView for QML: this is maintained by Marco and provides
a QML tree view using KItemModels::KDescendantsProxyModel. A copy
of this is already in use in the Plasma System Monitor.

* A DateTime collections of elements: this is maintained by both
me and David Edmundson and provides a date picker, a month view
for calendars and a time picker.

More plugins might be added in the future to allow to share basic
visual components between kirigami applications without putting
too much random stuff in Kirigami or adding dependencies to
Kirigami.

You can find a link to the repo here: 
https://invent.kde.org/libraries/kirigami-addons/

Regards
Carl Schwan
https://carlschwan.eu





I would like to see 
https://invent.kde.org/libraries/kirigami-addons/-/issues/2 fixed first 
as the date picker is sort of almost unusable right now.


Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/3/21 4:21 PM, Albert Astals Cid wrote:

El dimarts, 4 de maig de 2021, a les 0:07:19 (CEST), Carl Schwan va escriure:

Le lundi, mai 3, 2021 4:35 PM, Harald Sitter  a écrit :


On 23.04.21 01:00, Carl Schwan wrote:

Would you be open to an MR adding GitLab support to DrKonqi?


We don't use gitlab for user bug reports.


A bunch of KDE projects already do, in fact--such as NeoChat, all the 
Maui apps and its framework, and most (all?) of the PlaMo apps. You 
can't fight the tide forever.


One of the objections to using GitLab issues is a lack of DrKonqi 
support, so adding that support seems perfectly reasonable to me. This 
is a blocker anyway for any a coordinated migration of everything to 
GitLab issues.


Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/3/21 4:44 PM, Albert Astals Cid wrote:

El dimarts, 4 de maig de 2021, a les 0:36:57 (CEST), Carl Schwan va escriure:
"The project stays true to established practices"

The established practice in KDE is clearly using bugzilla for bugs.


Sure, but if we never investigated alternatives and stuck our heads in 
the sand when superior ones appeared, we'd be stuck in the technological 
stone age.


I spend at least 4 hours a day on bugs.kde.org--triaging bugs, moving 
them around, renaming them, commenting on them, fixing them, performing 
admin maintenance, and so on. The user experience is atrocious. The 
developer experience is atrocious. The upstream product is dead and 
development has ceased. I strongly believe that we need to make plans to 
migrate away from it. This is an opinion that will come to resemble a 
fact more and more as time goes on.


It's not my personal preference for individual projects to use GitLab 
Issues rather than Bugzilla; I'd prefer a coordinated migration. But I 
think that trying to fight against its use is a total waste of 
everyone's time. The migration is going to happen one way or another, be 
it piecemeal or coordinated--and it's time we admitted this and made 
technical and organizational plans to support using and moving to GitLab 
issues rather than pretending that we can stay with a dead product that 
nobody likes forever.


We have discovered one such blocker: DrKonqi support. I say let's add 
that so we can proceed with more productive lines of discussion.



Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/4/21 1:16 AM, Harald Sitter wrote:

Every time the bugz vs gitlab schism comes up I eventually tune out with
the distinct feeling that there is strong opposition to moving. What I,
what we all, do not want is to end up with two systems that require us
to maintain two client libraries with double the bugs for the next 10
years, and everyone gets to roll a dice which platform a given product
tracks bugs on. So what we need is community agreement which BTS to use
long term and then we can drive the technical changes to make that happen.

Short to mid term bugz is the reality we have to live with.


There is policy, and there is reality. Policy is not self-enforcing, and 
if it attempts to prescribe a reality too different from the actual one, 
it breaks and looks somewhat silly.


Since we have no way of actually *disabling* the Issues feature in our 
GitLab instance, certain projects are inevitably going to start using it 
despite all the policy we can come up with. Why? Because it's generally 
better for most of the things that most of us care about (it does not 
have to better for literally everything to still be a net win) . I don't 
see anyone really trying to argue otherwise.


Therefore, I think we need to re-focus the conversation towards "how do 
we migrate to GitLab issues in a coordinated and supported manner." This 
was supposed to be a big advantage of GitLab, yet we're not embracing it 
it despite clear demand from within the community.


Another thing: If we had a clear migration plan and roadmap, it would be 
an easier sell to tell new projects whose owners are accustomed to a 
better bug management UX, "You have to use Bugzilla for now, but we'll 
be able to use GitLab issues in X months."


Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/4/21 8:10 AM, Harald Sitter wrote:> Sure, I suppose, I mean, not 
this conservation, this conversation was

about koko and how it needs crash tracking because quite clearly there's
opportunity for crashing. The reality right here right now is that
drkonqi only sports bugz support and will not gain gitlab support until
at least October. Which is why I said that this is the reality we live
in short to mid term.


Sure, granted.

Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/4/21 7:50 AM, Halla Rempt wrote:

On Tuesday, 4 May 2021 15:28:30 CEST Nate Graham wrote:

I don't see anyone really trying to argue otherwise.


I have certainly made that argument many times. Since only developers can add 
tags, it will be impossible for ordinary users to provide enough information to 
classify the bug. Tagging systems suck big-time. Looking it GIMP's gitlab 
issues shows that not even the OS is reliably tagged!



Again, my point was not that everything about GLI is universally better 
than everything about BZ. Just that most things are mostly better in 
most ways that most of us care about. I'll acknowledge that some things 
are worse. But GLI is at least developed upstream so there is the 
possibility of improvement. With BZ, not so much.


---

FWIW I think it might make more sense to put information like the OS in 
the issue text itself--encouraged via a bug reporting template--than it 
is to use tags for that. In GLI, you can edit comments and even the 
original text, so anything that's missing can be added later, unlike in 
BZ. This mutability in GLI reduces the need for dedicated mutable text 
fields and comboboxes for this that and the other thing, the way BZ has. 
It's all kind of a workaround for the fact that you can't edit the 
original text of the bug report in BZ.


However those are implementation details we can probably hash out later.


Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/4/21 8:54 AM, Halla Rempt wrote:

On Tuesday, 4 May 2021 16:26:22 CEST Nate Graham wrote:


Again, my point was not that everything about GLI is universally better
than everything about BZ. Just that most things are mostly better in
most ways that most of us care about.


List them? I cannot think of a single thing that's good...


* Far simpler interface means that it's harder to get confused and 
accidentally add information in the wrong place
* Inline images makes it much easier to describe a bug visually compared 
to BZ where images are attachments that you have to go out of your way 
to view in another tab or whatever
* Being able to edit the text allows for the correction of typos and 
adding additional information rather than useless extra comments
* Mentioning an issue in another issue automatically creates a link to 
it, rendering the "See also" feature of BZ obsolete and removing the 
manual chore of having to manually link issues
* Tighter integration with the GitLab Merge Request feature without the 
need for a fragile bot

* Tighter integration with other GitLab features such as milestones
* Many more "closes X" keywords are accepted, reducing the chance that a 
merge request will try to close a bug report on merge but fail due to 
not getting the syntax quite right

* Per-project templates
* One fewer dedicated service for our overstretched sysadmins to host
* Responsive upstream
* Possibility of improvements over time

I could go on for longer if you want, but this is just what I came up 
with after a few moments of thinking about it. I won't pretend that GLI 
is perfect, and there are unresolved questions regarding how we would 
handle something like the "plasmashell" product that aggregates bug 
reports for user-facing components that live in many different repos. 
The search is less powerful too (though much faster). But let's all try 
to have an open mind. I don't think we'll get anywhere if anyone says, 
"no way, no how, never ever, over my dead body."


Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/4/21 12:57 PM, Alexander Semke wrote:

Jira can do all of this, except of the tight integration with GitLab out of
the box maybe, and even more. I'm heavily using Jira at work on the daily base
and it's a very reliable and feature-rich tool for project management and
issue tracking. Many open source communities are using Jira, also Qt.

If we try to have an open mind and are also ok with closed source software
that is offering its service for open source projects, should we consider Jira
as well?

https://www.atlassian.com/software/views/open-source-license-request


I don't think we can consider that kind of thing, or else we would be 
using GitLab EE (which is offered for free to FOSS projects) rather than 
GitLab CE.


FWIW I used Jira a lot professionally before my KDE days and am not a 
big fan of it. My experience with it was that it was slow, confusing, 
buggy, and ate my text a lot. Maybe it's better now, I dunno.


Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/4/21 1:23 PM, Ben Cooksley wrote:
Side note here: It is actually possible to disable issues on Gitlab 
projects.


Given that developers generally need a way to collaborate amongst 
themselves (as Phabricator tasks are used for) we leave the feature 
enabled however and generally don't allow for it to be disabled.


The fact that Phabricator is still up and running makes me think that we 
should absolutely close down GitLab issues so that we don't have 
confusion regarding where to discuss things. If GitLab issues are 
intended to be used as the replacement for Phabricator tasks, I think 
that has to wait until Phabricator is actually replaced and all the 
existing tasks migrated. Otherwise we run into the exact same problem 
that people are objecting to here: conversations happening in two 
places, on divergent, non-integrated pieces of infrastructure. If we're 
gonna migrate, we gotta actually migrate.



Nate

Re: Koko in KDEReview

[Nate Graham]

On 5/5/21 6:41 AM, Harald Sitter wrote:

On 04.05.21 17:53, Carl Schwan wrote:
Side note: this isn't a special need TBH ;)
Pretty much everyone has that need. So much so that I kind of have a
general game plan that there ought to be a kbugreport utility which is
able to gobble up all the very specific data $product needs through
scripts or something and either attaches the data to an existing report
or files a new one. Cause a filing template also only gets you so far  +
for the causal user it's still a fairly meh experience.


I am super duper in favor of this and I think it's a great idea. VDG has 
some mockups for a desktop bug filing app, in fact. We'd love to share 
them with you if you pop by in the chatroom (#kde-vdg).


Nate

Re: KInit - how to contribute patches

[Nate Graham]

Hello Sandeep,

Thank you for wanting to contribute!

See https://community.kde.org/Infrastructure/GitLab to learn how to 
submit merge requests.


Nate


On 9/13/21 5:53 AM, Sandeep wrote:

Hello,

I found some bugs in kinit , for which I'd like to contribute a patch.
I tried using invent.kde.org , but there's no facility for submitting
a merge request, and it doesn't allow me to fork a repository. Let me
know how to proceed.

Yours sincerely,
Sandeep

Re: Towards Excellent Defect Management

[Nate Graham]

On 9/14/21 11:43, Julian / xyquadrat wrote:
Most of Sentry is licensed under the BSL (Business Source License), 
which prohibits using the software to create your own commercial service 
providing "Application Monitoring Services" 
(https://github.com/getsentry/sentry/blob/master/LICENSE).
This is not an OSI-approved license. The issue whether such a license 
would be acceptable to use in KDE infrastructure has come up a few 
months back, in the thread "is a BSL licensed service acceptable for 
sysadminy use cases?" which was started on the 26.05 
(https://marc.info/?t=16220380561&r=1&w=2). There was no real 
conclusion in the thread.


Personally I'd be fine with BSL, since for all purposes of KDE, it is 
indeed free software,


That's more or less my opinion on the matter.


Nate

Re: State of server-side retrace of KDE crashes?

[Nate Graham]

For what it's worth, I don't think server-wise retracing is solely a 
workaround for distro-specific issues. Even for distros that ship debug 
symbols, I often find in my bug triaging that it can be a challenge to 
get users to actually use them.


The DrKonqi auto-symbol-downloader sometimes doesn't work (a bug that 
should be fixed, of course), and also when people file a crash reports 
manually and remember to submit a backtrace, they need to install the 
debug packages manually too, which they often forget or don't know how 
to do. As a result, I still have to ask for them to try again after 
reinstalling debug packages manually a lot.


Nate



On 12/19/21 11:47, Ahmad Samir wrote:

On 19/12/21 20:26, Antonio Rojas wrote:
El domingo, 19 de diciembre de 2021 17:27:52 (CET), Kevin Kofler 
escribió:


PS: Those major distributions have had this sorted out for a couple 
years

already. I really do not understand why it is such a problem
for Arch to get
this working. The current situation is a pain for everyone. I cannot
reasonably do any debugging on my PinePhone running Manjaro ARM. Even 
the

limited debugging support in the form of prebuilt rebuilds of GTK and Qt
with debugging information is available only for x86_64.


Because, unlike those other "major distributions", Arch infrastructure 
and

packaging work relies entirely on volunteers in their free time. And the
commercially-oriented derivatives that take advantage of this work 
(such as

the one you mention) do not ever contribute back.



As usual, "open-source, if you want something done, do it yourself, or 
send patches."


Regards,
Ahmad Samir

Reviewing the process for giving people commit rights

[Nate Graham]

Hello folks,

When someone is proposed to get commit access, currently a sponsor 
proposes it, the intended recipient contacts sysadmin, sysadmin reviews, 
and then asks the sponsor if it's okay. This process essentially only 
allows for sysadmin review, since the sponsor has already implicitly 
approved by virtue of being the sponsor.


This caused a problem recently in KWin. A new contributor was given 
commit rights very soon after he appeared, and then immediately after 
that, he inappropriately merged a not-fully-reviewed an un-accepted 
merge request 
(https://invent.kde.org/plasma/kwin/-/merge_requests/1980). It seems 
that he did not have a sense of the cultural norms around committing to 
KDE repos, and giving him commit access was probably premature.


I'd like to propose that we need to make the commit access review 
process open to review by more people so that we can flag issues like 
this sooner. Maybe kde-core-devel?


Nate

Re: Reviewing the process for giving people commit rights

[Nate Graham]

On 4/1/22 09:36, Nicolas Fella wrote:

I think this case shows more a lack of communication towards the person
in question what rights and responsibilities come with commit access
rather than a problem with the current review process. In other words,
other reviewers would likely not have prevented what has happened.


If I had seen a review request to give this person commit access, I 
would have objected on the basis that he only had one merged patch and 
had just appeared very recently. It takes time in a community to learn 
that community's social etiquette.


Nate

Re: Reviewing the process for giving people commit rights

[Nate Graham]

On 4/1/22 09:52, Ivan Čukić wrote:

On Friday, 1 April 2022 17:36:50 CEST Nicolas Fella wrote:

To summarize: I don't see a need to change how applications are


+1

One of the things I saw as a mark of a welcoming and trusting community
when I joined KDE was that everyone had direct push access to trunk
(good old SVN).


I agree, and I'm not proposing that we stop giving trustworthy people 
global commit access. I'm saying that we should do more review regarding 
who we give this access to and how long they've been in the community 
for, because it is quite a big privilege.


Nate

Re: Git merge workflow: reverse it?

[Nate Graham]

On 5/10/22 04:15, Ingo Klöcker wrote:

https://manifesto.kde.org/commitments/


I don't see anything in there that would force the same merge workflow on all
KDE projects. In my view the merge workflow is comparable to the coding style.

Regards,
Ingo


I don't think anyone is trying to force anything; rather, the proposal 
is to get voluntary consensus around standardizing on a single workflow 
(whatever it is) so that we all individually reap the benefits of 
consistency by not having to remember two workflows, look up which 
workflow a project uses, etc.


Personally I don't care which one we standardize on, but I am in favor 
of voluntarily and communally standardizing on one of them.


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

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: 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

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?

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: 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: 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/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/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/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: 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]

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]

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]

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

Nate



On 10/6/22 02:13, Nate Graham wrote:
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]

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]

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]

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]

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]

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: 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: 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: 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: KWeather

[Nate Graham]

Thanks, I'm happy with the UI now! 👍 Really great app.

Nate

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 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 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]

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: 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: 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: 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: 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: 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: 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: 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: 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

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: 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: "Logout Screen" only shows shutdown when pressing the power button

[Nate Graham]

This was an intentional change in Plasma 6.1: now, if you choose shut 
down, restart, or log out, you're taken to a confirmation screen showing 
only the thing you asked for plus a cancel button, so it's more of a 
confirmation screen. If instead you'd actually like to see all options, 
you'll want to use the "show logout screen" action/shortcut/button etc. 
instead.


Nate


On 7/14/24 5:21 PM, Michael Reeves wrote:
Just noticed I am only getting shutdown as an option when pressing the 
power button. This is not acceptable any more then just having skip 
directly  to shutdown. I choose to be presented with the log out dialog 
because I want a choose of actions not a timer on the shutdown or else. 
This is likely some sort of configuration change that I am not aware of.

Re: "Logout Screen" only shows shutdown when pressing the power button

[Nate Graham]

That's not what's supposed to be happening, and it's working for me: if 
I select "Show logout screen" for the "when power button pressed" 
combobox, I see the screen with all options when I press the power button.


Make sure you have this selected for all power states if your device has 
a battery.


If that's not working for you, it sounds like there's a bug, so I would 
recommend opening a bu report about it.


Nate




On 7/14/24 6:11 PM, Michael Reeves wrote:
That's want i have selected in "Energy Saver" 6.1 ignores this setting 
and treats as a shutdown with confirmation.


On Sun, Jul 14, 2024 at 5:24 PM Nate Graham <mailto:n...@kde.org>> wrote:


This was an intentional change in Plasma 6.1: now, if you choose shut
down, restart, or log out, you're taken to a confirmation screen
showing
only the thing you asked for plus a cancel button, so it's more of a
confirmation screen. If instead you'd actually like to see all options,
you'll want to use the "show logout screen" action/shortcut/button etc.
instead.

Nate


On 7/14/24 5:21 PM, Michael Reeves wrote:
 > Just noticed I am only getting shutdown as an option when
pressing the
 > power button. This is not acceptable any more then just having skip
 > directly  to shutdown. I choose to be presented with the log out
dialog
 > because I want a choose of actions not a timer on the shutdown or
else.
 > This is likely some sort of configuration change that I am not
aware of.