MaikuB/flutter_local_notifications

Changing notification details for a Linux notification doesn't apply immediately unless its old one is deleted first.

Open

#2.595 aberto em 3 de abr. de 2025

Ver no GitHub
 (2 comments) (0 reactions) (0 assignees)Dart (1.187 forks)batch import
help wanted

Métricas do repositório

Stars
 (2.208 stars)
Métricas de merge de PR
 (Mesclagem média 59m) (4 fundiu PRs em 30d)

Description

Describe the bug

If I create an urgent notification on Linux (Gnome 48), it appears as it should. However if I change the notification details by lowering the urgency, then display the same notification again, the result is that the notification is re-shown with the original urgency.

To Reproduce

  1. Set urgency of notification details to be critical, on Linux
  2. Create urgent notification
  3. Update notification details object with lower priority
  4. Create new notification with the same notification details object
  5. See that the incorrect urgency is applied
  6. Create new notification
  7. See that the desired notification type is now applied on the third notification

Expected behavior

The expectation is that the less urgent method will be used on the second and third notifications.

Sample code to reproduce the problem

Here is the commit I used to work around this issue in my app:

https://github.com/sandpiper-codes/open_alert_viewer/commit/8b2d5bf6e0bca4866fb001e51e58aed993b2c5c5

I decided to conditionally remove the previous notification before showing a new one, but perhaps removing every time would have the same effect.

Guia do colaborador

Direção de pesquisa
Investigue a implementação de notificações no Linux para entender como a urgência é aplicada e por que a atualização da urgência não tem efeito até que uma nova notificação seja criada. Concentre se no método que mapeia os detalhes da notificação para as propriedades da notificação Linux.
Pilha de tecnologia
dartflutter
Domain
mobiledesktop
Tipo Issue
Bug
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
2
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
1-3 horas
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Ativo
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
FlutterDartLinux
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
70