Canvas-based JS "Tree" Options

[CSM]

I hope I worked out all the major bugs, but I kinda got distracted from my main project a bit and spent a little time on this project that is, essentially, a visual Tree structure created via Canvas-drawn objects. A "TreeMenu" for for short. This can allow for displaying such things as simple XML, or just a plain old menu. The API should be flexible enough to do a wide range of things.

Since not everyone can download and play with it right away, I took a screenshot (click to see the larger [uncropped] version):

This was taken using a test Widget aimed at my "My Widgets" folder.

What this class does:

• Provides an easy way to display and use tree-like structures via some XML-like properties.
• Provides an easy way to change how it is displayed and looks.

What this class doesn't do:

• Respond well to changes. If you mess with a property that isn't intended to be changed directly, you could be asking for trouble (but that doesn't mean it won't work, if done properly).
• Set up top level nodes automatically.

What I mean by this: the code is easy to use, and you can set such properties as next, previous, whatever, but once they are included in a tree it's best not to mess with them directly. Please try to use the proper append/insert/remove methods provided. This code also doesn't set up the vOffset automatically for top level nodes. This means that if you assign a "next" item to the top level, in this case: My Widgets, you have to set the vOffset yourself. However, for lower levels, append/insert will take care of that for you.

Also, I provide a function called a "renderer" which can be replaced with a custom function to draw each node. Because I pass the CanvasContext to the renderer, it is possible to use one renderer for multiple nodes. A default renderer is provided as shown in the image, if you wish to make your own, you may look at my source for details. The renderer does not control the offset of the Text from the left edge of the nodes, that has to be changed by hand. Sorry.

Some things you might want:
Download Link
JSDoc

Important:
This code isn't entirely gratis, I do ask two simple things:

• You make it obvious I wrote this code (if you use it) by attributing it to me, leaving the @author intact, etc.
  • Notifying me you're going to use this in a project is purely optional, but I like such notices, I've only ever gotten one.
• If you find a bug or have a fix, please tell me and I will attempt to updated this code as soon as time/scheduling permits.

Thanks and enjoy this wonderful class and code. I think it could be very useful. Lets hope I'm not wrong, and that it works outside my test-cases. Have a good day!

[g6auc]

If you find a bug or have a fix, please tell me and I will attempt to update this code as soon as time/scheduling permits.

The test Widget works for me on the Macintosh with a very big Widgets folder which fills the screen height many times over. I had to drag the whole lot up to see it all.

I put the Category.js file through JSLint. After appeasing JSLint's style comments, I still had three lines to which it objected and which I did not see the need for.

CODE

    this.hOffset;
    this.vOffset;
    this.size;

I commented them out without seeing any difference.

The test Widget (correctly) displays files like ".DS_Store", although it is usual not to display such hidden files on the Macintosh/Unix.

[CSM]

The test Widget works for me on the Macintosh with a very big Widgets folder which fills the screen height many times over. I had to drag the whole lot up to see it all.

Yes, it is quite large, though one can change the sizes internally (by hand) to achieve smaller "blocks". I believe that everything is based on the font size, so the easiest way is to reduce the overall size is to reduce font size used in the title Text object.

I put the Category.js file through JSLint. After appeasing JSLint's style comments, I still had three lines to which it objected and which I did not see the need for.

CODE

    this.hOffset;
    this.vOffset;
    this.size;

I commented them out without seeing any difference.

I am not quite sure I need them either, however, I put them there to make JSDoc recognize them as an attribute of the object. If I did not visibly put them there, I do not know if JSDoc would know enough to display them (in the output HTML). As for style ... I used a lot of "one line if statements" for no real apparent reason, even though under normal circumstances I abhor them. I'm sure there were other oddities given that I have a few "underhanded" things I rely on to make sure all nodes are updated on changes.

The test Widget (correctly) displays files like ".DS_Store", although it is usual not to display such hidden files on the Macintosh/Unix.

Yeah, well, that is to be expected. The test Widget isn't meant to be a real filebrowser, just show one possible option for usage of the Category class. If one wished to make it ignore folders starting with "." (hidden folders on Unix/Linux) one could modify the code in main.js to do so easily.

Thanks for testing it. I really appreciate it.

[CSM]

Yes, it is quite large, though one can change the sizes internally (by hand) to achieve smaller "blocks". I believe that everything is based on the font size, so the easiest way is to reduce the overall size is to reduce font size used in the title Text object.

Well, I just tried it, and it doesn't work as nicely as I said it does. In fact, it works downright terribly. So I think I'll submit an update with an easier way to have differently sized elements.

[CSM]

Fixed. I uploaded a new script. All download links are the same. Updated the JSDoc as well. To avoid possible complications and other stuff, the size has to be sent/set when the Category is created. Hope that makes it easier to resize them.

[g6auc]

To avoid possible complications and other stuff, the size has to be sent/set when the Category is created. Hope that makes it easier to resize them.

Working fine - thanks.

[CSM]

I updated the Widget again. I made a mistake. When "setAllowMultipleOpenNodes(true);" was enabled, closing or opening nodes with one or more nodes following it (at any level) would have noticed some overlap from currently open sub-menus. This is due to the vOffset "chain" reseting the offsets without regard to open submenus. This is now fixed. All major issues should now be gone.

As was suggested to me, one might want to use this to create a "lazy menu" wherein some nodes have children, but they aren't currently "loaded" or physically there. This would be useful in situations where creating the whole "tree" at once might/could cause an out of memory error from Konfabulator.* At first, it seems there is no support for this. However, this is where the renderer comes in handy. The Category only knows and deals with physical quantities, but the renderer it employs is not limited in such a way. It can choose to use or ignore any data sent to it. So if that particular node has children (just not loaded yet), one could make their own renderer to draw it to look as if it did. Plus, if you're already changing the renderer to get your own look, it's not too much extra work.

* Those wishing to test this directly, just change the path in the test Widget's main.js to point to the root of your computer's main drive. It will take a long time to load, then fail spectacularly, leaving some incompletely loaded nodes which might generate too-much-recursion errors.