Volunteers for open source multiboxing program

[Freddie]

I'm thinking of starting an open source multiboxing project.

I'd like to get an idea of how many people would volunteer.

If you would be interested in working on this project, could you please send me a PM or email describing what exactly you would want to do.

For those folks who would like to do programming, could you please say which languages and other tools you'd prefer to use.

Thanks.

[Freddie]

One person has contacted me so far. He's highly skilled and intelligent. If we get a few more people like him, this project could have a very successful start.

[Aragent]

Sent you a PM on HKN site,

If I can be of help let me know.

[Freddie]

Thanks, I sent you a PM.

[Los]

Out of another programmers curiosity's pov, what are you going to make that is different that already is there? What tools will you be using, etc, bit more info! :)

[Freddie]

Naturally I have plenty of ideas about these things. But I don't want to impose my ideas any more than necessary. I'd like the project to be highly collaborative with all the participants having a voice. I'll just say the following:

It would be nice to put out a first release as soon as possible, in just a couple of months, that people can actually use, that does the basics. I guess the basics would be something like:

-- game launching
-- maximizer stuff
-- PIP and PIP toggling
-- key broadcasting, settable by active window and key

Maybe mouseover (KM) could also be added to an early release because I might be able to pretty much drop in HKN2's mouseover code.

So far, what I just described is only a vanilla mutilboxing program. But as I'll explain in a moment, a wide range of additional features could be added pretty soon. For example, the program could allow people to plug two keyboards into a single PC, and a given key would do something different depending on which keyboard it was pressed on. This is doable and would functionally replace X-Keys.

I think the choice of programming language(s) may have to depend on what the initial volunteers want to use.

If we create a good architecture for the program at the start, a large number of people will be able to add to its features easily for years to come. The program could eventually have an extremely rich range of features that go well beyond anything we've seen to date.

It would be good if the program is highly modular, with each module extremely encapsulated so different volunteers with different skills can all contribute to the code.

In particular, it would probably be good to completely separate the user interfaces (plural, there is no reason why there can't be more than one) from an underlying engine that does the actual work.

I think ease of use (automatic setup, intuitive GUI, high-quality user documentation, etc.) should be emphasized. We should try to attract as many users as possible. The more people use the program, the more motivated the developers will be.

Once the first release is in use, users will help design the program. The initial group of developers doesn't have to completely foresee what those users will want. We only have to create an architecture that is sufficiently robust and flexible for future development to expand in many directions.