from:"cat"

https://bugs.kde.org/show_bug.cgi?id=481132

Bug ID: 481132
   Summary: According documentation »kalarm« allows calendar
directories where each event is a single ICS file – in
practice it doesn't
Classification: Applications
   Product: kalarm
   Version: 3.5.4.2
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: djar...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

SUMMARY
According
https://docs.kde.org/stable5/en/kalarm/kalarm/create-edit.html#calendars
(search for the heading "Storage type") is claimed:
> KAlarm handles two alarm calendar storage types:
> …
> Local directory: Alarms are stored in a local folder, each alarm being stored 
> in a separate iCalendar file within the folder. 
> This storage method has the advantage that in the event of file corruption, 
> you should lose only one alarm, 
> not the entire calendar.

Exactly for that reason I wanted to create a "Local directory" calendar but
»kalarm« only allows to choose a 
local ICS file (i.e. all events lumped together within a single).


STEPS TO REPRODUCE
1. open »kalarm« and add a new calendar
2. the popup window only allows to select a single ICS file, not a directory
and provides no way to create a "Local directory" calendar.

OBSERVED RESULT
No option to add a "Local directory" calendar in contrast to documentation:

> Add...
>
>Add a calendar of the selected type to the list. You are asked to choose a 
> storage type, following which the calendar 
> configuration dialog is displayed, where you can enter the location of the 
> calendar and its characteristics. If there is no 
> existing alarm calendar in the specified location, a new one will be created.

EXPECTED RESULT
»kalarm« provides the choice of storage type as documented and implements
adding "Local directory" calendars.
(much less prefered solution: documentation is corrected … ;-)

SOFTWARE/OS VERSIONS
[copied from System Information]
Operating System: openSUSE Leap 15.5
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150500.55.44-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481068] The power to run a command upon a notification is severely limited by lack of information

https://bugs.kde.org/show_bug.cgi?id=481068

--- Comment #2 from Flossy Cat  ---
My bug report demonstrates there is user request for this feature and the
decision is contended: 
https://bugs.kde.org/show_bug.cgi?id=481069

These solitary declarations of unmaintenance show a lack of respect for
longterm KDE users who
used the (former) powers of KDE to set up sophisticated work environments.
This was the hallmark and unique selling point of KDE – without it you will
loose further user base …

I consider this very unwise – both in general and in this specific case.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481068] The power to run a command upon a notification is severely limited by lack of information

https://bugs.kde.org/show_bug.cgi?id=481068

