contextmenu {
      item("Copy text to clipboard") {
          setOnAction {
             val clipboard = Clipboard.getSystemClipboard()
             clipboard.putString(msg.text)
             }
        }
}

im using this

I'd just wrap in an hbox. the hbox might contain a single item like the main timeline or two items with the second one being context-specific (thread, files, etc)

and changing width of main object when second is visible?

start with a preferred width and let the layout manager handle the second items visibility

splitpane is another option

minwidth can be set to avoid one side collapsing

@chickenfresh this is an example I wrote about earlier of the journaling or deferred action to keep the app performant. I use this to save off a bunch of time-consuming operations that would make a TableView tough to use. I've left off logic that you might use to simplify the actions, say consolidating three updates on the same record in a row

@amanda.hinchman-dominguez AOP candidate in the above program. A JournalAspect could be added to the Controller add, delete, and update functions which would add to the pendingActions list. Would be useful if there were more Controllers and records types other than SalesRecord to consistently record journaled actions

@carlw I need to switch to computer real quick, but from what I skimmed this is good potential - I never take advantage of enum classes as I should

I'm writing up the blog post

Here's the write up: https://courses.bekwam.net/public_tutorials/bkcourse_tornadofx_journalingapp.html

@chickenfresh that might work well for an offline mode

You mean caching data so it can be used in offline?

caching operations

Like pulling them into queue and processing when online?

yep. maybe an offsetting queue if you need to rollback

Good. I was thinking about something related

Whole idea was about optimizing requests to the backend

there's room for consolidating and simplifying the operations in my example

For example I have

like

button in my app, which is capable for both like and dislike functions If I press the button 100 times in a few second (not sure I could but for example), and it results with no difference between state on start and on finish, then, instead of sending 100 requests I’d deal only with result. I know, that highload projects are using this, didn’t realize how yet (on backend or front end), but may be managing queue isn’t hard to implement?

i think a reduction of operations could be used before a network call is made

for the like, they probably do issue an immediate request though even if they're liking/liking over and over again

I implemented this in a few places. one was a graphical tool that let the user work creatively with a work in progress before saving. the work unit was a manipulated picture

Just dunno how to capture the queue if there are, for example, 10> requests per second

also, with drag and drop, another requirement I had was to organize several lists

So I could stack em and send as query

and the save operation came after a bunch of list drags

you could also work with the backend for a more optimal backend change.

in my example, this would be a single payload of all the changes and a returned payload of all the statuses

I know how to optimize it on backend, but I don’t know how to collect requests to send as one