-
Notifications
You must be signed in to change notification settings - Fork 3
Configuration
Karazeh provides threading support that enables it to do the patching and processing in a background thread, while updating the client renderer with the progress and feedback. Choosing a thread provider is highly recommended.
By default, Karazeh has adapters for the following thread providors:
- boost::thread
- Qt threads
- Poco threads
- Intel TBB
- GLib Threads
If you're not using any of these, and would like to use your own provider, you can do it by adding a new Thread wrapper class over your preferred solution. To see how that is done, check out PixyThreadQt.h and PixyThreadBoost.h as example wrappers. When you create your wrapper, you have to register it in the PixyThread.h header, and preferably add a switch in the KarazehConfig.h.cmake as an option to toggle it.
Five default renderers are provided, if they do not suit your needs, you may write your own. Check out Creating your own renderer for a guideline on creating custom renderers. To choose the renderer used, pass its name as an argument to Karazeh or specify it as KARAZEH_DEFAULT_RENDERER in KarazehConfig.h (preferably during cmake configuration).
This is made for CLI applications that have no GUI front-end. It basically dumps to STDOUT and awaits input from STDIN.
Usage: ./Karazeh
This is the preferred renderer for KDE users, as it's very easy to customize (using Qt Designer UI resources) and makes for a consistent cross-platform lookn'feel. Furthermore, if you're building the Qt Renderer, Karazeh will make use of Qt Threads and you will not have to build boost threads.
Usage: ./Karazeh Qt
A renderer that utilizes the Ogre engine, built using its sample SdkTrays. If you're already using Ogre for your game/application, and would not like to add a weighty dependency such as Qt or GTK3, you can use this. Otherwise, you really shouldn't, as Ogre was never meant to be a GUI toolkit and is thus not perfect for the job.
Usage: ./Karazeh Ogre
Suitable for GNOME/Linux window managers that use GTK3. It is recommended to use the GLib threads providor if you're using this renderer.
Usage: ./Karazeh GTK3
Highly recommended for Mac users. This is a native renderer for OS X 10.6 built using the Cocoa library. The interface can be conveniently edited using Apple's InterfaceBuilder.
Usage: ./Karazeh Cocoa
The following settings are tuned in include/Pixy.h
PIXY_APP_VERSION
String value representing the version of Karazeh (ie your application launcher). This is used the first time the application is run, or when the resource file is missing. The resource file holds the application's latest version, and is written everytime Karazeh deploys a patch. If the user spoofs around with the file, we resort to this string version.
It's good to update this value to reflect your actual application's value, otherwise it's useless and it will break on the first time it's run, because if it can't find PIXY_APP_VERSION in the patch script, it will not deploy the patch.
Example value: VERSION 1.0.0
PIXY_APP_NAME
This is not a core constant, it's only used in logging and in the Ogre renderer for setting the window title bar, and the CLI renderer's heading.
Example value: Karazeh
PIXY_LOG_CATEGORY
This is used for log4cpp logging, any value would do. All messages logged will be prefixed by this value.
Example value: Karazeh
PIXY_RESOURCE
Whenever a patch is deployed, or Karazeh is run for the first time, a resource file is created with the application's current version. The value in this file will be used everytime the application's version is validated.
Note: This value is not encoded or protected at all, it's plain text. The reason for doing this is that it's easier to debug and correct if the user has accidentally, or intentionally, modified its value. I have not found a better way to do this, to keep track of the version. You can see my (topic on StackOverflow)[http://stackoverflow.com/questions/6117222/versioning-executable-and-modifying-it-in-runtime] for more information. If you have any suggestion please do tell.
Example value: Karazeh.dat
PIXY_PERSISTENT
If this flag is defined, staged patch data will not be deleted when the launcher is exited. This adds the benefit of not having to re-download any data in the case where the user stopped the launcher midway through deploying a patch. This feature is not yet complete and might make for bloat.
PIXY_MIRRORS_RESOURCE
Path to a text file containing a list of patch server mirrors to be used. Each URL needs to be on a separate line.
Example value: patch_mirrors.txt
PROJECT_LOG_DIR:
Name of the directory in which logs will be placed. The log directory will be created under the root.
Example value: log
PROJECT_TEMP_DIR
Patch data will be staged in this directory, created and removed when patching (your users shouldn't see it unless PIXY_PERSISTENT is defined). Just as with the log dir, temp dir is created under the root.
Example value: temp
PIXY_EXTERNAL_APP_PATH
Path to the application launched relative to this application.
Example value: Karazeh.exe, this will launch a process located at BINPATH/Karazeh.exe, the extension - if any, must be specified
PIXY_EXTERNAL_APP_NAME
The process name of the external application you'd like to launch. This is required by execl()
Example value(one used for Karazeh): Karazeh
PIXY_EXTERNAL_APP_ARG
An additional argument can be passed to the launched application, specify it here. If you need to pass more than 1 argument, see Launcher::launchExternalApplication()
Example value: --help
PIXY_DISTANCE_FROM_ROOT
An integer value that represents how many directories there is between this binary and the application's root. This is very important as ALL the paths will be built according to this value.
The paths are created by first locating the running binary (Karazeh.exe or whatever), then we traverse up PIXY_DISTANCE_FROM_ROOT steps and choose that directory as our root. All patch operations are carried out based on the root.
Example value: if you're binary resides in bin/Karazeh, then the value should be 1. If it's in bin/Release/Karazeh.exe, it should be 2. If the binary is in the root, choose 0.
- PROJECT_RESOURCES: used only by the Ogre Renderer to point to the location where the resource files will be
-
PROJECT_OGRE_RESOURCES: same as
PROJECT_RESOURCES, it's composed together with it
You can specify a list of patch server URLs in an external file as per PIXY_MIRRORS_RESOURCE above, and you can also hard-code some default patch servers within the binary. The place to do that is inside src/Downloader.cpp within the constructor method near line 55. For example:
mHosts.push_back("http://myserver.com/patches/");
The server will be queried for a file named patch.txt. For creating this file, please see Generating Patches.