IntuitiveScenarioEditor - Revision history

Octalot: Mark as obsolete

2022-12-13T10:13:06Z

Mark as obsolete

ShikadiQueen: macro-reference.xhtml -> macro-reference.html

2010-01-21T13:58:08Z

macro-reference.xhtml -> macro-reference.html

Cjhopman: /* My Contributions to Wesnoth */

2008-04-13T03:38:14Z

‎My Contributions to Wesnoth

Cjhopman: /* Note */

2008-04-11T21:32:04Z

‎Note

Cjhopman: /* Note */

2008-04-11T21:30:18Z

‎Note

Cjhopman at 21:24, 11 April 2008

2008-04-11T21:24:23Z

Cjhopman: /* Open Source and Gaming */

2008-04-11T18:06:22Z

‎Open Source and Gaming

Cjhopman: /* My Contributions to Wesnoth */

2008-04-03T04:09:46Z

‎My Contributions to Wesnoth

Cjhopman: /* My Contributions to Wesnoth */

2008-04-03T04:09:35Z

‎My Contributions to Wesnoth

Cjhopman: /* Further Discussion */

2008-04-01T05:21:03Z

‎Further Discussion

← Older revision		Revision as of 10:13, 13 December 2022
Line 1:		Line 1:
	[[Category:Summer of Code]]		[[Category:Summer of Code]]
		+	{{Obsolete\|Reason: It's an GSoC application, and the ideas from it are now either implemented or logged in the issues database. There's a lot about handling WML macros in the editor, which 1.15.4 answered by allowing a separate .cfg file for the hand-edited parts to load the editor-generated .cfg via [[ScenarioWML\|'''[scenario]map_file=]].}}

	=== Note ===		=== Note ===

@@ Line 152: / Line 152: @@
 Now onto the second problem, not destroying macros on importing. I've been considering some possible ways to do this relatively easily. The first would go something like this: export the file naively, then run the preprocessor over the original file, compare the two to find differences, and then re-export the file updating only the areas that change. This seems like a rather brutish way of doing things, and I don't know that I like it. Another implementation would be for the editor to simply keep track of what it changes, and then to, when exporting, only update those things that it changes. This has the disadvantage that it may expand some macros that it doesn't need to.
-In addition to the second problem, it will be important to know how the editor will handle some other WML things. So, a quick discussion of things that I have been thinking about. One thing that will help prevent the editor from exporting expanded macros would be for it to recognize and use some macros itself. In particular, I think that the editor should recognize and use most of the core WML macros (that is those found at [[http://www.wesnoth.org/macro-reference.xhtml]]). This would also give a good set of basic functionality for the editor, in that most of these macros are things that the user should be able to change without knowledge of WML.
+In addition to the second problem, it will be important to know how the editor will handle some other WML things. So, a quick discussion of things that I have been thinking about. One thing that will help prevent the editor from exporting expanded macros would be for it to recognize and use some macros itself. In particular, I think that the editor should recognize and use most of the core WML macros (that is those found at [[http://www.wesnoth.org/macro-reference.html]]). This would also give a good set of basic functionality for the editor, in that most of these macros are things that the user should be able to change without knowledge of WML.
 And, a bit more about handling of WML macros. First, I think in the in-editor text-editor, it would be nice to by default have macros not be expanded, but to have a simple checkbox or something similar that would make the editor expand the macros. This may require the editor to maintain a library of defined macros, which could also be useful elsewhere.

← Older revision		Revision as of 03:38, 13 April 2008
Line 167:		Line 167:

	Bug fix [[https://gna.org/patch/?1041]]		Bug fix [[https://gna.org/patch/?1041]]
		+
		+	Went back and made some significant improvements to the unit map [[https://gna.org/patch/index.php?1046]]
		+
		+	Implemented a history feature for the new gui [[https://gna.org/patch/index.php?1054]]

@@ Line 4: / Line 4: @@
 For GSOC mentors -
-If you have read my proposal on the gsoc site, then you can skip most of this, as it is just repeated. The only thing from that proposal that is not here is the little essay type thing at the bottom.
+If you have read my proposal on the gsoc site, then you can skip most of this, as it is just repeated. The gsoc application contains the little essay at the end and that is not repeated here. Everything else is, so you could read either one.
 If you are looking for specific answers to some of the questions from the questionnaire they are at another page [[cjhopman SOC questionnaire]]. Most of that information was duplicated in my application, though.
 == Basics ==

← Older revision		Revision as of 21:30, 11 April 2008
Line 2:		Line 2:

	=== Note ===		=== Note ===
		+
		+	For GSOC mentors -
		+	If you have read my proposal on the gsoc site, then you can skip most of this, as it is just repeated. The only thing from that proposal that is not here is the little essay type thing at the bottom.
		+
		+	If you are looking for specific answers to some of the questions from the questionnaire they are at another page [[cjhopman SOC questionnaire]]. Most of that information was duplicated in my application, though.
		+
		+	The sections that are different from my application are [[#Further Discussion\| Further Discussion]] and [[#My Contributions to Wesnoth\| My Contributions to Wesnoth]].

	== Basics ==		== Basics ==

← Older revision		Revision as of 21:24, 11 April 2008
Line 1:		Line 1:
	[[Category:Summer of Code]]		[[Category:Summer of Code]]
		+
		+	=== Note ===

	== Basics ==		== Basics ==

← Older revision		Revision as of 18:06, 11 April 2008
Line 10:		Line 10:

	== Open Source and Gaming ==		== Open Source and Gaming ==
		+
		+	This section is repeated from my questionairre [[cjhopman SOC questionnaire]]
		+
	Sadly, I am not currently involved with any open source development projects. However, I have, for a while now, been interested in becoming involved, and my experience with the Wesnoth community in the past few weeks has lit that spark that I needed and I will continue to be involved in open source development, regardless of my involvement in Summer of Code.		Sadly, I am not currently involved with any open source development projects. However, I have, for a while now, been interested in becoming involved, and my experience with the Wesnoth community in the past few weeks has lit that spark that I needed and I will continue to be involved in open source development, regardless of my involvement in Summer of Code.

← Older revision		Revision as of 04:09, 3 April 2008
Line 153:		Line 153:

	A quick patch I wrote while I got myself a bit more acquainted with the WML preprocessor [[https://gna.org/patch/?1035]]		A quick patch I wrote while I got myself a bit more acquainted with the WML preprocessor [[https://gna.org/patch/?1035]]
−

	Bug fix [[https://gna.org/patch/?1041]]		Bug fix [[https://gna.org/patch/?1041]]

← Older revision		Revision as of 05:21, 1 April 2008
Line 128:		Line 128:
	== Further Discussion ==		== Further Discussion ==

		+	So, this is the spot to find information about my developing ideas. I thought I'd consolidate further information here so that finding it doesn't require digging through all that other stuff. Also, the following stuff is quite likely to evolve as I discuss my ideas with other developers.
		+
		+	I think I will add date/time info to these entries so that it's easier to find new stuff for anybody reading this. This means that the entries may not flow as best that they can, but oh well, gotta make sacrifices somewhere.
		+
		+	==== April 1, ~ 7:20 UTC ====
		+
		+	The first challenge that I have been considering is that of importing/exporting WML. Now, it is going to be relatively simple to export a scenario made by the editor, the real challenge is to import a hand-written scenario, make changes, and then export it without destroying it. That is, a naive import/export would simply expand all the macros while importing, and it would drop the comments, and then when exported you would have no macros or comments. This would not be a sufficient implementation.
		+
		+	The solutions that I have considered for these problems are slightly different. So, let's consider the problem of maintaining comments first. I think that the easiest, and possibly the best, solution to this problem would be to basically "attach" comments to nearby elements. That is if a comment immediately precedes a given tag, then "attach" it to that tag, and when exporting it will again immediately precede that tag. This would require defining the specific rules for attaching a comment to something. An easy way to do this would be to basically add a common attribute to every tag to hold the comment for that tag, this would be fairly easy to implement, but then comments would only be able to be attached to tags. Ideally, comments would be "attachable" to most WML elements. Clearly, I am still working out how exactly I would implement this.
		+
		+	Now onto the second problem, not destroying macros on importing. I've been considering some possible ways to do this relatively easily. The first would go something like this: export the file naively, then run the preprocessor over the original file, compare the two to find differences, and then re-export the file updating only the areas that change. This seems like a rather brutish way of doing things, and I don't know that I like it. Another implementation would be for the editor to simply keep track of what it changes, and then to, when exporting, only update those things that it changes. This has the disadvantage that it may expand some macros that it doesn't need to.
		+
		+	In addition to the second problem, it will be important to know how the editor will handle some other WML things. So, a quick discussion of things that I have been thinking about. One thing that will help prevent the editor from exporting expanded macros would be for it to recognize and use some macros itself. In particular, I think that the editor should recognize and use most of the core WML macros (that is those found at [[http://www.wesnoth.org/macro-reference.xhtml]]). This would also give a good set of basic functionality for the editor, in that most of these macros are things that the user should be able to change without knowledge of WML.
		+
		+	And, a bit more about handling of WML macros. First, I think in the in-editor text-editor, it would be nice to by default have macros not be expanded, but to have a simple checkbox or something similar that would make the editor expand the macros. This may require the editor to maintain a library of defined macros, which could also be useful elsewhere.
		+
		+	So, that's it for now...

	== My Contributions to Wesnoth ==		== My Contributions to Wesnoth ==