Version: SVN trunk (KDE 4) (using Devel) OS: Linux Newly created or modified events blink twice before remaining displayed in Agenda view. Reproducible: Always Steps to Reproduce: - Launch KOrg - Go to Agenda view - Click on 'New Event' - Fill in all the fields - Click on 'Ok' Actual Results: The new event appears in Agenda view but it blinks twice before being displayed definitely Expected Results: whereas this should not happen. The event should be displayed in agenda view without blinking. - Double click on the event you've just created in Agenda view and modify its name - Click on 'Ok' The event blinks twice before being displayed permanently. Event A -> 10:00-12:00 Event B -> 12:00-14:00 Event C -> 14:00-16:00 Also if the created or modified event (ex event C) is next to other events (event A and event B) in Agenda view both the events are blinking twice eventhough only one was modified (event C). Trunk, Svn Rev 1142760
SVN commit 1169291 by smartins: No need to recreate items a bunch of times. EventViews::AgendaView is a CalendarObserver, so it knows when incidences change. --flickering Reminder to self: Backport something similar to branch4.5 CCMAIL: iamsergio@gmail.com CCBUG: 242980 M +4 -4 koagendaview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1169291
SVN commit 1169294 by smartins: Currently there are 3 ways for a view to detect changes: - Through the CalendarObserver interface - Through akonadi's signals - changeIncidenceDisplay() called by korganizer This causes a great amount of flickering/item recreation. Remove changeIncidenceDisplay() from the public interface. --flickering CCBUG: 242980 M +0 -1 agendaview.cpp M +6 -2 agendaview.h M +0 -5 eventview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1169294
SVN commit 1169303 by smartins: --flicker Just bailout in fillAgenda() if updateNeeded() is false. ( it's set to true in the CalendarObserver inherited methods whenever there's a change ). korg calls updateView() like crazy. AgendaView is a separate lib now and doesn't need korg's help to know when changes are made. Now the items are only recreated once, it's a good improvement, but i'll try to get it to 0 (Items that didn't change don't need to be recreated). CCBUG: 242980 M +5 -6 agendaview.cpp M +0 -3 agendaview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1169303
SVN commit 1170014 by smartins: When adding incidences, don't call fillAgenda(), which recreates all items. Instead, just add the new item. Adding incidences is very smooth now, 0 flicker. CCBUG: 242980 M +4 -1 agendaview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1170014
SVN commit 1170017 by smartins: Same optimization for deletion. 0 flicker, 0 recreation of other items. CCBUG: 242980 M +7 -1 agendaview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1170017
SVN commit 1170072 by smartins: No more flicker when editing too. It's possible that there are regressions or corner cases, but tests were all ok. Also fixed a bug where conflict resolution didn't work ( conflict is when there are two incidences in the same cell ) CCBUG: 242980 M +13 -2 agenda.cpp M +3 -1 agenda.h M +12 -1 agendaview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1170072
SVN commit 1170289 by smartins: Last of the --flickering patches. This one for editing. Editing 1 incidence won't cause recreation of other incidences. BUG: 242980 M +9 -1 agendaview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1170289
I retested this today and it mostly works now Newly created events do not blink anymore. Renamed events do not blink anymore. => Good work!!! The only display pb still left is when dragging and dropping an event an hour later. The event(s) next to it blinks once or twice so I am reopening this bug. Trunk, Svn Rev 1170619
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of korganizer (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.