Пример архитектуры GUI-приложения

У wxpython хороший гайд. Делаешь 2-3 thread: один main уходит в loop, он порождает второй тред GUI, слушает его IPC через queue и или обрабатывает сам и шлёт GUI треду обратно команды, или передаёт отдельному треду вычислений или даже другому процессу. Вот как бы минимально, как это строится. В wx это совсем просто, все классы и методы свои, но можно и тупо в один тред, тогда гуй будет лечится при выполнении задач программы. Как в джаве не знаю.

Делаешь 2-3 thread

И новичок имеет гарантированный головняк с многопоточностью.

Занятно, да. Но я интересовался не с точки зрения потоков исполнения, а с точки зрения организации кода и внутренней логики. Какой паттерн вменить, как организовать код gui-приложения «правильно»?

с точки зрения организации кода и внутренней логики

один main уходит в loop, он порождает второй тред GUI, слушает его IPC через queue и или обрабатывает сам и шлёт GUI треду обратно команды, или передаёт отдельному треду вычислений или даже другому процессу. Вот как бы минимально, как это строится

))

Есть ли у кого статья на тему архитектуры десктопных GUI-приложений?

https://martinfowler.com/eaaDev/uiArchs.html

Реактивное программирование. Когда где то тык и как доминошка вжжжжжуууух пробежались зависимости, куда то тык и опять трррррр. Гугли. Обычно как события,эвенты их слушают на них реагируют, а тут явная привязка при изменении а меняется б в ответ на это меняется с зависимое от б. Был даже где то юморной доклад по этому поводу. Это концептуальный подход.

Склоняюсь к связке: View-Contoller + Commands + Services + Models + DAO.

Java и Swing/JavaFX

Это все неродное. Выглядит как говно. Надо на GTK/QT писать

В wx это совсем просто, все классы и методы свои

Какой паттерн вменить

Джависта видно сразу)

но можно и тупо в один тред, тогда гуй будет лечится при выполнении задач программы

или не будет, если все действия будут описаны как асинхронные функции.

Как в джаве не знаю.

В джаве, а конкретнее в свинге создаётся отдельный воркер в виде наследования абстрактного класса (или сразу анонимный класс из абстрактного). Этот воркер отправляется в пул тредов, когда тебе нужно не фризить гуй работой с данными.

В свинге наследуй все базовые компоненты при реализации своих панелей и прочих виджетов. Я с дуру начал композицией заниматься и рябь уже в глазах от такого кода. Буду переделывать.

Вообще, GUI должен пилиться в подмножестве HTML+CSS, но идиоты пытаются переизобрести гуй декларативно в коде ЯП (даже сахарок под это запиливают). Выглядит это всё ущербно и закостенело. И конечно же не взлетает, но старые идиоты идут на повышение или дауншифтят в поисках веры… Приходят новые олимпиадники и всё повторяется.

куда то тык и опять трррррр. Гугли

Послал так послал.

:D Ну не «тык и опять трррррр» гуглить, а «реактивное программирование» =)

А отлаживать подобное безобразие ты потом на chatgpt скинешь, удалившись на смузи в комнату отдыха?

эвенты их слушают на них реагируют, а тут явная привязка при изменении а меняется б в ответ на это меняется с зависимое от б.

Например, когда представление — это функция от состояния (view = f(state)), состояние — это свертка потока событий с начальным состоянием (state = events.reduce(g, initial-state)), а поток событий генерируется представлением (events = h(view)). Ka is a wheel, all it knows is how to roll.

Примерно как тут описано.

Такая система имеет ровно 1 состояние в момент времени, отлаживать ты будешь эвенты которые хз прилетели или нет, в каком порядке и в каких таймингах. А так всё надо отлаживать. Но я это я ещё не применял я только игрался с концепцией :3 Пердолинг в принципе вероятен где больше трёх кнопок =)

Такая система имеет ровно 1 состояние в момент времени

И если сделано по-человечески, то поток информации идет строго в одну сторону. Добавил в одном месте print, и вся история как на ладони — кто, что, куда, кого и как.

Ну да, если в лоб то так f=a(b(c(d(e(event))))) 1 событие == 1 состояние всей системы от event до f. В таком виде конечно выгдядит по уродски, зато наглядно. Обычно оно типа так

a = 1
b = 2
c = 3
d = 4
e = 5
x = 6
depend(a,b,func_a)
depend(b,c,func_b)
depend(c,x,func_c)

