Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long term maintenance strategy #15

Open
sharwell opened this issue Mar 8, 2018 · 18 comments
Open

Long term maintenance strategy #15

sharwell opened this issue Mar 8, 2018 · 18 comments

Comments

@sharwell
Copy link

sharwell commented Mar 8, 2018

Hi @michaelnoonan,

I noticed that the community is interested in expanding on this work to fix bugs. Would you be willing to do one of the following?

  1. Provide a bit of time to get bugs fixed and updated releases out
  2. Should an appropriate owner be available, transfer the repository to an organization where it can be maintained by other authors

If you are willing to consider the second option, I can provide a list of suggested owners who have extensive experience both with maintaining open source projects on GitHub and with the subject matter (the specific APIs involved).

📝 Transferring the repository would preserve the complete history of issues and pull requests, and provide automatic HTTP redirection for users who navigate to the repository in its current location.

Thank you,
Sam Harwell

@RudiHansen
Copy link

Any news about your request?
I am having some problems with Keyboard.KeyDown and Keyboard.KeyUp, that does not work in some applications.
And I can see the problem has already been created as an Issue, and a fix found but it's just not been fixed in the library, so I can't use the fix.
So it would be nice to know if something is being done, or I have to find other options.

@michaelnoonan
Copy link
Owner

Hi All, Sorry I have let this go dormant! 😧 If someone would be happy to take it over, I'd be happy to transfer ownership. 😄

@sharwell
Copy link
Author

@michaelnoonan Thank you for the response. I will check with a couple of people and get back with you shortly.

@sharwell
Copy link
Author

@michaelnoonan Sorry for the delay in a response. Right now there are two options I would suggest:

  • Primary (could take a few weeks to get approval): I'm working to get approval to move the repository under the .NET Foundation umbrella with two or more assigned maintainers coming from different backgrounds. One of the maintainers would be myself, but the other would be a different person with a long history of open source participation.
  • Backup (could be completed on any scheduled day that works for you starting 22 Aug): While I would accept the responsibility of maintaining the library under my personal organization (tunnelvisionlabs), I am trying hard to avoid this because it is not my intent to "steal" this project and I don't want the transfer to appear as such to you or any other participants. The only advantage here is there is much less paperwork involved in the transfer (from me, this makes no real difference to you).

@RWeigelt
Copy link

To weigh in on this issue as a user of the library (for a small private tool): With somebody (i.e. @sharwell) willing to do the paperwork/communication to try to get this project under the .NET Foundation umbrella, I'd say definitely go for it. I can imagine there's a certain bar to clear; if the .NET Foundation doesn't think the project is a good fit (which would be a shame), there's still the backup option.

@michaelnoonan
Copy link
Owner

I'm genuinely happy with whichever option leads to the best outcome for the library and its community. I'm actually just glad the work I did all those years ago has benefited a few people. :)

@TChatzigiannakis
Copy link
Collaborator

I too would be happy to become a maintainer of this project, if you need me to. Right now I maintain a fork and have already done a few minor changes that have been requested by the community, but I'd prefer it if I could continue development on the original project.

@michaelnoonan
Copy link
Owner

I lost track of our conversation @sharwell. What are the next steps from your point of view?

In the meantime I can make @TChatzigiannakis a maintainer without much problem at all. :)

@sharwell
Copy link
Author

sharwell commented Aug 5, 2019

I wasn't find enough people with an active need to use this project to make it a priority for adoption with new maintainers. If @TChatzigiannakis was another maintainer here, I think that would solve the immediate issues and allow the project to move forward.

@TChatzigiannakis
Copy link
Collaborator

@michaelnoonan @sharwell I'm happy to help as a maintainer.

I already have a couple of open issues in my fork (and I'm sure others have, in their own forks), so there already is work for the short-term future.

@TonyValenti
Copy link

Hi All, this library is really important to us as well. If you need a maintainer, I'm interested in volunteering.

@michaelnoonan
Copy link
Owner

Neat. I'll add you.

@TonyValenti
Copy link

Hi All,
There are two libraries that I tend to use together quite a bit:
InputSimulator (this one) and GlobalMouseKeyHook (https://github.com/gmamaladze/globalmousekeyhook)

In my mind, these libraries are different sides of the same coins. One is focused on sending key strokes and the other is focused on receiving key strokes. @michaelnoonan - Do you have an objection if I approach the GlobalMouseKeyHook folks about combinging these two libraries together?

@michaelnoonan
Copy link
Owner

I don't have any objection. :)

@TonyValenti
Copy link

@michaelnoonan -
Hey Michael! I wanted to let you know the progress on this is going really well! I have about a week or so left of work before I'll have something awesome to show.

One of the things I'm working hard to do is improve the debugging experience. For example, instead of processing raw INPUT[], I'm building classes that wrap the specific types of "standard" input - for example, I have ButtonClick, CharacterDown, KeyUp, and MouseMove classes.

As part of the refactoring, I noticed that the project has a handful of interfaces that seem to only be used once:
IInputDeviceStateAdaptor
IInputMessageDispatcher
IInputSimulator
IKeyboardSimulator
IMouseSimulator

Do you have other projects where these are reused? If not, do you have any problem with me removing the interfaces?

@michaelnoonan
Copy link
Owner

Such a long time ago I don't remember! If the interfaces are not useful for mocking nor the open/closed principle, I'm totally fine for you to remove them.

The downside to that approach is other consumers of the library might be using the interfaces in their code. You could revision the major version number when releasing this new version to indicate the API has changed.

@TonyValenti
Copy link

@michaelnoonan - Thanks so much!
I am still churning through this. The code is looking really nice but with as many changes anyone using it will need to update to the new methods.

Right now about all I have left is documentation and I plan to have that wrapped up later this week.

@TonyValenti
Copy link

Hi All! Here's the initial release of WindowsInput:
https://www.nuget.org/packages/WindowsInput/6.0.0
http://github.com/tonyvalenti/windowsInput/

@michaelnoonan - I would really love your input on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants