Re: print-manager and wacomtablet to Plasma

[Albert Astals Cid]

El dimecres, 1 de novembre de 2023, a les 1:10:55 (CET), Nate Graham va 
escriure:
> On 10/31/23 17:28, Nicolas Fella wrote:
> > On 10/31/23 23:23, Albert Astals Cid wrote:
> >> El dimarts, 31 d’octubre de 2023, a les 20:43:47 (CET), Jonathan
> >> Riddell va
> >> 
> >> escriure:
> >>> As discuccsed in Plasma meeting and just now with KDE gear release
> >>> spods,
> >>> Plasma would like to take over releases of print-manager and
> >>> wacomtablet.
> >>> This means renumbering the tars from e.g. 23.08 to 5.80.0.
> >>> 
> >>> Any issues?
> >> 
> >> What's the rationale for such move?
> > 
> > See https://mail.kde.org/pipermail/release-team/2023-June/013081.html
> > where I originally brought up the topic
> > 
> > partly it's not relevant any more since we settled on releasing Plasma
> > and Gear together this time. The point about these being effectively
> > tied to Plasma still stands, and as such releasing them together makes
> > sense, for example because it makes it easier to deal with changes in
> > their interaction with Plasma
> 
> Yes, the idea is to move into Plasma the things that really only make
> sense to use *in* Plasma. 

It's true that print-manager is mainly a plasmoid/kded/kcm so if Plasma folks 
want to adopt it, I'm not against it, please propose a MR like 
https://invent.kde.org/sysadmin/release-tools/-/merge_requests/39/diffs
(but in reverse)

> Having such software follow the Plasma release
> schedule prevents the problem of unsynchronized changes due to differing
> release schedules, which bit us multiple times during the Plasma 5 cycle.

That's not a good reason, Plasma developers need to remember that there's 
third party applications out there that may also want to tightly integrate 
with Plasma, so any breaking change that may affect print-manager or whatever 
other non-shipped-by-Plasma software should not be happening.

Cheers,
  Albert

> 
> Nate

Re: print-manager and wacomtablet to Plasma

[Albert Astals Cid]

El dimarts, 31 d’octubre de 2023, a les 20:43:47 (CET), Jonathan Riddell va 
escriure:
> As discuccsed in Plasma meeting and just now with KDE gear release spods,
> Plasma would like to take over releases of print-manager and wacomtablet.
> This means renumbering the tars from e.g. 23.08 to 5.80.0.
> 
> Any issues?

What's the rationale for such move?

Cheers,
  Albert

> 
> Jonathan

Re: Frameworks / Plasma/ Gear Release Schedule Plan

[Albert Astals Cid]

El diumenge, 10 de setembre de 2023, a les 19:50:48 (CEST), 
christ...@cullmann.io va escriure:
> On 2023-09-09 13:57, Luigi Toscano wrote:
>  Hi,
>  
>  yes, good point.
>  
>  Just a technical question: if we do this after that period, what is
>  the process to do it for an application belonging to Gear?
>  
>  Will it just be sufficient e.g. for Kate to drop the Qt 5 variants
>  in
>  
>  https://invent.kde.org/utilities/kate/-/blob/master/.kde-ci.yml?ref_typ
>  e=hea ds
>  
>  and
>  
>  https://invent.kde.org/utilities/kate/-/blob/master/.gitlab-ci.yml?ref_
>  type= heads
>  
>  and require KF 6 + Qt 6 in the CMake files or is there additional
>  stuff
>  that
>  needs updates to avoids one breaks stuff?
> >>> 
> >>> My guess is what you are describing plus updating things in
> >>> repo-metadata, i
> >>> can think of
> >>> 
> >>> dependencies/logical-module-structure
> >>>   to update the branch info (i.e. kf5-qt5 won't be master anymore, i
> >>> guess
> >>> point it to the latest stable branch)
> >>> 
> >>> dependencies/dependency-data-kf6-qt6
> >>>   to update the dependency info
> >>>   But this is autogenerated by Nico scripts nowadays so... maybe not?
> >>> or prod
> >>> him to run the script?
> >>> 
> >>> projects/*/*/i18n.json
> >>>   to update the i18n branch information
> >>> 
> >>> Anything else I am missing?
> >> 
> >> Hi,
> >> 
> >> Thanks for the additional pointers.
> >> 
> >> Given no one did seem to oppose so far, I would consider to switch
> >> Kate to Qt
> >> 6 in master next Wednesday and start the bit Qt 6 run :)
> > 
> > When you switch a branch to qt6, please remember to ping the
> > translation team
> > because we need to move the translations. Probably the best way is to
> > mention
> > the translation team in the merge request to sysadmin/repo-metadata.git
> > which
> > updates the content of the i18n.json file.
> 
> Thanks for the hint.
> 
> Just to be sure, perhaps I missed the docs, what would be needed in
> 
> https://invent.kde.org/sysadmin/repo-metadata/-/blob/master/projects-invent/
> utilities/kate/i18n.json?ref_type=heads
> 
> Now we have:
> 
> {"trunk": "none", "stable": "none", "stable_kf5": "release/23.08",
> "trunk_kf5": "master"}
> 
> Would it be something like:
> 
> {"trunk": "master", "stable": "none", "stable_kf5": "release/23.08",
> "trunk_kf5": "none"}

No.

trunk and master are kde4. 

You want trunk_kf6

Cheers,
  Albert

> 
> Greetings
> Christoph

Re: Frameworks / Plasma/ Gear Release Schedule Plan

[Albert Astals Cid]

El dimarts, 5 de setembre de 2023, a les 22:42:13 (CEST), 
christ...@cullmann.io va escriure:
> On 2023-09-04 22:59, Albert Astals Cid wrote:
> > El dilluns, 4 de setembre de 2023, a les 18:50:45 (CEST), David
> > Edmundson va
> > 
> > escriure:
> >> Following on from the last Akademy we checked where we were with our
> >> development progress in a meeting and settled on the following plan
> >> 
> >> for all 3 major parts:
> >>  - In KDE Gear master will be open for Qt6 code to land for those
> >> 
> >> ready to move. Not all apps need to port.
> > 
> > For the trigger happy among us...
> > 
> > This is a plan/proposal, let's give people at least one week to
> > comment/
> > disagree on it before making master Qt6-only for Gear apps.
> 
> Hi,
> 
> yes, good point.
> 
> Just a technical question: if we do this after that period, what is
> the process to do it for an application belonging to Gear?
> 
> Will it just be sufficient e.g. for Kate to drop the Qt 5 variants in
> 
> https://invent.kde.org/utilities/kate/-/blob/master/.kde-ci.yml?ref_type=hea
> ds
> 
> and
> 
> https://invent.kde.org/utilities/kate/-/blob/master/.gitlab-ci.yml?ref_type=
> heads
> 
> and require KF 6 + Qt 6 in the CMake files or is there additional stuff
> that
> needs updates to avoids one breaks stuff?

My guess is what you are describing plus updating things in repo-metadata, i 
can think of

dependencies/logical-module-structure
  to update the branch info (i.e. kf5-qt5 won't be master anymore, i guess 
point it to the latest stable branch)

dependencies/dependency-data-kf6-qt6
  to update the dependency info 
  But this is autogenerated by Nico scripts nowadays so... maybe not? or prod 
him to run the script?

projects/*/*/i18n.json
  to update the i18n branch information

Anything else I am missing?

Cheers,
  Albert

> 
> Greetings
> Christoph
> 
> >>  - The KDE Gear release will move by 2 months to allow for the extra
> >> 
> >> time needed for testing initial Qt6 changes
> >> 
> >>  - An Alpha will be made in November  (a soft freeze in Plasma terms)
> >>  
> >>  - Betas/RCs will be made throughout December and January (3 releases,
> >> 
> >> 3 weeks apart)
> >> 
> >>  - Final release of all 3 major parts in sync in February
> >> 
> >> Due to the delay of KDE Gear by an additional patch release of 23.08
> >> will be made.
> > 
> > Or maybe even two if there's bugfixes flowing.
> > 
> > Cheers,
> > 
> >   Albert
> >> 
> >> David Edmundson

Re: Frameworks / Plasma/ Gear Release Schedule Plan

[Albert Astals Cid]

El dilluns, 4 de setembre de 2023, a les 18:50:45 (CEST), David Edmundson va 
escriure:
> Following on from the last Akademy we checked where we were with our
> development progress in a meeting and settled on the following plan
> for all 3 major parts:
> 
>  - In KDE Gear master will be open for Qt6 code to land for those
> ready to move. Not all apps need to port.

For the trigger happy among us...

This is a plan/proposal, let's give people at least one week to comment/
disagree on it before making master Qt6-only for Gear apps.

> 
>  - The KDE Gear release will move by 2 months to allow for the extra
> time needed for testing initial Qt6 changes
> 
>  - An Alpha will be made in November  (a soft freeze in Plasma terms)
> 
>  - Betas/RCs will be made throughout December and January (3 releases,
> 3 weeks apart)
> 
>  - Final release of all 3 major parts in sync in February
> 
> Due to the delay of KDE Gear by an additional patch release of 23.08
> will be made.

Or maybe even two if there's bugfixes flowing.

Cheers,
  Albert

> 
> David Edmundson

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

[Albert Astals Cid]

El diumenge, 3 de setembre de 2023, a les 23:45:50 (CEST), Elvis Stansvik va 
escriure:
> I noticed today that my votes on some bugs had been removed. Visiting
> the bugs I see there's no longer any way to vote.
> 
> So I guess as a result of this discussion, voting was disabled on some
> products?
> 
> No problem with me, but would have been nice with some sort of
> announcement (sorry if I missed it!)

I'm with Elvis.

Why were votes removed? Or was this a mistake?

The discussion here was IMO not conclusive.

And even if it was, it needs to be announced before it happens.

Otherwise we have 0 knowledge of what's going on and have no way to answer our 
users when they start complaining of why the votes are gone.

Albert

> 
> Elvis
> 
> Den fre 4 aug. 2023 kl 23:55 skrev Harald Sitter :
> > Never looked at them. Never seen the benefit.
> > 
> > On Fri, Aug 4, 2023 at 3:53 PM Nate Graham  wrote:
> > > Hello folks!
> > > 
> > > I often find myself explaining to users that votes on Bugzilla tickets
> > > are generally meaningless and not used by most developers to help
> > > prioritize work. After I explain this, they generally express surprise,
> > > as it's not obvious.
> > > 
> > > I find myself wondering whether it would make sense to disable the
> > > voting feature by default to avoid giving our users this false
> > > impression.
> > > 
> > > So if you *do* take user votes into consideration when determining what
> > > tickets to prioritize, I'd like to hear from you!
> > > 
> > > 
> > > Nate

Re: weird plural in XDG translation

[Albert Astals Cid]

El divendres, 7 d’abril de 2023, a les 15:58:44 (CEST), Aleix Pol va escriure:
> It was indeed my intention. I don't know whether it was the right choice. :D
> 
> I'd leave it as is if it works for everyone.

To me it looks like there's a verb missing in the second sentence?

I mean the first sentence would look something like this i guess

"Sharing contents to firefox"

and the second would look like

"3 video streams to firefox".

Why does it not have a "Sharing" or "Sending" or "Forwarding" or something?

Cheers,
  Albert


