Hi, I ran across this on the OpenSuSE user list. It's also a problem for me at login time; I've been starting Kmail and Konqueror manually because of it.
Will the suggestion using systemd, listed at the end, work in Trinity also?
TIA, Leslie ---------- Forwarded Message ----------
Subject: Re: Make Kwallet behave ? Date: 2022-08-28, 06:43:19 From: Adam Mizerski adam@mizerski.pl To: users@lists.opensuse.org
W dniu 28.08.2022 o 07:19, Nicolas Kovacs pisze:
Hi,
I've been a KDE user since version 2.x on Slackware more than 20 years ago. I really like it for my daily work, but some details are a bit of a PITA. Kwallet is one of them.
Here's a few scenarios that happen erratically on my Tumbleweed installations.
- KDE starts, Kwallet pops up immediately and leaves me about ten
seconds to type in my very long GPG password. In the background, applications that need a password to connect (like OwnCloud) fail and have to be restarted.
- KDE starts, Wi-Fi tries to connect but fails, OwnCloud asks me for
the connection password, and after about a minute or so, Kwallet decides to pop up too late to the show.
- KDE starts, Kwallet pops up, I type in my password fast enough, Wi-Fi
connects but OwnCloud asks me for the connection password even though Kwallet has been opened successfully.
Any idea how I can make Kwallet behave ?
Cheers from the sunny South of France,
Niki
I have the same problem.
I just had an idea, but it needs some experimenting to check whether it would work. Recently KDE introduced managing it's services with systemd [1]. Systemd allows to extend units using "foo.service.d" directories [2]. Maybe it would be possible to inject a dependency between kwallet and nextcloud?
In my case it looks like this:
- kwallet runs under "dbus-:1.2-org.kde.kwalletd5@0.service"
- nextcloud runs under
"app-com.nextcloud.desktopclient.nextcloud-<random_id>.scope".
- both units are "a transient unit file, created programmatically via
the systemd API. Do not edit."
You can see all systemd units (they form a tree) using "systemctl --user status".
I'll try to do some experiments with it.
[1] https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ [2] "man systemd.unit" or https://www.freedesktop.org/software/systemd/man/systemd.unit.html
Unfortunately it's not a solution, but for the record: https://github.com/nextcloud/desktop/issues/1011
------------------------------------------------------- -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.12 tde-config: 1.0
systemd is not the salvation, it's svchost.exe
First identify what program wants access to kwallet. Then find out, why these program(s) start at session startup.
Nik
Anno domini 2022 Sun, 28 Aug 12:24:12 -0500 J Leslie Turriff scripsit:
Hi, I ran across this on the OpenSuSE user list. It's also a problem for me at login time; I've been starting Kmail and Konqueror manually because of it.
Will the suggestion using systemd, listed at the end, work in Trinity also?
TIA, Leslie ---------- Forwarded Message ----------
Subject: Re: Make Kwallet behave ? Date: 2022-08-28, 06:43:19 From: Adam Mizerski adam@mizerski.pl To: users@lists.opensuse.org
W dniu 28.08.2022 o 07:19, Nicolas Kovacs pisze:
Hi,
I've been a KDE user since version 2.x on Slackware more than 20 years ago. I really like it for my daily work, but some details are a bit of a PITA. Kwallet is one of them.
Here's a few scenarios that happen erratically on my Tumbleweed installations.
- KDE starts, Kwallet pops up immediately and leaves me about ten
seconds to type in my very long GPG password. In the background, applications that need a password to connect (like OwnCloud) fail and have to be restarted.
- KDE starts, Wi-Fi tries to connect but fails, OwnCloud asks me for
the connection password, and after about a minute or so, Kwallet decides to pop up too late to the show.
- KDE starts, Kwallet pops up, I type in my password fast enough, Wi-Fi
connects but OwnCloud asks me for the connection password even though Kwallet has been opened successfully.
Any idea how I can make Kwallet behave ?
Cheers from the sunny South of France,
Niki
I have the same problem.
I just had an idea, but it needs some experimenting to check whether it would work. Recently KDE introduced managing it's services with systemd [1]. Systemd allows to extend units using "foo.service.d" directories [2]. Maybe it would be possible to inject a dependency between kwallet and nextcloud?
In my case it looks like this:
- kwallet runs under "dbus-:1.2-org.kde.kwalletd5@0.service"
- nextcloud runs under
"app-com.nextcloud.desktopclient.nextcloud-<random_id>.scope".
- both units are "a transient unit file, created programmatically via
the systemd API. Do not edit."
You can see all systemd units (they form a tree) using "systemctl --user status".
I'll try to do some experiments with it.
[1] https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/ [2] "man systemd.unit" or https://www.freedesktop.org/software/systemd/man/systemd.unit.html
Unfortunately it's not a solution, but for the record: https://github.com/nextcloud/desktop/issues/1011
-- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.12 tde-config: 1.0 ____________________________________________________ tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydeskt...
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
On 2022-08-28 14:25:15 Dr. Nikolaus Klepp wrote:
systemd is not the salvation, it's svchost.exe
First identify what program wants access to kwallet. Then find out, why these program(s) start at session startup.
Nik
Well, I /want/ them to start at session startup, but I want kwallet to start /first/, and there doesn't seem to be any way to specify a priority or dependence in Autostart Manager.
Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.12 tde-config: 1.0
Hi Leslie,
Am Sonntag, 28. August 2022 schrieb J Leslie Turriff:
Hi, I ran across this on the OpenSuSE user list. It's also a problem for me at login time; I've been starting Kmail and Konqueror manually because of it.
The problem is not really clear to me. The user you are citing doesn't provide any information about his configuration settings.
I understand you want kwallet to start before an application starts which needs a password.
I had this working for years on TDE/Debian or Devuan. I configured kwallet to show up in the systray. A saved TDE session which automatically starts kmail works fine. Kwallet sits in systray and kmail is started. When kmail wants to get new mails, kwallet's dialog pops up to get the password.
Kmail is configured not to fetch new mails at start-up time, though. I guess it's not exactly what you wanted.
HTH
Kind regards, Stefan
On 2022-08-30 03:12:24 Stefan Krusche wrote:
Hi Leslie,
Am Sonntag, 28. August 2022 schrieb J Leslie Turriff:
Hi, I ran across this on the OpenSuSE user list. It's also a problem for me at login time; I've been starting Kmail and Konqueror manually because of it.
The problem is not really clear to me. The user you are citing doesn't provide any information about his configuration settings.
I understand you want kwallet to start before an application starts which needs a password.
I had this working for years on TDE/Debian or Devuan. I configured kwallet to show up in the systray. A saved TDE session which automatically starts kmail works fine. Kwallet sits in systray and kmail is started. When kmail wants to get new mails, kwallet's dialog pops up to get the password.
Kmail is configured not to fetch new mails at start-up time, though. I guess it's not exactly what you wanted.
HTH
Kind regards, Stefan
That's right, when kmail is configured to fetch mail at startup, it wants kwallet to be available. That's not too big an issue because it pops up the kwallet login. The worse one is konqueror, whose connections to other servers via fish fail when kwallet is not already running; konqueror doesn't try to start kwallet, just fails the connection.
Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.12 tde-config: 1.0
Am Dienstag, 30. August 2022 schrieb J Leslie Turriff:
On 2022-08-30 03:12:24 Stefan Krusche wrote:
I had this working for years on TDE/Debian or Devuan. I configured kwallet to show up in the systray. A saved TDE session which automatically starts kmail works fine. Kwallet sits in systray and kmail is started. When kmail wants to get new mails, kwallet's dialog pops up to get the password.
That's right, when kmail is configured to fetch mail at startup, it wants kwallet to be available. That's not too big an issue because it pops up the kwallet login. The worse one is konqueror, whose connections to other servers via fish fail when kwallet is not already running; konqueror doesn't try to start kwallet, just fails the connection.
When a TDE session with kwallet running is saved then kwallet should be running the next time you log in to that saved TDE-session. Maybe that suffices to provide kwallet access to konqueror when you start it then.
Cheers, Stefan
On 2022-08-31 02:44:53 Stefan Krusche wrote:
Am Dienstag, 30. August 2022 schrieb J Leslie Turriff:
On 2022-08-30 03:12:24 Stefan Krusche wrote:
I had this working for years on TDE/Debian or Devuan. I configured kwallet to show up in the systray. A saved TDE session which automatically starts kmail works fine. Kwallet sits in systray and kmail is started. When kmail wants to get new mails, kwallet's dialog pops up to get the password.
That's right, when kmail is configured to fetch mail at startup, it wants kwallet to be available. That's not too big an issue because it pops up the kwallet login. The worse one is konqueror, whose connections to other servers via fish fail when kwallet is not already running; konqueror doesn't try to start kwallet, just fails the connection.
When a TDE session with kwallet running is saved then kwallet should be running the next time you log in to that saved TDE-session. Maybe that suffices to provide kwallet access to konqueror when you start it then.
Cheers, Stefan
Hmmm... that doesn't seem to be working for me. My Personal Settings => Session Manager is attached.
Leslie
-- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.12 tde-config: 1.0
On 2022-09-02 04:28:11 Stefan Krusche wrote:
Am Freitag, 2. September 2022 schrieb J Leslie Turriff:
Hmmm... that doesn't seem to be working for me. My Personal Settings => Session Manager is attached.
You need activate "Restore manually saved session"…
HTH
Cheers, Stefan
Control Center says, | "Restore manually saved session | | Instead of restoring TDE to the state it was when you logged out last, | it will be restored to a specific state that you have saved manually." but 1) how does one save the session state manually? (I would expect an option in the Logout dialog, but there is none there.) 2) will that somehow remember the order for starting the applications at the next login? I see also that in Service Manager, the KDE Wallet Daemon Module is in the Load-on-Demand Services list (the last entry), and | "This is a list of available TDE services that will be started on demand. | They are only listed for convenience, as you cannot manipulate these services." which makes me wonder about the starup order.
Leslie
On 2022-09-03 03:26:13 Stefan Krusche wrote:
Am Freitag, 2. September 2022 schrieb J Leslie Turriff:
1) how does one save the session state manually?
It's an item in TDE-Menu (startup menu), the third from below here.
Cheers, Stefan
Maybe I'm looking in the wrong place? (See attached)
Leslie
Am Samstag, 3. September 2022 schrieb J Leslie Turriff:
On 2022-09-03 03:26:13 Stefan Krusche wrote:
Am Freitag, 2. September 2022 schrieb J Leslie Turriff:
1) how does one save the session state manually?
It's an item in TDE-Menu (startup menu), the third from below here.
Cheers, Stefan
Maybe I'm looking in the wrong place? (See attached)
No, right place, but yes, there's no "Save session" in your TDE menu. In mine it's between "Lock session" and "Lock Out…". I don't know/remember if I did something to activate that… BTW, how do you manage to get a screenshot of the opened menu?!
Stefan
On Tue September 6 2022 01:38:45 Stefan Krusche wrote:
No, right place, but yes, there's no "Save session" in your TDE menu. In mine it's between "Lock session" and "Lock Out…". I don't know/remember if I did something to activate that… BTW, how do you manage to get a screenshot of the opened menu?!
The option to save a session appears if you change Trinity Control Center / / TDE Components / Sessions Manager / On Login to "Restore Manually Saved Session".
--Mike
Am Dienstag, 6. September 2022 schrieb Mike Bird:
On Tue September 6 2022 01:38:45 Stefan Krusche wrote:
No, right place, but yes, there's no "Save session" in your TDE menu. In mine it's between "Lock session" and "Lock Out…". I don't know/remember if I did something to activate that… BTW, how do you manage to get a screenshot of the opened menu?!
The option to save a session appears if you change Trinity Control Center / / TDE Components / Sessions Manager / On Login to "Restore Manually Saved Session".
Ah, ja, thanks, I've been thinking there was something…
Cheers, Stefan
On 2022-09-06 05:28:25 Mike Bird wrote:
On Tue September 6 2022 01:38:45 Stefan Krusche wrote:
No, right place, but yes, there's no "Save session" in your TDE menu. In mine it's between "Lock session" and "Lock Out…". I don't know/remember if I did something to activate that… BTW, how do you manage to get a screenshot of the opened menu?!
The option to save a session appears if you change Trinity Control Center / / TDE Components / Sessions Manager / On Login to "Restore Manually Saved Session".
--Mike
Huh. Having to set this in order to save the session is rather non-intuitive.
Leslie
On 2022-09-06 03:38:45 Stefan Krusche wrote:
Am Samstag, 3. September 2022 schrieb J Leslie Turriff:
On 2022-09-03 03:26:13 Stefan Krusche wrote:
Am Freitag, 2. September 2022 schrieb J Leslie Turriff:
1) how does one save the session state manually?
It's an item in TDE-Menu (startup menu), the third from below here.
Cheers, Stefan
Maybe I'm looking in the wrong place? (See attached)
No, right place, but yes, there's no "Save session" in your TDE menu. In mine it's between "Lock session" and "Lock Out…". I don't know/remember if I did something to activate that… BTW, how do you manage to get a screenshot of the opened menu?!
Stefan
In KSnapshot, change Capture mode to anything but Region, then set Snapshot delay to a value that lets you open the menu. (For some reason, Snapshot delay is disabled only for the Region mode, which is very irritating.)
Leslie
On 2022-09-07 04:13:37 Stefan Krusche wrote:
Am Dienstag, 6. September 2022 schrieb J Leslie Turriff:
In KSnapshot, change Capture mode to anything but Region, then set Snapshot delay to a value that lets you open the menu.
Thanks, that worked.
Cheers, Stefan
Any idea why Region doesn't support Delay?
Leslie
Am Donnerstag, 8. September 2022 schrieb J Leslie Turriff:
On 2022-09-07 04:13:37 Stefan Krusche wrote:
Am Dienstag, 6. September 2022 schrieb J Leslie Turriff:
In KSnapshot, change Capture mode to anything but Region, then set Snapshot delay to a value that lets you open the menu.
Thanks, that worked.
Cheers, Stefan
Any idea why Region doesn't support Delay?
Sorry, no. Technical reason (harder to implement)? Use case? Because of mouse involvement?
Cheers, Stefan
Am Freitag, 2. September 2022 schrieb J Leslie Turriff:
2) will that somehow remember the order for starting the applications at the next login?
I don't know.
I see also that in Service Manager, the KDE Wallet Daemon Module is in the Load-on-Demand Services list (the last entry), and
| "This is a list of available TDE services that will be | started on demand. They are only listed for convenience, as you | cannot manipulate these services."
which makes me wonder about the starup order.
Well, that's fine, I guess. Kwallet needs to be started on demand when another application requires a saved password. I think if you "activate" kwallet in its settings dialog it will be running anyway, not only on demand. That is how I use it.
If kwallet sits in systray (is already running) and you save that session it will be started at session start-up time so it's already there when i.e. kmail needs passwords to retrieve mail etc.
I remember to also have had kmail saved in a session and can't remember any problems related to kmail/kwallet so I think the system is smart enough to start kwallet before kmail when both are lauched from a saved session start up (but I can't confirm that technically by reading the source…)
HTH
Kind regards, Stefan
Am Freitag, 2. September 2022 schrieb J Leslie Turriff:
On 2022-08-31 02:44:53 Stefan Krusche wrote:
Am Dienstag, 30. August 2022 schrieb J Leslie Turriff:
On 2022-08-30 03:12:24 Stefan Krusche wrote:
I had this working for years on TDE/Debian or Devuan. I configured kwallet to show up in the systray. A saved TDE session which automatically starts kmail works fine. Kwallet sits in systray and kmail is started. When kmail wants to get new mails, kwallet's dialog pops up to get the password.
That's right, when kmail is configured to fetch mail at startup, it wants kwallet to be available. That's not too big an issue because it pops up the kwallet login. The worse one is konqueror, whose connections to other servers via fish fail when kwallet is not already running; konqueror doesn't try to start kwallet, just fails the connection.
When a TDE session with kwallet running is saved then kwallet should be running the next time you log in to that saved TDE-session. Maybe that suffices to provide kwallet access to konqueror when you start it then.
Cheers, Stefan
Hmmm... that doesn't seem to be working for me. My Personal Settings => Session Manager is attached.
You also seem to have some applications excluded from being saved with the session regardless if it is manually saved or automatically (last session): kmail:konqueror:waterfox:keepassxc: …
Check that you don't exclude applications which you want to get started when restoring a saved session.
Stefan