Generalize TreeItem used in root and children of a TreeView

[JordanMartinez]

I named the two functions, projector and injector. However, I wonder if it might be better to name them valToPath and pathToVal. Seems to be more consistent....

[TomasMikula]

Looks reasonable. I would probably try to look if there is a way to avoid these type castings:

PathItem<T> pathCh = (PathItem<T>) ch;

Seems the only reason why you cast it to PathItem is to be able to call getPath(), but you could equally well call project(getValue()), right?

Another thing is, I'm not sure whether having NormalLiveDirs extend LiveDirs is worth it, compared to just having static factory methods on LiveDirs for the "normal" case. The question is, is

NormalLiveDirs<I>

simpler enough for the user than

LiveDirs<I, Path>

?

[JordanMartinez]

Seems the only reason why you cast it to PathItem is to be able to call getPath(), but you could equally well call project(getValue()), right?

That's smarter and cleaner.

Another thing is, I'm not sure whether having NormalLiveDirs extend LiveDirs is worth it, compared to just having static factory methods on LiveDirs for the "normal" case.

Would a user subclass NormalLiveDirs? That would probably be my only reason against your suggestion of using a static factory method.

Initially, I was trying to better distinguish LiveDirs basic instance from a CheckBoxLiveDirs instance. That might be worth initializing using a static factory class, but I might need to subclass that for JGitFX (not sure yet).

[TomasMikula]

LiveDirs is not meant to be subclassed by the user. Customization by inheritance rarely works well (it doesn't compose well, see e.g. CheckBoxTreeItem 😉).

[JordanMartinez]

But I want it to work well! 😆 Good point!

[JordanMartinez]

Seems the only reason why you cast it to PathItem is to be able to call getPath(), but you could equally well call project(getValue()), right?

I've tried out your idea but come across a couple of places where I will have to cast the TreeItem to a PathItem at some point. Either that, or I'll have to recompute stuff it already knows, e.g. Files.isDirectory(path).

[JordanMartinez]

LiveDirs is not meant to be subclassed by the user. Customization by inheritance rarely works well (it doesn't compose well, see e.g. CheckBoxTreeItem 😉).

I've actually been meaning to ask you about that. Much of what you've written already implements the Directory-watching code I'd need. (I only looked here first because I wasn't familiar with that how to write the necessary code and you'd already done a good job of writing it).

However, in terms of composition, there will be a lot of work I'll have to do if I use your code (specifically, I'm thinking about #2). In some ways, I feel like my need is a bit outside the scope of this project only because TreeView's code has very special requirements with TreeItem-related classes.

So, if I wanted to use part of your code in JGitFX directly (so I wouldn't need to add a dependency somewhere), how do I copy your code into that project's files while still adhering to the BSD License, especially once I start modifying the code according to my needs? Can I even do that?

[TomasMikula]

The license requires you to only redistribute the original copyright and license terms somewhere along the source and binary distributions (alongside whatever additional copyright and license terms you wish to add). But between us, don't worry if you don't 😉

[JordanMartinez]

Sweet! I'll use that as a last-resort. Thanks :-)

Edit: Besides the two issues I've opened up here, there's also the text coloring that needs to be done for each file's state

• not added: red
• newly added: green
• modified: blue
• unchanged: black

[JordanMartinez]

I've updated this with my CheckBoxTreeCell implementation. It works for the most part.

However, the recursive forced check/uncheck downwards doesn't work past the 1st children level. I'm not entirely sure why, but the stateInvalidation listener isn't getting called

[JordanMartinez]

Alright! That was hard, but it works!

[TomasMikula]

Well, I don't think the checkbox stuff belongs to this library. It is OK to provide a demo that shows this stuff is possible, but the core library itself is not concerned with UI stuff. It provides a model of a (changing) directory tree.

[JordanMartinez]

Ok, I can move it to a demo package like the one you have in RichTextFX

[TomasMikula]

That would be nice. But in order to not include the demos in the core library jar, it would first need a little reorganization of the directory tree and the build script (as in RichTextFX).

[JordanMartinez]

Lol... when I said "package", I meant "module." Might help if I used the right terminology... Yes, that's exactly what I had in mind.

[TomasMikula]

👍

[JordanMartinez]

How's that?

[TomasMikula]

Looks good. So can we eliminate those type casts ((PathItem<T>) child)?

I would call getNormalInstance just getInstance.

[JordanMartinez]

I would call getNormalInstance just getInstance.

Smart.

Looks good. So can we eliminate those type casts ((PathItem) child)?

Did you see my previous comment:

I've tried out your idea but come across a couple of places where I will have to cast the TreeItem to a PathItem at some point. Either that, or I'll have to recompute stuff it already knows, e.g. Files.isDirectory(path).

[JordanMartinez]

With the code and examples I've used, shouldn't that be dedicated to the public domain? Otherwise, doesn't your BSD license apply to it?

[TomasMikula]

Strictly speaking, yes. Otherwise, anyone who copies the code from the demo source would be required to carry on the copyright and license of this project. At least that is my understanding of the license. But I will not sue anyone for stealing code of the demos. Feel free to add a header to the demo files saying they are public domain.

[JordanMartinez]

Ok. That should suffice.

[TomasMikula]

👍