> 
> Thanks for checking!
> Aleix
> 
> On Mon, Apr 3, 2023 at 9:11 PM Frederik Schwarzer  wrote:
> > On Monday, April 3, 2023 8:48:04 PM CEST Aleix Pol wrote:
> > 
> > Hi Aleix,
> > 
> > > Where do you think the problem is?
> > > 
> > > If you are sharing only one stream, we just say we are sharing a
> > > stream with %2, if there are several we specify how many.
> > > 
> > > I'd expect 1 stream to be the norm anyway.
> > 
> > I was only sumbling over the difference in wording. Usually with plurals
> > it's "One element / %1 Elements" or so, here it is "contents / %1 video
> > streams". Just wanted to double check if that's inntended.
> > 
> > Cheers,
> > Frederik
> > 
> > > On Mon, Apr 3, 2023 at 5:38 PM Luigi Toscano  
wrote:
> > > > Frederik Schwarzer ha scritto:
> > > > > Hi,
> > > > > 
> > > > > in xdg-desktop-portal-kde.po we have the following message:
> > > > > 
> > > > > #: src/session.cpp:271
> > > > > #, kde-format
> > > > > msgctxt "%1 number of screens, %2 the app that receives them"
> > > > > msgid "Sharing contents to %2"
> > > > > msgid_plural "%1 video streams to %2"
> > > > > 
> > > > > Well, it *could* be alright but it might as well be a mistake. So I
> > > > > wanted to ask if anyone knows about this.> > > 
> > > > Better ask plasma people, cc-ing...
> > > > 
> > > > Ciao
> > > > --
> > > > Luigi

Re: Rename pt to pt_PT in svn

[Albert Astals Cid]

El diumenge, 8 de gener de 2023, a les 9:57:18 (CET), hanyoung va escriure:
> Hello everyone,
> 
> I'd like to rename `pt` directory in our svn to `pt_PT` to fix the bug that
> most applications treat `pt` as `pt_BR`. My understanding is that
> `l10n-kf5/$LANGUAGE/messages/plasma-workspace/plasmashell.po` will be sync
> to `plasma-workspace/po/$LANGUAGE/plasmashell.po`. In turn, when we call
> `KLocalizedString::availableDomainTranslations("plasmashell").values()` in
> systemsetting to get the list of available languages, it essentially
> iterates over the translation directories and return the list of directory
> names that have plasmashell.po in them. And that's why we're getting ["pt",
> "pt_BR"]. Sadly, most applications (include KDE itself) treat `pt` as
> `pt_BR`.

"most applications" is not correct, as far as i understand the only thing that 
says pt -> pt_BR is QLocale (and CLDR but as far as i know there's not much 
plain CLDR usage out there). 

The rest of the glibc world treats pt as that, just pt with no country 
specialization.

> So effectively, user can't set their system language to `pt_PT` in
> systemsettings.

That's a bug in systemsettings, we've had code tha takes into account "pt in 
glibc locale world needs to be pt_PT in QLocale world" since I fixed in 2015, 
but I guess someone removed it at some point.

> As a temporary measure, we can explicitly set 'pt' to 'pt_PT' in
> systemsettings code. As I did in this MR:
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2478

That seems reasonable (except for the hand rolled search algorithm) (haven't 
tested either)

I don't see why you consider that a temporary measure, it's the correct fix 
that manages correctly the fact that glibc and qlocale disagree.

> However, I wish in the long term we can rename the 'pt' in
> https://websvn.kde.org/trunk/l10n-kf5/pt/ to 'pt_PT'. This should fix the
> root issue.

I think that would be bad idea since it would make people using the pt_MO 
locale not getting any translation.

Cheers,
  Albert

> 
> Relevant bug report, forum discussion and MR:
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2478
> https://discuss.kde.org/t/rename-pt-in-i10n-svn-to-pt-pt/118
> https://bugs.kde.org/show_bug.cgi?id=454991
> 
> Note: please reply on either MR, forum post or bug report. Forum post is
> preferred since I linked it to the MR and bug report (and also in source
> code comment)
> 
> Regards,
> Han

Re: Rename pt to pt_PT in svn

[Albert Astals Cid]

El diumenge, 8 de gener de 2023, a les 9:57:18 (CET), hanyoung va escriure:
> Hello everyone,
> 
> I'd like to rename `pt` directory in our svn to `pt_PT` to fix the bug that
> most applications treat `pt` as `pt_BR`. My understanding is that
> `l10n-kf5/$LANGUAGE/messages/plasma-workspace/plasmashell.po` will be sync
> to `plasma-workspace/po/$LANGUAGE/plasmashell.po`. In turn, when we call
> `KLocalizedString::availableDomainTranslations("plasmashell").values()` in
> systemsetting to get the list of available languages, it essentially
> iterates over the translation directories and return the list of directory
> names that have plasmashell.po in them. And that's why we're getting ["pt",
> "pt_BR"]. Sadly, most applications (include KDE itself) treat `pt` as
> `pt_BR`. So effectively, user can't set their system language to `pt_PT` in
> systemsettings.
> 
> As a temporary measure, we can explicitly set 'pt' to 'pt_PT' in
> systemsettings code. As I did in this MR:
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2478
> However, I wish in the long term we can rename the 'pt' in
> https://websvn.kde.org/trunk/l10n-kf5/pt/ to 'pt_PT'. This should fix the
> root issue.
> 
> Relevant bug report, forum discussion and MR:
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2478
> https://discuss.kde.org/t/rename-pt-in-i10n-svn-to-pt-pt/118
> https://bugs.kde.org/show_bug.cgi?id=454991
> 
> Note: please reply on either MR, forum post or bug report. Forum post is
> preferred since I linked it to the MR and bug report (and also in source
> code comment)

No.

i18n decisions are made in i18n mailing list, not anywhere else that is more 
convenient for you but less convenient for all the rest of us.

Albert

> 
> Regards,
> Han

Re: Gitlab CI Dashboards and retirement of build.kde.org

[Albert Astals Cid]

El dissabte, 27 d’agost de 2022, a les 11:44:47 (CEST), Ben Cooksley va 
escriure:
> Hi all,
> 
> This evening I completed the necessary setup required to complete our
> Gitlab CI dashboards, which can now be found at
> https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer
> account login required)
> 
> These allow any developer to get a view on the current CI status of
> projects and groups of projects on a branch and platform basis - and should
> hopefully provide useful insight into the overall status that can currently
> be obtained from Jenkins.
> 
> As this was the last thing holding us back from shutting down build.kde.org,
> i'd like to proceed with retiring and shutting down build.kde.org as soon
> as possible so the capacity it occupies can be released and reallocated to
> Gitlab.
> 
> If anyone would like to experiment with customised views for their own
> purposes (where the above provided ones are insufficient) please file a
> Sysadmin ticket.
> 
> Please let me know if there are any questions on the above.

Looks great.

One thing that i'm not sure i understand correctly, currently in the General 
Overview, it says that there are 3 projects currently failing kwin, kpackage 
and kphotoalbum, but then if i go to the Per Platform View i get that rkward 
is failing on windows. Shouldn't rkward also be listed as failing on the 
general overview?

Cheers,
  Albert

> 
> Thanks,
> Ben

Re: Wallpaper idea

[Albert Astals Cid]

El diumenge, 19 de setembre de 2021, a les 2:02:20 (CEST), oldschoolcowboy va 
escriure:
> I have an idea for a wallpaper plugin. I also have never done anything like 
> this. I have no idea where or how to start. Will someone be willing to point 
> me to a starting point so I can start learning?

To create a wallpaper for plasma you need to implement a Plasma/Wallpaper type 
plugin

There are a few of them you can get inspiration from 

https://invent.kde.org/education/marble/-/tree/master/src/plasma/wallpapers/worldmap
https://invent.kde.org/plasma/kdeplasma-addons/-/tree/master/wallpapers

I'm CC'in plasma-devle that may give you more pointers

Cheers,
  Albert

> 
> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
> 

[sysadmin/repo-metadata] projects-invent/plasma/ksysguard: There's no ksysguard 5.23

[Albert Astals Cid]

Git commit 557142198c575f9b96cabaab749b409873e8410a by Albert Astals Cid.
Committed on 19/09/2021 at 21:08.
Pushed by aacid into branch 'master'.

There's no ksysguard 5.23

Keep stable i18n branch as 5.22 for now.

Plasma devs if there will be no new ksysguard 5.22.x release please tell
us and we'll clean it up from stable i18n

CCMAIL: plasma-devel@kde.org

M  +1-1projects-invent/plasma/ksysguard/i18n.json

https://invent.kde.org/sysadmin/repo-metadata/commit/557142198c575f9b96cabaab749b409873e8410a

diff --git a/projects-invent/plasma/ksysguard/i18n.json 
b/projects-invent/plasma/ksysguard/i18n.json
index 56e0074c..24b6740e 100644
--- a/projects-invent/plasma/ksysguard/i18n.json
+++ b/projects-invent/plasma/ksysguard/i18n.json
@@ -1 +1 @@
-{"stable_lts_kf5": "Plasma/5.18", "stable_kf5": "Plasma/5.23", "trunk_kf5": 
"master"}
+{"stable_lts_kf5": "Plasma/5.18", "stable_kf5": "Plasma/5.22", "trunk_kf5": 
"master"}

Re: Including LayerShellQt in Plasma in time for 5.22

[Albert Astals Cid]

El dijous, 1 d’abril de 2021, a les 19:12:30 CEST, Aleix Pol va escriure:
> Hi,
> In Plasma we have wanted a way to work with wlr_layer_shell for a
> while, I'd tried taking this weird route, where we were adding it into
> the project ad hoc, but it didn't really go anywhere.
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20
> 
> I then figured it would make sense to find a make sense to just go
> with what we need and implement it as a separate auto-contained
> component that can be used by any client:
> https://invent.kde.org/apol/layer-shell-qt
> Here's what it would look like when it's used by KScreenLocker:
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/20
> 
> I'd like to port KSplash to use it and possibly some other components
> it would make sense to get them there as well like KRunner or some
> plasma shell bits.
> 
> The approach is a bit limited by QtWayland where it only supports
> having one shell per process. I hope to work upstream to improve the
> situation, this is a first step.
> 
> So, I'd like to get it into the next Plasma release, I trust we can
> polish whatever might be necessary before 2021-04-29, the Repo freeze.
> 
> I've requested the move to kdereview, for those of you who can see:
> https://phabricator.kde.org/T14327

clang complains that 

/home/tsdgeos/devel/kde/layer-shell-qt/src/qwaylandlayershell_p.h:23:24: note: 
did you mean class here?
QWaylandLayerShell(struct QtWayland::zwlr_layer_shell_v1 *shell);
   ^~
   class 

clazy complains that
/home/tsdgeos/devel/kde/layer-shell-qt/src/qwaylandlayersurface.cpp:72:39: 
error: Pass small and trivially-copyable type by value (const class QMargins &) 
[-Wclazy-function-args-by-value]
void QWaylandLayerSurface::setMargins(const QMargins )

There are two TODO in the code, how important they are, should they be done 
before release?

Cheers,
  Albert

> Best regards,
> Aleix
> 
> PS: Not an April fools', no :)
> 

Re: plasma-systemmonitor in kdereview

[Albert Astals Cid]

El dijous, 1 d’octubre de 2020, a les 14:36:05 CEST, Arjen Hiemstra va escriure:
> On Thursday, 1 October 2020 14:11:16 CEST Harald Sitter wrote:
> > On 01.10.20 11:36, Arjen Hiemstra wrote:
> > > Hello,
> > > 
> > > I'd hereby like to announce that plasma-systemmonitor is in kdereview. It
> > > can be found at https://invent.kde.org/plasma/plasma-systemmonitor .
> > > 
> > > plasma-systemmonitor is a new system monitor UI built with Kirigami. It
> > > makes use of the ksystemstats daemon and the faces system for system
> > > monitor plasmoids that were both introduced in Plasma 5.19.
> > > 
> > > Our current plan is to do a "preview release" alongside Plasma 5.20, then
> > > have it be an official part of Plasma with 5.21.
> > 
> > Cool stuff.
> > 
> > L10n is currently a bit incomplete.
> > Notably
> > - the pages files lack any localization at all and I'm also not sure how
> > those could be best localized.
> 
> Yeah that is a good point. If we can somehow extract the strings from these 
> files I think we can make it work. But that may need some custom scripting.

