[kontact] [Bug 479425] O Kontact fecha ao adicionar uma tarefa

2024-02-09 Thread Bug Janitor Service
https://bugs.kde.org/show_bug.cgi?id=479425

Bug Janitor Service  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME
 Status|NEEDSINFO   |RESOLVED

--- Comment #3 from Bug Janitor Service  ---
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 481135] Closing KMail window with system tray icon enabled doesn't always close the window

2024-02-09 Thread Bug Janitor Service
https://bugs.kde.org/show_bug.cgi?id=481135

Bug Janitor Service  changed:

   What|Removed |Added

   Keywords||qt6

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 481135] New: Closing KMail window with system tray icon enabled doesn't always close the window

2024-02-09 Thread Stefano Crocco
https://bugs.kde.org/show_bug.cgi?id=481135

Bug ID: 481135
   Summary: Closing KMail window with system tray icon enabled
doesn't always close the window
Classification: Applications
   Product: kmail2
   Version: 5.240.95
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: UI
  Assignee: kdepim-bugs@kde.org
  Reporter: stefano.cro...@alice.it
  Target Milestone: ---

SUMMARY
In KF5, when the system tray icon is enabled in KMail, closing the window with
Alt+F4 or with the X button on the title bar used to close the window, leaving
only the system tray icon. However, with KF6 version of KMail, this only
happens a few times (often only once) after the application has been launched.
After that, closing the window minimizes it instead, leaving it on the task
bar. When this starts to happen, there's no way to restore the correct
behaviour except quitting KMail altogether (using the File/Quit menu entry).
This doesn't seem to happen if closing the window by clicking on the KMail icon
in the system tray.

When the behaviour described above starts happening, clicking on the KMail icon
in the system tray shows the window again, but it forget its maximized state.
This doesn't happen when restoring it by clicking on the corresponding entry in
the task.

STEPS TO REPRODUCE
1. Launch KMail and ensure that the "enable system tray icon" option is checked
2. Close the KMail window using the X button on the title bar or the Alt+F4
shortcut. It may be necessary to display the window and repeat this a couple of
times to trigger the bug

OBSERVED RESULT
KMail window is minimized and still visible in the task bar. When clicking on
the system tray icon to show it again, the window is not maximized, even if it
was maximized when I closed it

EXPECTED RESULT
KMail window gets closed and it disappear from the task bar. When clicking on
its system tray icon, KMail window is restored keeping the previous maximized
state.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo Linux 
KDE Plasma Version: 5.93.0
KDE Frameworks Version: 5.249.0
Qt Version: 6.6.1

ADDITIONAL INFORMATION
Gentoo doesn't provide official packages for the KF6 version of KDE Gear, so I
installed them using the Gentoo KDE overlay

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

2024-02-09 Thread Flossy Cat
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-bugs@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 the assignee for the bug.

[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

2024-02-09 Thread Flossy Cat
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 the assignee for the bug.

[kontact] [Bug 473673] Calendar Reminders: I click on "remind in 1 hour" and get the same reminder 30 seconds afterwards.

2024-02-09 Thread Robby Engelmann
https://bugs.kde.org/show_bug.cgi?id=473673

Robby Engelmann  changed:

   What|Removed |Added

   Keywords||qt6
 CC||robby.engelmann@r-engelmann
   ||.de
Version|5.23.3  |GIT (master)

--- Comment #2 from Robby Engelmann  ---
same here:
Operating System: openSUSE Tumbleweed 20240208
KDE Plasma Version: 6.0.80
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.1
Kernel Version: 6.7.4-1-default (64-bit)
Graphics Platform: Wayland
Processors: 20 × 13th Gen Intel® Core™ i7-13700H
Memory: 62.5 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: TUXEDO
Product Name: TUXEDO InfinityBook Pro Gen8 (MK1)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[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

2024-02-09 Thread Bernhard E. Reiter
https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #14 from Bernhard E. Reiter  ---
Two other potential "workarounds" for you (just for completion):
 * Stay on the elder version temporarily (to buy more time for a solution)
 * Go to Kontact from Trinity. It is still maintained

> Bernhard, I know you once were well-connected into the upper tiers of KDE.
> If this still holds true

Unfortunately I do not know (anymore) whom to approach in this case.
David of course used to be well connected as well. (*wave*)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[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

2024-02-09 Thread Flossy Cat
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 the assignee for the bug.

[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

2024-02-09 Thread Flossy Cat
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 the assignee for the bug.

[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

2024-02-09 Thread David Faure
https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #11 from David Faure  ---
Hi Bernhard! Long time no "see" ;-)

Yeah after my last comment I had a similar idea, one of the buttons in the
notification could trigger a dialog box like the old korgac one, where we can
have widgets to define a delay etc. KOrganizer might not be running, so it
wouldn't be the right process for popping up that dialog. But kalendarac (the
new daemon) could pop up the dialog like korgac did.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[korganizer] [Bug 473847] To-Do View empty but To-Dos shown in Kontact summary page

2024-02-09 Thread Robby Engelmann
https://bugs.kde.org/show_bug.cgi?id=473847

Robby Engelmann  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|REOPENED|RESOLVED

--- Comment #7 from Robby Engelmann  ---
(In reply to Daniel Vrátil from comment #6)
> If you are using Kontact, there should be a standalone "To-do List" action
> in the Kontact side-panel that opens the "Todo View" that you would
> otherwise normally get in standalone KOrganizer toolbar - I'm pretty sure
> this hasn't changed in the Qt6 build.
> 
> Or am I misunderstanding the problem?

I was referring to the todo-view that can be shown within the "Calender" tab.
For whatever reason this is fine again here since 1-2 days again.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[korganizer] [Bug 479351] It is not possible to add Sub-ToDos in Kontact ToDo-List

2024-02-09 Thread Robby Engelmann
https://bugs.kde.org/show_bug.cgi?id=479351

--- Comment #4 from Robby Engelmann  ---
Still the menu point to add Sub-To Dos is gray here.

The merge should be integrate into the last night build of git master in
openSUSE unstable KDE repos (I think at least).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[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

2024-02-09 Thread Bernhard E. Reiter
https://bugs.kde.org/show_bug.cgi?id=481024

--- Comment #10 from Bernhard E. Reiter  ---
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.).

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, 
 * and then I have the remaining minutes to completely concentrate on something
else until the alarm rings when I get up and walk to the meeting room. 
 * This I gain 12-8 minutes of working time.

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

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 . So in @Flossy Cat's use case a
delay for 3 days or so would be in the backup
and also working across synced machines.

I am not sure if the current status of the iCalender format - which is often
used nowadays - allows it. It might.

## 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.)

-- 
You are receiving this mail because:
You are the assignee for the bug.