bluehz,

if i understand things correctly, then you should ditch Default Folder, as it uses the same method (and maybe the same code) to modify apps' memory space.

but i could well not understand things correctly. perhaps slava could comment.

---

basically, i can't figure out how to feel about all of this. i want the tweaks that APE provides, but i also want a rock solid OS. in a perfect world, i could have both, but i don't have enough programming knowledge to understand if this is that perfect world.

my system seems relatively problem free with APE. there are a few quirks, and i have no idea if APE is related or not. these quirks mainly have to do with mounting and unmounting volumes. sometimes disk images will fail to mount. sometimes my iDisk will refuse to unmount. also, sometimes my DHCP address will revert to a 169 address, when others on OS X using the same router don't have that problem.

i've been guessing these problems aren't APE related. unfortunately, they are all intermittant enough that i'm not eager to spend the time testing properly.

All APE modules work by reassigning certain system calls to themselves in order to modify the standard behavior. This means that there can be only 2 kind of APE-related bugs:

1. APE module does something wrong in its own implementation of a system call and crashes. This bug is likely to happen when you use the functionality APE provides directly - collapse a window, use the Apple menu, open an Open/Save dialog box, etc. If the APE module is loaded, but you are not doing anything special, there's a very thin possibility the crash you got is related to the APE module. Think of it that way - APE module lurks in the background, doing nothing, until you try to do something it is intended to enhance. Only then the code kicks in, while being completely idle and not executed most of the time.

2. APE module does something on the application launch time that exposes a bug in the application. For example, we had an issue with one of the past releases of WindowShade X when it would load one additional system framework into an application, and one of well-known applications started to crash because they were over-releasing some memory object, but the bug didn't come up without the APE module because the above mentioned extra framework never was loaded. The developer issued a fix in a few weeks, but we did a small 'fix' on our own that would detect the faulty application and fix a bug in it.

To summarize, there's about only 2 circumstances when APE can cause an individual application crash:

1. During application startup when APE module does its own initialization too;
2. During actions related to the functionality APE provides.

The rest of the time APE module stays silent and is not being used, just like the rest of the system framework calls passively loaded into each application.

There might be exceptions, but I haven't heard of any in 2 years I am doing haxie programming.

In the case of something that poses a system-wide modification (e.g. SkinADock) isn't the module basically active all the time, or at the very least every time the user accesses the dock?

The most recent conflict I have found with APE was with SpellCatcher - which - depending on your settings - is active (e.g. interactive spell checking) all the time. Hence - I can't simply say.. "well everything is ok until I activate application XYZ" Now of course you could argue that application XYZ is at fault here, not APE. But that just leaves the next application XYZ to come along and conflict with APE. The way I see it APE lives on the edge - which believe me I am all for.... but when the edge ignores standardized API then I see that as a problematic item I do not want to tempt fate with.

True. But in that case, only Dock is affected, and the module is not loaded in any other applications, so the worst it can do is crash your Dock.

Who said we ignore standardized APIs? We might use them in a slightly different way, but that doesn't makes them less standardized. ;)

slava: thanks for taking the time to discuss the matter with us, could you please also take the time and explain why ape has to go with almost all unsanity haxies.
like petey reported the official answer is
but i fail to see how this would affect something like Metalize or XSounds of XLabels, since i assume the first only changes the nib files while the second and third should do no more than a single and permanent modification of the system and/or Finder respectively (i don't know much about programming though).
So why do these require APE?

Basically, the story is as follows. Before APE, there was a library providing the needed functionality of loading of our plugins into running applications. We used it, Default Folder X used it too (and still uses it at the moment, although its author uses some APIs from Application Enhancer in the recent versions of Default Folder X, as they are more stable, extendable and compatible than the old method). In order for that library to function, some background application had to be running to watch the launches of other applications (much like what aped does in APE). So every haxies needed to have its own daemon running that would do its thing. So we faced a problem there - first of all, it became much harder to maintain all of these haxies up-to-date with the library changes, if we make any; plus, the more haxies (or other products that used the same library) you had running, the more daemons would get spawned, sitting in your system, doing almost the same job.

So we decided to do a step further and make one universal framework that would take place of the multitude of daemons and provide all the needed functionality in the one place. Such framework would have a set of universal APIs that we (and other developers) can use; we also can update the framework at will in case any modifications or changes to the core functionality is required. This framework is named Application Enhancer. To rephrase, we have moved all of the commonly used code to one place, so it is easier to maintain and re-use.

If any of you is a developer, you can take a look at the list of the functions Application Enhancer provides - the free SDK download is available at http://www.haxies.com/ape/sdk/

:)

Forgot to mention (and pardon me for constantly emphasizing this fact), that Metallifizer doesn't actually touch any of the nib files on disk -- rather, it catches new window creation call and sets up a "metal" (or "no metal") attribute for the window, on-the-fly, in-memory. :)

slava,

so is there any reason that the PrefPane can't be put in ~/Library, rather than /Library?

and if the PrefPane is not global, am i correct that APE will not be active for any user that doesn't have the PrefPane installed?