it really is...i'm putting them in an envelope and will send them out tomorrow

We need some t-shirts....

if they're ok with you, I'll place the larger order and send them out to anyone with a Cherry MX compatible keyboard

Of course! I'd like to chip in for the cost as well 🙂

@carlw Same here... let us help pay...

I'll look into t-shirts 🙂

you guys get the next one

@jchildress I plan on getting these out to people who are giving talks as freebies

Good idea

it sounds like you an @edvin could use a pocketful to give out after a Q+A session

if anyone wants one (not just for talks), just DM me an address and I'll send them out

@User uploaded a file: and commented: One more shot

@thomasnield I cleaned up the TableViewDirtyTest.kt demo if you want to get some inspiration.

@thomasnield It reveal one weakness with the menu builders though. I have a context menu with conditionally enabled items to rollback/commit per row. They are written like this:

@User uploaded a file: Untitled

I think this would look better:

@User uploaded a file: Untitled

Been thinking about a way to evolve this API without breaking backwards compatibility, but I haven't come up with anything solid yet. Sure it's nice to not having to wrap actions in

setOnAction

but it makes it harder/uglier to do advanced stuff.

@edvin interesting, ill take a look tomorrow morning. I think there is definitely some stuff that needs to be streamlined, and I'm liking this approach and paradigm you are developing with selected contexts being handled.

@thomasnield My first attempt at those dynamic menus was without binding. That was really hard and ugly. That's why I exposed so many properties like

selectedItemDirty

on the edit model. It makes life much easier 🙂

(And I added

tableView.selectedColumn

to get at the selected column.

@edvin if you are working with the menuitems, are you looking for a way to populate a popupmenu?

as currently in the autocompletetextfield (in java) this happens:

@ron I've already found a nice way to do it with observable values, but it just feels clunky because of the way we have structured the menuitem builder. It also breaks with every other builder in the framework.

What I would like to do is to deprecate the ones we have and introduce new ones with a different syntax so we can keep both and not break existing apps.

You like breaking things?

Not really. But I do if I must. Hehe

Here we can keep the old functionality and API, but it might be confusing to keep it around for too long, because the old builders have the action as the op, while the new builders will require the setOnAction call.

What if we leave

menuitem

but create a new called

item

? The builder would be

menu { item ...

. That makes sense to me.