Closed anselmolsm closed 7 years ago
Since there is currently no mechanism that allows plugins to define settings, I think it would be fine to just simply create a "Logging" section (Enabled, Directory, ...?) next to the "Theme" section on the settings page on the app side for now.
How about something like this?
@jpnurmi Yeah, I wasn't sure about how to add a config option for a plugin. I'll follow your suggestion. New patch soon.
I pushed this commit again, now with the code changes suggested. The UI for settings and related changes are in my branch logger-wip, but first I want to find a proper way to disable the plugin, which might require a patch to PluginLoader as well.
@anselmolsm What would you suggest in PluginLoader
?
@Venemo Perhaps a way to execute QPluginLoader::unload() for a given plugin, to be used in cases like the checkbox "Logging" on the settings page. This would avoid calls to plugin's methods full of internal checks to abort them, if the plugin is disabled.
@anselmolsm Ah, I get your point. Perhaps there could be a list of plugins in Settings and the user could choose which ones to enable? Or do you mean to add a special case just for your logger plugin?
@Venemo I haven't thought about a list to enable/disable plugin, but I guess the load/unload infra in PluginLoader could be used for that as well.
@anselmolsm I believe I could give the PluginLoader
a go next weekend at the earliest. I will also see what I can do about the settings GUI. I like the proposal from @jpnurmi here.
One more question, just out of curiosity: as far as I see, your plugin simply logs messages into a file. Some other apps that do logging also load the logs and show the messages on the GUI at app startup. Is this something you plan to add, or is that out of your scope?
@Venemo cool, looking forward to see your changes :)
Regarding loading logs - Yes, I think loading logs belongs to this plugin as well. Once this initial patch gets merged, I'll resume the work on that.
@anselmolsm Okay, so I merged your plugin locally and implemented the necessary stuff, but there is an issue. I'll push my changes once I resolve it.
When the logger is disabled at application startup, then re-enabled during runtime, it doesn't log anything. The reason: when the plugin is disabled its bufferAdded
and bufferRemoved
methods don't get called, so it isn't connect
ed to any of the buffers... I should have thought of this earlier, but it didn't occour to me until I saw it happen.
So now I need to add a way for the BufferPlugin
to get the list of all the currently existing buffers. This is very tricky to do without introducing a bunch of inter-dependencies between stuff that shouldn't depend on each other, but I'll think of something.
Okay, the problem has now been solved, in a somewhat complicated way.
PluginLoader
to be able to enable and disable plugins on the fly. I then introduced GenericPlugin
which can listen to when it is enabled and disabled.SettingsPlugin
which can listen to settings changes.ConnectionPlugin
to get access to the list of all connections.And I modified LoggerPlugin
as well:
SettingsPlugin
so that it can listen to settings changesConnectionPlugin
so it can get all the current connections (which is used when the plugin is enabled)GenericPlugin
so that it knows when it is disabled / enabled. When it's disabled, it closes all files and stops listening to all buffers. When it's enabled, it iterates over all connections, gets all current buffers and listens to all of them.Hope this helps!
@anselmolsm Please take a look at my commits and see if they are okay with you.
@Venemo , cool! I couldn't see your patches during the weekend, but I'll take a look later today. By your comments, it looks promising :)
Submitting this PR to gather feedback on this. I wrote this plugin to store channels history in logfiles, as I need to grep things on them from time to time at work. After a few code modifications and weeks of tests, I thought it could be interesting to have this as part of communi.
As I said it works fine - I've been testing this for a while on Linux and Windows - however it needs polishing, for example there are hard coded things (e.g. dir logs are stored) and proper error handling is missing.