I use ktimer installed from Debian Live LXQt ISO 12.6.0.
Simple commands could be run from the command line, like speaker-test. But not a little more complex command, like aplay ~/wave.wav.
When this didn’t work, I tried: XDG_RUNTIME_DIR=/run/user/$(id -u) aplay ~/wave.wav
Tried to catch errors from terminal: XDG_RUNTIME_DIR=/run/user/$(id -u) /usr/bin/aplay ~/wave.wav > ~/ktimer.log 2>&1
Tried wrapping: "aplay ~/wave.wav"
Created a script, making it executable, then ran the script from command line: ~./script.sh
With both full path and symbolic path ~/
All efforts yielded a zero (or a negative ) outcome.
If someone has been successful in playing a wave file using the command line, then may please the info be passed on to me.
Hi! One question to start off here: is your interest specifically in playing a sound file, or is that more of an example of a command that takes arguments?
And just wondering, have you tried without using the ~ to represent your home, but by explicitly giving the full path (ex. /home/username/) just in case? I had read that there had been some issues at some point with expanding out the tilde, and was thinking maybe those issues were cropping up again somehow?
Hmm - do the contents of the script itself use the full path as well?
Are you seeing any messages in your system journal / logs when the timer fails to execute those commands? For example, running sudo journalctl --since=5m should show any such messages if run within 5 minutes of when it should have triggered.
For my system, the correct line is: journalctl --since "5 minutes ago"
Tried. No relevant journal entry.
Then, instead of directly using sudo, I added adm and systemd-journal to the user group and then ran journalctl.
No relevant output for inaction of ktimer.
I 'd tried to capture error earlier, but no errors caught.
Let us address the problem differently. The exact section of the source code should be looked into to determine the limitations and restrictions of the environment of the console that is interacted with via the Command line textbox.
By all means, the environment of the console accessed with the Command line textbox is far limited from a normal console/terminal.
If the internet is searched with an external search engine with keywords “ktimer problem does not” , many limitations of ktimer would come up in the search output.
So the source code holds the key. The functionality of the terminal, if altered, could solve this issue.
Yes, the screenshot seems to support your point. The version of ktimer in my system is 4:22.12.3-1. May be this one is compiled defective. Let me see if other editions work fine.
What is the version in your system?
Debian has many timers including kteatime.
Thanks for the screenshots. I will look into kteatime and the rest.
Ok, then my LXQt DE is incorrectly functioning with ktimer.
Attention is drawn to the incorrect way ktimer (or the system interface of the LXQt DE) incorrectly records the Path of file.
The correct path would usually be interpreted by a conversant user as /home/user/Music/filename.
The code on the Command line is aplay /home/user/Music/filename. But it could be observed how the interface garbles the path.
Thank you. I have the necessary info. Let me see if I can make a headway.
Postscript:
(1) I have brought the matter to the notice of the LXQt Team in their Discussion page in the Q&A category, with a question:
Does LXQt DE have a bug that convolutes ktimer? Or the other way round?
in https github . com lxqt discussions 2665.
(2) I already have a workaround to the current problem by having the Command line open a terminal and then execute the necessary command: qterminal -e "bash -c '~/Music/aplay_sound.sh; exec bash'", but I don’t like using this trick.
I want to know the reason for the problem and a clear solution.
LXQt maintainers/developers have responded to my query. They have pointed out to me – their replies could be perused from the link provided earlier – that ktimer weirdly connects a Command line textbox with a 'File open' dialog. It is this coupling that causes the confusion in the software, as shown in my screenshot in the Post no.9 above.
I have located the GitHub code repository for ktimer at https github . com / KDE / ktimer but there isn’t a discussion page.
It seems that the forum is framed in a way that restricts new posters from posting external links. But no issues. I am ok with these restrictions.
So how could the team developers of ktimer be contacted to pass on the observations that have been collected by my experience with this issue? About how I have been able to bypass the limitations of the Command line textbox.
For those who might be interested, the bypass is this:
I won’t write to individual developers of the package unsolicited.
Hi - KDE code repositories are mirrored onto GitHub for convenience, but the instances where work is happening are on a GitLab instanced called KDE Invent - for example, the code for KTimer is maintained here: Utilities / KTimer · GitLab
Bug reports and feature requests from users to developers happens through the KDE Bugzilla instance, and the community guide to completing and submitting an effective ticket is located here: Get Involved/Issue Reporting - KDE Community Wiki
For what it’s worth, I don’t know if using an “Open file” dialog for the command line field is conceptually inappropriate. However, from my own attempts to reproduce what you’ve been doing, I do agree that it’s hard to intuitively figure out what inputs are acceptable to get the result you’re looking for there.
Please then pass on the information gleaned from the discussion here and in GitHub LXQt to the team developers at KDE. Also, how I bypassed the limitation and if a rigorous method could be found to improve upon what I discovered.
Also, please un-restrict my present inability to post URL links in my posts.
Since you’re the one who’s experienced this issue and worked through the steps to reproduce and workaround, it would be best reported by you through the steps in the Issue Reporting link above
Posting external links is restricted for new accounts as a spam control measure - however, that ability is automatically granted by the Discourse software after a certain amount of activity.
This is what precipitates my distrust against automation and donation based ecosystem. This appears similar to the Marxist-Maoist-Leftist construct. Imagine your personal toil to enhance your scores in evaluation tests and your social stature getting replaced by the class performance average! A sure debacle.
Each individual is unique. So the evaluation system should accommodate and celebrate that uniqueness. Without which the system shall fail. Definitely fail.
Yes, but it also involves unnecessary toil. I use Debian LXQt, with some packages from KDE. Though I like those KDE packages that I use very much, the process of Bug Reporting is much detailed, lengthy and unduly automated, compelling me to keep a record of my password, etc. So I’d better not.
I have already talked to the developers of LXQt and presently in the process of convincing them to build a similar timer. They said that they would not prefer to use the KDE source code, but build from grounds up. The discussion could be perused from the afore-mentioned webpage.
I have shared my experience and that should be enough for individuals to work collaboratively and post a Bug Report. If there isn’t an automatic process of registering flaws then the system shall fail. Bound to fail.
Which is why I prefer RPOSS, rationalised Paid Open Source System, drawing inspiration from Dr. Stalman’s article on FOSS. ‘Freebie’ and ‘Donation’ are fatal to the spirit of the Social Contract.
) outcome.
