View source for The Lederhosen project - The Second Coming

← The Lederhosen project - The Second Coming
Jump to: navigation, search
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in the group: Users.
You can view and copy the source of this page:
LNF editor based on the Falagard skinning System.

== Open questions ==

=== Resource reloading after LNF file changes? ===
<source lang="text">
[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"
</source>

=== LNF name clashes ===
<source lang="text">
[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
</source>

=== Which "renderer" and "targetType" to use for a LNF widget ===
<source lang="text">
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
</source>

=== Simultaneous LNF editing of multiple widgets in one file ===
<source lang="text">
[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?
</source>

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

<source lang="text">
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
</source>


=== Should we throw a warning in CEGUI v0-8 when a WidgetLook is loaded and it has name clashes between Properties PropertyDefinitions and PropertyLinkDefinitions? ===
<source lang="text">
[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
</source>

=== 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.
<source lang="text">
[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
</source>

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 ===
<source lang="text">
[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
</source>
Return to The Lederhosen project - The Second Coming.
Retrieved from "http://cegui.org/wiki/The_Lederhosen_project_-_The_Second_Coming"
View source for The Lederhosen project - The Second Coming

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Main

Community

Documentation

Tools
