Hello. I noticed that commit c2438cf8f1d284c154f430ae6202ac40ddaf5235 is introducing a limit on the number of entries in the log file. Having myself for example eternal history enabled in Bash ($HOME/.bash_eternal_history), I disagree with restricting xfce4-notifyd entries to any particular number, such as 100 or 1000 entries. Since the log_max_size variable is already an integer (type: gint), it should be fairly straightforward to implement in C&Glade that the value of -1 means there is no limit to the number of entries in the log file. I agree with the viewpoint that having a lot of entries in the log file, such as 10000+, is _currently_ a performance issue and a memory consumption issue. But this is only because the current implementation in xfce-notify-log.c is rewriting the whole log file every time a new notification arrives. A proper fix would be to open the log file in append mode. Even in the case of the new default, which is 100 entries, appending would be faster than rewriting by a factor of 100. Unfortunately, GLib's key-value file parser has no support for opening the file in append mode.
Related bug: bug 14865
You should have read the tooltip, setting it to 0 means no limit
(In reply to Simon Steinbeiss from comment #2) > You should have read the tooltip, setting it to 0 means no limit Cool. Thanks. However, the performance issues remain if there is no limit. Is there a plan to switch the implementation to use append mode when updating the log file in the near future?
Well I also didn't close that other bugreport, did I? :) Yeah, would be nice to get that fixed (patches welcome!)