I think that shows a bit of a bad design decision. You shouldn't have default 
user visible strings in data files if they are also user editable

If you do, you have several chained problems:
 * You need to extract those strings somehow 
 * You need to feed all the "title" strings coming from .page files through 
i18n() to get the translation before showing it to the user
 * Once you do that, what happens if i create a page and call it "Disk"? i do 
*not* want to get the translation for that, it's something i manually created i 
want to get exactly what i wrote
 * This means that now for each title string in your .page files you need to 
store whether this is a default string and thus should be passed through i18n 
or if it is a user-entered string and should not be passed through i18n

Random suggestion after spending 2 minutes thinking on it, for the default 
pages instead of having
  title=Disk
you have
  default_page_title=overview_page_disk

and then on the C++ side you have a big group of
  if (default_page_title == "overview_page_disk") return i18nc("Label on 
Overview Page", "Disk");

and leave title only for user created pages.

Cheers,
   Albert

Re: plasma-systemmonitor in kdereview

[Albert Astals Cid]

El dijous, 1 d’octubre de 2020, a les 11:36:12 CEST, Arjen Hiemstra va escriure:
> Hello,
> 
> I'd hereby like to announce that plasma-systemmonitor is in kdereview. It can 
> be found at https://invent.kde.org/plasma/plasma-systemmonitor .
> 
> plasma-systemmonitor is a new system monitor UI built with Kirigami. It makes 
> use of the ksystemstats daemon and the faces system for system monitor 
> plasmoids that were both introduced in Plasma 5.19.
> 
> Our current plan is to do a "preview release" alongside Plasma 5.20, then 
> have 
> it be an official part of Plasma with 5.21.

How serious are these cmake warnings? http://paste.debian.net/1167754/

I'd personally would suggest to remove these default values from KillDialog.qml
property string killButtonText: "Exterminate"
property string killButtonIcon: "killbots"
property string questionText: "Ex-ter-mi-nate"
they are not used anywhere and just cause confusion.

I guess i'm running a too old version of some dependency?
  
"file:///home/tsdgeos/devel/kde/install/share/ksysguard/sensorfaces/org.kde.ksysguard.processtable/contents/ui/FullRepresentation.qml:127:18:
 Type ProcessTableView unavailable"
  
"file:///home/tsdgeos/devel/kde/install/share/ksysguard/sensorfaces/org.kde.ksysguard.processtable/contents/ui/ProcessTableView.qml:97:9:
 Cannot assign to non-existent property \"flatList\""
Would make sense to mark that in the cmakelists you think? or is it just 
supposed to be used with plasma master in sync?

Cheers,
  Albert

> 
> Cheers,
> Arjen
> 
> 
> 

Re: Peruse in KDEReview

[Albert Astals Cid]

El dimarts, 15 de setembre de 2020, a les 15:11:42 CEST, Dan Leinir Turthra 
Jensen va escriure:
> Hello there :)
> 
>   i've just moved Peruse to KDEReview. It is a comic book reader app and an 
> accompanying creation tool, both based on Kirigami, and targeted both for 
> desktops and mobile (hence the many email lists you may find this email on).
> 
>   The current website is at https://peruse.kde.org/ and as you can see, there 
> have in fact been releases made of this, though they are some time ago and 
> based on Kirigami 1, which also has been causing some headaches for Neon, 
> whose maintainers have been requesting that i get a new release out (which of 
> course then requires that we actually sort out the current playground nature 
> of the project).
> 
>   It should be noted that Peruse, when used as a generic viewer, uses the 
> Okular qtquick components, which we discovered recently are not packaged by 
> some distributions. It should be detected at runtime and Peruse ought to tell 
> you as much.
> 
>   If you haven't got any comics to hand, do check out the store integration, 
> where you might grab in particular Pepper & Carrot Volume 1, which also will 
> show you some of the fancier features of the reader (such as frame-by-frame 
> navigation, originally implemented by Wolthera).
> 
>   Look forward to seeing what people have to say about all this, and thank 
> you 
> to Wolthera and Carl who already made huge strides in improving the project 
> over the years!
> 

Missing i18n?

./src/app/qml/WelcomePage.qml:118:text: "Peruse";
./src/app/qml/Book.qml:201:text: "Reading Direction"
./src/app/qml/Book.qml:204:text: "Left to Right"
./src/app/qml/Book.qml:211:text: "Right to Left"
./src/creator/qml/AddPageArea.qml:236:text: 
"Transparent";
./src/creator/qml/AddPageArea.qml:241:text: "Inverted";
./src/creator/qml/AddPageArea.qml:293:text: "Page Index:"
./src/creator/qml/BookMetainfoPage.qml:123:text: 
modelData.length > 0 ? modelData : "(unnamed)";
./src/creator/qml/BookMetainfoPage.qml:793:text: 
modelData.length > 0 ? modelData : "(unnamed)";
./src/creator/qml/WelcomePage.qml:59:text: "Peruse Creator";
./src/app/qml/FileFinder.qml:91:label: "(go up one level)";
./src/creator/qml/Main.qml:154:nameFilters: [ "Comic Book Archive zip 
format (*.cbz)", "All files (*)" ]
./src/creator/qml/CreateNewBook.qml:119:nameFilters: [ "JPEG 
images (*.jpg, *.jpeg)", "All files (*)" ];
./src/app/qml/Settings.qml:108:title: "Select a folder"
./src/app/qml/PeruseMain.qml:51:title: "Comic Book Reader";
./src/app/qml/WelcomePage.qml:213:property string title: 
"unnamed";
 
Cheers,
  Albert

Re: Peruse in KDEReview

[Albert Astals Cid]

El dimecres, 16 de setembre de 2020, a les 12:36:18 CEST, Dan Leinir Turthra 
Jensen va escriure:
> On Tuesday, 15 September 2020 19:34:23 BST Albert Astals Cid wrote:
> > Which seems to point that there's something broken somewhere.
> 
>   There we go... a mutex and a few mutex lockers later, and i... think it's 
> happy? Give it a proper shove and see if it still falls over for you ;)

I can't make it crash nor get into the weird "can't find image" state now :)

Cheers,
  Albert

 

Re: Peruse in KDEReview

[Albert Astals Cid]

El dimarts, 15 de setembre de 2020, a les 15:11:42 CEST, Dan Leinir Turthra 
Jensen va escriure:
> Hello there :)
> 
>   i've just moved Peruse to KDEReview. It is a comic book reader app and an 
> accompanying creation tool, both based on Kirigami, and targeted both for 
> desktops and mobile (hence the many email lists you may find this email on).
> 
>   The current website is at https://peruse.kde.org/ and as you can see, there 
> have in fact been releases made of this, though they are some time ago and 
> based on Kirigami 1, which also has been causing some headaches for Neon, 
> whose maintainers have been requesting that i get a new release out (which of 
> course then requires that we actually sort out the current playground nature 
> of the project).
> 
>   It should be noted that Peruse, when used as a generic viewer, uses the 
> Okular qtquick components, which we discovered recently are not packaged by 
> some distributions. It should be detected at runtime and Peruse ought to tell 
> you as much.
> 
>   If you haven't got any comics to hand, do check out the store integration, 
> where you might grab in particular Pepper & Carrot Volume 1, which also will 
> show you some of the fancier features of the reader (such as frame-by-frame 
> navigation, originally implemented by Wolthera).

I did that and it's failing quite a bit, half of the times i open it, it 
crashes the one third of the times, i get https://i.imgur.com/ehey654.png and 
the other third works.

Which seems to point that there's something broken somewhere.

Cheers,
  Albert

Backtrace:
#0  0x759e1615 in raise () from /usr/lib/libc.so.6
#1  0x759ca862 in abort () from /usr/lib/libc.so.6
#2  0x75a235e8 in __libc_message () from /usr/lib/libc.so.6
#3  0x75a2b27a in malloc_printerr () from /usr/lib/libc.so.6
#4  0x75a2cb9e in _int_free () from /usr/lib/libc.so.6
#5  0x76056b0c in QByteArray::operator=(QByteArray const&) () from 
/usr/lib/libQt5Core.so.5
#6  0x760411aa in QRingBuffer::clear() () from /usr/lib/libQt5Core.so.5
#7  0x76115bec in QIODevice::seek(long long) () from 
/usr/lib/libQt5Core.so.5
#8  0x7610df0f in QFileDevice::seek(long long) () from 
/usr/lib/libQt5Core.so.5
#9  0x75771e17 in ?? () from /usr/lib/libKF5Archive.so.5
#10 0x7577682a in KZipFileEntry::createDevice() const () from 
/usr/lib/libKF5Archive.so.5
#11 0x75776153 in KZipFileEntry::data() const () from 
/usr/lib/libKF5Archive.so.5
#12 0x7fffe80a6c68 in ArchiveImageRunnable::run (this=0x7fffc00223b0) at 
/home/tsdgeos/devel/kde/peruse/src/qtquick/ArchiveImageProvider.cpp:185
#13 0x76003dc2 in ?? () from /usr/lib/libQt5Core.so.5
#14 0x75fffe8f in ?? () from /usr/lib/libQt5Core.so.5
#15 0x758253e9 in start_thread () from /usr/lib/libpthread.so.0
#16 0x75aa4293 in clone () from /usr/lib/libc.so.6




> 
>   Look forward to seeing what people have to say about all this, and thank 
> you 
> to Wolthera and Carl who already made huge strides in improving the project 
> over the years!
> 
> 

Re: plasma-disks in kdereview

[Albert Astals Cid]

El dimarts, 4 d’agost de 2020, a les 15:46:20 CEST, Harald Sitter va escriure:
> Hey
> 
> It'd be awesome if I could get some eyes at the new
> https://invent.kde.org/system/plasma-disks which implements smart
> monitoring as requested in https://bugs.kde.org/show_bug.cgi?id=254313
> I've opted to not put it in kinfocenter directly because it is a bit
> much with its own kded module and kauth helper, plus I guess there's
> an opportunity to add further monitoring tech for RAIDs or something.
> It still targets plasma releases though.
> 
> This runtime depends on smartctl (from smartmontools) to read the
> smart status via a kauth helper. Device states are managed inside a
> kded that maps the devices into dbus from which the kinfocenter KCM
> then loads the data for visualization.

I have a feeling that the qml i18n's won't work pick up the correct domain, the 
-DTRANSLATION_DOMAIN only sets the domain for the C++ calls.

Cheers,
  Albert


> 
> Ta
> HS
> 

Re: KRunProxy

[Albert Astals Cid]

El dissabte, 6 de juny de 2020, a les 19:00:59 CEST, David Faure va escriure:
> In order to switch kdeclarative to 
> -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054700
> we need to port KRunProxy away from KRun, or to deprecate KRunProxy.
> 
> AFAICS it exposes an object named KRun to QML files, but searching for
> qml files with KRun in them leads to no results: 
> https://lxr.kde.org/search?_filestring=*.qml&_string=KRun
> 
> Am I doing this wrong? 

Yes, this is the correct search

https://lxr.kde.org/search?_filestring=.*%5C.qml&_advanced=1&_string=KRun&_casesensitive=1

>From what i can see it's only used in one place to launch ksysguard

Cheers,
  Albert

> Are there other file extensions to take into consideration?
> 
> If not, can I deprecate KRunProxy?
> 
> 

Re: New Plasma modules and localization

[Albert Astals Cid]

