+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: PVR Development (/forumdisplay.php?fid=136)
+--- Thread: Unified PVR frontend (DVR/HTPC client GUI with EPG) and Addons API for PVR backends? (/showthread.php?tid=28918)
- SSchocke - 2009-01-21 22:15
OK... after a brief bit of experimentation, it seems this will be way harder than anticipated. Even the simplest of classes (CURL, CDateTime) all in some way or another link back to the CFile, which means the whole CFile* range of classes get pulled in. A BIG problem seems to be the CUtil class, which pulls in so many headers, it looks more like all the functions seem to have been bundled into one file, from simple StdString functions, to SDL stuff, network protocols, player cores, FTP stuff and GUI functions.
In short, moving any of these classes out of the XBMC source is going to be lots of hard work!!!
- alcoheca - 2009-01-21 23:14
Aye CUtil pulls in crap-loads.
Bit of a bummer then...
The three threading related classes look like better candidates, and I'm thinking that we should aim to guarantee that each client has it's own thread to ward against buggy client code. So maybe that's as simple as having IPVRClient inherit CThread.
Building wise, it would be great if Windows compiled plugins would work on Xbox. Linux and OSX would be two seperate builds?
I wonder how we can make things easier for developers to release for all platforms.
- jmarshall - 2009-01-22 00:32
We'd have no problem if you were to undertake such work. CUtil in particular is a dumping ground for many, many things, much of which could do with a good refactor.
We have StringUtils for instance for string based stuff.
Cheers,
Jonathan
- SSchocke - 2009-01-22 07:24
alcoheca Wrote:The three threading related classes look like better candidates, and I'm thinking that we should aim to guarantee that each client has it's own thread to ward against buggy client code. So maybe that's as simple as having IPVRClient inherit CThread.
Will have a look at them when I get home tonight
jmarshall Wrote:We'd have no problem if you were to undertake such work. CUtil in particular is a dumping ground for many, many things, much of which could do with a good refactor.
We have StringUtils for instance for string based stuff.
Great
I think I am going to take the path of trying to "Categorize" the functions and classes more. Like StringUtils, FileUtils, URLUtils, etc. and building up the classes on top of those afterwards. Perhaps also create a couple of Interfaces with no functionality and let XBMC internals implement those interfaces instead of whole classes in the util lib for File, Network and System related functions. Then the util functions can still receive parameters with internal XBMC data structures, without having to implement them 
- SSchocke - 2009-01-23 05:50
This stuff is so convoluted and dependent on each other, it's going to take a day and a year, not mentioning moving over 80% of the stuff over just to make CDateTime work. (CDateTime provides regional formatting, regions get loaded in from XML, which region gets loaded is handled via settings file, settings files use CFile, all of which gets loaded into global variables in XBMC source.)
Pretty much anything else uses CLog. CLog SHOULD NOT be a problem, but it also relies on the settings file, not to mention, it relies on Path Translation functions from CUtil, which rely on IOSupport functions, which relies on Media Detection routines, which relies on .....
I'm sorry, but I just find this fundamentally wrong
. The logging functionality of an application should by definition not rely on anything to be in place. As it stands, an improperly formatted settings file breaks the entire applications logging facility. A problem detecting which media XBMC is running from breaks the logging.I am not saying determining a valid logging location (LiveCD, multi-platform obviously has special needs in this regard), I am just saying it should not be the CLog class that determines it.
As a starting point, I am going to see if I can rewrite the CLog class to simply do the logging, and move the initialization out to CApplication or so.
Also, coming back to an earlier question... Static vs Dynamic library. I noticed that all the existing libraries (like guilib) are statically linked into XBMC. I need to setup a test application in this regard, but maybe somebody can give me a quick answer.
If I have static library A, and I statically link it into Application B and Application C, and I have a global variable X defined in A, and I change X in App B, does App C also see the update, or does B and C create their own copy of the X variable in memory?
If each creates it's own copy, using static libraries to create a interface to XBMC seems impossible. And I still have no idea how the DllLoader concept works, and if it would be possible to use it to load in the util lib which would host so many of the fundamental classes and functions required to initialize the application
Sorry for the long rant... Had to get it out of my system... Short version is HELP
- SSchocke - 2009-01-23 06:40
SSchocke Wrote:Also, coming back to an earlier question... Static vs Dynamic library. I noticed that all the existing libraries (like guilib) are statically linked into XBMC. I need to setup a test application in this regard, but maybe somebody can give me a quick answer.
If I have static library A, and I statically link it into Application B and Application C, and I have a global variable X defined in A, and I change X in App B, does App C also see the update, or does B and C create their own copy of the X variable in memory?
Quick test case created. Unless I am missing something, it does not work. The value of X in the two application does not stay synced... Guess it would have been too easy if it did.
- jmarshall - 2009-01-23 07:12
One thing to watch:
CLog is a static class. Thus, the logging will begin whenever it is first called. This could be from any of the globally allocated variables for instance, and may well be before other initialization is one. Now, I'm pretty sure this won't be an issue, but it's something to be aware of.
Note that I (and all devs) fully support any cleaning up that is performed.
Cheers,
Jonathan
- d4rk - 2009-01-23 22:51
SSchocke Wrote:Quick test case created. Unless I am missing something, it does not work. The value of X in the two application does not stay synced... Guess it would have been too easy if it did.
Every application has it's own address space, you can't use a static (or dynamic) library to share address space or variables. Best case, if one application forks from another, then it will get a copy of the variables in its current state. You'll need to use alternate methods like shared memory, if you want to share global data across processes.
- SSchocke - 2009-01-24 16:41
d4rk Wrote:Every application has it's own address space, you can't use a static (or dynamic) library to share address space or variables. Best case, if one application forks from another, then it will get a copy of the variables in its current state. You'll need to use alternate methods like shared memory, if you want to share global data across processes.
All I can say is I must have been either drunk or smoking something when I came up with that idea.
What I was actually trying to establish is whether we can have a static library that we link XBMC against, and link plugin dynamic libraries against that same static library. Then, when the plugin library gets loaded, would it create duplicates of all the variables and functions in the static library, or would it use the already defined variables and functions from the XBMC instance?
I mean, if we pull the dynamic library into the same address space than the running application, surely we can make calls from the XBMC application to the library. How else would any plugin system work. And if you can make them in that direction, surely there must be a way for the plugin to make calls back into the application. If so, if I call the GetLogFolder function, which is defined in that static library that both XBMC and the plugin are linked against, which "instance" of the function would get called?
I think I seriously need to play around outside XBMC for a while first before I tackle this particular problem...
- apocalip - 2009-03-04 11:59
Is there any status on this Project?