Make Look n' Feel inheritable in a way that it is possible to change widget-specific images in an inheriting sub-widget

Issue #988 new
Lukas Meindl created an issue

cegui train-of-thought log:

[18:57:31] Ident how about we make these LNF so that they can be inherited [18:58:13] Ident then we make a base falagard widget [18:58:15] Ident for all types [18:59:11] Ident and the taharez, vanilla etc., they would inherit these widgets [18:59:19] Ident and then override the images in them with their own skins [19:02:10] Ident because the widgets itself wont change much [19:03:01] Ident so it does not make sense to redefine these things in every LNF [19:03:08] Ident if somebody needs an explicit custom widget [19:03:18] Ident it can still be done in the inheriting skin-LNF [19:03:34] Ident but the general widgets could be inherited, and easily skinned by overriding the image definitions [19:05:42] Ident also, this could be way way easilier be made editable in CEED by just providing support for the reskinning of inherited lnf-widgets [19:06:10] Ident all thats needed is a preview of the widget, and the variables to be defined with images, and being able to select from a list of defined skinnable widgets for this purpose [19:06:20] Ident so its kind of a soft-editing [19:06:33] Ident artists could handle this - thats my point. anyone can handle it. [19:07:04] Ident and it wouldnt limit the possibility of in the end doing it in xml by hand to define the widgets urself, its just that in that case u d have to do it without help of CEED [19:07:08] Ident but thats just an idea pauldt Ident: they can be already (with some perfectly justified limitations( [22:06:39] pauldt timotei_: docs are right [22:06:48] Ident pauldt: be already? [22:06:48] Ident what [22:07:24] pauldt A widgetLook can inherit from another widgetlook [22:07:37] pauldt and override stuff [22:07:51] pauldt with limitations [22:49:56] Ident whats the limitation [22:49:56] Ident and [22:50:02] Ident why dont we change the current LNFs to that system [22:50:16] Ident the only negative side i see is tat loading will take a bit longer but from then on the result should be exactly the same [22:50:18] Ident or am i wrong? [22:54:55] pauldt it may be a little slower [22:55:11] pauldt probably not excessively so [22:55:25] pauldt the limitations depend on what you want to do! [22:55:41] pauldt if you want to do something and can't, that's one of the limitations :-p [22:56:43] pauldt as for migrating existing stuff. It's a lot of work. [22:57:07] Ident run-time will be slower too? [22:57:18] Ident the abstract stuff could be held just for the loading [22:57:31] Ident and in run-time there could only be the "result-stuff" [22:57:36] Ident or is that inconsistent? [22:57:46] pauldt it's not what I would want [22:57:56] pauldt it's not dynamic [22:58:47] pauldt any speed difference is likely nothing to be concerned about [22:58:52] Ident good [22:58:58] Ident what are the limitations? [22:59:09] Ident and can overwriting be broken down to just setting variables? [22:59:17] Ident i ll have to look at the docu for this i guess [22:59:37] pauldt the overridable things are basically the named components [22:59:51] pauldt of course you can set properties to whatever values too [23:00:12] pauldt so the limitations are of granularity [23:00:18] pauldt but they are logical [23:01:36] pauldt and you can't do "most of the ImagerySection from the base skin, but change this one thing" [23:01:52] pauldt i.e you override the complete imagerysection [23:03:05] pauldt or named area, or whatever else has a 'name' of some kind [23:03:45] pauldt the exact mechanics of it are not really documented from what I recall [23:04:16] pauldt it's documented as far as the inherits attribute goes [23:04:40] pauldt but IIRC it does not go into a lot of detail as far as acutally how to make use of it. [23:05:49] pauldt oh wow, I just looked, it's not documented at all from what I can tell [23:05:53] pauldt that's a total failure [23:05:59] pauldt I wonder what happened there [23:06:24] pauldt I'm usually pretty good at keeping that falagard stuff up to date (becuse I have to refer to it, too!) [23:06:36] pauldt wow, I'm quite disappointed [23:07:34] pauldt goes to sit in the naughty corner [23:13:03] pauldt I will add a freaking mantis ticket for it [23:15:53] Ident well [23:15:54] Ident like i said [23:15:59] Ident the interesting part would be to just have [23:16:02] Ident a widget name [23:16:11] Ident tell what the super-widget name is [23:16:18] Ident (from which we want to inherit everything) [23:16:38] Ident and then u just define, imagebordertop = paulskin/bordertop [23:16:39] Ident etc [23:16:44] Ident would that be possible? [23:17:11] Ident i mean without having to use propertydefinitions which , as far as i remember, werre said to be slower than having the direct image defined in LNF? [23:17:36] pauldt it's not possible as things stand [23:17:54] pauldt and yes, property defs would be a little slower [23:18:31] Ident yes [23:18:32] pauldt this facility already kind of exists though [23:18:43] Ident especially because property defs are slower [23:18:45] Ident it would be interesting [23:19:01] Ident to get rid off all the repetitive stuff like define editbox 5 times in different skins [23:19:02] pauldt effectively you're just changing the imageset [23:19:05] Ident and just be able to define the images [23:19:08] Ident well [23:19:16] Ident i think its better to do it per-image [23:19:35] Ident so u re not forced to use the same imagenames in ur imageset [23:19:48] Ident what if u wanna have 2 editbox skins in 1 LNF [23:19:56] Ident if ujust change imageset u d need 2 imagesets then [23:20:03] Ident the name definitions for Image would be the same [23:20:05] Ident is that what u meant? [23:20:11] pauldt yes [23:20:18] Ident that doesnt sound too good to me [23:20:36] Ident the question is how u identify the images and be able to replace them in ur sub-widget [23:20:44] Ident with skin-specific images [23:20:53] Ident if thats given [23:20:58] Ident than u can really cut it down [23:21:00] Ident to a minimum of xml code [23:21:05] Ident artists could handle that [23:21:12] pauldt it needs something [23:21:20] pauldt and I know what it is [23:21:33] pauldt however [23:21:53] Ident yes? [23:22:04] pauldt I'm thinking [23:23:27] pauldt it's somewhat similar to the global colour properties request on mantis (it does not sound similar, I know, but it is). [23:24:15] pauldt I know what's mentioned here is in the widgetlook and not global, but the approach would be the same [23:24:26] pauldt lnf global, that is [23:24:58] Ident u mean global inside a specific lnf but not inter-lnf? [23:25:01] pauldt but anyway, it's definitely an interesting to have I think [23:25:13] Ident i think it would allow to cut down all base widgets into 1 LNF file [23:25:17] pauldt yes, local to a specific looknfeel [23:25:32] Ident it would make it easier to make new skins [23:25:32] pauldt well [23:25:38] pauldt not always [23:25:41] Ident where not?= [23:25:54] pauldt because not all skins take the same approach [23:26:09] pauldt WL button = 9 images, TL button 3 [23:26:55] pauldt I like the idea though, and it would certainly be useful in the vast majority of cases [23:27:28] Ident why the hell 9 [23:27:45] pauldt four corners, four edges and the middle bit [23:27:58] pauldt that's 4 + 4 + 1 = 9 [23:28:03] Ident i forgot the middle [23:28:04] Ident :D [23:28:07] pauldt lol [23:28:08] Ident well for those cases [23:28:21] Ident one could either implement it fully in the specific LNF [23:28:22] Ident or [23:28:25] Ident there could be 2 button templates [23:28:43] pauldt yeah, it's not a reason to not have the suggested feature [23:29:00] Ident i think its even a reaso nfor it, considering that many ppl migth have 3 and many others might need 9 images [23:29:08] Ident assuming there would be many ppl making skins at all

[23:38:46] pauldt ideally it would work without a name lookup (since that kind of replicates property defs - though not quite), and that would be easily done /without being able to inherit/. Being able to inherit complicates things, because in c++ parlance, those things are like pure virtual - and used in the 'base' widgetlook, but defined in sublooks. So I think would always need the lookup. There are solutions, but I don't like any of them.

Reproducibility: always

Comments (0)

  1. Log in to comment