Project

General

Profile

Actions

Feature #288

closed

new attribute for <include condition=''foo">

Added by byron over 10 years ago. Updated over 10 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
User Interface
Target version:
-
Start date:
02/11/2014
Due date:
% Done:

0%

Resolution:
wontfix

Description

I was always under the impression that if a skinner coded

<include condition="foo" file="bar">Blur-Ba-Dee-Blurb</include>

then xbmc would just look past the condition (and the Includes_bar.xml) until the condition was met, but clearly this is not the case.

http://www.xbmc4xbox.org.uk/forum/viewtopic.php?f=15&t=2318#p18913

I'm not sure if this is something that anyone who knows the source code is willing to implement, I think this idea is fantastic in theory, but I have no idea how to write the code (what files to change etc). So I was thinking if the code was easy enough, a new attribute could be added specifically for conditional includes -- I'll refer to it as "wait" for this request -- in which if set to "true" xbmc passes right over the entire include (especially the file that's holding all of the code to be included) if the conditions equal false. Think of how many users never use all of the options that a skin has to offer, yet at the same time they are all included into memory either way and it's a total waste of ram at that point.

If a file isn't included in includes.xml to begin with (a workaround that I've exploited in clarity), but want's to be included somewhere else in another skin.xml then a skinner only needs to add the [file=""] attribute to connect the dots (this approach saves a good deal of ram). Problem becomes that at window render when said skin.xml is activated [file="bar"] is included into memory...if this

<include condition="foo" file="bar" wait="true">

could work the way I'm thinking, then the condition (and huge chunks of code) could be completely bypassed until conditions are met and much ram could be saved for sure.

Actions #1

Updated by dom-dxecutioner over 10 years ago

This would be a good approach; however, looking at mainline xbmc code https://gitorious.org/xbmc/paulepanters-xbmc/source/577b784548ea9d51b37c5537812ec5e7c27f4858:xbmc/guilib/GUIIncludes.cpp, it looks as if this is how they, too, handle the includes (tho i could be mistaken). Perhaps you can discuss this over at mainline and suggest this approach; then BuZz can back-ported to xbmc4xbox, in this manner, we can all benifit.

Actions #2

Updated by buzz over 10 years ago

  • Status changed from New to Rejected
  • Resolution set to wontfix

I am not interested in customising the skin system other than porting across xbmc changes. sorry.

Actions

Also available in: Atom PDF