El dissabte, 16 de maig de 2020, a les 14:50:12 CEST, Yuri Chornoivan va 
escriure:
> Hi,
> 
> Plasma 5.19 sports several KCM updates that lead to some changes in 
> translations. It is good to see the continuous progress in the design, 
> features, and usability of Plasma.
> 
> It is sad, however, to see some regressions in translations. I cannot test by 
> myself but there are reports that some parts of the new KWin Rules KCM are 
> untranslatable:
> 
> https://phabricator.kde.org/D29413
> 
> Can somebody test if it's true?
> 
> The new ksysguard translations are broken. Extraction scripts do not work.
> 
> $XGETTEXT *.cpp -o ksysguard_plugins_global.pot
>  $XGETTEXT *.cpp -o ksysguard_plugins_process.pot
> 
> should be replaced with
> 
> $XGETTEXT `find -name \*.cpp` -o $podir/ksysguard_plugins_global.pot
> $XGETTEXT `find -name \*.cpp` -o $podir/ksysguard_plugins_process.pot

I fixed these two, with a slightly different syntax since i had them fixed this 
morning and was just waiting for the repos to re-open.

Cheers,
  Albert

> 
> The root localization of libksysguard is broken as well.
> 
> Messages.sh extracts to KSysGuardSensorFaces.pot, QML code contains something 
> like i18nd("KSysGuardSensorFaces", "Remove") but CMakeLists.txt points to 
> add_definitions(-DTRANSLATION_DOMAIN=\"ksysguard_faces\")
> 
> What should be used for this to work as expected?
> 
> (Spotted by Victor Ryzhykh)
> 
> Thanks in advance for your answers.
> 
> Best regards,
> Yuri
> 
> 
> 

Re: kwallet-pam >= 5.18.4 and ecryptfs homes

[Albert Astals Cid]

P.S: Remember to CC me

El dilluns, 4 de maig de 2020, a les 21:11:22 CEST, Nate Graham va escriure:
> On 5/3/20 4:02 PM, Albert Astals Cid wrote:> Problem with SOLUTION 1 is 
> that it adds lots of code in a relative "sensitive" piece of code like a 
> pam module for for what it is a one time thing.
> > Problem with SOLUTION 2 is that it's not a solution :D
> > 
> > 
> > Opinions?
> 
> I feel pretty confident in your skills at implementing option 1 safely. 
> :) 

Here the problem is that i actually need to be able to reproduce the issue 
myself first, i guess i can try installing some old KUbuntu and then upgrading 
in a VM. Let's try to give it a try.

> Once the code is pushed out to users in 5.18.5, could we remove it in 
> master to avoid an ongoing maintenance and security issues?

No, we need it "forever" so that people updating from < 5.18.3 to >= 5.18.4 
don't face the problem.

Cheers,
  Albert

P.S: Remember to CC me

> In any event, it seems like we don't really have much of a choice since 
> as you mention, option 2 doesn't actually solve the problem for the 
> typical user.
> 
> Nate
> 

kwallet-pam >= 5.18.4 and ecryptfs homes

[Albert Astals Cid]

Remember to CC me, I'm not subscribed to the list

Sadly, a fix i made for Plasma 5.18.4 so that kwallet-pam reads/stores the salt 
file inside the encrypted home dir (if there is one) means that if you had used 
kwallet-pam < 5.18.4 and now use kwallet-pam the salt file is not found and 
your kwallet is not auto-opened on login as you wanted.

SOLUTION 1:
 * read the salt file in the "authenticate step" (encrypted home if there is 
one still not mounted), keep it in memory
 * Read file the file again in the "open_session step" (encrypted home if there 
is one is now mounted), if there is no salt file, write it with what we have in 
memory


Problem A) The "old" file is still there outside the unencrypted home, which is 
not optimal

Problem B) This doesn't help people that have already updated to 5.18.4, since 
those will have a new salt file already in place



Potential solution to A) Keep the file descriptor for the "salt file from 
authenticate step" and if we find we have to use that file, delete or empty 
that fd
This is assuming that fd to "now unexisting paths because a folder was mounted 
or" are still valid/usable


Potential solution to B) If opening the wallet failed and there was a different 
salt file in the authenticate step file try to use the contents of the old salt 
file to open the wallet, if that succeds show a long dialog with instructions 
of what they should do (i would rather not overwrite salt files just in case)


SOLUTION 2:
 * Ignore it and hope people will read my blog 
https://tsdgeos.blogspot.com/2020/05/kwallet-pam-5184-and-ecryptfs-homes.html 





Problem with SOLUTION 1 is that it adds lots of code in a relative "sensitive" 
piece of code like a pam module for for what it is a one time thing.
Problem with SOLUTION 2 is that it's not a solution :D


Opinions?


Cheers,
  Albert

Remember to CC me, I'm not subscribed to the list

Re: Information regarding upcoming Gitlab Migration: clarifications

[Albert Astals Cid]

El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> >
> > > We have made a big fuss in the past about having different projects
> > > that do the same thing and now we'll have that but also we'll have
> > > several projects with the same name?
> > > It really feels off to me and I wonder if this is related to the move to
> > > gitlab.
> >
> > +1 to both sentiments - that projects should have different names and that
> > this is a bit off topic for the gitlab migration.
> 
> The projects *DO* have very different names. That *HAS NOT* changed.
> To use the example Bhushan gave above, one is called Plasma Mobile
> Dialer and the other one is called Maui Dialer.
> 
> With the current git.kde.org setup, we have a flat namespace, so all
> repositories if the name appears to be generic (as dialer is) have to
> be namespaced by prefixing of the repository name.
> 
> With Gitlab however we will now namespaces that group repositories,
> making the prefixing unnecessary and as some projects have complained
> about, duplicative.
> 
> Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> path, which just looks silly.

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

Cheers,
  Albert

> 
> >
> > Cheers,
> > Ivan
> >
> >
> 
> Regards,
> Ben
> 
> >
> > --
> > dr Ivan Čukić
> > i...@cukic.co, https://cukic.co/
> > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12
> >
> >
> 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 3:40:01 CEST, Bhushan Shah va escriure:
> [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> replies]
> 
> Hello Community members,
> 
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
> 
> We had multiple options,
> 
> - Flat structure: In this option we would have everything under one
>   single namespace/group: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
>   under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
>   groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> 
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
> 
> - Provides good visibility on all reviews, tasks and other items within
>   the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
>   task board should it fit their needs (for tracking a release for
>   instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>   in option 2 is duplicative considering the Gitlab instance is under
>   kde.org.
> - The discoverability of projects is maximised, as there is no need to
>   open the top level ‘KDE’ group before going into the subgroup.
> 
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
> 
> If we don't have any objections we would like to implement this next
> week and move projects to https://invent.kde.org.

Anything that breaks kde:$repo will break the release-tools used for the 
monthly releases done by the release service and the l10n scripty scripts.

If it ends up happening it would be good if such change is as far away as 
possible from a release so the scripts can be adapted timely and hopefully 
without mistakes.

Cheers,
  Albert

> 
> Thanks!
> Bhushan for sysadmin team
> 
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> 
> 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure:
> On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud  
> wrote:
> >
> > Hi,
> >
> > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
> > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah  wrote:
> > > >
> > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for
> > > > replies]
> > > >
> > > > Hello Community members,
> > > >
> > > > In view of upcoming Gitlab migration, we sysadmin team wants to share
> > > > the recommended structuring for the repositories on Gitlab.
> > > >
> > > > We had multiple options,
> > > >
> > > > - Flat structure: In this option we would have everything under one
> > > > single namespace/group: https://invent.kde.org/kde/knetwalk
> > > > - Subgroups under top-level group: In this option we would have a groups
> > > > under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> > > > - Groups at top level: In this option we would establish a series of
> > > > groups at the top level, e.g.  https://invent.kde.org/games/knetwalk
> > > >
> >
> > Thank you for having options and talking to us before implementing it.
> >
> > > > We have discussed this with small but representative group of
> > > > contributors or maintainers, and based on their suggestions, we
> > > > recommend that we go with option 3. Having sub-groups at top level will
> > > > allow us to,
> > > >
> > > > - Provides good visibility on all reviews, tasks and other items within
> > > > the groups/modules we define
> > > > - Provides improvements to discoverability of projects
> > > > - Makes it possible for groups of projects to establish a group level
> > > > task board should it fit their needs (for tracking a release for
> > > > instance)
> > > > - Makes the most semantic sense, as the ‘KDE’ top level group suggested
> > > > in option 2 is duplicative considering the Gitlab instance is under
> > > > kde.org.
> > > > - The discoverability of projects is maximised, as there is no need to
> > > > open the top level ‘KDE’ group before going into the subgroup.
> > > >
> > > > I've worked on draft "move" of the current set of the repositories in
> > > > their respective subgroups at the repo-metadata project's branch [1].
> > > > You can browse the directory structure to get idea of how final
> > > > structure on Gitlab would look like.
> > > >
> > > > If we don't have any objections we would like to implement this next
> > > > week and move projects to https://invent.kde.org.
> > > >
> > > > Thanks!
> > > > Bhushan for sysadmin team
> > > >
> > > > [1] 
> > > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> > >
> > > 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?
> > >
> > > I really prefer when I don't have to guess this kind of things when
> > > fetching a repository.
> > >
> >
> > I 100% agree with Aleix and I think it would also be detrimental for 
> > discoverability, exactly for the examples Aleix just gave.
> >
> > We came back from this subgroups ideas some times ago : wiki pages were 
> > hard to find because hidden under layers of groups. The same was true for 
> > api documentations. Now everything is flat and I think it's easier to find.
> >
> > Another bad message could also be sent by this: instead of exposing Konsole 
> > or Ark as two applications under the KDE umbrella, it would look like Utils 
> > for KDE, bringing back the KDE Desktop idea (where every application is 
> > already store in a submenu).
> >
> > As someone wrote later, if I'm looking for a given application, there is 
> > always the search function...
> 
> That requires that you know it exists. We have 1,043 mainline
> repositories at the moment, which translates to 53 pages of projects
> under a flat structure system.
> Reality is nobody is going to page through that looking for something.

But they have gitlab search, don't they?

I mean it's the solution you told Aleix to figure out if Okular was inside 
graphics or okular.

Why is search valid for one case and not for the other?

Cheers,
  Albert

> 
> Please also see my point regarding listing merge requests at the group
> level - you can see an example of what a flat structure ends up
> looking like at https://gitlab.gnome.org/GNOME
> 
> For those projects that span multiple repositories, you have just
> denied them any chance or ability to see a listing of everything
> related to their wider project.
> 
> >
> > Best regards,
> > Olivier
> > > Aleix
> >
> >
> 
> Cheers,
> 

Re: Information regarding upcoming Gitlab Migration

[Albert Astals Cid]

El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va escriure:
> In part I am mostly re-iterating what Ben already mentioned in different
> messages.
> 
> On Mon, Apr 27, 2020 at 12:38:42PM +0200, 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?
> 
> Yes
> 
> [Rest of message is with sysadmin hat off and as a developer]
> 
> > 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.
> 
> I do agree that it maybe small inconvience, but let's be honest, most of
> us have been using kdesrc-build or some kind of automated tooling for
> building everything, apart from very rare case we never have to manually
> clone any of KDE repository, at least it is true for me personally. I am
> not sure about others.

Please let's refrain from saying things like "most of us have been using 
kdesrc-build" when you don't have any data to back that up.

Cheers,
  Albert

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Albert Astals Cid]

El diumenge, 22 de març de 2020, a les 16:12:04 CET, Ben Cooksley va escriure:
> On Mon, Mar 23, 2020 at 12:49 AM Albert Astals Cid  wrote:
> >
> > El diumenge, 22 de març de 2020, a les 3:19:57 CET, Ben Cooksley va 
> > escriure:
> > > Note however that images based upon Fedora or anything that shares
> > > it's lineage (including CentOS and it's derivates) is strictly
> > > prohibited and won't be accepted for inclusion.
> >
> > I still find this highly annoying since Fedora seems to be the only distro 
> > providing an almost full stack of mingw packages so for example i could add 
> > easily a mingw/windows CI to QCA using fedora but i can't because, for some 
> > reason i forgot, you are very unhappy with them.
> >
> 
> ...
> 
> This is why Fedora and all associated derivatives are banned from our systems.

