@edvin understand. if you want me to incorporate your version that's working prior to the improvement, let me know and I'll pull it

@carlw I think it's best to wait. I don't like to waste your time, but this thing has been very valuable for me in terms of JavaFX knowledge (and very frustrating). My biggest problem these days is that I just can't get enough time to sit down and solve something before something else interrupts me. It's been a couple of weird weeks 🙂

@edvin i know what you mean. i'm wearing out my F6 key in intellij refactoring a bunch of fx code

Haha, our profession is demanding at times. Today I've dealt with 13 different issues (error situations) where 9 involved rolling new code into production in different systems and one involved rewriting an old servlet based app to JavaEE and putting it into production. I'm pretty sure I'll deal with debris from this during the weekend as well. It's nice to get stuff done though, but soon I will take a week off work and focus on TornadoFX to get ajour with everything.

Ouch, just forgot. I also got a report about a bug in my native Windows driver for WebDAV💣, so I need to deal with that as well. What a week 🙂

@edvin I'll be looking at the pool over the weekend, maybe as a general JavaFX blog post. I think that's going to give me the hook for keeping ListCell in sync with Fragment. I know there's a one-to-one correspondence that would make "val itemFragment" attractive, but I can't see how to clean up with that scheme at least from my testing. It seems like a new ListCell with a new ItemFragment can be created on the same item without freeing any other similar Cell/Fragment pairs. The pool idea would proactively clean up the ListCell's itemFragment (unbind, etc) when it pulls from the pool and then re-set the fragment.

@carlw That's an interesting approach, and I'd very much like to see it!

@edvin should only be a few lines of code. i'm going to look at a commons collection class "CircularFifoBuffer" at the start

@edvin ...put 100 item fragments in that and just repeatedly call get() / unbind() / setItem() and maybe make this lazy with an on-demand add

@carlw Let's compare the code needed when we're done and discuss the approaches to see if we can learn something from that!

Man, I wish I could just drop what I'm doing and play with this now 🙂

@edvin I'm thinking of putting up some video showing visualvm with the RAM-heavy version I have in my fork contrasted with what I've ended up with

@edvin Your "val fragment" approach is way better in terms of memory

@carlw Cool. Then we can compare all versions in the end. My main goal is to reduce the work needed by the developer while beeing fair when it comes to resources consumption. It will have some listeners, but will be light weight in respect to Nodes.

OK, gotta get back to debugging this file system issue 🙂 Will be back tonight!

@edvin I found about a 5 fold increase in RAM if I keep a full fragment around with each model component

@carlw Yeah, that will cost with a million items 🙂 hehe

BTW I moved off of that POK3R I was writing about earlier because it interfered with a lot of the IntelliJ keyboard shortcuts. I'm using a tenkeyless Leopold FC750R which has dedicated arrow keys (move line up, move argument left, etc) Also, the POK3R is full programmable, but required too much power from the keyboard port on my KVM. I was running it off of the mouse port, but the mouse port on the KVM doesn't support the keys to switch to another computer.

@carlw Oh, that looks nice! I bet it was nice to get the arrow keys back. I tried a Steel Series keyboard today that was also very comfortable and quiet for a mechanical keyboard. The only issue with those beauties are screen casts. It makes too much noise!

@edvin i have a stack of mushy membrane keyboards for those. actually i have to take my whole screencast set up to another part of the house because i have some noisy parrots so a keyboard isn't a big deal

@edvin they're quiet now, but they get triggered when i start camtasia studio. they must hear the opcodes

@carlw Haha, that's fantastic 😂

My home office is in the basement so I can get some quiet when needed. But right now I have two workers (that damned cabin) living there, so I only have my laptop, sitting in the living room.

@carlw commented on @edvin’s file https://kotlinlang.slack.com/files/U0F3291QE/F2JCF88SF/-.kt: Was searching for this today

@User shared a file: Untitled

@carlw I finally solved it 🙂 The issue I was having was that

cell.updateItem

is not called with a null value for cells that are no longer used, so I was having a hard time unbinding for cells that where previously bound but then suddenly not used. This was easily solved by listening to the indexProperty in the cell, since it will receive index -1 when it's not used. I'll post some code shortly!

@edvin that's great. I'm glad you found at the hook to clean things up

Now I'm going to make one more adjustment to ViewModel and then we should be all set.

@carlw I would also like to try to leverage the editing capabilites of ListView instead of faking it, like we do now (and all the other samples as well)

Latest commit message: "ViewModel bind return value is now optional to support eventually available items". I think I need to create a screencast to explain this one 🙂