SummerOfCodeProposal Kahowell - Revision history

Esr: Hide historical references to Subversion from the wiki search function

2013-03-21T01:35:55Z

Hide historical references to Subversion from the wiki search function

Crab: /* SoC Application */

2010-04-09T22:10:17Z

‎SoC Application

Crab: /* IRC */

2010-04-09T21:33:30Z

‎IRC

Kahowell: /* Description */

2010-04-09T20:08:40Z

‎Description

Kahowell: /* Questionnaire */

2010-04-09T20:07:46Z

‎Questionnaire

Show changes

Kahowell at 19:51, 9 April 2010

2010-04-09T19:51:21Z

Kahowell at 19:50, 9 April 2010

2010-04-09T19:50:42Z

Kahowell: /* Questionnaire */

2010-04-09T18:56:15Z

‎Questionnaire

Kahowell at 18:53, 9 April 2010

2010-04-09T18:53:51Z

Crab: fix a category

2010-04-09T18:51:23Z

fix a category

@@ Line 95: / Line 95: @@
 * If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have
-gained commit access to our SVN (during the evaluation period or earlier) please state so.
+gained commit access to our S&shy;&shy;V&shy;&shy;N (during the evaluation period or earlier) please state so.
 ==Communication skills==
@@ Line 186: / Line 186: @@
 .1) Are you familiar with any of the following tools or languages?
-*Subversion (used for all commits) - Yes
+*Sub&shy;&shy;version (used for all commits) - Yes
 *C++ (language used for all the normal source code) - Yes
 **STL - Yes

@@ Line 9: / Line 9: @@
 kahowell
 =SoC Application=
-[http://socghop.appspot.com/gsoc/student_proposal/review/google/gsoc2010/kahowell/t127083650353 t127083650353]
+[http://socghop.appspot.com/gsoc/student_proposal/review/google/gsoc2010/kahowell/t127083650353 Making the Wesnoth Input Framework More Flexible]
 =Questionnaire=

@@ Line 8: / Line 8: @@
 =IRC=
 kahowell
 =Questionnaire=

@@ Line 4: / Line 4: @@
 =Description=
 <h4>Kahowell - Making the Wesnoth Input Framework More Flexible</h4>
-(Please see my GSoC application or contact me for more details). This would involve learning about the current state of the Wesnoth input system, and creating an input layer which is highly portable between different sorts of devices. Since Wesnoth already uses SDL, this project would mainly involve creating a subsytem to enumerate input devices and create a default configuration. I will look into different ways of identifying input devices (hopefully cross-platform), and perhaps create a database of default configurations (most likely just a collection of files). This project would also involve creating a dialog for input configuration.
+This would involve learning about the current state of the Wesnoth input system, and creating an input layer which is highly portable between different sorts of devices. Since Wesnoth already uses SDL, this project would mainly involve creating a subsytem to enumerate input devices and create a default configuration. I will look into different ways of identifying input devices (hopefully cross-platform), and perhaps create a database of default configurations (most likely just a collection of files). This project would also involve creating a dialog for input configuration.
 =IRC=

@@ Line 156: / Line 156: @@
 #Right now, the input for Wesnoth is mouse-centric.
 #There are a couple of methods to try to decouple Wesnoth from the mouse.
-   ##Mouse emulation (w/ Joystick) - Quick and dirty relocation of the mouse using SDL_WarpMouse, emulation of clicking via some refactoring...
+##Mouse emulation (w/ Joystick) - Quick and dirty relocation of the mouse using SDL_WarpMouse, emulation of clicking via some refactoring...
-   ##Using input to select menu items, etc. (preferred). The logic is similar to using the keyboard and Wesnoth has plenty of keyboard shortcuts. TODO: list what steps are required to make this happen.
+##Using input to select menu items, etc. (preferred). The logic is similar to using the keyboard and Wesnoth has plenty of keyboard shortcuts. TODO: list what steps are required to make this happen.
 *Input flexibility

@@ Line 144: / Line 144: @@
 .5) Include as much technical detail about your implementation as you can
-I intend to write/edit code to probe the system upon program startup to determine what types of input devices are available. Then, after identifying available input devices, the code would load a previously created input configuration/create a sane default configuration based on detected input devices (There would be sanity checking such that a default configuration would be used if the config contained only input devices that were unavailable, a safe default one would be used).
+* Startup
-Additionally, I would write an additional dialog to be placed under the configuration main menu (Input) where the found input devices would be enumerated, along with toggle boxes for each input device. Each device would start as enabled, and then would be ignored if the box were unticked. There would be sanity checks to insure that the user does not disable all input devices, perhaps also a timeout where the user must show that they can still interact with Wesnoth.
+*Decoupling input from the mouse
-I plan to play around with different ways of determining which button to use for each action. For example, axes might be adjustable as a threshold or raw values with determine cursor position. Also, for devices with limited keys or buttons, I may experiment with allowing held-in buttons to generate different events one that were simply pressed.
+*Input flexibility
-I expect that this much flexibility may require a large portion of code refactoring/rewriting. Therefore, one thing I plan to do is to write a script (probably a shell script) to grep the source code for certain input related strings (to aid myself and possibly others in switching to the new framework).
+#I plan to play around with different ways of determining which button to use for each action. For example, axes might be adjustable as a threshold or raw values with determine cursor position.
-If I accomplish a large portion of this, I would also like to work on making the system more error-proof. For example, if a user unplugs an input device, it might be wise to switch (temporarily to a default, sane configuration). If a user plugs in a device after startup, it might be a nice touch to automatically load an associated input configuration.
+*Extra
 .6) What do you expect to gain from this project?

← Older revision		Revision as of 18:51, 9 April 2010
Line 1:		Line 1:
−	{{~~SoC2010Student~~}}	+	{{SoC2010Student_2\|kahowell\|SoC Ideas Gui2 Input}}
	[[Category:SoC Ideas Gui2 Input]]		[[Category:SoC Ideas Gui2 Input]]