Is there a way they can be ever forgiven or is your plan to ban Fedora forever?

> 
> > Cheers,
> >   Albert
> 
> With regards to MingW, the better way to do this would be by using
> native MingW rather than cross compiling. Craft already uses MingW for
> some dependencies, and Krita's binary factory builds use it as well so
> most of the infrastructure for this is already in position.

But that's something that requires magic and thus sysadmin to do it, a 
Fedora+mingw gitlab CI is something i can do myself.

But If you're volunteering to do a Windows gitlab CI for QCA I'll take it :)

Cheers,
  Albert

> 
> Regards,
> Ben
> 
> >
> > >
> > > >
> > > > Regards,
> > > >
> > > > - Johan
> > >
> > > Cheers,
> > > Ben
> > >
> >
> >
> >
> >
> 

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Albert Astals Cid]

El diumenge, 22 de març de 2020, a les 3:19:57 CET, Ben Cooksley va escriure:
> Note however that images based upon Fedora or anything that shares
> it's lineage (including CentOS and it's derivates) is strictly
> prohibited and won't be accepted for inclusion.

I still find this highly annoying since Fedora seems to be the only distro 
providing an almost full stack of mingw packages so for example i could add 
easily a mingw/windows CI to QCA using fedora but i can't because, for some 
reason i forgot, you are very unhappy with them.

Cheers,
  Albert

> 
> >
> > Regards,
> >
> > - Johan
> 
> Cheers,
> Ben
> 

D27935: Make kwallet-pam work with pam_fscrypt

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R107:2bb4c6dc870f: Make kwallet-pam work with pam_fscrypt 
(authored by aacid).

REPOSITORY
  R107 KWallet PAM Integration

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27935?vs=77963=78049

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

AFFECTED FILES
  pam_kwallet.c

To: aacid, sitter
Cc: sitter, security-team, davidedmundson, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, 
ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, ahiemstra, mart

D27935: Make kwallet-pam work with pam_fscrypt

[Albert Astals Cid]

aacid updated this revision to Diff 77963.
aacid added a comment.


  restore the code that calls pam_sm_open_session from pam_sm_authenticate if 
they were called "out of order"

REPOSITORY
  R107 KWallet PAM Integration

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27935?vs=77232=77963

BRANCH
  Plasma/5.18

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

AFFECTED FILES
  pam_kwallet.c

To: aacid
Cc: sitter, security-team, davidedmundson, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, 
ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, ahiemstra, mart

D27935: Make kwallet-pam work with pam_fscrypt

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> sitter wrote in pam_kwallet.c:329
> Alex did add this check in a dedicated commit 
> 634464255a82de55e0288f7e425e50f6c409f51d 
>  
> and even though I couldn't find a subsequent commit that made use of that 
> preparation I'm sure he must have had a reason to add it. Perhaps it was this:
> 
> http://www.linux-pam.org/Linux-PAM-html/mwg-expected-of-module-overview.html#mwg-expected-of-module-overview-1
> 
> > The independence of the four groups of service a module can offer means 
> > that the module should allow for the possibility that any one of these four 
> > services may legitimately be called in **any order**. Thus, the module 
> > writer should consider the appropriateness of performing a service without 
> > the prior success of some other part of the module.
> 
> gnome-keyring, as the most topically relevant example, doesn't explicitly 
> have 'open called before' but its written in a very particular way. Both auth 
> and session can unlock the keyring (and attempt a daemon start) it seems. Not 
> really the same, but there's certainly some nuance to how modules may get 
> called.
> 
> So, the original check for sm_open_session in our code may have been not 
> entirely pointless, it does kinda meet that any-order expectation. It 
> probably also wasn't entirely correct though as it didn't meet the 
> independence expectation ^^
> 
> Removing it leaves me a bit uneasy without input from someone who knows more 
> about pam and the two of us. At the same time it's clearly not quite right 
> either.
> 
> How about leaving it in for 5.18 and drop it for master?
> Should there be an unexpected problem we'll at least have months of 
> theoretical testing and a shorter window from 5.19.0 to .1 to hotfix a 
> potential regression.

> How about leaving it in for 5.18 and drop it for master?
>  Should there be an unexpected problem we'll at least have months of 
> theoretical testing and a shorter window from 5.19.0 to .1 to hotfix a > 
> potential regression.

Doesn't sound very convincing to me, if there's going to be a regression i'd 
prefer it to be this month when i still remember this code and i still use 
kwallet-pam and pam_fscrypt, if you delay it to 5.19.0 or something I will not 
totally remember this code and may not be using this any of those two either os 
my motivation to fix it may be pretty small.

I can try adding the code that makes pam_sm_open_session from here if you think 
it makes sense to have it

REPOSITORY
  R107 KWallet PAM Integration

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

To: aacid
Cc: sitter, security-team, davidedmundson, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, 
ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, ahiemstra, mart

D27935: Make kwallet-pam work with pam_fscrypt

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> sitter wrote in pam_kwallet.c:313
> This can ENOMEM. Does that maybe need handling? Or will pam_set_data just 
> fail if you give it a nullptr?

Passing nullptr is fine, see comment on 
https://github.com/linux-pam/linux-pam/blob/master/libpam/pam_data.c#L110

> sitter wrote in pam_kwallet.c:329
> I wonder about this comment. Can the call sequence here be random? Can open 
> be called before authenticate?

That is a good question, the old code was kind of prepared for it.

I am going to say "no" open can not be called before authenticate, if you read 
https://pubs.opengroup.org/onlinepubs/008329799/pam_open_session.htm it says

"The pam_open_session() function opens a new session for a user previously 
authenticated with a call to pam_authenticate()."

But my pam knowledge is between none and i googled a little, so I would be 
happy if someone can google a bit more and agree/disagree with me

REPOSITORY
  R107 KWallet PAM Integration

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

To: aacid
Cc: sitter, security-team, davidedmundson, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, 
ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, ahiemstra, mart

D27935: Make kwallet-pam work with pam_fscrypt

[Albert Astals Cid]

aacid updated this revision to Diff 77232.
aacid added a comment.


  don't log the password to journald ^_^

REPOSITORY
  R107 KWallet PAM Integration

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27935?vs=77231=77232

BRANCH
  Plasma/5.18

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

AFFECTED FILES
  pam_kwallet.c

To: aacid
Cc: security-team, davidedmundson, plasma-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, 
ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, ahiemstra, mart

D27935: Make kwallet-pam work with pam_fscrypt

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  fscrypt encrypts folders, you can use pam_fscrypt to auto-unencrypt
  some, for example your home folder.
  
  This means that the old code of kwallet-pam would not work
  since it tries to read/write the salt file at the auth step.
  
  This change moves that from the auth step to the open step, sadly that
  means we need to keep the password in (pam "secure") memory for a while more.

TEST PLAN
  I can now login into my session and the kwallet password prompt is not shown

REPOSITORY
  R107 KWallet PAM Integration

BRANCH
  Plasma/5.18

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

AFFECTED FILES
  pam_kwallet.c

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

D27686: Fix connection to invalid signal

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R124:ead61e26ab78: Fix connection to invalid signal (authored 
by aacid).

REPOSITORY
  R124 System Settings

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27686?vs=76498=77143

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

AFFECTED FILES
  sidebar/package/contents/ui/SubCategoryPage.qml

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

D27686: Fix connection to invalid signal

[Albert Astals Cid]

aacid added a comment.


  ping

REPOSITORY
  R124 System Settings

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

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

D27686: Fix connection to invalid signal

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  Don't do an = when we have a binding that does the same thing

TEST PLAN
  I have NOT tested this actually works better than it did with the broken 
connect, only that it removes the wrong connect

REPOSITORY
  R124 System Settings

BRANCH
  Plasma/5.18

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

AFFECTED FILES
  sidebar/package/contents/ui/SubCategoryPage.qml

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

D27462: Include comment for translators for Power Down

[Albert Astals Cid]

aacid added a comment.


  i think it's better than nothing yes

REPOSITORY
  R122 Powerdevil

BRANCH
  master

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

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

Re: 2 kirigami fixes for a point release

[Albert Astals Cid]

El dimarts, 18 de febrer de 2020, a les 4:03:05 CET, Nate Graham va escriure:
> On 2020-02-16 14:43, Albert Astals Cid wrote:
> > Maybe i explain myself wrongly, i'm not blaming distros at all.
> > 
> > They made a decision, we/I may agree with them or not, that's *my/our* 
> > problem, what I was disagreeing is to us having to do extra work because 
> > someone elses (the distros) decision.
> 
> We already do this: it's called the Plasma LTS product. :-) It's been 
> specifically created to cater to various distros' desires for an 
> extended-support product they can ship to users of their own LTS releases.
> 
> But yes, I can also agree with more tests, better stability, moving to 
> GitLab so tests are run before merging, etc. I think we can all agree 
> with that.
> 
> However all the autotests in the world will not resolve the fundamental 
> incompatibility between the Plasma LTS product, which is built around 
> the release model of extended, ongoing bugfix releases, and Frameworks, 
> which is built around a rolling release model with no bugfix releases at 
> all.

I still don't see why this is a problem, as said Plasma depends on a myriad of 
libraries that are building each with their own release model, most probably 
with no bugfix releases at all either.

Incidentally what happens is that those libraries are not buggy, and it seems 
the Plasma-facing parts of KF5 are, well, let's make them not be.

Cheers,
  Albert

Re: 2 kirigami fixes for a point release

[Albert Astals Cid]

