new input-uiohook source plugin for mouse/keylogging

[ChristianFrisson]

Using a fork of the cross-platform libuiohook library (https://github.com/kwhat/libuiohook) as submodule, this source plugin allows to log mouse and keyboard events into a text file.

Why a source plugin? I wanted users to be allowed to add/remove the plugin to the scene conveniently from the obs GUI, main window. Is there a more suitable plugin type for that purpose and requirements?

I had to modify obs/libobs so that source plugins are informed when the recording is started/stopped.

[ONSBalder]

Can one of the admins verify this patch?

[palana]

One question I was going to ask you on IRC: what's the use case for recording all mouse/keyboard activity?

Also, instead of adding those new start/stop functions you should probably look at the output signals instead.

Unless there's a very compelling answer to the first question I don't think this will/should be merged (disregarding code style issues and such)

[dodgepong]

Well, as a plugin, he can submit it as a new plugin resource on the forums if anyone wants to just install it on their own, like the Browser source.

[btorellALTA]

Though I overlooked that this has libobs modifications, so it can't be a standalone plugin.

[lorddrachenblut]

For people creating howto videos being able to have all the keypress the
use during a video could be very useful much like the gamepad site someone
created

On Fri, Dec 11, 2015, 4:31 PM btorellALTA notifications@github.com wrote:

Though I overlooked that this has libobs modifications, so it can't be a
standalone plugin.

—
Reply to this email directly or view it on GitHub
#491 (comment).

Cheers

Matthew "Lord Drachenblut" Williams

[ChristianFrisson]

@palana one the use cases of recording all mouse/keyboard activity is to regenerate a timeline of commands and actions done during the screencast, as @lorddrachenblut noticed. I am working on an opensource solution similar to the Autodesk Screencast (http://screencast.autodesk.com/) timeline.

@dodgepong I'd rather have the plugin be part of the main obs-studio distribution so that it is easier for users to get it ready.

[ChristianFrisson]

Note: the "libobs/obs add source start/stop methods" commits implement a solution for error reporting to users similar to what has been proposed in issue 309 "Implement better error reporting for encoders/outputs" https://obsproject.com/mantis/view.php?id=309

[palana]

Let me rephrase

Also, instead of adding those new start/stop functions you should probably look at the output signals instead"

These API calls don't make sense, and won't be merged. Use output signals instead.

Note: the "libobs/obs add source start/stop methods" commits implement a solution for error reporting to users similar to what has been proposed in issue 309 "Implement better error reporting for encoders/outputs" https://obsproject.com/mantis/view.php?id=309

Similar in the sense that it returns a string, but not at all what's required. Ignoring the fact that these API calls don't make sense, the error message that the mantis issue wants is something to display to the user; so it would have to be localized. Also it should be possible to return a string with semi-dynamic content, so const char * return type won't work at all (the mantis issue explicitly mentions dstr * and char **)

[ChristianFrisson]

@palana Let me propose you another use case for the possible relevance of start/stop methods in source plugins. When choosing proper settings for a recording, say one wants to evaluate the load of every source in the scene, to estimate if the system will handle both the load from the recording and the load from the main task that the user wants to record (gaming or other intensive workflows). From what I investigated prior to developing to work of this pull request, it seems that this user would have to add/remove each source (activate/deactivate signals) to/from the main view and reconfigure each source settings again and again. Moreover, if I understood it well the show/hide signals only affect the display of the sources in the main view and their presence in the recording, not the activity of their processes.

In a way, what I want to achieve would require both a source plugin (mouse/key events) and an output plugin (logging to file).

But my main concerns are 1) to merge as much as possible from this work into the main repository and 2) make this feature efficient and easy to use. So I'm ready to change the plugin type to output plugin if that's what is necessary to get the first concern solved.

I'm afraid this will require obs/libobs changes:

• another tab in the advanced output settings (OBSBasicSettings.ui)
• another group box in the simple output settings (OBSBasicSettings.ui)
• the underlying code to manage this in obs/libobs

Are these changes suitable?

[ChristianFrisson]

If I understand well (from #494), there is a major release with API changes (0.13.0) upcoming, I'll wait until then to mod commit what is required for this pull request. Good luck for the release!

[jp9000]

I should have looked at this more closely and in-depth sooner because it almost implicitly implied I was considering/thinking about it, but after seeing it I really don't see any place at all what-so-ever where this fits in with our project and our goals. I'm just not interested in it for our project, both for the sake of keeping down maintenance costs and because it just doesn't seem to have a place with our current goals.

I can understand how it benefits your personal needs/fork, but how does this benefit the main project and our users? How many total people will it benefit? I can't help but feel the costs for adding this code is greater than the benefits we receive from it, because for users of OBS itself this will almost never be used/needed, at least as far as I can assess based upon what it does.

We have limited people on the project and every little bit of code adds a maintenance cost. Adding an entire submodule/library dependency especially. As much as I would love to add every feature imaginable, I just can't afford to do so when there's only one/two people really spending significant time working/maintaining the project. We have to prioritize things best we can due to limited resources.

Please keep in mind that I am not even judging your code or what you've actually done, you could have the best code in the world but it would still be the same situation. I'm just talking about the proposal overall.

[jp9000]

By the way, if you (or anybody else) feel differently, please speak up and let me know. I am completely willing to listen and debate it.