Тоже тупо, но ближе к рельностиь поменял значнение a дальше всё само по дереву зависимостей пробежалось. Жопа начинается правда когда в обратную сторону должно идти или с середины, первое ещё ладно взаимная зависимость, а вот когда из серединки то что-то пошло не так в идеале цепочка должна отработать ровно вся и только та которая нужна, а не как любят всё везде со всем связано. Ой, мне ещё самому вникать, но я кажется проникся этим, красиво, это я всё про концепт ,а не реальность. Но всё же

В основе цикол апдейтов. Либо «все код». Либо разметка с кодом за ней, либо разметка с прокладками из абстракций. Либо жизненый цикл приложения делается весь руками («самописный фреймворк»), либо есть в прокладках («абстрагирован» в кем-то написанный фреймворк) и выставлены «хуки»/«события»/«реактивные свойства», к которым ты цепляешь свои обработчики/«команды»/«подписки»/«обсерверы» и т.д. «Норм» или не «норм» зависит от задачи. В хеллуворлде из примеров к огромной библиотеке например «ехал mvc через mvc, видит mvc в mvc, сунул mvc mvc в mvc mvc mvc mvc» ни разу не норм, т.к. не наглядно — и вообще скрывает от людей голую, жо... жестокую правду. Какое на самом деле говно все эти «паттерны» и «фреймворки» внутри.

Делаешь 2-3 thread

И новичок имеет гарантированный головняк с многопоточностью.

А если всё в одном потоке, то головняк поимеет юзер: гуй будет лагать и тормозить. Новичок спрашивал «как делать НОРМ». Два потока – обязательно, и в Swing ЕМНИП испокон веков был вполне толковый туториал, где говорилось в т.ч. и про это. ТС-у бы его почитать, прежде чем на форум с вопросами лезть. Три потока – хз, от задачи зависит. Если воркеры долгоиграющие, то там целый пул нужен.

А если всё в одном потоке, то головняк поимеет юзер: гуй будет лагать и тормозить.

Сильно зависит от задач, которые приложение решает. И тут как с преждевременной оптимизацией – не надо усложнять раньше времени. А потом можно и очередь заданий прикрутить.

Сильно зависит от задач, которые приложение решает.

Однопоток не будет тормозить только если оно вообще не решает никаких задач. Кроме собственно отрисовки гуя.

Тоже верно.

Видимо, также.

GUI должен пилиться в подмножестве HTML+CSS

Еще в latex предложи гуй делать.

VCL навсегда! Ну или любой другой ООП набор виджетов. Не надо париттся ни по какой вёрстке.

Кто тебе не даёт в HTML виджетов наделать, в том числе нативных под каждую ОСь (или даже взять готовые из SDK фреймворка)? Там даже из коробки они уже есть еще с web 1.0

Не надо париттся ни по какой вёрстке.

Ты в любом случае начнёшь париться в вёрстке, если ты конечно не очередной калькулятор пилишь. В том числе начнёшь репу чесать, когда в ООП тебе нужно будет изобразить responsive design. В HTML+CSS это делается проще и воспринимается легче. В ООП твой код через месяц ты сам не проссышь с первого захода.

А когда тебе потребуется кастомные виджеты запилить? Я уже не говорю о запиливании кастомного взаимодейтсвия между несколькими виджетами.

И надеюсь ты понимаешь, что я не про браузер в ГУЙ запихать, а об кастомном фреймворке по типу свинга, но только на базе подможножества современного HTML+CSS.

С HTML ты через неделю начнёшь париться во вложенных div и хитросплетениях стилей. А если захочешь кнопочки со скруглениями, облом, их не завезли в SDK.

Задаёшь свои стиль переопределяющий базовый и будут у тебя кнопочки со скруглениями.

С HTML ты через неделю начнёшь париться во вложенных div и хитросплетениях стилей

Ну, а в ООП ты и не будешь париться, потому что не сможешь запилить в разумные сроки кастомные компоненты. А если и запилишь убив на это кучу времени, то париться будешь не меньше, если не больше.

А еще все эти свинги и их сегодняшние последователи просто не вкуривают, что одно и тоже приложение может запускаться на 5, 14, 27 и 50 дюймовых дисплеях. С HTML+CSS это еще можно порешать, а со свингами ты просто опять убьёшь кучу времени/бабок, чтобы поддерживать все эти дисплеи. Ну, или опять же сделаешь всё через задницу - отказавшись от такой поддержки.