El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va escriure:
> On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote:
> > This is their fault, they as a distribution have decided to support a random
> > KDE Frameworks version for longer than we do support it, so they are the
> > ones that should be the job of supporting it.
> > 
> > It's like you are trying to say we should be doing the distributions jobs,
> > what we should be doing is doing our job which is making the best software
> > we can, not spending time accomodating decisions that somebody else took
> > for us, and since distributions often only bring us pain in the shape of
> > not updating versions, etc. IMHO what we should be doing is moving away
> > from distributions model and more into the snap/flatpak model in which we
> > control what we give our users.
> > 
> > Sadly flatpak doesn't work for non applications and snap is
> > Ubuntu-only-not-really-but-yes-really so for Plasma this doesn't really
> > solver the problem so maybe we should just finally tell our users to start
> > using the good distributions if they care about their user experience. By
> > good meaning those with a rolling KDE software suite or those that actually
> > do backport fixes to the version they have randomly decided to lock onto.
> 
> At the same time, we can only successfully convince distributions to upgrade 
> to the monthly KF5 releases if they are stable and don't come with 
> regressions. I believe this is true for most of the frameworks, but I'm not 
> so 
> sure about kirigami/qqc2-desktop-style, based on what I hear (not just the 
> recent issue).
> 
> Before blaming distros, I believe we have our own backyard to take care of,
> with for sure more systematic use of code reviews and possibly more automated 
> testing, for those frameworks (for the latter I guess that QtQuick doesn't 
> make it easy, but that's part of the problem...).

Maybe i explain myself wrongly, i'm not blaming distros at all. 

They made a decision, we/I may agree with them or not, that's *my/our* problem, 
what I was disagreeing is to us having to do extra work because someone elses 
(the distros) decision.

And yes, totally, we need more autotests, and moving to gitlab so tests are 
finally run *before* merging stuff.

Cheers,
  Albert

> 
> 

Re: 2 kirigami fixes for a point release

[Albert Astals Cid]

El dissabte, 15 de febrer de 2020, a les 20:35:23 CET, Nate Graham va escriure:
> On 2020-02-15 11:55, Ben Cooksley wrote:
> > My point above was that the version you decide to freeze on should
> > only be the version you depend on during development.
> > The version you depend on when you release will be the next release of
> > Frameworks (so by freezing on 5.66 for development, it should have had
> > a release-day dependency of 5.67)
> > 
> > The release of Plasma should then take place shortly after the
> > Frameworks version you have a release-day dependency on.
> > 
> > You stagger it like this to ensure that developers are performing a
> > full burn in of the Frameworks version for several weeks on their
> > systems, and to ensure that all the problems they find end up in the
> > Frameworks that users will have on their systems.
> 
> None of this makes a difference for distros that ship LTS Plasma don't 
> ship newer Frameworks versions. No matter how much testing you do, some 
> bugs in Frameworks will slip through and need to be fixed after the 
> release. But the frameworks release cycle has no concept of the 
> post-release bugfix like Apps and Plasma do; instead the expectation is 
> that the distro will just ship a new Frameworks version in a month. This 
> expectation does not match the reality for the distros that want to ship 
> an LTS plasma version and do not ship newer Frameworks versions.

This is their fault, they as a distribution have decided to support a random 
KDE Frameworks version for longer than we do support it, so they are the ones 
that should be the job of supporting it.

It's like you are trying to say we should be doing the distributions jobs, what 
we should be doing is doing our job which is making the best software we can, 
not spending time accomodating decisions that somebody else took for us, and 
since distributions often only bring us pain in the shape of not updating 
versions, etc. IMHO what we should be doing is moving away from distributions 
model and more into the snap/flatpak model in which we control what we give our 
users. 

Sadly flatpak doesn't work for non applications and snap is 
Ubuntu-only-not-really-but-yes-really so for Plasma this doesn't really solver 
the problem so maybe we should just finally tell our users to start using the 
good distributions if they care about their user experience. By good meaning 
those with a rolling KDE software suite or those that actually do backport 
fixes to the version they have randomly decided to lock onto.

Cheers,
  Albert

> 
> 
> > As for the distributions that are refusing to update Frameworks, do
> > you have a list of those distributions?
> > If they're providing a poor experience to our users then we at the
> > very least should ensure we steer people away from them.
> 
> Oh, you know, just some weird, unimportant little ones, like Debian, 
> Ubuntu/Kubuntu, and openSUSE Leap. ;-) We should definitely make sure 
> that our users don't use *those*; it's not like they're the big heavy 
> hitters of the Linux world that are used in large numbers by 
> corporations and shipped on hardware or anything. :)
> 
> Nate
> 

D26892: Switch to the old-style button text for the KNSQuick buttons

[Albert Astals Cid]

aacid added a comment.


  stable branch please :)

REPOSITORY
  R119 Plasma Desktop

BRANCH
  restore-old-style-kns-button-text (branched from master)

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

To: leinir, #plasma, davidedmundson
Cc: aacid, yurchor, davidedmundson, kde-i18n-doc, gikari, plasma-devel, Orage, 
LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, 
ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, ahiemstra, mart

Re: Plasma 5.18 Branched

[Albert Astals Cid]

El dijous, 16 de gener de 2020, a les 14:30:29 CET, Jonathan Riddell va 
escriure:
> Plasma has branched for the 5.18 releases.  Beta is due today and final
> release in three weeks time.
> 
> Could i18n team move over the stable translations from master?

Luigi did this.

Cheers,
  Albert

> 
> Plasma team please don't commit new features to Plasma/5.18 branches but
> please do make lots of bug fixes.
> 
> Jonathan
> 

D26192: Fix localization of the systemmonitor widget configuration window

[Albert Astals Cid]

aacid added a comment.


  For the future, ideally, if a component is used as a library (like it seems 
is the case here) it should be extracted to it's own catalog and then 
translated with i18nd* variants that specify that catalog to be loaded instead 
of asking the translators to translate it N times (not that it's a problem 
since any good tool will make this very fast, but it's the better architectural 
solution in my opinion)

REPOSITORY
  R120 Plasma Workspace

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

To: yurchor, #localization, #plasma, davidedmundson, ngraham
Cc: aacid, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: KInit - Current state and benchmarks

[Albert Astals Cid]

El dimarts, 26 de novembre de 2019, a les 8:56:54 CET, Milian Wolff va escriure:
> On Montag, 25. November 2019 22:57:11 CET Albert Astals Cid wrote:
> > El dissabte, 23 de novembre de 2019, a les 11:47:40 CET, Milian Wolff va 
> escriure:
> > > On Mittwoch, 19. Juni 2019 19:57:56 CET Albert Astals Cid wrote:
> > > > El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va
> > > 
> > > escriure:
> > > > > > Are we sure it's fair to assume people have SSD? our of the 4
> > > > > > laptops i
> > > > > > own, only 2 have SSD.>
> > > > > 
> > > > > It's at least safe to assume it's the trend moving forward.
> > > > > 
> > > > > > Do you think it's worth me trying in one of the two that don't have
> > > > > > SSD?
> > > > > 
> > > > > More data is normally a good thing. If you or anyone else wants to
> > > > > collect stats:
> > > > > From my git link above, it's as simple as running the normal ; cmake;
> > > > > make ; ./kinittest -median 5
> > > > 
> > > > On my very old/very slow computer seems to make a lot of difference
> > > > 
> > > > RESULT : DaveTest::testQProcess():
> > > >  2,625 msecs per iteration (total: 2,625, iterations: 1)
> > > > 
> > > > RESULT : DaveTest::testKInit():
> > > >  1,852 msecs per iteration (total: 1,852, iterations: 1)
> > > > 
> > > > RESULT : DaveTest::testQProcess():
> > > >  2,390 msecs per iteration (total: 2,390, iterations: 1)
> > > > 
> > > > RESULT : DaveTest::testKInit():
> > > >  1,846 msecs per iteration (total: 1,846, iterations: 1)
> > > 
> > > Hey Albert,
> > > 
> > > these numbers are quite impressive but I can't quite explain those. Are
> > > you
> > > measuring maybe a full debug build without any compiler optimizations?
> > 
> > I obviously can't remember, this was *months* ago, but i just ran the test
> > again (making sure -O3 was there and not any -g) and got a bit different
> > results, so maybe it was.
> 
> Does this apply to your whole stack (instead of just the inittest from Dave)?

Yes

> 
> > New results:
> >  * testQProcess: 2200 msec per iteration
> >  * testKInit:1700 msec per iteration
> > 
> > Still a 20% speed improvement.
> > 
> > > Then
> > > the library sizes will be _much_ larger and thus trigger more page faults.
> > > If every one of those is extremely slow on that machine compared to more
> > > modern machines?
> > > 
> > > May I ask how old this machine is and what the speed of the HDD is?
> > 
> > It's a Lenovo ideapad S10-3t, around 10 years old, the HDD is slow. But it's
> > of similar power to the Librecomputer La Frite i just got for free at
> > LinuxAppSummit, so even this is on the slow end of things we support i
> > think there's value on supporting it.
> > 
> > If you're interested i can arrange you to get ssh access to the machine (the
> > ideapad, i don't have all the KF5/Qt stack built for the LaFrite).
> 
> Yes, that would be interesting for me!

I sent you the details on private.

Cheers,
  Albert

> 
> Cheers
> 

Re: KInit - Current state and benchmarks

[Albert Astals Cid]

El dissabte, 23 de novembre de 2019, a les 11:47:40 CET, Milian Wolff va 
escriure:
> On Mittwoch, 19. Juni 2019 19:57:56 CET Albert Astals Cid wrote:
> > El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va 
> escriure:
> > > > Are we sure it's fair to assume people have SSD? our of the 4 laptops i
> > > > own, only 2 have SSD.> 
> > > It's at least safe to assume it's the trend moving forward.
> > > 
> > > > Do you think it's worth me trying in one of the two that don't have SSD?
> > > 
> > > More data is normally a good thing. If you or anyone else wants to
> > > collect stats:
> > > From my git link above, it's as simple as running the normal ; cmake;
> > > make ; ./kinittest -median 5
> > 
> > On my very old/very slow computer seems to make a lot of difference
> > 
> > RESULT : DaveTest::testQProcess():
> >  2,625 msecs per iteration (total: 2,625, iterations: 1)
> > RESULT : DaveTest::testKInit():
> >  1,852 msecs per iteration (total: 1,852, iterations: 1)
> > 
> > 
> > RESULT : DaveTest::testQProcess():
> >  2,390 msecs per iteration (total: 2,390, iterations: 1)
> > RESULT : DaveTest::testKInit():
> >  1,846 msecs per iteration (total: 1,846, iterations: 1)
> 
> Hey Albert,
> 
> these numbers are quite impressive but I can't quite explain those. Are you 
> measuring maybe a full debug build without any compiler optimizations? 

I obviously can't remember, this was *months* ago, but i just ran the test 
again (making sure -O3 was there and not any -g) and got a bit different 
results, so maybe it was.

New results:
 * testQProcess: 2200 msec per iteration
 * testKInit:1700 msec per iteration

Still a 20% speed improvement.

> Then 
> the library sizes will be _much_ larger and thus trigger more page faults. If 
> every one of those is extremely slow on that machine compared to more modern 
> machines?
> 
> May I ask how old this machine is and what the speed of the HDD is?

It's a Lenovo ideapad S10-3t, around 10 years old, the HDD is slow. But it's of 
similar power to the Librecomputer La Frite i just got for free at 
LinuxAppSummit, so even this is on the slow end of things we support i think 
there's value on supporting it.

If you're interested i can arrange you to get ssh access to the machine (the 
ideapad, i don't have all the KF5/Qt stack built for the LaFrite).

Cheers,
  Albert

> 
> Thanks
> 
> 

Re: KScreen/libkscreen commit message policies

[Albert Astals Cid]

El dilluns, 11 de novembre de 2019, a les 23:25:34 CET, Albert Astals Cid va 
escriure:
> El dilluns, 11 de novembre de 2019, a les 22:41:18 CET, Roman Gilg va 
> escriure:
> > Hi,
> > 
> > I just pushed commit message policies to KScreen [1] and libkscreen
> > [2] (linked below from GitHub so they can be read with Markdown
> > formatted).
> 
> That's not how it works, you can't override the manifesto that says we can 
> all push everywhere :)

I think i kind of did a fool of myself by commenting before reading the article.

I can't really find stuff openly against the manifesto on it.

Sorry for being a bad community member :/

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > 
> > I intend to revert in the future all manual commits to KScreen and
> > libkscreen deliberately ignoring the policies. Here "manual" means
> > here that I won't revert commits based on a script that are regularly
> > pushed to many repositories (like release number changes) or
> > automatically named merge commits.
> > 
> > If you have questions or other comments you can also reach me on IRC
> > #plasma, romangg.
> > 
> > Thanks,
> > Roman
> > 
> > [1] https://github.com/KDE/kscreen/blob/master/CONTRIBUTING.md
> > [2] https://github.com/KDE/libkscreen/blob/master/CONTRIBUTING.md
> > 
> 
> 
> 
> 
> 

Re: KScreen/libkscreen commit message policies

[Albert Astals Cid]

El dilluns, 11 de novembre de 2019, a les 22:41:18 CET, Roman Gilg va escriure:
> Hi,
> 
> I just pushed commit message policies to KScreen [1] and libkscreen
> [2] (linked below from GitHub so they can be read with Markdown
> formatted).

That's not how it works, you can't override the manifesto that says we can all 
push everywhere :)

Cheers,
  Albert

