Talk:DecouplingEmber

I'll try to address the points you raise in "Feature requests"

1. The ember script is mainly there for when Ember is run through an autopackage installation, since then the paths are not known. When normally installed, all paths are already set, but when run as a relocatable autopackage we have to do some logic to figure out where we are installed so that we can set the correct LD_LIBRARY* settings. Note that this is regarding the basic data paths. The parts where it refers to version specific data, such as copying ember-media-<major>.<minor>.<patch> to the user's home directory could probably be moved to somewhere else. Also note that _all_ settings in ember.conf can be overridden by calling ember.bin using the flag "--config <section>:<key> <value>". This is not very much documented and the ember script strips out all flags. You can use as many "--config..." flags as you want. So for example if you want to use another data directory you can do "ember.bin --config paths:datadir /foo/bar/data" or if you want to disable the wfut service you can do "ember.bin --config wfut:enabled false"
2. Both the location of the shared data and the location of the user-specific data can be changed by setting the variabled "sharedir" and "datadir" in the config section "paths". Note that we however still want to store the data under PREFIX/share/ember/* as per the FHS. We would however want to use separated subdirectories there, so that mason specific data is stored at PREFIX/share/ember/data/mason or something.
3. I don't follow you regarding the shared libraries. This is a package specific issue. I provide the autopackage version, which has some parts of the libraries statically linked, and other parts supplied as shared objects. These shared objects are however local to the ember package only and does not interfere with other libraries installed by either other autopackage installations or by the system. If ember would be packaged by any distro it would surely be packaged in such a way that it won't interfere with other libs. I cannot however see how the usage of shared would in any way affect the users. In 99% of the cases people will download and install the app without having any idea whether it uses any shared libs or not.
4. I agree, we would probably want to move the copying of the user data from the wrapper to a function within the app, and make it more configurable.
5. Regarding the paths for the textures currently in ember.conf, they are very much temporary. I'm working on an xml-format for defining the bindings between textures and terrain layers, but until that is done I just needed a place to put it. However, the correct way forward here is to use multiple config files. The Varconf lib that is used for config files allows for many config files to be loaded. So what we would want to do is to have one small ember.conf file that contains the most basic settings, and then separate config files for each "world", such as "mason.conf". The config file to load would be specified at startup. As noted above, both the path to the shared media and the user specific media can be set in the config file.
6. The carpenter and jesus functionality isn't used currently, but it's working. Use the command /show_jesusEdit to bring up the editor for it.

--Erik 17:51, 3 October 2007 (CEST)

Carpenter

Btw, Carpenter was intended to be a library for building structures by stitching together building blocks very much like Lego. Jesus (a carpenter) was the Ember interface for editing Carpenter blueprints. There are some screenshots here and here. --Erik 17:54, 3 October 2007 (CEST)