По очереди - есть приложение которое коннектится по вебсокетам к серверу. в UI меняются настройки и показывается статус соединения.

Мне надо чтобы если коннекшн дропался то я обновлял лейбл с другим текстом и показывал кнопку ре-коннекта

ну в принципе когда программа определила разрыв (как это уже не очень важно) то ты меняешь текст твоего label, советую сделать val textConnect = SimpleStringProperty(), label(textConnect) (сделать bind) ну и эту ссылку держать в Контролере, и менять когда нужно, один главный момент менять проперти можно только в потоке Javafx. Ну и добавить кнопку, при удачном конекте убирать, ее создать заранее тоже

Я тебя понял

Буду ковырять

спасибо

Советую посмотреть что такое JavaFx property, ну и на ютубе есть видео от edvin Tornadofx

В идеале, собственно, сам model.WSConnected уже иметь в виде проперти, тогда во вьюхе будет bind и она будет сама реактивно обновляться при обновлении поля в модели.

Раз уж пошла  такая пьянка, может кто-то скажет, почему CorotineScope и Job - это не одно и то же?

Например, под отладчиком видно, что эти интерфейсы реализует один и тот же объект.
И еще они выполняют одну и ту же задачу: образуют дерево structured concurrency, которое можно отменять со всеми потомками.

И еще CorotineScope лазит в свой контекст в поисках Job.
Короче такое ощущение, что это две стороны одной медали, но почему тогда их две сущности, а не одна?

Пьянка шла в другом чате)
А вообще CoroutineScope - это просто штука, в области видимости которой можно запускать новые корутины. Предполагается, что там всегда есть Job в контексте (которая станет родителем).

Ой, и точно в другом, совсем с этими чатами запутался )

Я тогда там лучше спрошу

Там не отвечают что-то.
Да, я понимаю что scope - это штука для области видимости. Точнее для того, чтобы организовать иерархию из запущенных корутин и отменять их всех пачкой при необходимости. Это structured concurrency.

Мне просто кажется, что вроде бы Job занимается примерно тем же самым. И почему тогда выделили отдельную сущность CoroutineScope, если уже есть Job.

Я немного не об этом. Я о том, как это будет выглядеть в коде.
CoroutineScope как минимум нужен, чтобы все билдеры были расширениями scope, а не job.
Представьте, что у вас в коде вместо CoroutineScope везде станет Job. Мне кажется, вылезут места, где это смотрится как-то странно.

Ну пусть будут расширениями Job, какая разница
Все равно в  scope ничего нет кроме контекста, и эти расширения тут же лезут в контекст за Job, который реально всю работу и делает.

Мой вопрос он не потому что как надо делать.
А скорее у меня глаза разбегаются от большого количества разных абстрактных сущностей, которые ввели, и я пытаюсь понять что к чему и зачем.
Потому что continuation, scope, job, context, dispatcher и так далее...
И в этом изобилии начинаешь плавать, хочется разложить все по полочкам.

Да, там есть доки по каждому классу в отдельности. Но из них общая картина пока до конца не сложилась.

Я так понял, пока нормального объяснения , что такое CoroutineScope, нет. Как минимум в доке по корутинам.
Мне кажется, это просто искусственная конструкция, которую не надо рассматривать как самостоятельную сущность.

Как минимум, скоуп существует для централизованной остановки запущенных внутри корутин

У скоупа свой диспетчер (при этом один диспетчер может использоваться в разных скоупах)