OSNews

Porting OpenTracker is far more complicated, actually, than porting a display driver. Why is that?
There are a few reasons, actually. For one thing, BeOS has a threading/application design/implementation model that, AFAIK, has only Syllable and its parent with a matching or almost identical model. If you take out the B out of the names of the classes OpenTracker uses from the Interface Kit and other things, it would likely largely compile.

However, above and beyond that, is that (though this isn't as big of an item as it could be) it uses some undocumented BeOS API's that are not officially supported, and may change. At this point, it's likely that perhaps only yellowTab would change them, if you consider Zeta the heir apparent to BeOS 5.03. Then again, Zeta is likely in the future to replace more portions of its codebase and libraries with those developed for Haiku.

And the last meaningful thing: OpenTracker is a snarled piece of code for anything that was part of OpenTracker when it was released. Anything that started out in OpenTracker itself (that is, the vector icons did NOT start out in OpenTracker, and use a pre-existing library) is cyclically dependent on itself, to where less than 1% of the original OpenTracker code can be reused without a lot of hacking at the source. Supposedly, Tracker was published as OSS under the thoughts and hopes the code would be reused in other BeOS software. The reality, because of the structure, is that the only reuse of the code has been in branches of a full OpenTracker itself, because almost all of the code is completely spaghettified, and it isn't worth the bother to try to reuse it.

OpenTracker should be completely replaced with something that does at least as much as OpenTracker currently does, but written with a fresh design with no code from the old Tracker, with using notes about the file handling in terms of copying files with all the attributes, etc. that make OpenTracker distinct from most other file managers. This will, of course, likely cause some breakage of applications that use BFilePanel, the file selection dialog that's used as part of the standard BeOS API: this is exported from the OpenTracker executable, such that an application that uses a it effectively brings in almost all of the code of OpenTracker into its address space, just to allow a common file dialog for opening and saving files. Perhaps this is something that will happen with Haiku R2, which may very likely have major API changes anyway, besides likely using a more recent version of gcc where the C++ ABI is different from that of gcc 2.9x.