--- Comment #4 from Flossy Cat  ---
(In reply to fanzhuyifan from comment #3)
> How about let's consolidate the discussion on resupporting this in 481069?
> (That's why I cc'ed 481069 when I closed this report.) We can always reopen
> if we decide to resupport this.

That sound much more respectful than closing the issue without a word of
explanation.

Let's go.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481053] kalarm CLI options wrongly transfered to »--edit-new-display« and actual alarm

https://bugs.kde.org/show_bug.cgi?id=481053

--- Comment #5 from Flossy Cat  ---
(In reply to David Jarvie from comment #4)
> Versions already released by KDE cannot be modified other than by patching
> the source and rebuilding yourself (or by persuading OpenSUSE to issue a
> patched version, which I assume they are unlikely to do). 

As OpenSuSE is not only providing regularly security update but also bug fixes 
to all components in the release repository it would be worth a try.
(The reason I use this distro as productive base …)
I expect to see an automatic update suggested by SW monitoring, if you
kindly apply the fix to version 3.5.4.2 in KDE Gear 22.12.3 (if possible at
all).
It would be an interesting experiment and I would report back.

> If you can't patch and build yourself, 

I could, but it is quite an effort and leaves my productive systems in a
non-automatic patch state
(at least partially) – last resort, IMHO.

> you'll have to wait for KDE Gear release 23.08.5 
< (based > on Qt5, due on 15 February) or 24.02 (based on Qt6, due on 28
February),
> although I don't know when or if OpenSUSE will issue these releases.

I'll wait – perhaps the dependency mess in the KDE 23.08.4 is an indicator of
this
upcoming change …

Thank you for quickly providing the fix.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #17 from Flossy Cat  ---
(In reply to David Faure from comment #16)
> I'm working on a patch.

Nice – thank you.

Do you care to explain what kind of patch?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481166] New: When entering VTODOs into KALARM's ICAL calender they are ignored

https://bugs.kde.org/show_bug.cgi?id=481166

Bug ID: 481166
   Summary: When entering VTODOs into KALARM's ICAL calender they
are ignored
Classification: Applications
   Product: kalarm
   Version: 3.5.4.2
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: djar...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

SUMMARY
When entering VTODOs with active alarms into »kalarm«'s ICAL calender – e.g.
with »korganizer« (see https://bugs.kde.org/show_bug.cgi?id=481024) – they are
ignored: Neither are they displayed in the listing of »kalarm« nor are their
alarms triggered and reminded.
This is somewhat unexpected, as VEVENTs and VTODOs are extremly similar in
structure and especially the reminders (VALARMs) used, are completely identical
data structures, used in an identical manner both in VEVENTs and VTODOs.
(There might be a reason for this behavior (being an active design decision) –
but it is not obvious for me.)

STEPS TO REPRODUCE
1. Stop »kalarm« completely.
2. Create a valid VTODO with alarms in the near future and insert it into the
active calendar of »kalarm« – i.e. "~/.local/share/kalarm/calendar.ics", e.g.
via »korganizer« or some other calendaring tool or manually. 
3. Create similarly a VEVENT.
4. Restart »kalarm«.
(tested: a running »kalarm« actually notices the file change and processes the
change – well done!)
5. look into the list of future alarms + calendar entries – the VEVENT shows,
the VTODO not …
6. Wait for the alarms – the VEVENT alarms trigger, the VTODO alarms not …

OBSERVED RESULT
The VTODO is neither displayed nor its alarms (VALARMs) rung.

EXPECTED RESULT
VTODOs are displayed and reminded like their "fraternal twin" VEVENT.

SOFTWARE/OS VERSIONS
[copied from System Information]
Operating System: openSUSE Leap 15.5
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150500.55.44-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

ADDITIONAL INFORMATION
As a seasoned computer engineer I might help with changes if brought up to
speed …

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #21 from Flossy Cat  ---
(In reply to David Faure from comment #20)
> Sorry for derailing the discussions about workarounds with a proper fix ;-)
> (see description in merge request)

Thank you – behavior looks good, judging from reading the code.

Nevertheless: to derail the workaround discussions the fix needs to be brought
back to KDE Gear 22.12.3 – otherwise
I'm happy you provided the fix but cannot profit from it with reasonable effort
in the near future …

Can you be so kind, to apply your fix back to KDE Gear 22.12?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481053] kalarm CLI options wrongly transfered to »--edit-new-display« and actual alarm

https://bugs.kde.org/show_bug.cgi?id=481053

--- Comment #7 from Flossy Cat  ---
(In reply to David Jarvie from comment #6)
> The KDE 22.12 branch was effectively closed when 23.04 was created, so I
> wouldn't be willing to apply the fix to it. 

When it is closed it is closed …

> I'm afraid the options are to
> apply a patch to the OpenSUSE repository or to wait for 23.08.5.

For this specific bug fix I can wait.
(I'm just wondering from which source OpenSUSE is pulling all the bug fixes I
regularly receive alongside the security patches …)

Thank you, again.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481166] When entering VTODOs into KALARM's ICAL calender they are ignored

https://bugs.kde.org/show_bug.cgi?id=481166

--- Comment #2 from Flossy Cat  ---
(In reply to David Jarvie from comment #1)
> By design, KAlarm stores all its alarms in VEVENT, and in order to provide
> all its functionality it uses quite a few custom properties in VEVENT and
> VALARM. 

Perhaps I have a wrong understanding of the function of KAlarm within the KDE
ecosystem.

I perceive it as a reminder application which would serve well – and with
better functionality
than »korganizer« (or the patch by David) ever provided – as substitute for the
notifications
(see https://bugs.kde.org/show_bug.cgi?id=481024).
(Better, namely: the preview of impending alarms, the overview over recent
alarms, command alarms, … more)

IMHO it is neither a substitute for a calendaring application nor a todo list.

What is your intended usage of KAlarm?

> Giving full support to VTODO would be outside the current scope of
> KAlarm, whose purpose is to provide reminders.

VTODOs contain VALARMs with the exact same syntax and semantics
as VEVENTs. (There are only minimal differences between VTODOs and
VEVENTs anyhow – they are practically fraternal twins. The only differences
coming readily to my mind are "transparency" and "dtend" for VEVENTs and 
"percentage completed" and "due" for VTODOs – all seemingly not used by KAlarm
anyhow.)
(see https://www.rfc-editor.org/rfc/rfc5545#section-3.6.1 and
https://www.rfc-editor.org/rfc/rfc5545#section-3.6.2)

I only suggest to honor the reminders in the VALARMs of both ICAL-entry-types
to make KAlarm an universal reminder for all ICAL-entry-types having reminders
i.e. VALARMS …

> Adding todo functionality
> would almost certainly need significant user interface changes in addition
> to logic changes.

That is not my intention at all – only reminders.

> It might be possible to add import (read-only) support for VTODO. This would
> need to convert them to VEVENT. I don't know how practical this would be,
> and I don't think the work would be justified unless there was evidence that
> people would actually use that facility. 

Trivial. The only difference between VTODO and VEVENT for the purpose of
KAlarm is, if the time period is not given via DTSTART and DURATION (identical
for both) 
but by start and end time, then for the end time
* VTODO uses DUE
* VEVENT uses DTEND 

(Actually users knowledgeable about the ICAL format have an unexpected nasty
surprise 
if KAlarm handles only alarms of VEVENTs because they are for many purposes
completely
interchangeable with VTODOs …)

> Of course, if you wanted to
> implement something yourself along these lines, I'd be happy to consider
> incorporating that into KAlarm, and could point the way to how to go about
> it.

Point me ;-)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481166] When entering VTODOs into KALARM's ICAL calender they are ignored

2024-02-11 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481166

--- Comment #4 from Flossy Cat  ---
(In reply to David Jarvie from comment #3)
> As stated in its handbook, KAlarm is designed as a personal message, email
> and command scheduler. It is not designed for group use. 

I do not intend group use – only personal reminders.

The option to schedule commands is very valuable and much needed, especially
as it seems to be scratched elsewhere in KDE.

> It aims to present
> a simple interface (unless the user chooses to expand the options displayed)
> to allow ordinary (i.e. non-technical) users to schedule alarms. 

Which it does very well.

(But the existence of a command scheduler aims at technical users, IMHO –
unless we have a very different definition ;-)

> Most users only use it with its default calendars, and not with any calendars 
> created
> by other applications. 

But you provide both for import of ICS files as well as r/w and r/o access to
other ICAL calendars.
VTODOs are integral part of the RFC 5545 specification as are VEVENTS, both
using the identical 
VALARM substructure for reminders – users are bound to expect, that reminders
reminders in
ICAL/RFC-5545-conformant calenders work, ie. in reminders in their todos
work the same as within their events, when importing ICS files.

The change is trivial and probably very small – please point me to the place
and provide some
guidance, and I will do this …

> The fact that KOrganizer reminders have been messed
> up in recent times is unfortunate, 

Polite understatement of the week ;-)

> but I don't want KAlarm to be amended or
> expanded in any way in order to be used as an adjunct to KOrganizer to
> provide its reminder functionality. 

KAlarm as reminder system is much better than anything I've seen so far.
The unique advantages, I personally see, are:
* (optional) list of recent reminders triggered – very valuable when you lose
track on a stressy day
* lookeahead of upcoming reminders – very valuable to e.g. shift them
proactively if you need some undisturbed time or to preemptively do tasks if a
meeting is cancelled
* color-coding of reminders
* command execution reminders

As such it could improve on any existing calendaring and todo application and
act as central reminder application.

There a two independent avenues of interfacing:

1. (essential) enable snoozing alarms triggered by read-only ICS calendars –
IMHO a very small and simple change: the snoozed reminder is copied to KAlarms
standard active calendar (it should be even possible to have a reference to the
original). 
This change would easily integrate all RFC-5545-conformant ICS calendar based
applications (their reminder function could be switched of by the user …)

2. (optional) listen on the D-BUS for notifier events
(»org.freedesktop.notification«) – this probably is some effort, but the change
is well isolated new functionality. Code for listening on the D-BUS for this
events, more or less filter logic, creating reminders from templates configured
for specific notification types. Besides reacting to calendar reminders this
opens up many other use-cases. 
This would work in any desktop environment having a D-BUS and conforming to the
relevant parts of the freedesktop standard (ie. most).
On any desktop without facility to run commands in reaction to notifications
KAlarm would be greeted by any user sophisticated
enough to automate their workflows – eg. on KDE (the facility is crippled to be
mostly useless in 5 and shall be dropped in 6 …)

If you completely oppose these ideas, I will not bother you further in this
direction.
If you are interested, I will help as much as I can.

> It's up to KOrganizer to sort out its own deficiencies.

I would be more than happy, if KOrganizer would just stop willingly introducing
new ones ;-)

> For these reasons, I don't see it as important to provide KAlarm with the
> ability to read VTODOs, but I wouldn't object. It would be important to
> first of all decide on how reading calendars containing VTODOs should fit
> into KAlarm's user interface. 

No change needed in the interface at all.

For processing you are using »kcal«, which out of the box should – as any
RFC-5545-conformant library – be fully capable to handle this correctly anyhow.

> As I said previously, I would see it as being
> via some sort of import function, but I don't know whether that would
> satisfy your goal of users not being surprised when VTODOs are ignored if
> KAlarm is told to use a calendar which it didn't create itself. Bear in mind
> that if VTODOs were edited in KAlarm, or if they contained recurrences, they
> would need to be rewritten as VEVENTs (and of course, functions specific to
> todos would be not show in KAlarm).

Please kindly point me to the code, where you do the processing of VEVENTS, and
I
will provide solid and concrete technical answers.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-02-12 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #24 from Flossy Cat  ---
(In reply to Bernhard E. Reiter from comment #23)
> …
> It also maybe an option on OpenSuse to use one of the
>   https://en.opensuse.org/SDB:KDE_repositories
> that is providing newer KDE Application revision to stable Opensuse Leap.

That I did before reporting the bug – alas then the repositories failed on
their
internal requirements, perhaps a momentary glitch.
But it provides applications only in version 23.08.04, and the patch probably
will take some
time to shine up, if I not have to wait to 23.08.05 …

I will first have to catch up with my work delay caused by this nasty surprise
before trying again
or following David's suggestion …

My workaround via KAlarm from 2024-02-09 (see
https://bugs.kde.org/show_bug.cgi?id=481024#c13)
works very well and actually brings several benefits and solves the problem of
reminder storms you
mentioned when switching machines.
(Benefits:
* (optional) list of recent reminders triggered – very valuable when you lose
track on a stressy day
* lookeahead of upcoming reminders – very valuable to e.g. shift them
proactively if you need some undisturbed time or to preemptively do tasks if a
meeting is cancelled
* color-coding of reminders
* command execution reminders
* waking machine from suspend for reminders (not my cup of tea but maybe
valuable for some)
)

It is really great David restored the eliminated snoozing functionality –
thanks – but KAlarm as
general reminder handler is worth considering, IMHO.

Looking at the further crippling of KDE (see e.g.
https://bugs.kde.org/show_bug.cgi?id=481069) after
a quarter of a century of choosing KDE I have to consider on which desktop and
tool set I will bet
for my old age, when I will not be able anymore to workaround, patch, juggle
numerous repository
and weather dependency messes …
(I'm relatively relaxed concerning the desktop having a well-tuned XFCE as
fall-back since KDE 4,
but the use-breaking regression in KDE PIM hit my hard, unsuspected and with
very bad timing …)

I consider the change culture in KDE fundamentally broken:

Since the KDE3/4 transition I regularly see breaking changes all over the
place, "discussed" and
"announced" in some very small circles with minimal reach into the end-users.
(And IMHO the discussions show these persons do not have a sophisticated usage
of the components
they are crippling …) 
The end-users are then hit by nasty surprises a dozen month or more later which
then leads to 
numerous complains, bug reports etc. which are handled quite lukewarm judging
from the handling 
of the duplicate bugs I collected in my bug report.

Only when I "threatened" to quickly draft up a working workaround to show the
urgency, David took pity 
and kindly patched and restored the lost functionality. And the patch is – no
offense meant, David! –
a relatively minor one (still, of course, hours of work I appreciate!).

All the while KDE is losing user base – many of the participants of the
duplicated bug reports did not
partake in this discussion, despite me inviting them in every duplicated report
thread.
I consider those potentially lost users …

Any idea where this fundamental discussion about the change culture of KDE
should be started?
(bug reports is the wrong place, IMHO)

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-02-12 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #26 from Flossy Cat  ---
(In reply to Bernhard E. Reiter from comment #25)
> …
> However it is most helpful to understand that there are many volunteers
> that work on KDE's software products. While the whole process may have its 
> downsides and bad outcomes, any volunteer time and effort is appreciated.

I know, having contributed to FLOSS continuously (in varying degrees and
functions) since 1986 …

The volunteer workers on the software products on the other hands should not
disrespect the
time and effort of the volunteer users in setting up convincing working
environments in turn to
use in advocating open SW use – be that advocacy intentional or incidental just
by example.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481166] When entering VTODOs into KALARM's ICAL calender they are ignored

2024-02-12 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481166

--- Comment #6 from Flossy Cat  ---
(In reply to David Jarvie from comment #5)
> Yes, KAlarm is for both technical and non-technical users, but to serve the
> latter, it needs a simple interface. More advanced users can expand the
> range of displayed options, and use such things as command alarms.

A good solution.

> Currently, if the user configures KAlarm to access in read-write mode a
> calendar which has been created by another application, KAlarm will write
> its own custom properties into the VEVENTs and VALARMs in order, for
> example, to track when recurrences were last triggered by it. If alarms are
> subsequently created or edited, they also will contain KAlarm custom
> properties. If the user also accesses the calendar file from another
> application such as KOrganizer, the KAlarm specific data may or may not
> survive, so this could alter how KAlarm functions for these alarms.

(My answers rest on https://github.com/KDE/kalarm/tree/master/src – 
I hope this is the correct repository (it still has Akonadi-calls in it and you 
mentioned the docs where outdated, because Akonadi support was dropped …))

As your custom properties have the RFC-conformant custom property prefix 
you at least have done anything possible to make it work – but of course you
are right: alas that is no guarantee …

For KOrganizer I can report: it works correctly with an ICS file both share in
R/W mode.
(Both detect if the other application changed content and reread the file, but
of
course there are no provisions for avoiding concurrent changes (which would
either corrupt the file or loose changes of one application) – but careful
handling by the user …))
(Therefore my question about ICAL directory calendar sources – they, for
various reasons, reduce this risk significantly …)

Actually, there might be a really good solution for this: 
The "Related To" property (see
https://www.rfc-editor.org/rfc/rfc5545#section-3.8.4.5).

KAlarm would then generate a dependent object (child), referencing back to the
parent object in the r/o ICS of the other application.

With any luck »kcal« already has implemented it, and might even has a complete
view of all calendars within KAlarm, so that it just works …

In effect the child would have access to changes of the parent, especially
deletion or start/end changes (for relative alarms) and any need to write
anything back into the shared ICS would vanish …

> Having thought about what you've said, I realise that KAlarm could handle
> alarms within VTODOs similarly to those in VEVENTs, and update them with its
> own custom properties to keep track. There isn't any need to copy VTODO
> alarms into VEVENTs - they can just stay in the VTODOs, and KAlarm would
> simply ignore the todo-specific data.

We are on the same page.

> Consideration would need to be given to:
> 
> 1) How to handle VTODOs with multiple alarms. Currently, KAlarm stores each
> user-configured alarm in a separate VEVENT (although it often creates
> multiple VALARM instances within the VEVENT to handle different aspects of
> what to the user is a single alarm: for example, a display alarm which also
> plays a sound would contain a VALARM for display and a VALARM for sound, but
> there are other less obvious reasons to have multiple VALARMs). This scheme
> would not be able to handle two completely separate alarms in a VTODO (and
> indeed doesn't handle two completely separate alarms in a VEVENT either).

RFC 5545 not only allows but advocates that VEVENT/VTODO can each have multiple
VALARMs with absolute or relative time specifications triggering at different
points in time (and actually each VALARM can have its own summary and
description, which is useful for some use-cases (example see below)).

KAlarm should be capable to cope with this and the ICAL library may already is
…

> 2) When a VTODO alarm is edited in KAlarm, should it be saved as a
> replacement VTODO? I presume yes.

Well, KAlarm has its native entries (via command line parameters, via its own
GUI, via imported ICSes or perhaps in the future from D-BUS messages – see
below). For these of course: yes.

Then it has external entries from ICS files shared with another ICAL-aware
application.

I can imagine many use-cases where KAlarm and the other application act as
peers, both writing changes back with collision avoidance done by some outside
mechanism.

Finally I see some asymmetric use-cases where KAlarm is ancillary as a reminder
manager for a calendaring application.
The calendaring application is the owner/manager of the events and todos – and
the place for editing them.
KAlarm allows fine-tuned managing of the reminders and has r/o access to the
calendar of the other application.

Technically I hope "Related To" works as solution.

>From the user's point of view:
When a "Related T

[kalarm] [Bug 481166] When entering VTODOs into KALARM's ICAL calender they are ignored

2024-02-14 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481166

--- Comment #8 from Flossy Cat  ---
(In reply to David Jarvie from comment #7)
> Many of your proposals go beyond the intended scope of KAlarm, and if
> implemented would expand its function from being a stand-alone personal
> alarm application to something more general. This would add more code
> complexity, and therefore more maintenance overhead, which I don't think are
> desirable for the application as it is designed. Specific comments are below.

Thank you for speaking your mind and explaining the intended scope for your
application.

I speak my mind in turn and explain the foundations of my suggestions:

In the eighties I've choosen the philosophy underlying UNIX and IP as my
professional basis:
Build small versatile tools, interoperable by common open protocols and
formats, and create
quickly solutions from this as new problems turn up.

IMHO this is the most successful computational philosophy so far, which –
against all odds –
made unixoid systems dominant in the server world. X11-based GUI, especially
KDE, were
long following this philosophy and actually, IMHO, there was a window of a few
years, where 
they might have become significant on the desktop, too. Alas, GNOME and KDE,
IMHO departed
from this philosophy …

In your application I saw potential to increase versatility – but if this is
not your cup of tea, this
is OK with me and, as promised, I stop proposing this idea.

Thank your for your work and time so far!

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] With framework version 6 the option to execute commands as part of notifications seems gone

2024-02-15 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #2 from Flossy Cat  ---
(In reply to Nate Graham from comment #1)
> Not being familiar with the functionality, can you take a few steps back and
> explain what it did, 

It allowed to trigger a command execution when specific notifications where
displayed – either in combination with other notification actions or as the
sole action.

> how you were using it, 

To automate system behavior upon the occurrence of events as well as to fix
regressions in KDE SW (see e.g. https://bugs.kde.org/show_bug.cgi?id=481024)

> and also confirm that you tried
> to use it in Plasma 6 and were not able to (this is to make sure it didn't
> simply move to a place where you weren't looking for it)?

I can read the code and gave the relevant code repositories for reference – the
functionality is gone.

In https://bugs.kde.org/show_bug.cgi?id=481068#c1 fanzhuyi...@gmail.com
confirmed, that this functionality will be removed in Plasma 6.

This is a severe regression and usability degradation, breaking existing
sophisticated KDE setups of long-time users like me (a quarter of a century).

If people want a crippled desktop, where the user has to serve the computer,
instead of the computer serving the user, there is a large choice.

The unique selling point of KDE, as perceived in my working enviroments, is the
capability of automation – if KDE removes this all over the place, it becomes
dispensible.

To put it simple: you don't win a cross-country race by following the tracks of
others …
Have a look at your user-base developement …

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] With framework version 6 the option to execute commands as part of notifications seems gone

2024-02-15 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #4 from Flossy Cat  ---
(In reply to Nate Graham from comment #3)

> How exactly was this feature found and
> configured? How did you set it all up? What was the UX like? Etc.

Get a system with
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
or earlier.

Go to »system settings« -> »Notifications« -> »Application-specific settings«
-> »Configure…«

There choose any application where you can »Configure Events…« – e.g. Network
Management, Bluetooth, Device Notifier, KDE Mail, KMail, Calendar Reminders and
many more.

If you press »Configure Events…« a configuration window pops up, where for each
event you can choose any combination of »Play a sound«, »Show a message …«,
»Log to file«, »Mark taskbar entry«, »RUN COMMAND«, »Speech«.

Use-cases:

* workaround fatal regressions like
https://bugs.kde.org/show_bug.cgi?id=481024#c5
* detect when you are within your home WLAN and call a script doing things like
hooking up to the call notification of your phone system, mounting local NAS,
relaxing screen locking, home automation, …
* detecting loosing a bluetooth connection and lock screen (with timed shutdown
after some time) as theft counter-measure (to protect your information) when
e.g. traveling by railway
* etc.

> I ask because this is the first time I'm learning about the feature and I've
> been triaging KDE bug reports for 6 years. To my knowledge it's even the
> first bug report I've seen about it too. So I'm guessing whoever removed it
> assumed that it had no users. 

Counterquestion: how would anybody at KDE know about usage statistics of
features or sophisticated use-cases?

Basing deprecation on "no bug reports" is an excellent strategy to remove
things which are working flawlessly and guarantees your user base nasty
surprises. I really hoped this lesson might have been learned from the
disastrous KDE 3 to 4 transition …

Well, when we are at guessing – my guesses are as valid as your's:
Those removing valuable features from KDE – and I could give a very long list
from the last decade … – are simply haughty enough to assume that there exists
no more sophisticated usage than their unimaginative own …

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

2024-02-16 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #6 from Flossy Cat  ---
(In reply to Nate Graham from comment #5)
> Got it, thanks. I can see how that would be useful for powerful custom
> workflows.

Glad to be of service.

Anyhow, my counterquestion was not rhetorical, but in earnest. I really think
it worth answering, because together we have just demonstrated that a valuable
and powerful feature was removed on a whim without checking its user base and
its UX value:

How does KDE know which features are unused and how is removal decided?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

2024-02-18 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481069

Flossy Cat  changed:

   What|Removed |Added

   Keywords||regression, usability

--- Comment #8 from Flossy Cat  ---
(In reply to Nate Graham from comment #5)
> Got it, thanks. I can see how that would be useful for powerful custom
> workflows.

Some technicalities: 

You set this bug report as "wish list", but it is NOT a FEATURE REQUEST.
It is about a REGRESSION, breaking existing usage and use-cases – as we
discussed.

Further the related bug report https://bugs.kde.org/show_bug.cgi?id=481068 is
about an actually buggy (incomplete) implementation.

If the REGRESSION is avoided by not removing the feature, the code handling the
%-escapes needs fixing.

Further the code should be improved by providing better provision of the
notification information to the executed process.
I suggest generally providing all information via 
* environment variables to the called process in the likeness of
»KDE_notifier_cmd_«_"PARAMETER" where parameter is "Title", "WinID", etc.
* STDIN – simply the complete visible text in the notification window, perhaps
amended with additional info available (a "key=value" version is already
provided by the environment variables)

I consider it much simpler to provide all these parameter passing in parallel
than have a GUI component for selection.

Finally the functionality NEEDS to be documented: KDE can't expect widespread
use (or even discovery) of functionality like this, if there is no
documentation …

I can easily support in doing
1. tests
2. the English and German documentation

I can support with coding if guided (I know C++ well enough, but not the KDE
libraries).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481166] When entering VTODOs into KALARM's ICAL calender they are ignored

2024-02-18 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481166

Flossy Cat  changed:

   What|Removed |Added

 Resolution|INTENTIONAL |FIXED

--- Comment #10 from Flossy Cat  ---
(In reply to David Jarvie from comment #9)
> I'm well aware of the benefits of how UNIX tools can work together to do
> more complex tasks, which for example allows versatility in scripting. 

I do not doubt that you are aware of this – nevertheless practice and
experience changes the awareness: I use these mechanisms from the early
eighties – roughly 4 decades – more or less on a daily basis, all the while
monitoring my computer usage and refactoring it into automatable sub-tasks …

I use this not only for scripting but my command-lines regurlarly contain
pipes, variables, history references, redirections, …

> But GUI applications as they currently exist generally don't lend themselves 
> to
> this, due in part I'm sure to the need for user interaction using a mouse.

IMHO a misconception:
The CLI needs interaction too – no command executes without pressing the enter
button, not to speak of the arcane key-press sequences needed before to have a
command doing anything complex.

The core is clever inter-process communication and the pipe as well as
environment variables are an ingeniously clever IPC mechanism.

With this and some scripting you can go a long way with existing GUI
applications:
I have large test-beds which fire up an editor for documentation, the load
generators and performance monitors (both visual and more detailed non-visual).
With a keyboard macro in »vi« you trigger both a screenshot as well as a
timestamp (more precise: the name of the screen-shot) and can document the
observations. You close the editor – the tests are stopped, performance data is
collected, processed in various ways and presented visually in GNUplot sessions
as graphs which interactively can be fine-tuned, e.g. by selection of time
periods, annotations, manual fitting of the parameters of mathematical models
of the investigated systems, etc.
(From the tool choices you easily see: these test-beds are decades old and used
since ;-)

>From the outside this looks like an elaborate framework or application – but it
isn't.

IPC directly between GUI applications is of course more difficult. 

>From the era of mainframes (which had no GUI but monolithic applications) we
have the concept of "user exits":
Specific actions like opening or storing or application-internal
transformations can be configured to be done by calling external programs. Easy
and effective – I know some really large applications (>500 developer years) in
a technically very challenging environment which even nowadays use this
intensively.

Shared storage is easy, too – be it common file formats (and some form of race
condition prevention), data bases or service like »akonadi« (a good idea
implemented l…ess than optimal …).

D-Bus is, IMHO, a very clever approach of IPC for GUI application, alas, not
very well accessible from scripting … but with a lot potential.

> …
> It's interesting to have your ideas - thank you. Even if some are out of
> scope for KAlarm's intended use, others do provide some ideas for future
> development.

I'm looking forward to these future developments.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

2024-02-29 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #12 from Flossy Cat  ---
(In reply to Nate Graham from comment #9)
> From the perspective of Bugzilla, this isn't a bug; the removal of the
> feature was intentional. The request being made here is to reconsider that
> removal and bring it back. Note that the "regression" keyword is already
> applied.

Yes – because I applied it …

> Since you've identified the commit that removed the feature, and you know
> C++, submitting a merge request to re-add it (including your proposed code
> improvements so that it doesn't get removed again) hopefully should be
> feasible!

The important words were "support" and "if guided", meaning:
"I do not know my way around the KDE development eco-system and need
introduction and help!"
Knowing C++ alone is not sufficient to successfully navigating the
re-introduction …

I also do not like the sound of "hopefully … feasible".
I'm not in dire need of opportunities to waste my time.
I'm an IT professional with a definitely non-empty schedule.

I'm willing to carve out the necessary time from my schedule only when

1. there is a commitment by KDE to re-introduce and keep this IMHO important
feature, if I do a proper implementation.

2. there is introduction/help to find my way around and to quickly set up an
adequate working environment – hopefully you have some kind of onboarding
process for new volunteers and a mentoring system?

3. crucial technical information is provided, like
3.1 what is the time-frame for re-introducing the feature
3.2 have I identified the correct GIT (you affirmed this, thank you – but with
KAlarm I identified an obsolete one …)
3.3 which library and function is to be used to retrieve specific data from the
D-Bus, akonadi, or the notifier window – in the cases where I can't derive this
from the code around the removed feature
(i.e. I need somebody in the know, willing to answer similar questions)

4. the same support request applies to the documentation part – if the function
is not properly documented, it essentially does not exist and is not used ->
back to square one …

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 483545] New: Kmail2 silently looses mails while displaying the correct counts with the folders

https://bugs.kde.org/show_bug.cgi?id=483545

Bug ID: 483545
   Summary: Kmail2 silently looses mails while displaying the
correct counts with the folders
Classification: Applications
   Product: kmail2
   Version: 5.22.3
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: critical
  Priority: NOR
 Component: general
  Assignee: kdepim-b...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

Created attachment 167165
  --> https://bugs.kde.org/attachment.cgi?id=167165&action=edit
Error Messages by Kmail when it is losing mails

SUMMARY
Kmail2 silently looses mails without any error messages or warnings.
The fact is hidden by wrong counts given with the folder display.
Further a complete self-disintegration of akonadi was witnessed – potentially a
follow-up error …

STEPS TO REPRODUCE
not known, as the disintegration silently continued over at least 2 month and
neither start nor disintegration trigger can be reconstructed from backups.

But the core problem is obvious from the observations – see below.

OBSERVED RESULT
On an air-gapped system, physically only accessible by me (used for highly
confidential work with severe contractual penalties), – this precludes any
malicious external causes! – the following happened:

When sorting my old mail archives (no HTML view, no attachments!) suddenly I
notice changes in the folder pane on the left:
Sequentially the number of messages in folders counted down and folders were
removed.
Trusting in my backups I let the system run its course, to at least risk no
further inconsistencies …
The mail resided in ~/.local/share/local-mail – when the system was finished
there was a new folder ~/.local/share/.local-maildir and the akonadi-DB in
~/.local/share/akonadi seemed to be completely reset.
All mails were lost according kmail.

In the storage location ~/.local/share/local-mail roughly 2 thousand mails of
originally around 12 thousand remained – surprisingly all in the "new" branch
of the maildir structures, albeit none of the mails was displayed as unread.

The next nasty surprise:
Obviously there has been a creeping loss of mails beforehand.
In all the backups up to 2 month prior mails were missing, while the akonadi
database (via the number of mails in the folder pane) claimed all was fine.

This 100% sure knowledge because – when embarking on this little project of
triaging my mail archives – I had set apart a folder of mail correspondence
with a dear friend who died much to young (to avoid losing them by any
mis-triaging …).
This folder was empty even in the backups 2 month old.

Curiously all mails still present in the backups always resides in the "new"
branch of the maildir structures.

I then went back to the archive, I'd used to transfer the mail-archives from
the pre-cursor system (still KDE4 based – no problem as air-gapped as well) to
the current system. Here all mails were still present (in their past sorting
state) and all resided in the "cur" branch of the maildir structures, as was to
be expected.

(So happily I could recover the complete archive but still lost many, many
hours of triaging!)

All in all around 2500 mails were silently lost by Kmail2 over a period of a
little more than 2 month.
I investigated a sample of roughly 10%: 
While old mails with crypto predating 2010 (e.g. inline/pgp) and the common
less-than-standard-conformant M$-mails were clearly over-represented also
completely harmless, standard-conformant, non-crypto mails were lost, too.

All of these mails display without problems in the Kmail-viewer-component
(might not be well formatted, but complete text with all attachments etc.)

When experimenting with these I could capture some error messages of Kmail –
see attachment.

The core cause seems:
»"Unable to fetch item from backend (collection -1) : Unable to retrieve item
from resource: [LRCONFLICT] Resource akonadi_maildir_resource_2 tries to modify
item 29196 () (in collection 102) with dirty payload, aborting STORE."«

Seemingly the akonadi-component handling storage is much pickier than the
display-component and simply drops items when they are moved between folders or
the branches of the maildir structures.

The machine has 8 cores and 16 GB RAM and is boring itself to death, while I'm
triaging mails (there are more demanding tasks for the machine, but not during
triaging …) – so there were no "out of memory" problems … (ie. the copious Swap
is not even touched).

EXPECTED RESULT
1. Kmail2 not loosing mails.
2. Kmail2 giving visual warnings to the user if there are problems
3. akonadi_maildir_resource_2 not silently dropping mails when it has any
problems handling them.

SOFTWARE/OS VERSIONS
[copied from System Information]
Operating System: openSUSE Leap 15.5
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150500.55.44-de

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #18 from Flossy Cat  ---
(In reply to Nate Graham from comment #13)
> I'm afraid I can't formally commit to that level of personal hand-holding as
> my time is split 500 ways and extremely limit these days. But I will be
> happy to assist as my time and skill levels do permit.

Thank you for your generous offer and sorry for my delay: 
The "new KDE version" coming with OpenSuSE 15.5 seems to be one of those
notorious "devastating improvements".
The newest unwanted "entertainment" soaking up all spare time during the last
weeks: https://bugs.kde.org/show_bug.cgi?id=483545

The further reactions to this discussion show clearly: The decision to remove
this feature was very ill advised.

Before coming back to your generous support offer and going into
technicalities, I really think it necessary that those people responsible for
this decision look into this discussion and commit themselves into keeping
these functionality if we re-implement it.

Otherwise we risk wasting our time, when in the end somebody does not accept
the commit on the ground of "the lowest denominator of supported platforms
determines what power KDE is allowed to have" or some similar 

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #19 from Flossy Cat  ---
(In reply to Nate Graham from comment #7)
> (In reply to Flossy Cat from comment #6)
> > …
> > How does KDE know which features are unused and how is removal decided?
> We largely have no idea. 

The reactions of users in this discussion clearly show, how ill advised the
removal of this feature was.

This clearly demonstrate a serious bug in the KDE decision processes.

Further your answer in comment #13 demonstrates more crucial bugs:
There seems no onboarding process for new volunteers, no mentoring, not even
introductive documentation …

Where to discuss this bugs and proposals for solution?

> It's an unfortunate side effect of our commitment
> to not spy on our users. It means we're in the dark about what they actually
> do with our software when they're not somehow making noise about it
> publicly. Features that get bug reports and that people are talking about in
> public (on social media, in our forum, in reviews of our software, etc) are
> features that we know people use. Other ones... well, we don't. We try not
> to remove stuff for no reason, but when a feature's code is old and flawed
> at a fundamental level and it seems like it's blocking an effort to do
> something new, that's when the feature is going to end up on the chopping
> block rather than getting fixed if no one can find anyone who uses it.
> 
> This is obviously pretty flawed but I don't know how we can do any better
> without turning to the dark side and spying on our users.

I'm not as pessimistic, but this is not the proper place to propose solutions …

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #20 from Flossy Cat  ---
My comments #18 and #19 were classified as spam – can somebody enlighten me,
why?

And remove this classification because I am actually trying to achieve some
progress here.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #26 from Flossy Cat  ---
Thank you!

When you are at it, kindly consider the following improvement (sample code
below) (see also https://bugs.kde.org/show_bug.cgi?id=481068):

IMPROVEMENT

Add pre-filled environment variables with notification details.

RATIONALE

For anything not directly solvable with an existing program the users typically
will have to script.
Providing all notification details in environment variables significantly
simplifies this:
* Tighter test-loop: no need to adapt the call in the KDE UI, when other
details should be used
* no need for parameter parsing

CODE (suggestion)

In »notifybyexecute.cpp« insert between
 KProcess proc;
and
 proc.setShellCommand(execLine.trimmed());
the following 

// code suggestion start
const std::string envPrefix = "KDE_NOTIFICATION_PARAMS_"; // name-space, your
choice
proc.setEnv(envPrefix + "EventID", notification->eventId() ) // or any string
concatenation of your choice
proc.setEnv(envPrefix + "AppName", notification->appName() )
proc.setEnv(envPrefix + "DisplayName",
QGuiApplication::applicationDisplayName() )
proc.setEnv(envPrefix + "Title", notification->title() )
proc.setEnv(envPrefix + "Text", notification->text() )
// code suggestion end

Thank in advance!

I will support with end user documentation in English and German if pointed to
the proper entry point.
(I consider end user documentation essential for this feature to communicate
the potential.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #27 from Flossy Cat  ---
ERRATA
Ooops, forgot the ";" at line ends. Blush …

// code suggestion start
const std::string envPrefix = "KDE_NOTIFICATION_PARAMS_"; // name-space, your
choice
proc.setEnv(envPrefix + "EventID", notification->eventId() );
proc.setEnv(envPrefix + "AppName", notification->appName() );
proc.setEnv(envPrefix + "DisplayName",
QGuiApplication::applicationDisplayName() );
proc.setEnv(envPrefix + "Title", notification->title() );
proc.setEnv(envPrefix + "Text", notification->text() );
// code suggestion end

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #29 from Flossy Cat  ---
(In reply to Andreas Schneider from comment #28)
> You can pass it as command line options:

I know, but kindly read the rationale section in
https://bugs.kde.org/show_bug.cgi?id=481069#c26
to see why this additional IPC mechanism is an advantage.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #31 from Flossy Cat  ---
(In reply to Andreas Schneider from comment #30)
> As initially said that this is something for power users,

I'm the initial reporter of both this bug report and
https://bugs.kde.org/show_bug.cgi?id=481068
and I'm a computer SW engineer with decades of work life, contributing to FLOSS
since the 80ies. 
My suggestions are not idle talk.

A real power user "does not need" this feature at all, as many use-cases can be
implemented by UDEV.
Or all by "dbus-monitor" and the likes piping into a named pipe, where some
script filters and triggers actions.
Both well within my scope. And both even having the advantage of being quite DE
independent …

The whole point in this feature is to make advanced automation accessible to as
many users as possible.
There the parallel provision of the details via environment variables improves
their experience, IMHO.
Then users have both options.

The question is not, if you or I can cope, but how to make a solution
accessible to a broad user base.

> …
> If you really need all of those variables to make a decision what to do in
> the script. 

Scripts develop with use – the env vars makes this less hassle.
Your approach is IMHO a deterring nightmare to document for end users … 
So few will use it and it will be dropped again soon …

> Then you're advanced enough to quickly code up option parsing in
> your bash script. It is a 30 line switch statement in bash.

A completely unnecessary hurdle …

Intimidating for new users. 
I'd prefer to encourage many users to extent their skills and DE automation,
because that gives KDE a leading edge …

> Providing the
> expansion on the command line allow you to use them with already existing
> executables.

That is well understood by me – I suggested to ADD the env vars as parallel IPC
mechanism.
Doesn't cost much, avoids an additional GUI choice, eases end-users life …

But don't bother, I'll do it myself later when your change has stabilized …

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] New: The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-02-07 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

Bug ID: 481024
   Summary: The loss of user-defined snoozing for calendar and
todo reminders is a massive functional regression and
actually a hard show-stopper for my kontact usage
Classification: Applications
   Product: kontact
   Version: 5.22.3
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: grave
  Priority: NOR
 Component: calendar
  Assignee: kdepim-b...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

FOR CONTEXT
I'm using the KDE PIM tools since well over two decades when there was no
integration into kontact.
Thus, when I write "hard show-stopper" this is no lighthearted whim. The
functional regression is so
disruptive to decade-old workflows that I definitely – to my utmost regret –
will have to switch to 
Thunderbird (providing sufficient snoozing and other functionality) within a
short time-frame, when neither 
solution or work-around is available. Because of the effort involved, this
migration will be permanent.

SUMMARY
With the upgrade from openSuSE 15.4 to 15.5 and thus to the mentioned SW
versions reminders
for calendar events or tasks are only notified via KDE notifications, with
fixed snooze options of 5 minutes
and 1 hour. This is a catastrophic regression – consider work-flows like the
following:

Sample workflow: 
Every year in mid October a reminder to empty the rain barrels is needed to
prevent damage by freezing. 
When the reminder comes up, long-term weather forecast are checked and the
reminder postponed accordingly
(last year in several steps until December – making good use of the water …)

It is no option to change the reminder timing in the issue itself, because the
timing should be preserved for the next year.
The delays only apply to the current reminder …

I have many analogous workflow in the areas of taxes, technical inspections,
medical examinations, vaccinations, …

STEPS TO REPRODUCE
1. Create a calendar event with reminder in the very near future.
2. Watch the notification.

OBSERVED RESULT
KDE notification popup with only 2 fixed delays (5 min, 1 hour).

EXPECTED RESULT
An option to configure a user-choosen delay.

POSSIBLE DUPLICATES
I judge the following Bug-IDs (in part older than one year!) addressing the
same problem – but neither do I see solutions, workarounds nor progress:
457046
452264
453298
453299
457046
461233

SOFTWARE/OS VERSIONS
[copied from System Information]
Operating System: openSUSE Leap 15.5
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150500.55.44-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

ADDITIONAL INFORMATION
I'm a computer engineer and willing and capable of contributing to a solution
if brought up to speed by some guidance.
(e.g. around 2003 I contributed to the PDA integration and syncing …)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #1 from Flossy Cat  ---
SEARCH FOR A WORKAROUND
Within this comment thread I suggest to collect the discussion about
workarounds.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481053] New: kalarm CLI options wrongly transfered to »--edit-new-display« and actual alarm

https://bugs.kde.org/show_bug.cgi?id=481053

Bug ID: 481053
   Summary: kalarm CLI options wrongly transfered to
»--edit-new-display« and actual alarm
Classification: Applications
   Product: kalarm
   Version: 3.5.4.2
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: djar...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

SUMMARY
The command line parameters of »kalarm« invocations are not correctly
transferred into the edit window
(and the alarm itself if the edit window is skipped).

STEPS TO REPRODUCE
1. call »kalarm --edit-new-display -n "Name" "Message"«
2. call »kalarm -n "Name" "Message"«

OBSERVED RESULT
The "Name" is put into the message text field, the name field remains empty and
the "Message" is dropped completely.

EXPECTED RESULT
"Name" should show in the name field, "Message" in the message field.

SOFTWARE/OS VERSIONS
[copied from System Information]
Operating System: openSUSE Leap 15.5
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150500.55.44-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #2 from Flossy Cat  ---
Possible Workaround: »kalarm«
==

»kalarm« provides all the necessary functionality to set and postpone alarms
(and even some useful additional functionality).

The burning question remains, how to call »kalarm« or create »kalarm« reminders
from »korganizer« reminder events.

Usage of »kalarm« is quite simple – 3 useful variants exist (a matter of
personal preference):

»kalarm -b --edit-new-display -n "Test kalarm" -t 14:50 "Test notification via
kalarm"«
Opens a window to edit the alarm and change various details, the time, etc.

»kalarm -b -n "Test kalarm" -t 14:50 "Test notification via kalarm"«
This will immediately set and trigger an alarm at the given time (which has to
be slightly in the future).
The alarm is presented in a separate window, providing a button, opening a
window for flexible snooze options.

»kalarm -N -b -n "Test kalarm" -t 14:50 "Test notification via kalarm"«
This will immediately set and trigger an alarm as above, but because of »-N«
the alarm
is presented as notification, providing a button, opening a window for flexible
snooze options.
(»-N« can be used in the »--edit-new-display« too, to preselect notification as
method).


(In all variants there is a annoying bug in handling the parameters:
https://bugs.kde.org/show_bug.cgi?id=481053)

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 457046] Recent update removes the reminder popup window with a notification, snooze time adjustment is no longer available

https://bugs.kde.org/show_bug.cgi?id=457046

Flossy Cat  changed:

   What|Removed |Added

 CC||flossy-...@online.de

--- Comment #2 from Flossy Cat  ---
I experienced the same issue when upgrading within my distribution.
As neither here nor in the many duplicates I see any progress to a solution,
I've set up a discussion about possible workarounds to which I invite anybody 
interested: https://bugs.kde.org/show_bug.cgi?id=481024#c1

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 452264] Appointment reminder handling reduces usability and functionality between 21.12.3 and 22.03.80

https://bugs.kde.org/show_bug.cgi?id=452264

Flossy Cat  changed:

   What|Removed |Added

 CC||flossy-...@online.de

--- Comment #26 from Flossy Cat  ---
(In reply to Bernhard E. Reiter from comment #0)
I experienced the same issue when upgrading within my distribution.
As neither here nor in the many duplicates I see any progress to a solution,
I've set up a discussion about possible workarounds to which I invite anybody 
interested: https://bugs.kde.org/show_bug.cgi?id=481024#c1

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 453298] kalendarac: Notifications miss option to remind later with other time duration than 5 minutes

https://bugs.kde.org/show_bug.cgi?id=453298

Flossy Cat  changed:

   What|Removed |Added

 CC||flossy-...@online.de

--- Comment #7 from Flossy Cat  ---
(In reply to Till Schäfer from comment #0)
I experienced the same issue when upgrading within my distribution.
As neither here nor in the many duplicates I see any progress to a solution,
I've set up a discussion about possible workarounds to which I invite anybody 
interested: https://bugs.kde.org/show_bug.cgi?id=481024#c1

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 453299] kalendarac: Notifications miss option to edit event directly

https://bugs.kde.org/show_bug.cgi?id=453299

Flossy Cat  changed:

   What|Removed |Added

 CC||flossy-...@online.de

--- Comment #5 from Flossy Cat  ---
(In reply to Till Schäfer from comment #0)
I experienced the same issue when upgrading within my distribution.
As neither here nor in the many duplicates I see any progress to a solution,
I've set up a discussion about possible workarounds to which I invite anybody 
interested: https://bugs.kde.org/show_bug.cgi?id=481024#c1

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 457046] Recent update removes the reminder popup window with a notification, snooze time adjustment is no longer available

https://bugs.kde.org/show_bug.cgi?id=457046

--- Comment #3 from Flossy Cat  ---
(In reply to geekiehiway from comment #0)
I experienced the same issue when upgrading within my distribution.
As neither here nor in the many duplicates I see any progress to a solution,
I've set up a discussion about possible workarounds to which I invite anybody 
interested: https://bugs.kde.org/show_bug.cgi?id=481024#c1

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 461233] Default time unit for suspending

https://bugs.kde.org/show_bug.cgi?id=461233

Flossy Cat  changed:

   What|Removed |Added

 CC||flossy-...@online.de

--- Comment #3 from Flossy Cat  ---
I experienced the same issue when upgrading within my distribution.
As neither here nor in the many duplicates I see any progress to a solution,
I've set up a discussion about possible workarounds to which I invite anybody 
interested: https://bugs.kde.org/show_bug.cgi?id=481024#c1

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481053] kalarm CLI options wrongly transfered to »--edit-new-display« and actual alarm

https://bugs.kde.org/show_bug.cgi?id=481053

--- Comment #1 from Flossy Cat  ---
I forgot to mention: as a seasoned computer engineer I might help with changes
if brought up to speed …

-- 
You are receiving this mail because:
You are watching all bug changes.

[korganizer] [Bug 481063] New: A reminder option to run a command would enable valuable use-cases

https://bugs.kde.org/show_bug.cgi?id=481063

Bug ID: 481063
   Summary: A reminder option to run a command would enable
valuable use-cases
Classification: Applications
   Product: korganizer
   Version: 5.22.3
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: incidence editors
  Assignee: kdepim-b...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

SUMMARY
A few examples of IMHO valuable use-cases:
* start a video-conferencing client a few minutes before a meeting
* start more complex set-ups like a VPN and a collaboration platform before a
meeting
* change the desktop activity suiting to the event or todo at hand

I consider the availability of such "user exits" to implement new and
sophisticated functionality (especially as a proof of new concept) generally as
an important advantage of the unixoid eco-system and characteristic for a
sophisticated usage of computers.

SECURITY CONSIDERATIONS
Obviously when importing calendar or todo events from any source, "run command"
reminders MUST be ignored.
(As RFC 5545 does not provide for this kind of reminders the risk is
theoretical anyhow.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #3 from Flossy Cat  ---
VIA KORGANIZER

(In reply to Flossy Cat from comment #2)
> Possible Workaround: »kalarm«
> ==
> …
> The burning question remains, how to call »kalarm« or create »kalarm«
> reminders from »korganizer« reminder events.

AFAIR there once was an option within »korganizer« – even if not I see valuable
use-cases besides this workaround topic.
You might care to support and comment on the feature request:
https://bugs.kde.org/show_bug.cgi?id=481063

-- 
You are receiving this mail because:
You are watching all bug changes.

[korganizer] [Bug 481063] A reminder option to run a command would enable valuable use-cases

https://bugs.kde.org/show_bug.cgi?id=481063

--- Comment #1 from Flossy Cat  ---
I forgot to mention: as a seasoned computer engineer I might help with changes
if brought up to speed …

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481068] New: The power to run a command upon a notification is severely limited by lack of information

https://bugs.kde.org/show_bug.cgi?id=481068

Bug ID: 481068
   Summary: The power to run a command upon a notification is
severely limited by lack of information
Classification: Frameworks and Libraries
   Product: frameworks-knotifications
   Version: 5.103.0
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kdelibs-b...@kde.org
  Reporter: flossy-...@online.de
CC: kdelibs-b...@kde.org
  Target Milestone: ---

SUMMARY
While it is possible to trigger a command execution for specific event types,
these commands do not have all available information from the triggering
notification event, severely limiting the possibility of the programmatic
response and thus the use-cases (of course the content of a specific
notification is controlled by some other piece of SW – but it is a serious flaw
of the notification system to not convey all available information!)

Consider providing all information by actually providing the title of the
notification – %t is not set currently!
Alternatively or additionally consider to provide all information in a
structured format (name=value / JSON / XML) on
STDIN of the executed command or as an environment variable (there several
formats could be provided in different variables).

STEPS TO REPRODUCE
1. edit in system settings a notification type to contain a command
2. verify the data provided to it (see
https://invent.kde.org/frameworks/knotifications/-/blob/kf5/src/notifybyexecute.cpp?ref_type=heads)
and the discussion in response to comment 2 of
(https://bugs.kde.org/show_bug.cgi?id=481024)

OBSERVED RESULT
Insufficient information of the triggering notification is available to the
command.

EXPECTED RESULT
All information pertaining to the triggering notification should be available
to the command to allow optimal programmatic response.

SOFTWARE/OS VERSIONS
SOFTWARE/OS VERSIONS
[copied from System Information]
Operating System: openSUSE Leap 15.5
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150500.55.44-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

ADDITIONAL INFORMATION
As a seasoned computer engineer I might help with changes if brought up to
speed …

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] New: With framework version 6 the option to execute commands as part of notifications seems gone

https://bugs.kde.org/show_bug.cgi?id=481069

Bug ID: 481069
   Summary: With framework version 6 the option to execute
commands as part of notifications seems gone
Classification: Frameworks and Libraries
   Product: frameworks-knotifications
   Version: unspecified
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: grave
  Priority: NOR
 Component: general
  Assignee: kdelibs-b...@kde.org
  Reporter: flossy-...@online.de
CC: kdelibs-b...@kde.org
  Target Milestone: ---

SUMMARY
Comparing
https://invent.kde.org/frameworks/knotifications/-/tree/kf5/src?ref_type=heads
with
https://invent.kde.org/frameworks/knotifications/-/tree/master/src?ref_type=heads
I notice that »notifybyexecute« is missing.

I suspect that this implies the plan to drop this functionality.

I consider this a severe degradation of usability and strongly object:
So-called "user exits", i.e. an option for the power user to establish
sophisticated workflows have always been the hallmark of the unixoid ecosystem
in general and KDE especially.

There is a multitude of use-cases:
* start a video-conferencing client a few minutes before a meeting
* start more complex set-ups like a VPN and a collaboration platform before a
meeting
* change the desktop activity suiting to the notification at hand
* trigger actions upon connection of specific media
* trigger actions when a specific WLAN becomes available or is lost (e.g.
locking screen)
* trigger actions when a specific bluetooth device becomes available or is lost
(e.g. alarms, locking screen, etc.)

On a general note I consider it very unfortunate when such fundamental, long
available functionality is silently scratched without any prior effort to find
out about sophisticated usage. Long-term KDE users like me – around a quarter
of a century! – tend to have a lot of sophisticated customization others might
not imagine in their wildest dreams. It is *not respectful* to thoughtlessly
break long-time users environments! 

STEPS TO REPRODUCE
1. compare the named source code repositories

OBSERVED RESULT
Loss of the functionality »notifybyexecute«

EXPECTED RESULT
Preservation of the functionality »notifybyexecute«

SOFTWARE/OS VERSIONS
– not applicable –

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #5 from Flossy Cat  ---
VIA KNOTIFIER

(In reply to Flossy Cat from comment #2)
> Possible Workaround: »kalarm«
> ==
> …
> The burning question remains, how to call »kalarm« or create »kalarm«
> reminders from »korganizer« reminder events.

The notification demon (at least »knotifier«) allows (still – see below) to
trigger a command with a notification.

To usefully trigger a »kalarm« workaround we'd need sufficient information to
construct a new reminder.

I tested for
* arguments – the command triggered receives no data via arguments added to the
call
* enviroment – the command triggered receives no data via environment variables
* STDIN – the command triggered receives no data via its STDIN file descriptor

Finally I tested for %-escaped variables and found the following:
(https://invent.kde.org/frameworks/knotifications/-/blob/kf5/src/notifybyexecute.cpp?ref_type=heads)
%e – Event ID
%a – Application Name
%s – text of the notification
%w – WinID
%t – window title
%i – notification ID
%d – Application display name

For the event in the attached screenshot this yields
EventID(%e)=»alarm«
AppName(%a)=»kalendarac«
Text(%t)=»Aufgabe hat um 16:32 begonnen«
NotificationID(%i)=»10«
DisplayName(%d)=»Erinnerungen«
WindowTitle(%t)=»%t« – obviously this variable is not expanded?
WinID(%w)=»0« – effectively no windowID returned

As can be seen from the screenshot – essential information is not provided. :-(

There is much room for improvement to make the option of programmatic
notifications useful – if you share this sentiment you might care to comment on
https://bugs.kde.org/show_bug.cgi?id=481068

Further, judging from the code, the option of executing commands as part of a
notification will be removed in KF6: »notifybyexecute« is missing in
https://invent.kde.org/frameworks/knotifications/-/tree/master/src?ref_type=heads
 
I strongly object to this further usability-degradation – you might want to
join that cause: https://bugs.kde.org/show_bug.cgi?id=481069

Further I tested the option to write notification data to a file (which could
of course be a suitably hooked-up socket):
This just yields »- KNotify Mi. Feb. 7 16:54:01 2024: Aufgabe hat um 16:32
begonnen« for the event above – again not useful as essential information is
missing and even less useful than the %-escapes!

Because of this short-comings this approach is alas not viable (as isn't "via
»korganizer«") …

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #6 from Flossy Cat  ---
Created attachment 165676
  --> https://bugs.kde.org/attachment.cgi?id=165676&action=edit
Screenshot of a notifier popup

This screenshot of a notifier popup serves for comparison with the information
provided to "execute command" hooks in comment #5

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #7 from Flossy Cat  ---
Comment on attachment 165676
  --> https://bugs.kde.org/attachment.cgi?id=165676
Screenshot of a notifier popup

This screenshots serves as comparison to the information actually provided via
the "execute command" hook – see comment #5

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #8 from Flossy Cat  ---
(In reply to David Faure from comment #4)
> I was told this was because freedesktop.org notifications don't support
> custom widgets, only a few action buttons, for interoperability with other
> desktop environments. 

I know – but this only demonstrates the choice to move to "freedesktop.org
notifications" as sole solution was ill-advided.

> I agree however this is really suboptimal, especially when not caring for 
> other desktop environments.

"really suboptimal" is runner-up for the euphemism of the week …

IMHO it is a fundamental lack of respect and rude to long-term KDE users to
fundamentally break existing functionality (and their workflows) without proper
announcement and transition provisions.

The fatal decision happened around 2 years ago, complaints exist since more
than 18 month – without solution.
I was confronted with this breaking changes when non-suspecting upgrading my
distribution – and the heart-ripping decision to give up a quarter of a century
KDE PIM usage, if I do not find a working workaround within 2–3 weeks. (And
that is not the first incident of this time – but so far definitely the worst
and potentially final one.)

IMHO the proper way would have been to keep the old behavior as an option and
wait for the reaction for at least 2 years before cutting of the old
functionality.

> As for "workarounds", you can find the code in
> akonadi-calendar/reminder-daemon/alarmnotification.cpp line 135 and add more
> buttons like "remind tomorrow".

The number of buttons is limited and cannot provide for my variable needs, lest
the needs of the numerous others having raised similar complaints. This is *not
a viable workaround*.

Are there any D-Bus-events I could hook on?

> Maybe we should implement an alternative notification solution in kalendarac
> that looks more like the old korgac dialog (minus its bugs...).

Definitely. And very soon. 
Actually you should never have removed the original functionality without a
substitute or a transition strategy as lined out above.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #12 from Flossy Cat  ---
(In reply to David Faure from comment #9)
> > Actually you should never have removed the original functionality 
> 
> "You"? Just because I have a @kde.org address does not mean I was part of
> that decision in any shape of form. 

Sorry, no offense meant – I am not a native speaker/writer of the English
language.

I used "you" as second person plural. In my native language (German) this is
clearly
set apart from second person singular and even written different if one is
addressing
the actual participants of a conversation or a loosely specified group.

The text, rendered in German, would have clearly conveyed, I do not mean you as
person,
but "them" in charge of this solitary decision and "them" responsible for this
"decision culture"
alienating loyal user and supporters of KDE since the transition from KDE3 …

What would be a proper phrase in English to transport this meaning?

> On the contrary I was among the first
> ones to complain about it when I found out, as a user. And I'm writing here
> because I'm on the same side as you, trying to find possible solutions. 

I concluded this from your phrase "I was told this …" and the provided
suggestion and really did not intend to attack you.

> I know you're frustrated but please refrain from attacking the first person
> you talk to.

I would only be frustrated if I would be helpless – that I'm definitely not.
I'm annoyed by the nasty surprise of a grave functional regression of core SW I
daily rely on.
I'm angered to have to postpone my native own tasks and quickly find a
workaround or migrate to Thunderbird.
I'm alienated by the repeated disregard of the decision makers in the KDE
community for the effort loyal and
dedicated KDE users put in sophisticated work environments and work flows.

> As for DBus, I'm sure the notification library sends a DBus signal that
> plasma reacts to, but I'm not sure how that would help as long as kalendarac
> only has code to postpone by 5 minutes and 1 hour.

Here a sketch of the workaround (which easily could be grown into a
professional solution):

I presume that some »korganizer« sender will send a message with all necessary
information
to some »knotifier« endpoint (receiver). As a lot is going on on my session
DBus some guidance
to narrow the search down would be welcome.

I then will hook on this message (via »qdbus-qt5« or »busctl«) and have some
script act upon it, 
probably firing up a suitably tailored »kalarm« command. Then this workaround
has to be made
permanent – i.e. autostart with each GUI login and deactivate all notifier
actions for calendar reminders …

The final solution could be achieved along this lines if the »kalarm«
developers would honor the 
kind request to provide an option to do this natively in »kalarm« itself. Some
minor improvements
suggested within the GUI of »kalarm«'s edit window for reminders and we would
have an excellent
substitute for (and even improvement over) the old functionality.

All at the individual user's choice:
Those happy with the current solution just keep it.
All the others essentially configure »kalarm« as reminder handler for
»korganizer«.

»kalarm« should even capable to address Bernhard's problem of stale reminder
storms when
switching between different machines: It can suppress late reminders …

Actually I'm just prototyping a workaround but are stalled by some minor bugs
both in »kalarm« and »korganizer«
I do not yet fully understand …

If you, David, could be so kind to draft persons knowledgeable in »kalarm« or
»korganizer« (both skills are needed
but not necessarily within one person), this would be very helpful.

Thanks in advance.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #13 from Flossy Cat  ---
(In reply to Bernhard E. Reiter from comment #10)
> I also find that the regression is a major one. (I've reported this in
> https://bugs.kde.org/show_bug.cgi?id=452264 among other significant
> usability problems.).

Speaking of usability problems (and I share your view on usability problems in
KDE PIM 
and could extend the list …) – slightly off-topic:

I now had 2 times the collision warning page when entering a comment, because
others
commented while I edited my comment. I have no idea, which of the 2 presented
options
does not pose the risk of unintended nuking the other person's comments.
I workaround by copying my comment text and starting anew – any advice from an
experienced
bugs.kde.org user? 

> To add more use cases: 
> ### saving working time shortly before a meeting
>  * I have many meetings where the reminder is 15 minutes, so I can prepare.
>  * When this is checked I delay up to 2 minutes before the appointment, …

Same here, but with a slightly different workflow:
I always have a preparation reminder (typically 15–30 minutes in advance) and
a final reminder (2–5 minutes in advance) configured – so I definitely get the
final reminder even if absorbed in preparation.

I would very much appreciate an "user exit" reminder option (execute commands).
Use cases:
* Open the necessary tools for preparation, e.g. a specific JIRA issue.
* Fire up a web-conference client or a browser with the conference URL as or in
parallel with the final reminder.

See https://bugs.kde.org/show_bug.cgi?id=481063 and
https://bugs.kde.org/show_bug.cgi?id=481068 and
https://bugs.kde.org/show_bug.cgi?id=481069

> ### using several computers
>  * I have at least three computers with Kontact, that all sync their
> appontments (using the stone-old Kolab 2 format for historical reasons).
>  * When working from home once a week, I have to click away all appointments
> that have been there since last starting kontact on this machine.
>  (This is not a delay use case, but... I mention it because:)

Well, actually strongly related and my current workaround approach would
probably
solve your problem, as »kalarm« optionally ignores "late reminders" and would
work even
without sync'ing …

See https://bugs.kde.org/show_bug.cgi?id=481024#c12

> The old kontact/korgac  saved the delay in the internal memory and did not
> sync it on the machine.
> 
> A property what would really improve the situation would be to sync the fire
> time of reminders to the servers
> and thus also record a potential new delay . …
> I am not sure if the current status of the iCalender format - which is often
> used nowadays - allows it. It might.

Definitely, if implemented conformant to RFC 5545.

> ## User Interface
> What about if the desktop notifications bring up a special
> korganizer/kontact view that holds all fired alarms for appointments, tasks
> and so on with options that allow at least what the old overview did and a
> compact overview? (Just an idea.)

»kalarm« provides this.

Bernhard, I know you once were well-connected into the upper tiers of KDE. 
If this still holds true, can you kindly draft some knowledgeable persons for 
»kalarm« and »korganizer« into the discussion?
The workaround I'm PoCing might easily and quickly be upgraded to full-grown 
solution with some knowledgeable help …

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #15 from Flossy Cat  ---
(In reply to Bernhard E. Reiter from comment #14)
> Two other potential "workarounds" for you (just for completion):
>  * Stay on the elder version temporarily (to buy more time for a solution)

Alas no viable option:
* The elder version is not available in the OpenSuSE 15.5 repositories. This
would need some tricks and risk instabilities.
* It would probably not receive security updates.
* The effort would be more than rolling forward to Thunderbird.

>  * Go to Kontact from Trinity. It is still maintained

Again, not very viable:
I tried Trinity some years ago when KDE had one of its serious transition fits.
While I really like the look and fell of the GUI, the tool functionality stays
mostly frozen and the kontact variant would not sufficiently serve me.
And again, the effort would be more than rolling forward to Thunderbird.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kalarm] [Bug 481053] kalarm CLI options wrongly transfered to »--edit-new-display« and actual alarm

https://bugs.kde.org/show_bug.cgi?id=481053

--- Comment #3 from Flossy Cat  ---
(In reply to David Jarvie from comment #2)
> Now fixed for KAlarm version 3.6.4 in KDE Gear 23.08.5 (commit
> a05422923b625f9cf5f1d6f167e6a6d0b3e60b7f) and KAlarm version 3.7.0 in KDE
> Gear 24.02 (commit f3dd19a8e2b900a36ca2433e59f6ae9c93ae42da).

Thank you very much for your quick solution.

Would it be possible to apply the fix also to the reported version 3.5.4.2 in
KDE Gear 22.12.3?

Because that is the version available in OpenSuSE 15.5 without non-standard
repositories.
Even when resorting to
https://download.opensuse.org/repositories/KDE:/Applications/KDE_Frameworks5_openSUSE_Leap_15.5/
I only get 23.08.4 – thus missing out on your fix. 
(Worse: at the moment this repository seems not to be consistent within itself
and produces a wealth of dependency problems within the KDE components … :(

> Thanks for reporting this. There was a slip-up when originally implementing
> the --name option.

Be my guest – thank you for fixing so fast!

-- 
You are receiving this mail because:
You are watching all bug changes.

[korganizer] [Bug 481129] New: When adding an ICAL calendar file to korganizer the resource first fails to work then duplicates in the GUI …

https://bugs.kde.org/show_bug.cgi?id=481129

Bug ID: 481129
   Summary: When adding an ICAL calendar file to korganizer the
resource first fails to work then duplicates in the
GUI …
Classification: Applications
   Product: korganizer
   Version: 5.22.3
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kdepim-b...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

SUMMARY
When adding an ICAL calendar file (as opposed to an ICAL calendar directory) to
korganizer the resource first fails to work then duplicates in the GUI into a
functional and a non-functional twin.


STEPS TO REPRODUCE
1. Start »kalarm« to produce an empty ICS file (correct VCALENDAR data
structures without VEVENTS or VTODOS produced by KDE library »libkcal«) (Reason
for this see https://bugs.kde.org/show_bug.cgi?id=481024)
2. optional: completely stop »kalarm« to prevent any interaction of the 2
programms
3. within »korganizer« settings create a new ICS file calendar with path
/home/X/.local/share/kalarm/calendar.ics and optionally a choosen name
4. the calendar will be created and displayed in the »korganizer« GUI but your
name choice will be ignored and something like "akonadi_ical_resource_5" will
be displayed.
5. monitor the calendar file "/home/X/.local/share/kalarm/calendar.ics" for
changes with the tool set of your choice.
6. with »korganizer« add events and/or todos to this new calendar – you wont
see changes in the ICS file.
5. Restart the calendar within »korganizer« settings (calendar tab) – while the
number of calendars in the calendar tab stays the same, in the »korganizer« GUI
the calendar suddenly duplicates: one with your choosen name, one still with
"akonadi_ical_resource_5" or the like.
7. with »korganizer« add events and/or todos to the calendar with your choosen
name – they are written to the ICS file.
8. with »korganizer« add events and/or todos to the calendar with the
"akonadi_ical_resource_5"-style name – they will not find their way into the
ICS file (but are display in the calendar!).
9. delete the dysfunctional "akonadi_ical_resource_5"-style named calendar –
both vanish …

OBSERVED RESULT
Described in detail in the steps above.

The same behavior is observed invariant of the following:

* The ICS file is an RFC 5545 conformant empty VCALENDAR file – i.e. the file
is NOT empty, but contains a proper VCALENDAR structure without events or todos
like so:

BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
X-KDE-ICAL-IMPLEMENTATION-VERSION:1.0
X-KDE-KALARM-VERSION:2.7.0
…
END:VCALENDAR

* or the file contains proper events or todos.

* The file is or is not opened in parallel by »kalarm«. 

EXPECTED RESULT
A single calendar is added which works correctly and displays its given name
correctly. 
(preferably directly or at least after a restart of the calendar).

SOFTWARE/OS VERSIONS
[copied from System Information]
Operating System: openSUSE Leap 15.5
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 5.14.21-150500.55.44-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

ADDITIONAL INFORMATION
As a seasoned computer engineer I might help with changes if brought up to
speed …

POSSIBLE DUPLICATE
The bug report https://bugs.kde.org/show_bug.cgi?id=452588 – but the path to
error state is more convoluted than in my case.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 493233] New: Maximize a window cause it no longer update framebuffer under Wayland

2024-09-16 Thread Rin Cat

https://bugs.kde.org/show_bug.cgi?id=493233

Bug ID: 493233
Summary: Maximize a window cause it no longer update
framebuffer under Wayland
Classification: Plasma
Product: kwin
Version: 6.1.5
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: kwin-bugs-n...@kde.org
Reporter: rin...@rincat.dev
Target Milestone: ---

Created attachment 173746
--> https://bugs.kde.org/attachment.cgi?id=173746&action=edit
left side is freeze dolphin at back, right side is a freeze dolphin and mouse
move shadow

***
If you're not sure this is actually a bug, instead post about it at
https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

Please remove this comment after reading and before submitting - thanks!
***

SUMMARY
When I maximize a window, after the animation, the window no longer update its
framebuffer. Leaves the last frame and others can draw on it, as I attached
screenshot.
The window still able to response any actions, like click or keyboard, and the
mouse will change to different icon like move or busy.
When the window undo the maximize, like use super + drag, everything back
normal.
I am not sure what actually cause this, but I start notice it recently around
plasma 6.1.

STEPS TO REPRODUCE
1. Maximize a window
2.
3.

OBSERVED RESULT
The window freeze and no longer update its framebuffer.

EXPECTED RESULT
Window able to update its framebuffer.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.11.0-gentoo-x86_64
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
Under Wayland, with LLVM/clang/clang++
Intel A770 GPU

--
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-08-15 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

Flossy Cat  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #45 from Flossy Cat  ---
The bug is not resolved or fixed for the version it was reported!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 491636] Kwin crashes out of the blue on an unloaded system

2024-08-29 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=491636

--- Comment #4 from Flossy Cat  ---
It does not work for all those people:

https://bbs.archlinux.org/viewtopic.php?id=281129
https://forum.manjaro.org/t/how-to-troubleshoot-broken-kde-plasma-window-manager/133533
https://forum.garudalinux.org/t/kwin-x11-crashing-repeatedly/25240
https://forum.manjaro.org/t/kwin-core-xcb-error-reproducible/78330
https://forums.opensuse.org/t/kde-plasma-random-crashing-tumbleweed/162569
https://github.com/FreeRDP/FreeRDP/issues/8114

WORKSFORME IMHO shows gross disrespect to all those people …

All not coming here for help – wonder why?
(Help is meant two-way: Reporting bugs here is both about getting help yourself
as well as providing help to KDE!)


My case is potentially a regression, if the original MESA change was
re-introduced …
See Bug 461316 and Bug 457847 …

And of course there is a further bug:
DrKonqi is meant to produce a backtrace – as can be seen from my provided logs.
Of course it can't with kwin gone. This is a bug, as intended behavior fails.
Either a DrKonqi bug – DrKonqi needs a reporting strategy if kwin is gone – or
a (further) kwin bug – kwin shouldn't use DrKonqi as method to provide
backtraces …
(But I'm meanwhile tired of reporting bugs here: It's probably contributing to
karma but definitely not to joy …)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 491636] Kwin crashes out of the blue on an unloaded system

2024-08-29 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=491636

--- Comment #6 from Flossy Cat  ---
(In reply to Nate Graham from comment #5)
> I understand it's frustrating for your non-actionable bug report to be
> closed as RESOLVED WORKSFORME, 

This is not about frustration, but about attitude.

I'm computer scientist, SW-engineer and project trouble-shooter with 40+ years
experience, hunting difficult bugs since (and since 1986 in FLOSS). So, I
completely understand, that – while I delivered what was available in the
system – that is not much to work from.
Read the following as "from professional to professional" and not as rant!

I could perfectly well live with REPORTED and WAITINGFORINFO – because that
would be factually correct and might later contribute to a more complete view
when similar bug reports with other indicators pop up. 

Closing the issue is IMHO wrong both on the process level as well as in social
communication.
WORKSFORME as a state conveys gross impoliteness, disinterest and neglect as
well as communicates a very egomaniac perspective not in concordance with the
spirit of a community. It further communicates, that KDE doesn't care both
about problems in crucial components like kwin (or KDE-PIM, see my the
corresponding bug reports) and the problems KDE user experience (again, see my
KDE-PIM bug reports).
In German we have a shorter term for WORKSFORME: LMAA …

I was a fervent user and advocate of KDE for a quarter of a century – with much
heartache I'm migrating away from KDE-PIM, which was the main reason for still
using KDE. Having worked on many ailing and failing projects professionally, I
recognize many warning indicators in many KDE elements (programs, docs,
foundation). What is your perception as QA manager by profession?

> but there's a solution to that: make it actionable. If you aren't able to, 
> maybe any of those people might be able to.

So far the crash did not repeat – I check regularly for systemd-coredump
collecting a core-dump (as OpenSUSE already
has a counter-measure by having systemd restarting kwin, a repetition could go
by without noticeable effects …)

As you see from the links: I did research and I'm providing the information I'm
able to collect. 
Obviously "those people" don't care, and – with the exception of my Kalarm bug
reports – I have still to see any level of care of spirited bug resolution for
the KDE LTS version at KDE-BUGS. 

> Bug reporting is a technical process that demands something from the bug
> reporter too. See
> https://community.kde.org/Get_Involved/
> Issue_Reporting#Issue_reporting_involves_responsibility.

Where do I not follow my responsibility?

> The issue with being unable to get a backtrace for KWin was solved in Plasma
> 6 which was released 6 months ago, but unfortunately you're still on Plasma
> 5, so that doesn't help either.  There have been so many KWin changes since
> Plasma 5.27 that it's quite possible the issue is already fixed anyway. It
> could also have been fixed in a newer Mesa, Kernel, etc. Bug reports on old
> software like this one often end up in such a state; it's just the way
> things are. Using more up-to-date software definitely helps to make bug
> reports more actionable.

As given in the version section:
I'm using OpenSUSE LEAP 15.6 which is current software which uses the current
KDE LTS version.
I use my systems for productive work and this precludes manually compiling or
installing leading edge versions, because I need timely security patches. This
is state of the art and not open for discussion. This professional stance
should be embraced by KDE.

What sense does a KDE LTS version make, if KDE does not consider itself bound
by the promise of *Long Term Support*?

If the only choice is "bleeding edge with continuous nasty surprises" vs. "live
2 years with bugs till repaired versions trickle downstream into
well-maintained distributions", my choice is clearly the 3rd option: 
Switch the desktop and the tool-set. That definitely WORKSFORME and RESOLVES my
problems.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 483545] Kmail2 silently looses mails while displaying the correct counts with the folders

2024-09-03 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=483545

--- Comment #3 from Flossy Cat  ---
(In reply to Bernhard E. Reiter from comment #2)
> Do you know which database akonadi is using for the cache? (Usually it would
> be postgresql, sqlite or mariadb.)

MariaDB 10.11.8-MariaDB source revision
3a069644682e336e445039e48baae9693f9a08ee

-- 
You are receiving this mail because:
You are watching all bug changes.

[korganizer] [Bug 491119] New: Persisting loss of user-defined snoozing for calendar and todo reminders is a massive functional regression

https://bugs.kde.org/show_bug.cgi?id=491119

Bug ID: 491119
   Summary: Persisting loss of user-defined snoozing for calendar
and todo reminders is a massive functional regression
Classification: Applications
   Product: korganizer
   Version: 5.24.5
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: major
  Priority: NOR
 Component: reminder daemon (korgac)
  Assignee: kdepim-b...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

SUMMARY
The functional regression described in Bug 481024 is not resolved in the
long-term support KDE version (version described below) used by OpenSUSE 15.6
and the corresponding SLE 15 (SUSE Linux Enterprise).

This impacts at least all users of the current version of KONTACT (Version
5.24.5 (23.08.5)) in these current versions of these well-spread distrubutions.

It makes KONTACT unusable for any calendaring and task workflow usage but the
most unsophisticated …
(Evidence: the reaction of other users in the thread of Bug 481024)

If your intention is to diminish the user base it is a viable approach. More
fair and respectful to your user base would be a official deprecation of
KONTACT with at least 2 years advance warning time to facilitate migration
(which requires some considerable effort …)

STEPS TO REPRODUCE / OBSERVED RESULT / EXPECTED RESULT
described in detail in Bug 481024 (https://bugs.kde.org/show_bug.cgi?id=481024)

SOFTWARE/OS VERSIONS
Operating System: openSUSE Leap 15.6
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12
Kontact Version: 5.24.5 (23.08.5)
Kernel Version: 6.4.0-150600.23.14-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics


ADDITIONAL INFORMATION
–

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #29 from Flossy Cat  ---
The regression is unresolved Kontact Version: 5.24.5 (23.08.5), which is used
e.g. in OpenSUSE 15.6 and the corresponding SLE 15 (SUSE Linux Enterprise) as
part of the current long term support KDE version, which is these distributions
rely on.

See (and support) bug 491119 – https://bugs.kde.org/show_bug.cgi?id=491119

PS:
Any suggestions for alternatives to Kontact but Thunderbird or Evolution?

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 491130] New: Session management loses state between sessions

https://bugs.kde.org/show_bug.cgi?id=491130

Bug ID: 491130
   Summary: Session management loses state between sessions
Classification: Plasma
   Product: plasmashell
   Version: 5.27.11
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Session Management
  Assignee: plasma-b...@kde.org
  Reporter: flossy-...@online.de
CC: natalie_clar...@yahoo.de
  Target Milestone: 1.0

SUMMARY
After logout or shutdown, when logging in again, session is occasionally not
restored correctly.
When multiple windows of an application were open, sometimes they are not
restarted.
(This never happened with Plasma 5.27.9 over a period of more than 20 months,
but happens roughly in 1 out of 5 re-logins with Plasma 5.27.11 – so the bug
was introduced between)

STEPS TO REPRODUCE
Plasma is configured to restore the session from the last logout.

So far no reproducible trigger could be identified – it seems to happen
randomly on several different systems (with the same SW versions).

OBSERVED RESULT
After logout sometimes multiple windows of several programs – observed with
Dolphin, Konsole (and some tabs of Firefox, but that might be an uncorrelated
issue) – are not restored. Instead either no window or a single window of the
program is opened (at the default location – i.e. user home)

Funnily: If then you logout immediately and then re-login, often the windows
are restored correctly as you left them with the session second to last … (nice
bug – bug, because it should have restored the incomplete state of the previous
session – but recovers the state of the penultimate (which the previous session
should have had recovered) …

EXPECTED RESULT
KDE/Plasma correctly and reliable recovers the window states of the previous
session.
(as can and is expected from X11 window managers since the days of "olvwm" – 35
years ago …)

SOFTWARE/OS VERSIONS
Operating System: openSUSE Leap 15.6
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12
Kernel Version: 6.4.0-150600.23.14-default (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-10210U CPU @ 1.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

ADDITIONAL INFORMATION
–

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #31 from Flossy Cat  ---
(In reply to David Faure from comment #30)
> It's fixed in 24.02, I'm not sure what else you're asking for. 23.08 is a
> year old, and time machines haven't been invented yet.

Very simple: OpenSUSE Leap 15.6 and SLE 15 SP6 are widespread current
distributions used by millions of users.
Both rely on the LTS versions of KDE/QT. This results in the following version
for Kontact and its components: 5.24.5 (23.08.5)
SLE 15 SP6 users have support for several years (5 AFAIR) and are potentially
stuck with this fundamentally unusable version …
Leap users for at least a year …

People like me (and my customers) use versioned distribution like Leap to have
a reliable, well tested, stable system. (I personally returned from Tumbleweed
to Leap because I was bitten by Tumbleweed several times – for that same reason
I don't want to use the OBS KDE factory repositories: just not yet mature and
well tested enough for my everyday work, and the dependency resolver has
complains …)

The quality assurance done by the distributions takes time and effort – with
less than a year slack OpenSUSE is relatively quick, IMHO …

Either the KDE community is interesting in keeping a user base amongst the
Linux distribution users – or not.

If yes, port bug fixes back to the LTS versions and thrive.

If no, feel free to wither further.

I personally are very sick of this kind of discussion, of ill-advised
deprecations and functional regressions and the inherent lack of respect thus
expressed against the KDE user base  – after more than a quarter of a century I
will cease to support, recommend and use KDE.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-08-02 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #36 from Flossy Cat  ---
Dear Bernhard,

thanking you for your soothing words – but …

(In reply to Bernhard E. Reiter from comment #32)
> Dear @Flossy Cat,
> 
> > I personally are very sick of this kind of discussion, of ill-advised 
> > deprecations and functional regressions and the inherent lack of respect 
> > thus expressed against the KDE user base
> 
> it is sad to read about your frustrations with some KDE products like
> Kontact. 

This is not about frustrations but about realizing facts and drawing
conclusions for the viability of further relying on KDE for my workflows.

Let's have a look together at what I perceive as facts here:

F1: It is completely normal for code changes to travel around 1–2 years
downstream from the development frontier to the end user.

F2: So many bugs and detrimental deprecation decisions will only discovered
then – that is 1–3 years down the line.

F3: KDE changes have – starting with the transition from KDE 3 to 4 – a long
history of very nasty surprises for their user base, with fundamental changes
and deprecations biting the users without early warning and time for proactive
measures.
F3.1: "Announcements" are typically in the style of the beginning of
"Hitchhiker's Guide to the Galaxy": in some obscure, small mailing lists or the
commits some deprecation notice is given.
(I'd had to follow around 400 such sources to cover my SW base against nasty
surprises – CONCLUSION: not viable …)
F3.2: At least the deprecation and regression this bug is about as well as the
Bug 481069 both seemingly were decided by people either not having a sufficient
sophisticated use of the SW components they decide to deprecate or they didn't
care for the effect on the user community.
Evidence: Even very unsophisticated users of calendaring see the necessity for
flexible snoozing of reminders!
(Or the whole decision process is haphazard, not providing for any
consideration of stake holders, impact analysis, etc., and allowing for random
whims of individuals.)
CONCLUSION: I can not rely on KDE SW for long-term use anymore.
F3.3: Supporting F3.2, the explanations given so far for these decisions do not
hold water:
If you dive into the developer discussions around the deprecation leading to
the regression in Bug 481069, the primary argument is essentially "can not be
implemented on smartphones" …
The regression was defended with "we don't see any bug reports for this
component, so it is not used" – equivalent to saying: we deprecate all
functionality mature enough to not cause frequent bug reports anymore …
(Next absurd defense line: "we cannot learn real usage because of privacy" –
this in a discussion on "bugs.kde.org", which proliferates the mail-addresses
of the bug reporters like there is no tomorrow (I've burned several pseudonyms
here meanwhile – my suggestion to change this problematic behavior of
"bugs.kde.org" was not greeted with politeness …))
Similarly here with this bug: "we want to switch to a notification framework
available on smartphones" (and drop functionality without consideration of the
impact)
CONCLUSION: User experience and satisfaction ("no nasty surprises", functional
and UI continuity, etc.) is not taken in consideration and/or desktop
experience is no important consideration anymore -> I can not rely on KDE SW
for long-term use anymore.

F4: KDE is either not capable or willing to consider F1 and F2 and to correct
regressions in LTS versions at least 3 years backwards.
When David kindly fixed the regression in February the version 23.08 was just
half a year old and it was already known it will be part of LEAP 16.6 and SLE
16.6. This means users are stuck with this regressions for a long time – in
case of LEAP 16.6 at least till summer 2025.
CONCLUSION: That is not viable. I could use a workaround for the last 6 month
because of a hiatus, but not any longer. (And using OBS KDE to get a more
current version fails on numerous resolver complains, taking a lot of effort to
resolve and seemingly resulting in the choice to drop other SW – the effort
extends to several systems, not acceptable … The same is true of compiling from
source, as I would lose automatic security updates …)

F5: In both bug reports I offered my help and support for implementation as a
seasoned computer engineer if I'm pointed to introductory material or are
guided. No reaction to this offer …
CONCLUSION: Active support is either not wanted or needed.

OVERALL CONCLUSIONS: 
1. KDE does not care for its user base and does not respect the time, effort
and love sophisticated users invested in sophisticated KDE working environment,
which shine and promote KDE.
2. This leads to a vicious circle and downward spiral of the user base and
their support (take me as an example)

FINAL CONCLUS

[plasmashell] [Bug 431382] Display logout screen only on primary display, not all displays

2024-08-03 Thread Schrödingers Cat

https://bugs.kde.org/show_bug.cgi?id=431382

Schrödingers Cat  changed:

   What|Removed |Added

 CC||schroedingers...@disroot.or
   ||g

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 390503] Logout screen item focus not synced with multiple screens

2024-08-03 Thread Schrödingers Cat

https://bugs.kde.org/show_bug.cgi?id=390503

Schrödingers Cat  changed:

   What|Removed |Added

 CC||schroedingers...@disroot.or
   ||g

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-08-03 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #38 from Flossy Cat  ---
(In reply to David Faure from comment #34)
> It is a bit contradictory to want to use a "stable LTS version" (which means
> no new features) and then ask for a new feature to be added to it. I know
> it's frustrating because that new feature is needed to fix a regression, but
> it *is* a new feature.

Your claims are counterfactual:
This bug report is about a regression and re-establishing functionality which
was present in previous versions since many years and were deprecated without
announcement and any consideration on the usability of Kontact for calendaring
afterwards.

"Regression" is part of the title and pervades both the bug report itself as
well as the discussion thread.

The patch you kindly provided – according your own words – reused code from
"korgac" (which was scraped without consideration of the impact, which is the
root cause of the regression), proving the regression.

As stated in comment 8, this change happened 2 years before my bug report and
similar bug reports like mine existed 6 months after this crippling change –
i.e. 18 months before my bug report. This should have been early enough to
avoid having a crippled Kontact (unusable for calendaring) make its way into
LTS and distributions like OpenSUSE and SLE.

The ignored users of these early bug reports probably have left the KDE user
base meanwhile.

I'd worked around 6 month till the advent of LEAP 16.6. I'd would have to wait
roughly a further year to see your patch in the regular distribution. (Or to
compile myself and lose automatic security patches or wade through the
dependency hell of OBS KDE Factory versions and lose other SW because of
resolver clashes – on several systems.) 

That is neither viable nor acceptable, and in any case much more effort than to
migrate to a new PIM solution.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-08-03 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #39 from Flossy Cat  ---
(In reply to Martin Steigerwald from comment #33)
> I understand your frustrations, Flossy Cat. I truly do. KDEPIM has been a
> big trigger of frustrations for me as well. 

Thanks for your quantum of solace, but this is not about "frustrations" –
please see comment 36, my answer to Bernhard.

> …
> But I do also appreciate that the KDEPIM development team is very small. And
> they care about their software. That can be seen again and again like for
> example in the blog posts about the recent meetup they had.

When I opened this bug the crippling change (silent scraping of korgac) was
already 2 years old. (see comment 8 and the related bugs)

Very obviously nobody considered the usability impact of this: 
Even the most simplistic users of any calendaring tool I can question,
immediately answer
that only being able to snooze reminders for 5 min or 1 h would not be
acceptable …

The first bug reports complaining about the effects of this change happened 6
month after the change and 18 month before my bug report. To no avail … – they
were ignored …

I can't rely upon software with this level of care – and I don't care for
software which is cared for like this.

> Also I see that the change implemented by David has more than 160 new lines
> and changes more than 30 other lines. That IMHO is quite a bit for a
> backport. 

David extracted code from the scrapped "korgac" and re-implanted it.
This is neither a "new feature" nor "160 new lines" if "new" is used with its
usual meaning of "something not present earlier".
The change to fix the regression might change around 200 lines to arrive from
"crippled" to "usable" again, but many of these (as well as the functionality)
have been present for many many years.

> But… another approach would be, to talk with openSUSE people
> whether a backport can be done and maybe try to bring forth a back port in
> cooperation between upstream and distro developers? From what I read
> openSUSE volunteer based team is also quite small 

Exactly. The small KDEPIM team causes a use-breaking regression by some
ill-considered decision.
It then ignores all early warnings about the problem and freezes the LTS
versions so that when these decisions start to hurt users relying on KDEPIM no
easy backport of the fix and no easy propagation to the suffering users is
feasible.

Instead I should involve the (equally) understaffed openSUSE team (and other
users their respective distro teams).
This multiplies the effort needed in comparison with the KDEPIM team just
realizing how ill-considered their decision was and fixing it.

If FOSS teams are understaffed (and they definitely are!) this is a very stupid
strategy.

Or we go with David's idea of each user compiling for themselves, further
multiplying the effort (and dangerous, as the self-compiled version does not
receive automatic security patches).

I go with my idea: switch to a PIM solution actually caring for end user
experience …

> and I am not sure whether KDEPIM is a focus for the enterprise variants of 
> SUSE, 

It isn't. The default choice there is Evolution. I always wondered why, because
I regularly every few years reevaluate my SW choices, and Kontact so far always
had a slight edge on Evolution and Thunderbird (but the gap was closing). With
this regression Kontact is far behind and the whole handling of this regression
deeply undermines my trust in KDEPIM.

If the SLE team had similar experience I now understand the preference for
Evolution.


> an approach where you could use your energy in a constructive manner to
> resolve the issue at hand for you and others. Especially also if that fix is
> required by enterprises that use KDEPIM… 

It would be …

> have you consider to ask for or
> organize some paid development work on making a back port? Remember a lot of
> work on KDEPIM is volunteer work. That means it is often enough work done by
> people who also have to do something else to earn money. 

I'm a seasoned computer engineer supporting FOSS since 1986, mostly by
contributed
code and bug fixes and I offered my active support with this bug report – to no
avail.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-08-03 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #40 from Flossy Cat  ---
Dear Bernhard,

(In reply to Bernhard E. Reiter from comment #32)
> …  You were asking for alternatives, I know of Claws mail
> which has is a small but long term team behind it. …

Thanx for the hint. But Claws is an e-mail client and calendaring is only
available as a plugin providing for a single calendar.
I have the need for multiple calendars, making – so far – Evolution and
Thunderbird the only viable solutions to Kontact …

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 491130] Session management loses state between sessions

2024-08-06 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=491130

--- Comment #2 from Flossy Cat  ---
(In reply to Kishore Gopalakrishnan from comment #1)
> I also seem to have a similar issue. When this happens again, can you check
> if you have messages like the following in your system logs?
> 
> ```
> $ journalctl -b -0 | grep "Session management error"
> Aug 04 22:00:34 kishore-thinkpad-e495 kate[4510]: Qt: Session management
> error: Authentication Rejected, reason : MIT-MAGIC-COOKIE-1 authentication
> rejected
> ... [many more messages like this]
> ```

Good hint!

Similar, but slightly different, messages here – on all machines affected, one
example of many identical:

2024-08-06T01:12:45.845617+02:00 systemname kscreenlocker_greet[25446]: Qt:
Session management error: networkIdsList argument is NULL


> Usually this authentication works fine (and the session restores properly),
> but sometime I get this. Perhaps some sort of race condition?

I suspect a bug in the newly implemented option to explicitly manually save and
restore sessions …

(Which IMHO is conceived quite sub-optimally: 
The save option is only present when the system is configured to only manually
restore sessions – but you have to restart your session to have the "save
option" turn up :-(

Much better would have been IMHO:
You always have the option to manually save your session state with a name of
your choice.
The automatic saving of the session at logout (name "last session") can be
toggled.
If there is more than one saved and named session state available, you are
offered the choice …
)

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-08-10 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #42 from Flossy Cat  ---
Hi Bernhard,

(In reply to Bernhard E. Reiter from comment #37)
> …
> > F5: In both bug reports I offered my help and support for implementation
> > as a seasoned computer engineer if I'm pointed to introductory material
> > or are guided.
> 
> >  No reaction to this offer …
> > CONCLUSION: Active support is either not wanted or needed.
> 
> KDE welcomes people, needs and wants active support!

Then, I wonder why nobody pointed me to some kind of primer, guidance,
an onboarding process or anything like this – because  I explicitely asked …

If KDE needs and wants active support this kind of things should be available, 
know to the bug triage theme and promoted on request.

> The problem often is that if someone offers this on a specific defect is
> that 
> (because of Moore's law) you often put more effort into the mentoring
> or guidance than to fix it yourself. Especially if the defect is
> a chain of technical decision and dependencies. Thus mentoring someone
> makes sense if there is high chance that this person wills stay within KDE
> at least for a while.

I'd provided in several bugs the code segments, commits or discussions, where
the root cause lies. I provided code snippets. Some capability can be plausibly 
assumed. This should be sufficient to at least explicitly ASK if I will provide
lasting support (instead of silently assuming I wont – which BTW is a wrong
assumption …)

> Another aspect is that getting a development setup and putting contributions 
> forward is already documented in general for KDE products. So anyone could 
> (in principle) do it without guidance. You could just set this up, come up 
> with patches for a code variant into mobile and desktop and contribute them 
> without much specific interaction. (Yes I am fully aware that this is a 
> suboptimal decision process when looking at it from a greater scale.)

I explicitly stated with my support offers that I want guidance because I'm
aware
of the complexity of the KDE products and want to avoid acting against plans or
carelessly introduce detrimental side-effects.

> You could also propose a backport patch to OpenSuse LTS.

As explained in my answer to Martin:
This multiplies the effort and wastes the scarce resources of several
downstream distribution teams
(if other users replicate the request to their distribution support teams)

More important:

F6: The first bug reports arrived 6 month after the regression was coded – more
than 2 years ago!
There is no "official reaction" of the KDEPIM team on any of these.
Further there is no KDEPIM team reaction on similarly fatal bug 483545.
Meanwhile I know for sure: this is no matter of potentially old, incorrect mail
formats:
It happens in my productive system to! (If you use Kontact, you should dig into
it)

AFAIR Kontact (more exactly the whole Kolab suite) was once officially funded,
supported 
and used for public authorities (as a substitute for Outlook). For that reason
I actually
expected a backport by SLE.

This not happening I conclude the use by public authorities has ceased …

2 years of silence by the KDEPIM team and no reaction to the fatal bug 483545
let's
me conclude: there is no proper maintenance of Kontact anymore …

Bug 481069 tells a similar story on KDE level itself: ill advised functional
regressions
biting a lot of users.
Bug 491130 is about a fatal regression on KDE level, breaking very old, very
fundamental
desktop functionality – with no "official" maintainer reactions so far.
KDE maintenance level perhaps is also already questionable?!?

> To be more specfic: What kind of help would you need to come up with 
> improvements on aspects?
> 
> Getting to back on some other aspects, though it somehow gets beyond this 
> issue.

I think the proper place for this discussion would be discuss.kde.org and this
discussion would need some supporters because it will require IMHO fundamental
changes in the way KDE is curated, if the decline is to be stopped …

-- 
You are receiving this mail because:
You are watching all bug changes.

[Reminder Daemon] [Bug 481024] The loss of user-defined snoozing for calendar and todo reminders is a massive functional regression and actually a hard show-stopper for my kontact usage

2024-08-10 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #44 from Flossy Cat  ---
(In reply to Martin Steigerwald from comment #43)
> …
> 1) Researched yourself where a suitable place for offering help would be. It
> could be kde-pim mailing list. It could be their Matrix channel. It could be
> both. I do not think discuss.kde.org would be suitable, cause AFAIK it is
> meant for user discussion.
> 
> 2) Researched yourself for resources on how to start contributing to KDE.
> Sure, I bet the documentation on that is still not perfect while AFAIK some
> people worked on it recently, but there is documentation available.

So I did with my Kalarm bug reports. The maintainer kindly pointed out,
that both documentation and git repository were outdated and the current
git is residing somewhere else …
Wasted time for both of us. Nevertheless issues were resolved promptly and
friendly.

Farewell.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 483545] Kmail2 silently looses mails while displaying the correct counts with the folders

2024-08-12 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=483545

--- Comment #1 from Flossy Cat  ---
Kmail loses e-mails on my productive system too.
Lost were mails in the "sent" folder – that is: recent e-mails according
current standards generated by Kmail itself.

There seems to be a very fundamental bug rendering Kmail effectively unusable …

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 491636] New: Kwin crashes out of the blue on an unloaded system

2024-08-12 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=491636

Bug ID: 491636
   Summary: Kwin crashes out of the blue on an unloaded system
Classification: Plasma
   Product: kwin
   Version: 5.27.11
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: crash
  Priority: NOR
 Component: generic-crash
  Assignee: kwin-bugs-n...@kde.org
  Reporter: flossy-...@online.de
  Target Milestone: ---

Created attachment 172556
  --> https://bugs.kde.org/attachment.cgi?id=172556&action=edit
Extract of crash from /var/log/messages

SUMMARY
Kwin crashes out of the blue on an unloaded system, seemingly unrelated to
ongoing light user activity.
System had copious free RAM and CPU and is airgapped, so that external causes
can be precluded.
Kwin was quickly restarted by systemd – so usability impact was low …

Backtrace cannot be provided as DrKonqui failed to start (obviously …).

STEPS TO REPRODUCE
1. not known

OBSERVED RESULT
Kwin crashes

EXPECTED RESULT
Kwin shouldn't crash

SOFTWARE/OS VERSIONS
Operating System: openSUSE Leap 15.6
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12
Kontact Version: 5.24.5 (23.08.5)
Kernel Version: 6.4.0-150600.23.14-default (64-bit)
Graphics Platform: X11
Processors: 8 × AMD Ryzen 5 with Radeon Vega Graphics
Memory: 14.6 GiB of RAM

ADDITIONAL INFORMATION
KWin-Support-Infos:
==

Version
===
KWin version: 5.27.11
Qt Version: 5.15.12
Qt compile version: 5.15.12
XCB compile version: 1.13

Operation Mode: X11 only

Build Options
=
KWIN_BUILD_DECORATIONS: yes
KWIN_BUILD_TABBOX: yes
KWIN_BUILD_ACTIVITIES: yes
HAVE_X11_XCB: yes
HAVE_EPOXY_GLX: yes

X11
===
Vendor: The X.Org Foundation
Vendor Release: 12101011
Protocol Version/Revision: 11/0
SHAPE: yes; Version: 0x11
RANDR: yes; Version: 0x14
DAMAGE: yes; Version: 0x11
Composite: yes; Version: 0x4
RENDER: yes; Version: 0xb
XFIXES: yes; Version: 0x50
SYNC: yes; Version: 0x31
GLX: yes; Version: 0x0

Decoration
==
Plugin: org.kde.breeze
Theme: 
Plugin recommends border size: None
onAllDesktopsAvailable: true
alphaChannelSupported: true
closeOnDoubleClickOnMenu: false
decorationButtonsLeft: 0, 1
decorationButtonsRight: 3, 4, 6, 5
borderSize: 2
gridUnit: 10
font: Noto Sans,11,-1,5,63,0,0,0,0,0,SemiBold
smallSpacing: 2
largeSpacing: 10

Output backend
==
Name: KWin::X11StandaloneBackend

Cursor
==
themeName: Oxygen 04 Red Ruby
themeSize: 24

Options
===
focusPolicy: 1
xwaylandCrashPolicy: 
xwaylandMaxCrashCount: 3
nextFocusPrefersMouse: false
clickRaise: true
autoRaise: true
autoRaiseInterval: 500
delayFocusInterval: 750
shadeHover: false
shadeHoverInterval: 250
separateScreenFocus: false
activeMouseScreen: true
placement: 
activationDesktopPolicy: 0
focusPolicyIsReasonable: true
borderSnapZone: 10
windowSnapZone: 10
centerSnapZone: 0
snapOnlyWhenOverlapping: false
rollOverDesktops: true
focusStealingPreventionLevel: 2
operationTitlebarDblClick: 5015
operationMaxButtonLeftClick: 5000
operationMaxButtonMiddleClick: 5015
operationMaxButtonRightClick: 5014
commandActiveTitlebar1: 0
commandActiveTitlebar2: 0
commandActiveTitlebar3: 2
commandInactiveTitlebar1: 4
commandInactiveTitlebar2: 4
commandInactiveTitlebar3: 2
commandWindow1: 7
commandWindow2: 8
commandWindow3: 8
commandWindowWheel: 28
commandAll1: 10
commandAll2: 3
commandAll3: 14
keyCmdAllModKey: 16777251
condensedTitle: false
electricBorderMaximize: false
electricBorderTiling: false
electricBorderCornerRatio: 0.25
borderlessMaximizedWindows: false
killPingTimeout: 5000
hideUtilityWindowsForInactive: true
compositingMode: 1
useCompositing: true
hiddenPreviews: 1
glSmoothScale: 2
glStrictBinding: true
glStrictBindingFollowsDriver: true
glPreferBufferSwap: 101
glPlatformInterface: 1
windowsBlockCompositing: true
latencyPolicy: 
renderTimeEstimator: 
allowTearing: true

Screen Edges

desktopSwitching: false
desktopSwitchingMovingClients: false
cursorPushBackDistance: 1x1
timeThreshold: 150
reActivateThreshold: 350
actionTopLeft: 0
actionTop: 0
actionTopRight: 0
actionRight: 0
actionBottomRight: 2
actionBottom: 0
actionBottomLeft: 5
actionLeft: 0

Screens
===
Active screen follows mouse:  yes
Number of Screens: 2

Screen 0:
-
Name: eDP-1
Enabled: 1
Geometry: 0,1080,1920x1080
Scale: 1
Refresh Rate: 60049
Adaptive Sync: incapable
Screen 1:
-
Name: HDMI-1
Enabled: 1
Geometry: 1,0,1920x1080
Scale: 1
Refresh Rate: 6
Adaptive Sync: incapable

Compositing
===
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics (CML GT2)
OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.3.4
OpenGL platform interface: GLX
OpenGL shading language version string: 4.60
Driver: Intel
GPU class: Comet Lake
OpenGL version: 4.6
GLSL version: 4.60
Mesa version: 23.3.4
X server version: 1.21.1
Linux kernel ve

[kwin] [Bug 491636] Kwin crashes out of the blue on an unloaded system

2024-08-12 Thread Flossy Cat

https://bugs.kde.org/show_bug.cgi?id=491636

--- Comment #2 from Flossy Cat  ---
(In reply to Zamundaaa from comment #1)
> Please get a backtrace for the crash:
> https://community.kde.org/Guidelines_and_HOWTOs/Debugging/
> How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl

I'd read that guideline – but as explained in the summary, I can't provide a
coredump:

DrKonqui failed to start because Kwin was gone.
I do not have coredumpctl installed, as this is one of the 2 systems were I
only use
rock-solid, time-tested SW and normally have no need for this and no coredumps
are written.

The crash happened out of the blue with no obvious trigger from activity on the
system.
Thus it is not reproducible so far …
Thus I cannot produce a backtrace ex post …

I provided what is available. 
When DrKonqui somewhere leaves any intermediary information point me to it and
I'll retrieve it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 493274] Endless loop of new thumbnails in /tmp

2024-10-05 Thread Rin Cat

https://bugs.kde.org/show_bug.cgi?id=493274

Rin Cat  changed:

   What|Removed |Added

 CC||rin...@rincat.dev

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 493233] Maximize a window cause it no longer update framebuffer under Wayland

2024-09-22 Thread Rin Cat

https://bugs.kde.org/show_bug.cgi?id=493233

--- Comment #3 from Rin Cat  ---
I've noticed a strange behavior. If I first occupy half of the window close to
the taskbar and then maximize it, this abnormal behavior does not occur.
However, if I first occupy the half far from the taskbar and then maximize, it
does appear. 

This behavior seems to be related to the floating taskbar. If you turn off
floating, this problem no longer occurs.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 493233] Maximize a window cause it no longer update framebuffer under Wayland

2024-09-22 Thread Rin Cat

https://bugs.kde.org/show_bug.cgi?id=493233

--- Comment #4 from Rin Cat  ---
Created attachment 173957
  --> https://bugs.kde.org/attachment.cgi?id=173957&action=edit
Maximize from left to right

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

--- Comment #8 from Flossy Cat  ---
Created attachment 174281
  --> https://bugs.kde.org/attachment.cgi?id=174281&action=edit
Screen shots documenting the solution path for the allegedly "LOST" game

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

--- Comment #5 from Flossy Cat  ---
Created attachment 174278
  --> https://bugs.kde.org/attachment.cgi?id=174278&action=edit
Screen shots documenting the solution path for the allegedly "LOST" game

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

--- Comment #9 from Flossy Cat  ---
Created attachment 174282
  --> https://bugs.kde.org/attachment.cgi?id=174282&action=edit
Screen shots documenting the solution path for the allegedly "LOST" game

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] New: Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

Bug ID: 493919
   Summary: Solver falsely claims unsolvable and lost games
Classification: Applications
   Product: kpat
   Version: 23.08.5
  Platform: Compiled Sources
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: solver
  Assignee: co...@kde.org
  Reporter: flossy-...@online.de
CC: co...@kde.org, kde-games-b...@kde.org
Depends on: 493918
  Target Milestone: ---

Created attachment 174272
  --> https://bugs.kde.org/attachment.cgi?id=174272&action=edit
Game state of the allegedly not winnable game

SUMMARY
The solver is a cool feature. It would be way cooler, if it would not tag
actually solvable games as "not winnable" or "lost".

STEPS TO REPRODUCE
1. Set the game number to the two example game numbers provided in the screen
shots.
2. Reproduce the game situation.
3. Play along the solution path sketched out by the screen shot.

In contrast to the solver claiming both games either "not winnable" (the first
one) or even "lost" (the 2nd one), both are winnable.

OBSERVED RESULT
Solver claims the given examples to be either "not winnable" or even "lost",
despite them being clearly winnable.

While for the allegedly "not winnable" game at least the game could be stored
as "*.kpat" (provided), for the allegedly "lost" game saving the game state is
even not possible anymore.

EXPECTED RESULT
Correct classifications or at least not preventing the user from saving the
game …

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
the problem exists since years …


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=493918
[Bug 493918] Suit of 2 under other cards not determinable
-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493918] Suit of 2 under other cards not determinable

https://bugs.kde.org/show_bug.cgi?id=493918

Flossy Cat  changed:

   What|Removed |Added

 Blocks||493919


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=493919
[Bug 493919] Solver falsely claims unsolvable and lost games
-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

--- Comment #7 from Flossy Cat  ---
Created attachment 174280
  --> https://bugs.kde.org/attachment.cgi?id=174280&action=edit
Screen shots documenting the solution path for the allegedly "LOST" game

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #39 from Flossy Cat  ---
(In reply to Andreas Schneider from comment #38)
> The merge request has been closed :-(
> 
> https://invent.kde.org/frameworks/knotifications/-/merge_requests/143

Thank you for the information – and thank you very much for your spirited
effort to re-establish that valuable functionality.

As "the dunce" had so nicely put it in the "invent" discussion thread:

"I guess the lesson to take away from this is to never become reliant on any
KDE feature because someone might rip it out on a whim for not being the
theoretically perfect implementation, even if it doesn't cause any problems in
its current state."

Which – in the light of the other bugs and regressions reported by me – at
least for me shortens to:
"Never rely on KDE anymore." 

A single person blocks the repair of a regression against the expressed wishes
and well-founded use-cases of numerous users and several developers advocating
the repair. IMHO Open Source Software is commons (in the sense of the original
agricultural concept) and such despotic ruling of a single person over the
wishes and needs of many is not acceptable.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

--- Comment #3 from Flossy Cat  ---
Created attachment 174275
  --> https://bugs.kde.org/attachment.cgi?id=174275&action=edit
Screen shots documenting the solution path for the allegedly "unwinnable" game

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

--- Comment #2 from Flossy Cat  ---
Created attachment 174274
  --> https://bugs.kde.org/attachment.cgi?id=174274&action=edit
Screen shots documenting the solution path for the allegedly "unwinnable" game

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

--- Comment #6 from Flossy Cat  ---
Created attachment 174279
  --> https://bugs.kde.org/attachment.cgi?id=174279&action=edit
Screen shots documenting the solution path for the allegedly "LOST" game

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493918] New: Suit of 2 under other cards not determinable

https://bugs.kde.org/show_bug.cgi?id=493918

Bug ID: 493918
   Summary: Suit of 2 under other cards not determinable
Classification: Applications
   Product: kpat
   Version: 23.08.5
  Platform: Compiled Sources
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: co...@kde.org
  Reporter: flossy-...@online.de
CC: kde-games-b...@kde.org
  Target Milestone: ---

SUMMARY
Suit of 2 under other cards not determinable

STEPS TO REPRODUCE
1. Choose a game with a horizontal layout – e.g. "Burk" (which probably is
another error, because it claims to steem from the German word for castle which
is "Burg" …)
2. generate a layout, where a "2" is covered
3. right-click on the 2 – it is tilted, but not sufficiently to identify the
suit.

OBSERVED RESULT
You only see a red or black "2", when tilting it, but not the actual suit (e.g.
diamonds).

EXPECTED RESULT
The actual suit should be visible.

SOFTWARE/OS VERSIONS
not relevant

ADDITIONAL INFORMATION
the problem exists since years …

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #48 from Flossy Cat  ---
(In reply to Nate Graham from comment #45)
> I too am dissatisfied with the resolution here, but let me correct the
> record on one thing right now: bugs.kde.org is not violating the GDPR.
> There's a banner when you sign up for an account informing you that your
> email address will be publicly visible, and that if you don't want this to
> happen, you shouldn't sign up for an account. This is GDPR-compliant.

There is absolutely no technical necessity to publish e-mail addresses of bug
reporters. 
Tying bug-reporting to consenting to publishing your e-mail address thus is at
least dubious, as is "implicit consent".

Further, there needs to be a way to revoke consent – i.e. delete the account
and stop the e-mail address being published.
This option is missing. IMHO this is not GDPR-compliant. It is definitely not
state of the art or a privacy-aware implementation.

We both do not have the final say in this matter.
Is it really necessary to ask the Commissioner for Data Protection or might –
just once – rational technical arguments prevail?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications

https://bugs.kde.org/show_bug.cgi?id=481069

--- Comment #44 from Flossy Cat  ---
Farewell to everyone, who has tried to contribute to a good solution.

I did some bug-reporting on KDE the last months and essentially these bug
reports were either not acted upon or in a very unsatisfying manner like here.

All the while bugs.kde.org is happily spreading the e-mail addresses of all
participants like there is no tomorrow or no GDPR.
(While on the other hand KDE representatives are sanctifying regressions by "we
do not know about actual usage of features because we are so privacy-aware" …)

Fact 1: even if KDE users do in length and breadth explain how and how
intensely they use a feature – as we did in this thread –, KDE gives a 

Fact 2: the privacy handling of  bugs.kde.org is neither state of the art nor
in concordance with the General Data Protection Regulation of the EU.

Fact 3: A representative of KDE has been informed by me concerning the – IMH
expert's O – GDPR violations on 2024-09-01 19:07 via e-mail, i.e. a month ago.
No corrective action was taken.

Consequence 1: I've required the representative and the admins to immediately
remove my e-mail-address from public view and to delete my account.

Consequence 2: I do not consider KDE dependable anymore nor a trustee of the
common resource pool (or commons in the classical agricultural sense) of the
open source, which was entrusted to the community by a multitude of developers
– the gifts they made to the community are, IMHO, obviously not handled with
care and respect by KDE, as can be seen from this regression.

Again: my best wishes and respect for all those, who once made KDE an excellent
desktop and now tried to contribute to solutions – live long and prosper!
Farewell.

FLOSSy Cat

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games

https://bugs.kde.org/show_bug.cgi?id=493919

--- Comment #1 from Flossy Cat  ---
Created attachment 174273
  --> https://bugs.kde.org/attachment.cgi?id=174273&action=edit
Screen shots documenting the solution path for the allegedly "unwinnable" game

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 493233] Maximize a window cause it no longer update framebuffer under Wayland

2024-09-18 Thread Rin Cat

https://bugs.kde.org/show_bug.cgi?id=493233

--- Comment #2 from Rin Cat  ---
(In reply to Vlad Zahorodnii from comment #1)
> Please check kwin's logs `journalctl --user-unit --boot plasma-kwin_wayland`

I am using OpenRC, so I checked log in
`~/.local/share/sddm/wayland-session.log`.
Although there are some logs like:
`The cached device pixel ratio value was stale on window update.  Please file a
QTBUG which explains how to reproduce.`

But when the issue happens, there is no logs. No output at all.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 493919] Solver falsely claims unsolvable and lost games