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

← Older revision		Revision as of 01:35, 21 March 2013
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		* 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 SVN (during the evaluation period or earlier) please state so.

	==Communication skills==		==Communication skills==
Line 186:		Line 186:
	5.1) Are you familiar with any of the following tools or languages?		5.1) Are you familiar with any of the following tools or languages?

	*~~Subversion~~ (used for all commits) - Yes		*Subversion (used for all commits) - Yes
	*C++ (language used for all the normal source code) - Yes		*C++ (language used for all the normal source code) - Yes
	**STL - Yes		**STL - Yes

Crab: /* SoC Application */

2010-04-09T22:10:17Z

SoC Application

← Older revision		Revision as of 22:10, 9 April 2010
Line 9:		Line 9:
	kahowell		kahowell
	=SoC Application=		=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=		=Questionnaire=

Crab: /* IRC */

2010-04-09T21:33:30Z

IRC

← Older revision		Revision as of 21:33, 9 April 2010
Line 8:		Line 8:
	=IRC=		=IRC=
	kahowell		kahowell
			=SoC Application=
			[http://socghop.appspot.com/gsoc/student_proposal/review/google/gsoc2010/kahowell/t127083650353 t127083650353]

	=Questionnaire=		=Questionnaire=

Kahowell: /* Description */

2010-04-09T20:08:40Z

Description

← Older revision		Revision as of 20:08, 9 April 2010
Line 4:		Line 4:
	=Description=		=Description=
	<h4>Kahowell - Making the Wesnoth Input Framework More Flexible</h4>		<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=		=IRC=

Kahowell: /* Questionnaire */

2010-04-09T20:07:46Z

Questionnaire

Show changes

Kahowell at 19:51, 9 April 2010

2010-04-09T19:51:21Z

← Older revision		Revision as of 19:51, 9 April 2010
Line 156:		Line 156:
	#Right now, the input for Wesnoth is mouse-centric.		#Right now, the input for Wesnoth is mouse-centric.
	#There are a couple of methods to try to decouple Wesnoth from the mouse.		#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		*Input flexibility

Kahowell at 19:50, 9 April 2010

2010-04-09T19:50:42Z

← Older revision		Revision as of 19:50, 9 April 2010
Line 144:		Line 144:
	4.5) Include as much technical detail about your implementation as you can		4.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
			#Look into probing SDL upon startup to determine what types of input devices are available. Compare these devices with a listing of previously identified devices. Each device would have a value to disable or enable it in the config, so disable all devices disabled in the config.
			#If a previously configured device is identified, load the configuration for it. Else, load/create a default config.
			* Dialog
			#Additional dialog to be placed under the configuration main menu (Input)
			#This dialog can be similar to the one for hotkeys. (It would be nice to integrate the two).
			#Enumerate input devices, 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.

	~~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
			#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...
			##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.

	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.
			#Also, for devices with limited keys or buttons, I may experiment with allowing held-in buttons to generate different events from ones that were simply pressed.
			#I plan 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).

	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
			TODO: extra

	4.6) What do you expect to gain from this project?		4.6) What do you expect to gain from this project?

Kahowell: /* Questionnaire */

2010-04-09T18:56:15Z

Questionnaire

← Older revision		Revision as of 18:56, 9 April 2010
Line 144:		Line 144:
	4.5) Include as much technical detail about your implementation as you can		4.5) Include as much technical detail about your implementation as you can

	~~Please see my actual application~~ for this ~~info~~ (~~or email me~~).		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).

			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.

			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.
			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).

			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.

	4.6) What do you expect to gain from this project?		4.6) What do you expect to gain from this project?

Kahowell at 18:53, 9 April 2010

2010-04-09T18:53:51Z

← Older revision		Revision as of 18:53, 9 April 2010
Line 3:		Line 3:

	=Description=		=Description=
	<h4>Making the Wesnoth Input Framework More Flexible</h4>		<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.		(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.

Crab: fix a category

2010-04-09T18:51:23Z

fix a category

← 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]]