Reply to thread

Message

<blockquote data-quote="knutinh" data-source="post: 62522" data-attributes="member: 14776">I havent looked into the skin engine at all. But it seems to me that creating (and updating) skins in several resolutions is a waste of creative energy that could be used for making genuinly new stuff?Ideally, the skin designer would start out with a screen &quot;size&quot; measured in inches, not pixels. Or even better, &quot;degrees of visual coverage&quot;, such that a 60&quot; screen at 6 meters would equal a 10&quot; screen at 1 meter. That is the size that matters for the user. When it is given, we can talk about ideal font-size etc. I am guessing that most elements are either synthetically composed in e.g. photoshop, rendered text, or simple lines/borders specified in pixels?After the screen have been composed in &quot;infinite resolution&quot; to consist of certain elements, those elements could be &quot;rendered&quot; at any resolution provided that it is high enough to carry the necessary information.I guess I am saying that even if a native SVG skinning engine is far away, it could be possible to have a local offline skin rendering engine that parses generalised skin SVG info into the current skin format, optimzed for the local resolution (and viewing size). That way, skin designers can concentrate on making good looking skins, and one does not have to re-write the run-time skinning engine.Also, would it be possible to make a skin engine that behaves nicely when the application contains elements that isnt supported in the skin yet? This may be backwards and impossible, but I imagine scanning the skin against e.g. blue two at startup. Every element found in blue two but not in the chosen skin is rendered as blue two. In other words, one can keep up with current releases without the skin-maker, even though the new functions will look &quot;bad&quot;.regardsKnut</blockquote>

[QUOTE="knutinh, post: 62522, member: 14776"] I havent looked into the skin engine at all. But it seems to me that creating (and updating) skins in several resolutions is a waste of creative energy that could be used for making genuinly new stuff? Ideally, the skin designer would start out with a screen "size" measured in inches, not pixels. Or even better, "degrees of visual coverage", such that a 60" screen at 6 meters would equal a 10" screen at 1 meter. That is the size that matters for the user. When it is given, we can talk about ideal font-size etc. I am guessing that most elements are either synthetically composed in e.g. photoshop, rendered text, or simple lines/borders specified in pixels? After the screen have been composed in "infinite resolution" to consist of certain elements, those elements could be "rendered" at any resolution provided that it is high enough to carry the necessary information. I guess I am saying that even if a native SVG skinning engine is far away, it could be possible to have a local offline skin rendering engine that parses generalised skin SVG info into the current skin format, optimzed for the local resolution (and viewing size). That way, skin designers can concentrate on making good looking skins, and one does not have to re-write the run-time skinning engine. Also, would it be possible to make a skin engine that behaves nicely when the application contains elements that isnt supported in the skin yet? This may be backwards and impossible, but I imagine scanning the skin against e.g. blue two at startup. Every element found in blue two but not in the chosen skin is rendered as blue two. In other words, one can keep up with current releases without the skin-maker, even though the new functions will look "bad". regards Knut [/QUOTE]

Verification