[haiku-development] Re: University Dissertation - Tracker replacement/improvements

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 12 Nov 2013 20:45:42 +0100

On 11/12/2013 07:17 PM, Julian Harnath wrote:
Joshua Rice <rice43@xxxxxxxxxxxxxx> schrieb:
Obviously nothing is set in stone ATM, I just wanted to see what
Haiku devs thought of this idea. Criticisms and comments are welcome.

First of all, I wonder whether a full-on rewrite of Tracker is
necessary. I heard some comments here and there that it would be
necessary at some point given its current code base, but those were
just little comments on the side and I have never dived into its source
code myself to see. Maybe someone experienced with working on it could
mention whether a full on rewrite is necessary in their opinion (as
opposed to an evolutionary development with the current code)?

That the Tracker code needs some refactoring at least is rather obvious just from looking at the source file size. The 10k LoC PoseView.cpp is way beyond what is reasonable and ContainerWindow.cpp is also quite big.

That aside, a main design issue I see is that everything is too file system object focused. E.g. when implementing the virtual directory feature I had to resort to creating temporary files as a representation of the virtual subdirectories, since a file system object is needed to show them in a window.

Adding support for browsing the content of a zip file (like Window's Explorer) would be even more tricky (well, or end up extracting the zip file in a temporary directory). A feature like this would ideally be integrated smoothly with the rest of the system. So, if something like this is desirable, the scope of the redesign will be even wider.

The current add-on interface (headers/os/add-ons/tracker/TrackerAddOn.h) is extremely primitive. Pre-filtering which add-ons are applicable for a selection is the least that should happen. Multiple actions per add-on should be possible and it probably makes sense to move the menu items up one level in the context menu.

Add-ons should also be able to decorate the displayed items -- e.g. by adding icon overlays or custom columns. And if we want to go all the way, they should also be able to customize/replace the complete window. E.g. a mail folder add-on could display the mail files organized by threads, add a mail specific tool bar, etc.

If these kind of things shall be possible, a clean design with good interfaces will be needed. It may be possible to rework the current code base into such a shape, but I guess it will be simpler to start from the scratch and just see which of the old code can be adopted when fleshing out the implementation.

CU, Ingo


Other related posts: