in smartresize, columnwidth: tablecolumn accepts double and contendwidth accepts number. Number has the preference, right?

@tieskedh If we accept Number, we can just convert to Double before we call the JavaFX API. We try to do this everywhere.

exactly what i suspected

It's very convenient to just pass an Integer if you don't care about/need decimals 🙂

@carlw I found a solution to https://github.com/edvin/tornadofx/issues/443 - give it a try when you have time!

I posted some test code as well.

Man, it feels good to work on the framework again 🙂

I'm going to workout the adapters later. Gives me to much frustration. focusing on refactoring other things now.

OK 🙂

I am back and will try to have a further look at the drawer problem. therefore I installed Windows in a VM and it first did not work but after an update everything is back to normal. On MacOS I still have the problem that the drawer behave like Toggle Buttons. I however still have to check if tornadofx really has been updated by gradle. I can not see which version is currently running and if gradle automatically updates

I used ./gradlew build --refresh-dependencies and it downloaded https://oss.sonatype.org/content/repositories/snapshots/no/tornado/tornadofx/1.7.11-SNAPSHOT/tornadofx-1.7.11-20170910.160123-19.jar Is this the latest version?

Still having the same problem

Okay, I found out something. When I start it with intellij I have the problem. When I run from the command line with ./gradlew run it seems to work. Maybe there is some other cache in intellij idea?

Okay, it works now. Your fix from the morning seem to have fixed it. From then intellij idea did not correctly update the dependencies (the tornadofx snapshot) and I only have had the broken project under macOS and Windows. Now I used ./gradlew build --refresh-dependencies in the console and started with run and the project worked again. The trap was however that starting it in IDEA did not fix the project and executing gradle task “./gradlew build --refresh-dependencies” under intellij did not fix it either. The solution was to right click the gradle project in idea and execute refresh dependencies. Now it also works in IDEA. So my advice when working with the snapshot with gradle in idea. Refresh the dependencies when you know that the snapshot updates. It does not seem to work automatically.

So it was indeed a problem with the Snapshot in the morning but it looks like you fixed it but I was not able to update the recent snapshot

One thing that I however recognized since today is, that I can rightclick on the drawer and have an option “Multiselect” and “Floating Drawer”. I think the problem was, that multiselect was preset . Is this new functionality and can I disable this popup?

@thomasnield again about:

asSequence().filter(predicate).toList().asSequence().foreach{}

I get the idea, but I believe kotlin does not use sequences in parallel Having said that, I think there is no need for a sequence. This means that the same result can be reached by using

filter(predicate).foreach{}

Am I right?

ah, all your code is written for multithreading... but nothing is multithreaded 😜

haha, up to kobalt 😉

@tieskedh if you are referring to the

TableView

extension functions still.... have you considered the

ConcurrentModficiationException

? Again, that has nothing to do with concurrency per se, but rather you are iterating the list while modifying it.

@User uploaded a file: Untitled

That last

asSequence()

in the line snippit you posted is extraneous though and not necessary.

But that

toList()

is critical to prevent the

ConcurrentModificationException

@thomasnield my question is: is

asSequence.filter.tolist

not the same as

.filter

without

asSequence

and

.tolist

so

mutableList.filter(it.length < 5).forEach(mutableList.remove(it)

@tieskedh well now you are just making me look silly.

But yes that would be better for this particular case, you're right. If you have multiple operations then it would be better to use a Sequence to prevent creating an intermediary List at each stage. But for a single-step operation like this one, this is actually leaner

I do have a habit of switching to Sequences pre-emptively

Just because of my habits with Rx

Which is not always good.

haha, there do you have a point. I am waisting much performance at long chains, because I most of the time don't change to sequences... We keep each other in balance;-)