начал композицией заниматься

О, месье знает толк в сексуальных извращениях.

То есть попросту ты не осилил документацию к свингу и решил, что JavaFX спасёт от рукожопия.

Куда от вас деваться - осиливших документацию. Только все приложухи в веб убежали. А на очередной гуй от таких осиливших документацию посмотришь и рука-к-лицо.

JavaFX спасёт от рукожопия

Еще одно не взлетевшее поделие макак-олимпиадников. Хотя там идиоты начали что-то подозревать, не спорю.

я не про браузер в ГУЙ запихать

Как будто что-то плохое.

а об кастомном фреймворке по типу свинга, но только на базе подможножества современного HTML+CSS

Так это ведь и есть практически (недо)реализация (недо)браузера. Если перефразировать классика — каждая гуи программа содержит доморощенную неспецифицированную, бажную и тормозную реализацию половины браузера.

Чего бы хотелось на самом деле, так это стандартной минимальной реализации браузера, а лучше модульной. Попилить условный хромиум, как б-г черепаху на модули, как девятую жабу попилили. Глядишь, и электрон бы меньше тормозить и жрать стал.

Для Swing есть хорошая книга: https://www.oreilly.com/library/view/java-swing-2nd/0596004087/

В остальном, поддержу foror: Swing и прочие - это боль и страдания. Хочешь GUI - юзай HTML + CSS, у него хотя бы с HiDPI / MixedDPI быстро решаются проблемы, благодаря флагманам браузеростроения. Движки браузеров ушли далеко вперед по удобству от Swing / JavaFX.

Только latex спасет в переменном DPI!

Зачастую фреймворки диктуют архитектуру приложения своей архитектурой. Я бы советовал внимательно их изучить, возможно вопрос отпадёт.

Электрон не тормозит и не жрет. Тормозит и жрет то, что в него запихивают говнокодеры, уповающие на HTML/CSS.

Как это не жрёт? В вашей айтишечке всё тормозит, жрёт и вдобавок течёт, а критические нульдеи каждую неделю. А электрон вдруг особенный вышел? Тут только огнемёт от Илония поможет.

На дельфи всё было правильно с начала. Кнопку на форму кинул - она создала свойство в классе формы. Двойной щелчок - у кнопки в свойстве «нажато» появился метод, который тоже в класс формы добавился. Чего вам ещё надо, собаки? ©

Так там старая гвардия по уму всё делала. Всё нормально генерилось. А щас гуи генераторы - без слёз не взглянешь. Аусторс, индусы, все дела…

А тут с идеи обратно слез в эклипс, но ничего не поменялось и также чертыхаюсь об эти индуские поделки смузиприхлебателей.

В последнем Netbeans красивую тему для Swing сделали.

Есть где скриншоты глянуть? Я Flatlaf с закосом под идею юзаю.

https://www.formdev.com/flatlaf/

Прекрасно понимаю почему возник этот вопрос, но к сожалению несколько поздно: десктоп на Java уже практически не делают. А то что делают - делают на RCP, вроде такого.

Там все с одной стороны сложно, с другой - вопрос архитектуры не возникает, поскольку каждый чих завязан на ту или иную функцию RCP.

Чистый Swing хоть и декларируется как:

is rooted in the model-view-controller ( MVC) design

но когда 99% логики реализуется через цепочку Listener или Observer - от MVC остается одно название.

JavaFX - это уже ближе к WPF, отдельный язык разметки, похожий на XAML.

Но надо иметь ввиду что JavaFX так и остался в непонятном статусе, в JDK его нет, отдельный большой проект , который еще надо поставить у клиента. С нативными библиотеками и сопутствующими проблемами.

Вообщем если интересен JavaFX, то самое лучшее это попробовать поискать более-менее большие открытые проекты и использовать их внутреннюю структуру как образец.

но когда 99% логики реализуется через цепочку Listener или Observer - от MVC остается одно название.

Ловите наркомана! Observer это и есть классика MVC тащемта.

Зы: последний раз делал гуй на жабе в 2008, у них прям на сайте очешуительная документация по swing.

Норм на свинге гуй делать, если не хочешь обмазываться электронщиной или того хуже на жабаскриптиках пилить гуй. Оно жрёт в два раза меньше жабаэфыкс и с новыми темами от флатлаф даже выглядит современно.

Конечно не разгуляешься с качественным гуем, но кроссплатформу по десктопам можно сделать.