> 
> I intend to revert in the future all manual commits to KScreen and
> libkscreen deliberately ignoring the policies. Here "manual" means
> here that I won't revert commits based on a script that are regularly
> pushed to many repositories (like release number changes) or
> automatically named merge commits.
> 
> If you have questions or other comments you can also reach me on IRC
> #plasma, romangg.
> 
> Thanks,
> Roman
> 
> [1] https://github.com/KDE/kscreen/blob/master/CONTRIBUTING.md
> [2] https://github.com/KDE/libkscreen/blob/master/CONTRIBUTING.md
> 

D24614: Micro optimizations

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R31 Breeze

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

To: aacid, zzag
Cc: zzag, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, 
GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D24614: Micro optimizations

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  Add some const & for things that return const & so there's no need to make a 
copy
  Add a std::move for a thing that we pass by copy and it's just saved in 
another variable

REPOSITORY
  R31 Breeze

BRANCH
  master

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

AFFECTED FILES
  kstyle/animations/breezescrollbarengine.cpp
  kstyle/breezeframeshadow.cpp
  kstyle/breezehelper.cpp
  kstyle/breezemdiwindowshadow.cpp
  kstyle/breezemdiwindowshadow.h
  kstyle/breezestyle.cpp

To: aacid
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D19337: Fixed some undefined properties runtime errors.

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R169 Kirigami

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

To: malteveerman, #kirigami, mart, aacid
Cc: aacid, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, 
davidedmundson, mart, hein

D23713: strongswan support for custom proposals

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R116:9d88ac7082cf: strongswan support for custom proposals 
(authored by rrichmond, committed by aacid).
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D23713?vs=65799=65969#toc

REPOSITORY
  R116 Plasma Network Management Applet

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D23713?vs=65799=65969

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

AFFECTED FILES
  vpn/strongswan/nm-strongswan-service.h
  vpn/strongswan/strongswanprop.ui
  vpn/strongswan/strongswanwidget.cpp

To: rrichmond, fvogt, jgrulich
Cc: plasma-devel, pino, kde-frameworks-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, fbampaloukas, GB_2, ragreen, Pitel, michaelh, ZrenBot, ngraham, 
bruns, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
mart

D19337: Fixed some undefined properties runtime errors.

[Albert Astals Cid]

aacid added a comment.


  does not merge cleanly into "origin/master"
  
  Could you please rebase it?

REPOSITORY
  R169 Kirigami

BRANCH
  master

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

To: malteveerman, #kirigami, mart
Cc: aacid, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, apol, 
davidedmundson, mart, hein

D22976: Fix compilation

[Albert Astals Cid]

aacid added a comment.


  And what are you or ben waiting for? You've both got commit access :)

REPOSITORY
  R120 Plasma Workspace

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

To: ngraham, #plasma, aacid
Cc: usta, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D22691: Remove the share dataengine.

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R120 Plasma Workspace

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

To: aacid, davidedmundson
Cc: apol, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, mart

D19676: Fix out of bounds access error in SystemLoadViewer.qml

[Albert Astals Cid]

aacid added a comment.


  This is unlandable in KDE at this point because (say our sysadmins) "the 
nameservers for the domain estada.ch are highly unreliable and fail fairly 
often." and our git is very picky and doesn't like that.
  
  I don't particularly care about this piece of code, but if you do i guess you 
should try to fix that, or give us a different email address to use.

REPOSITORY
  R114 Plasma Addons

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

To: stefantux, #plasma, davidedmundson
Cc: aacid, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D22691: Remove the share dataengine.

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  It seems it's unused and also is the only source code in all of the KDE repos 
that uses kjsembed

REPOSITORY
  R120 Plasma Workspace

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  dataengines/CMakeLists.txt
  dataengines/share/CMakeLists.txt
  dataengines/share/Messages.sh
  dataengines/share/backends/CMakeLists.txt
  dataengines/share/backends/im9/CMakeLists.txt
  dataengines/share/backends/im9/contents/code/main.js
  dataengines/share/backends/im9/metadata.desktop
  dataengines/share/backends/imgsusepasteorg/CMakeLists.txt
  dataengines/share/backends/imgsusepasteorg/contents/code/main.js
  dataengines/share/backends/imgsusepasteorg/metadata.desktop
  dataengines/share/backends/imgur/CMakeLists.txt
  dataengines/share/backends/imgur/contents/code/main.js
  dataengines/share/backends/imgur/metadata.desktop
  dataengines/share/backends/kde/CMakeLists.txt
  dataengines/share/backends/kde/contents/code/main.js
  dataengines/share/backends/kde/metadata.desktop
  dataengines/share/backends/pastebincom/CMakeLists.txt
  dataengines/share/backends/pastebincom/contents/code/main.js
  dataengines/share/backends/pastebincom/metadata.desktop
  dataengines/share/backends/pasteopensuseorg/CMakeLists.txt
  dataengines/share/backends/pasteopensuseorg/contents/code/main.js
  dataengines/share/backends/pasteopensuseorg/metadata.desktop
  dataengines/share/backends/pasteubuntucom/CMakeLists.txt
  dataengines/share/backends/pasteubuntucom/contents/code/main.js
  dataengines/share/backends/pasteubuntucom/metadata.desktop
  dataengines/share/backends/privatepaste/CMakeLists.txt
  dataengines/share/backends/privatepaste/contents/code/main.js
  dataengines/share/backends/privatepaste/metadata.desktop
  dataengines/share/backends/simplestimagehosting/CMakeLists.txt
  dataengines/share/backends/simplestimagehosting/contents/code/main.js
  dataengines/share/backends/simplestimagehosting/metadata.desktop
  dataengines/share/backends/wklej/CMakeLists.txt
  dataengines/share/backends/wklej/contents/code/main.js
  dataengines/share/backends/wklej/metadata.desktop
  dataengines/share/backends/wstaw/CMakeLists.txt
  dataengines/share/backends/wstaw/contents/code/main.js
  dataengines/share/backends/wstaw/metadata.desktop
  dataengines/share/data/plasma_shareprovider.desktop
  dataengines/share/packagestructure/CMakeLists.txt
  dataengines/share/packagestructure/plasma-packagestructure-share.desktop
  dataengines/share/packagestructure/share_package.cpp
  dataengines/share/packagestructure/share_package.h
  dataengines/share/plasma-dataengine-share.desktop
  dataengines/share/share.operations
  dataengines/share/shareengine.cpp
  dataengines/share/shareengine.h
  dataengines/share/shareprovider.cpp
  dataengines/share/shareprovider.h
  dataengines/share/shareservice.cpp
  dataengines/share/shareservice.h

To: aacid
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D19865: Linux softraid: Define _GNU_SOURCE for pipe2

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R106 KSysguard

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

To: awilcox, #plasma, davidedmundson, broulik
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D17552: Fix 2 typos

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R169 Kirigami

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

To: lepagevalleeemmanuel, ngraham, bshah
Cc: plasma-devel, fbampaloukas, domson, dkardarakos, apol, davidedmundson, 
mart, hein

D4775: Suggestion - newline ending after password to output

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R105 KDE SSH Password Dialog

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

To: martinkostolny, cfeck, davidedmundson
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D19440: Exclude non-managed devices from plasma-nm

[Albert Astals Cid]

aacid added a comment.


  @jgrulich should we land this?
  
  Alex is unsure you're convinced it's good

REPOSITORY
  R116 Plasma Network Management Applet

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

To: afiestas, #plasma, jgrulich
Cc: aacid, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D9388: Fix queued connection error

[Albert Astals Cid]

aacid closed this revision.
aacid added a comment.


  There's no minimizeall applet anymore

REPOSITORY
  R114 Plasma Addons

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

To: iromanov, graesslin, mart
Cc: aacid, davidedmundson, anthonyfieroni, plasma-devel, LeGast00n, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Re: RFC: Running clang-format across all Plasma (and more?) repos

[Albert Astals Cid]

El dijous, 11 de juliol de 2019, a les 16:18:08 CEST, David Edmundson va 
escriure:
> One topic discussed at the recent Plasma sprint was that we should run
> a code formatting tool (clang-format) over all our repos to ease all
> future review comments about whitespace.
> 
> All new contributions simply have to run the same tool and we get
> consistent code without having to comment on every minor thing in a
> review individually.
> 
> I've written up a wall of text outlining steps, challenges etc.
> https://phabricator.kde.org/T11214
> 
> Does anyone have any thoughts / objections?

If we don't get some sort of precommit hook or "Merge Request" stage support 
it'll be somewhat useless.

"No one" will run the tool manually before doing a commit, this means that 
you'll need to run the tool every N months because commits go ignoring the 
format. I don't think that'd be sustainable in the long runo

I know "automation" is in your plan, but AFAICS only as optional, i don't 
really think that's optional.

Cheers,
  Albert

> 
> David
> 

D22302: fix kstart5 crash on wayland

[Albert Astals Cid]

aacid added a comment.


  In D22302#491786 , @ngraham wrote:
  
  > Oh, this was already landed, but Phab didn't notice because its commit 
message was altered to no longer include the `Differential Revision: 
https://phabricator.kde.org/D22302` text. Closing manually.
  
  
  Yeah, sorry about that, arc patch failed because of how the diff file was 
created and i forgot to manually add the differential line when recreating the 
commit

REPOSITORY
  R126 KDE CLI Utilities

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

To: garrison, davidedmundson
Cc: aacid, ngraham, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D21980: Fix ocasional crash on the touchpad kded

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:920e39c2e5cc: Fix ocasional crash on the touchpad kded 
(authored by aacid).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21980?vs=60283=60285

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

AFFECTED FILES
  kcms/touchpad/src/backends/x11/libinputtouchpad.cpp

To: aacid, atulbi, ngraham
Cc: ngraham, knambiar, atulbi, plasma-devel, LeGast00n, jraleigh, fbampaloukas, 
GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D21915: Fix crash in the touchpad kded

[Albert Astals Cid]

aacid abandoned this revision.
aacid added a comment.


  ok, abandoning for https://phabricator.kde.org/D21980 then

REPOSITORY
  R119 Plasma Desktop

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

To: aacid
Cc: atulbi, knambiar, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D21980: Fix ocasional crash on the touchpad kded

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  Use the proper enabled property name

REPOSITORY
  R119 Plasma Desktop

BRANCH
  Plasma/5.16

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

AFFECTED FILES
  kcms/touchpad/src/backends/x11/libinputtouchpad.cpp

To: aacid
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D21915: Fix crash in the touchpad kded

[Albert Astals Cid]

aacid added a subscriber: atulbi.
aacid added a comment.


  In D21915#482182 , @knambiar wrote:
  
  > In D21915#482145 , @aacid wrote:
  >
  > > The other question is if "enabled" was ever the correct atom to check for
  > >
  > > libinput Tapping Enabled
  >
  >
  > I'm fairly sure we were checking for `libinput Tapping Enabled` atom in the 
past, and so does GNOME: 
https://gitlab.gnome.org/GNOME/gtk/blob/master/gdk/x11/gdkdevicemanager-xi2.c#L410
  
  
  I can't find any use of that, the current use of "enabled" was added by 
@atulbi

REPOSITORY
  R119 Plasma Desktop

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

To: aacid
Cc: atulbi, knambiar, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D21915: Fix crash in the touchpad kded

[Albert Astals Cid]

