i love xbmc and the frequent improvements in functionality are nice... but they are, imo, adding frills and polishing up existing functionality but not adding new functions that allow for more customizability.
example: exposing the system hd free space to the gui... this is what the home theater / audio crowd would call "bells and whistles" - basically something only a select few will use, not adding to core functionality.
what i mean by this is that it seems when several users ask for a new feature... the ability to create a custom screen using built-in views. maybe for something like to have a separate tv shows screen that has its own "remembered" view different then 'my videos'.
when these types of request are made i frequently see answers such as...
"this is a limitation of the way xbmc does... <fill in the reason here>"
or "the core code would need a complete rewrite."
or <insert simular phrase here>
so i guess what i'm asking is... "why?"
why not make the code flexible so that things are not "hard coded" to only be used one way, with specific screens?
why not make it easier to use object ids?
why not make it so that users could create thier own custom screen without needing to completely write thier own code?
i'd love to build a screen that allowed me to have both music and videos on the same screen. this way i could create a 'surround sound demo" screen and have two columns, one for videos and one for surround music. and the columns would each display the file types correctly (in other words... the exact way i told it to for that specific screen). i might have the videos shows using thumbs and the music in a list.
if each control was truely an object i could create a custom screen, define a new object using the control object as a reference and then give it specific properties.
this is how object oriented programming works (for those that did not know) but i'm not telling the coders here anything new.
i guess i'm wondering why the xbmc code is not following that convention?
i'm interested to hear the thoughts from the dev's?
example: exposing the system hd free space to the gui... this is what the home theater / audio crowd would call "bells and whistles" - basically something only a select few will use, not adding to core functionality.
what i mean by this is that it seems when several users ask for a new feature... the ability to create a custom screen using built-in views. maybe for something like to have a separate tv shows screen that has its own "remembered" view different then 'my videos'.
when these types of request are made i frequently see answers such as...
"this is a limitation of the way xbmc does... <fill in the reason here>"
or "the core code would need a complete rewrite."
or <insert simular phrase here>
so i guess what i'm asking is... "why?"
why not make the code flexible so that things are not "hard coded" to only be used one way, with specific screens?
why not make it easier to use object ids?
why not make it so that users could create thier own custom screen without needing to completely write thier own code?
i'd love to build a screen that allowed me to have both music and videos on the same screen. this way i could create a 'surround sound demo" screen and have two columns, one for videos and one for surround music. and the columns would each display the file types correctly (in other words... the exact way i told it to for that specific screen). i might have the videos shows using thumbs and the music in a list.
if each control was truely an object i could create a custom screen, define a new object using the control object as a reference and then give it specific properties.
this is how object oriented programming works (for those that did not know) but i'm not telling the coders here anything new.
i guess i'm wondering why the xbmc code is not following that convention?
i'm interested to hear the thoughts from the dev's?
