The Lederhosen project - The Second Coming
From CEGUI Wiki - Crazy Eddie's GUI System (Open Source)
Revision as of 17:58, 10 June 2014 by Ident (Talk | contribs) (→Should we throw a warning in CEGUI v0-8 when a WidgetLook is loaded and it has name clashes between Properties PropertyDefinitions and PropertyLinkDefinitions?)
LNF editor based on the Falagard skinning System.
Contents
- 1 Open questions
- 1.1 Resource reloading after LNF file changes?
- 1.2 LNF name clashes
- 1.3 Which "renderer" and "targetType" to use for a LNF widget
- 1.4 Simultaneous LNF editing of multiple widgets in one file
- 1.5 How to solve the issue arising when having deleted FalagardMapping after deleting a window using it (dead-window pool)
- 1.6 Should we throw a warning in CEGUI v0-8 when a WidgetLook is loaded and it has name clashes between Properties PropertyDefinitions and PropertyLinkDefinitions?
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
