The Lederhosen project - The Second Coming

LNF editor based on the Falagard skinning System.

Open questions

Resource reloading after LNF file changes?

[17:46:25]	mpreisler	one issue that doesn't have to be solved now but eventually we have to solve it is how to propagate the LNF changes to other windows
[17:46:34]	mpreisler	lets say you are editing a layout and LNF at the same time in different tabs
[17:46:40]	mpreisler	you change the LNF and save it
[17:46:43]	mpreisler	then switch to layout editing
[17:46:51]	mpreisler	your changes will not be there until you click "Reload project resources"

LNF name clashes

[17:38:12]	mpreisler	LNF names are global
[17:38:23]	mpreisler	so they will clash which we must prevent
[17:38:34]	mpreisler	I guess we can make the names up when loading the LNF
[17:38:38]	mpreisler	which will be an OK solution
[17:38:42]	Ident	filename/widgetname

Which "renderer" and "targetType" to use for a LNF widget

mpreisler	the editor itself opens the looknfeel file but should probably look into scheme for hints about which renderer and widget to use for preview

Simultaneous LNF editing of multiple widgets in one file

[17:36:47]	mpreisler	how will the users switch between edited LNFs?
[17:36:53]	mpreisler	because you can have tons of them in one file
[17:37:22]	Ident	whole LNF has to be parsed and stored in local memory during editing
[17:37:28]	Ident	like
[17:37:31]	Ident	each widget
[17:37:36]	Ident	and then when writing out
[17:37:41]	Ident	they all get parsed into xml again
[17:37:49]	Ident	is there an issue with this?

How to solve the issue arising when having deleted FalagardMapping after deleting a window using it (dead-window pool)

Solution:
In CEED v0-8 we will add a clear call:
PyCEGUI.WindowManager.getSingleton().cleanDeadPool()
 
In CEED default we will have to remove it once CEGUI default has a pool for removing falagardmappings: (ToDo !!!)
[15:08:09]	Ident	if i added lazy delete similar to deadwindowpool for falagardmappings
[15:08:44]	mpreisler	I don't think we should be adding lnf pools to v0-8
[15:08:50]	Ident	that was my question
[15:08:51]	Ident	lol
[15:08:53]	mpreisler	so IMO we can fix this in default and in interim we use the workaround in v0-8
[15:08:55]	mpreisler	that you suggested
[15:09:01]	Ident	which is?
[15:09:09]	Ident	adding the clean to the remove?
[15:09:12]	mpreisler	just run the deadpool beofre you remove the mapping
[15:09:23]	Ident	what if we merge into default then
[15:09:26]	Ident	wont it be added to default?
[15:10:06]	mpreisler	hmm, I was suggesting to run the method from CEED

Should we throw a warning in CEGUI v0-8 when a WidgetLook is loaded and it has name clashes between Properties PropertyDefinitions and PropertyLinkDefinitions?

[19:43:45]	Ident	as far as i see there is no mechanism to check if a widgetlook has a name clash between propertydefinition, properties or propertylinkdefinitions
[19:43:58]	Ident	or rather i mean: it is not checked on load
[19:47:05]	Ident	i consider this a candidate for spitting out a warning at least
[19:47:30]	Ident	could be added to v0-8 couldnt it?
[19:47:37]	Ident	after all a warning doesnt change the behaviour
[19:48:10]	mpreisler	yeah
[19:48:21]	mpreisler	warning can go into v0-8 I think

Solve the SectionSpecification look attribute to not be written in case it equals the WidgetLookFeel we are in anyways

Also the string lookups in CEGUI should probably replaced by references for that purpose. Can only be done in default.

[2014-06-15 15:36:57] <mpreisler> I wonder how to check this
[2014-06-15 15:37:05] <mpreisler> you have to pass the parent when writing it out
[2014-06-15 15:37:11] <mpreisler> if it matches you wouldn't write it out
[2014-06-15 15:36:55] <Ident> it does "WidgetLookManager::getSingleton().getWidgetLook(d_owner).getImagerySection(d_sectionName);"
[2014-06-15 15:37:00] <Ident> in the render function
[2014-06-15 15:37:07] <Ident> which btw sounds terrible
[2014-06-15 15:37:11] <Ident> why is there not just a reference
[2014-06-15 15:37:33] <Ident> void SectionSpecification::render
[2014-06-15 15:37:50] <mpreisler> pauldt claims that you can change falagard in between renders without CEGUI crashing
[2014-06-15 15:37:53] <mpreisler> but yeah I noticed this too
[2014-06-15 15:37:56] <mpreisler> lot of string lookups
[2014-06-15 15:37:58] <mpreisler> while rendering
[2014-06-15 15:43:08] <Ident> mpreisler: thats irrelevant tho
[2014-06-15 15:43:13] <Ident>  we re talking about parsing to string here
[2014-06-15 15:43:26] <Ident> i cant add a member right?
[2014-06-15 15:43:30] <Ident> it would break abi/api or whatever
[2014-06-15 15:43:38] <mpreisler> yeah, you can't
[2014-06-15 15:58:57] <Ident> mpreisler: whats also annoying is that the mapping will be visible
[2014-06-15 15:59:05] <Ident> i could of course hide it
[2014-06-15 15:59:24] <Ident> for example i nthe editor we could show:
[2014-06-15 15:59:26] <Ident> <Section look="Vanilla/Shared" section="Frame" controlProperty="UseStandardImagery" >
[2014-06-15 15:59:40] <Ident> but actually what is parsed is <Section look="101637856/Vanilla/Shared" section="Frame" controlProperty="UseStandardImagery" >
[2014-06-15 16:00:07] <Ident> so everytime we get the code from a WLF or turn a WLF into a string we have to map and unmap
[2014-06-15 16:00:29] <Ident> not doing it would confuse users
[2014-06-15 16:00:36] <Ident> also it is kind of a clutter
[2014-06-15 16:00:54] <Ident> mpreisler: if i wanted to replace string lookups i d have to store references
[2014-06-15 16:00:58] <Ident> again cant be done in v0-8

Probably we should also replace the hard-coded strings by publically accessible constnats such as defined in the XMLHandler, maybe by using a separate header

Find a solution for String constants used in the xml handler

[20:58:32]	Ident	so all the classes for the elements of Falagrd parse out to xml using hard-coded strings (for attribute names)
[20:59:06]	Ident	while those same strings are already defined in the XMLhandler as string constants already
[20:59:12]	Ident	i dont like this
[20:59:23]	Ident	why not just use the constants
[20:59:34]	Ident	even if the xmlhandler is not to be included, the constants could just be be put in a separate header