aacid added a comment.


  The other question is if "enabled" was ever the correct atom to check for
  
  In my system the atoms names are
  libinput Send Events Mode Enabled
  libinput Send Events Mode Enabled Default
  libinput Send Events Modes Available
  libinput Left Handed Enabled Default
  libinput Left Handed Enabled
  libinput Disable While Typing Enabled Default
  libinput Disable While Typing Enabled
  libinput Middle Emulation Enabled Default
  libinput Middle Emulation Enabled
  libinput Tapping Enabled
  libinput Tapping Enabled Default
  libinput Tapping Button Mapping Default
  libinput Tapping Button Mapping Enabled
  libinput Tapping Drag Enabled Default
  libinput Tapping Drag Enabled
  libinput Tapping Drag Lock Enabled Default
  libinput Tapping Drag Lock Enabled
  libinput Accel Speed Default
  libinput Accel Speed
  libinput Accel Profiles Available
  libinput Accel Profile Enabled Default
  libinput Accel Profile Enabled
  libinput Natural Scrolling Enabled Default
  libinput Natural Scrolling Enabled
  libinput Horizontal Scroll Enabled
  libinput Scroll Methods Available
  libinput Scroll Method Enabled Default
  libinput Scroll Method Enabled
  libinput Button Scrolling Button Default
  libinput Button Scrolling Button
  libinput Click Methods Available
  libinput Click Method Enabled Default
  libinput Click Method Enabled

REPOSITORY
  R119 Plasma Desktop

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

To: aacid
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D21915: Fix crash in the touchpad kded

[Albert Astals Cid]

aacid updated this revision to Diff 60091.
aacid added a comment.


  -mutable

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D21915?vs=60090=60091

BRANCH
  Plasma/5.16

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

AFFECTED FILES
  kcms/touchpad/src/backends/x11/libinputtouchpad.cpp
  kcms/touchpad/src/backends/x11/libinputtouchpad.h
  kcms/touchpad/src/backends/x11/synapticstouchpad.cpp
  kcms/touchpad/src/backends/x11/synapticstouchpad.h
  kcms/touchpad/src/backends/x11/xlibbackend.cpp
  kcms/touchpad/src/backends/x11/xlibtouchpad.h

To: aacid
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

D21915: Fix crash in the touchpad kded

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  My libinput touchpad doesn't have an enabled atom so doing
  
  *m_atoms[QLatin1Literal("enabled")].data()
  
  and then using that atom ends up with a crash
  
  So instead of asking the atom out, just pass the atom to compare in

TEST PLAN
  Unfortunately i can't really really reproduce the crash, it just happens 
every other day, so i can only say "this code is safer and should crash less"

REPOSITORY
  R119 Plasma Desktop

BRANCH
  Plasma/5.16

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

AFFECTED FILES
  kcms/touchpad/src/backends/x11/libinputtouchpad.cpp
  kcms/touchpad/src/backends/x11/libinputtouchpad.h
  kcms/touchpad/src/backends/x11/synapticstouchpad.cpp
  kcms/touchpad/src/backends/x11/synapticstouchpad.h
  kcms/touchpad/src/backends/x11/xcbatom.h
  kcms/touchpad/src/backends/x11/xlibbackend.cpp
  kcms/touchpad/src/backends/x11/xlibtouchpad.h

To: aacid
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, 
ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, mart

Re: KInit - Current state and benchmarks

[Albert Astals Cid]

El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va 
escriure:
> > Are we sure it's fair to assume people have SSD? our of the 4 laptops i 
> > own, only 2 have SSD.
> 
> It's at least safe to assume it's the trend moving forward.
> 
> > Do you think it's worth me trying in one of the two that don't have SSD?
> 
> More data is normally a good thing. If you or anyone else wants to
> collect stats:
> From my git link above, it's as simple as running the normal ; cmake;
> make ; ./kinittest -median 5


On my very old/very slow computer seems to make a lot of difference

RESULT : DaveTest::testQProcess():
 2,625 msecs per iteration (total: 2,625, iterations: 1)
RESULT : DaveTest::testKInit():
 1,852 msecs per iteration (total: 1,852, iterations: 1)


RESULT : DaveTest::testQProcess():
 2,390 msecs per iteration (total: 2,390, iterations: 1)
RESULT : DaveTest::testKInit():
 1,846 msecs per iteration (total: 1,846, iterations: 1)


So can we please keep/improve it?


Cheers,
  Albert

Re: KInit - Current state and benchmarks

[Albert Astals Cid]

El dilluns, 17 de juny de 2019, a les 11:56:15 CEST, David Edmundson va 
escriure:
> Results:
> (Showing the median out of 5 runs on a mid range SSD desktop)

Are we sure it's fair to assume people have SSD? our of the 4 laptops i own, 
only 2 have SSD.

Do you think it's worth me trying in one of the two that don't have SSD?

Cheers,
  Albert

Re: Review Request: plasma-thunderbolt

[Albert Astals Cid]

El dimecres, 15 de maig de 2019, a les 15:27:07 CEST, Daniel Vrátil va escriure:
> 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.

There's this cmake warning

CMake Warning at /usr/lib64/cmake/KF5Package/KF5PackageMacros.cmake:74 
(message):
  KPackage components should be specified in reverse domain notation.
  Appstream information won't be generated for kcm_bolt.
Call Stack (most recent call first):
  src/kcm/CMakeLists.txt:22 (kpackage_install_package)




clazy complains about a few Q_PROPERTY that should ideally either have a NOTIFY 
signal or be marked as CONSTANT

it also complains about a few const slots that return values. Seems like what 
you want is to actually mark them as invokable/scriptable and not as slots?

Cheers,
  Albert

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

D19064: Add break to fix tty information

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R111:dcb0901e5438: Add break to fix tty information (authored 
by aacid).

REPOSITORY
  R111 KSysguard Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19064?vs=51810=52784

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

AFFECTED FILES
  processcore/processes_linux_p.cpp

To: aacid, davidedmundson
Cc: apol, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, mart

D19064: Add break to fix tty information

[Albert Astals Cid]

aacid added a comment.


  If noone disagrees i'll commit this next week

REPOSITORY
  R111 KSysguard Library

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

To: aacid
Cc: apol, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, mart

D19186: [KCM & UI] Use the word "Sleep" instead of "Suspend"

[Albert Astals Cid]

aacid added a comment.


  -0.2 from my side, the thing is called suspend not sleep, if you look for 
"linux sleep" in a search engine you get references to the sleep (3) and sleep 
(1) man pages, which would only confuse the users.

REPOSITORY
  R122 Powerdevil

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

To: ngraham, #vdg, #plasma, broulik
Cc: aacid, plasma-devel, kde-doc-english, jraleigh, gennad, GB_2, ragreen, 
Pitel, ZrenBot, skadinna, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

D19135: DelegateRecycler: Fix translation using the wrong domain

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R169 Kirigami

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

To: aacid, mart
Cc: plasma-devel, dkardarakos, apol, davidedmundson, mart, hein

D19135: DelegateRecycler: Fix translation using the wrong domain

[Albert Astals Cid]

aacid created this revision.
aacid added a reviewer: mart.
Herald added a project: Kirigami.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  Use first KLocalizedContext as contextObject instead of the root one
  
  This way when there's a stack of contexts with KLocalizedContext we get the 
right one

REPOSITORY
  R169 Kirigami

BRANCH
  master

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

AFFECTED FILES
  src/delegaterecycler.cpp

To: aacid, mart
Cc: plasma-devel, dkardarakos, apol, davidedmundson, mart, hein

D19070: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R128 User Manager

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

To: aacid, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19069: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R123 SDDM Configuration Panel (KCM)

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

To: aacid, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19068: Use AuthCore instead Auth

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R258:03d4bab121eb: Use AuthCore instead Auth (authored by 
aacid).

REPOSITORY
  R258 Plymouth KCM

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19068?vs=51814=51837

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt

To: aacid, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19066: Link to AuthCore instead of Auth

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:a748fb9e9be1: Link to AuthCore instead of Auth (authored 
by aacid).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D19066?vs=51812=51835#toc

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19066?vs=51812=51835

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

AFFECTED FILES
  CMakeLists.txt
  runners/kill/CMakeLists.txt

To: aacid, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19067: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R119 Plasma Desktop

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

To: aacid, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19063: Use AuthCore instead of Auth

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R111:cd17327111d4: Use AuthCore instead of Auth (authored by 
aacid).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D19063?vs=51808=51834#toc

REPOSITORY
  R111 KSysguard Library

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19063?vs=51808=51834

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

AFFECTED FILES
  CMakeLists.txt
  processcore/CMakeLists.txt
  processui/CMakeLists.txt

To: aacid, apol
Cc: kdevelop-devel, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19062: Link against AuthCore instead of Auth

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R134:916ff7fa7a46: Link against AuthCore instead of Auth 
(authored by aacid).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D19062?vs=51807=51833#toc

REPOSITORY
  R134 Discover Software Store

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19062?vs=51807=51833

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

AFFECTED FILES
  CMakeLists.txt
  libdiscover/backends/SnapBackend/libsnapclient/CMakeLists.txt

To: aacid, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19055: Use the new KAuthCore

[Albert Astals Cid]

aacid closed this revision.

REPOSITORY
  R122 Powerdevil

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

To: aacid, apol
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19070: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  It's a smaller library and contains everything we need

TEST PLAN
  Compiles

REPOSITORY
  R128 User Manager

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19069: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid updated this revision to Diff 51816.
aacid added a comment.


  also update the KF5 requirement

REPOSITORY
  R123 SDDM Configuration Panel (KCM)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D19069?vs=51815=51816

BRANCH
  arcpatch-D19069

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19069: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  It's a smaller library and provides everything we need

TEST PLAN
  Compiles

REPOSITORY
  R123 SDDM Configuration Panel (KCM)

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19068: Use AuthCore instead Auth

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  It's a smaller library and provides everything we need

TEST PLAN
  Compiles

REPOSITORY
  R258 Plymouth KCM

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19067: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  is a smaller library and provides all we need

TEST PLAN
  Compiles

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  kcms/dateandtime/CMakeLists.txt
  kcms/kfontinst/dbus/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19066: Link to AuthCore instead of Auth

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  Is a smaller library and provides everything we need

REPOSITORY
  R120 Plasma Workspace

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  runners/kill/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19064: Add break to fix tty information

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  I'm not confident i understand the code, but without the break the value of 
ps->setTty is always overwritten, so i guess we need this? (or otherwise we 
have to remove the line after case 5: altogether)

REPOSITORY
  R111 KSysguard Library

BRANCH
  Plasma/5.15

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

AFFECTED FILES
  processcore/processes_linux_p.cpp

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19063: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid added a subscriber: kdevelop-devel.
aacid added a comment.


  KDevelope people the comment says to ask you too about it

REPOSITORY
  R111 KSysguard Library

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

To: aacid
Cc: kdevelop-devel, plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19063: Use AuthCore instead of Auth

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  Gives us what we need and has less dependencies

TEST PLAN
  Compiles

REPOSITORY
  R111 KSysguard Library

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  processcore/CMakeLists.txt
  processui/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19062: Link against AuthCore instead of Auth

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  It's a smaller library and provides everything we need

TEST PLAN
  Compiles

REPOSITORY
  R134 Discover Software Store

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  libdiscover/backends/SnapBackend/libsnapclient/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D19055: Use the new KAuthCore

[Albert Astals Cid]

aacid created this revision.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
aacid requested review of this revision.

REVISION SUMMARY
  Doesn't link to QtWidgets link KAuth does, which is unneeded for the helpers

TEST PLAN
  Compiles

REPOSITORY
  R122 Powerdevil

BRANCH
  master

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

AFFECTED FILES
  CMakeLists.txt
  daemon/backends/CMakeLists.txt

To: aacid
Cc: plasma-devel, jraleigh, GB_2, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D12278: [Colors KCM] Port to new design

[Albert Astals Cid]

aacid added a comment.


  Did this land in Plasma 5.15 on purpose or was it a mistake?

REPOSITORY
  R119 Plasma Desktop

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

To: broulik, #plasma, #vdg, davidedmundson
Cc: aacid, GB_2, nicolasfella, mart, abetts, ngraham, davidedmundson, 
plasma-devel, jraleigh, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, sebas, apol