alkresin Oct 24 2018 at 15:42

GUI-фреймворки — на поток

5 min

18K

Open source *Programming *Interfaces *C *Go *

+22

Comments 60

UFO just landed and posted this here

alkresin Oct 24 2018 at 16:12

Думаю, что скорость выполнения здесь не критична. Создание GUI-объектов — это ведь не сложный вычислительный процесс в длинном цикле. В реальной программе замедление должно быть практически незаметно.

UFO just landed and posted this here

alkresin Oct 24 2018 at 16:32

Не очень понял про таблицу настроек, ну а прогресс бар — там же не секундные задержки будут.
Для повышения скорости предусмотрены функции BeginPacket(), EndPacket(), которые позволяют отправлять группу сообщений — для создания окна, например, со всеми его виджетами и их свойствами, как один пакет. Кроме того, некоторые обработчики событий можно передать серверу — я об этом писал.

RPG18 Oct 24 2018 at 16:40

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

alkresin Oct 24 2018 at 16:46

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

RPG18 Oct 24 2018 at 17:14

Я как фрондендер ожидаю, что все это на себя возьмет фреймворк, как например Qt

alkresin Oct 24 2018 at 19:54

И здесь вы можете просто передать двумерный массив строк и GuiServer все возьмет на себя. Для этого есть функция BrwSetArray().

RPG18 Oct 24 2018 at 22:46

Вообще не вариант. В ui фреймворке должен быть model/view, что бы view подтягивала данные по мере необходимости, а не загружать всё.

alkresin Oct 25 2018 at 09:14

Модели могут быть разные, правила устанавливаем мы сами. Но я подумаю над вашим предложением.
Реализация подобной таблицы (browse) в HwGUI достаточно гибка, модели поведения можно создавать самые разные. По умолчанию два варианта — переданный массив данных или dbf файл, локальный или через соответствующую СУБД, Ads или LetoDB. Но подставив другие обработчики событий, можно реализовать и что-то еще для своих нужд. Эти другие предопределенные варианты можно будет задать в GuiServer, а из программы выбирать нужный.

Shtucer Oct 24 2018 at 20:23

А что с Drag'n'Drop?

alkresin Oct 24 2018 at 20:32

Drag'n'Drop я не делал даже в самом HwGUI, если не считать сплиттеры.
В любом случае обрабатываться это дело должно GuiServer'ом, а пользовательской программе — передаваться начальное и конечное состояние.

RPG18 Oct 24 2018 at 16:03

А где примеры использования на Go?

alkresin Oct 24 2018 at 16:15

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

Shtucer Oct 24 2018 at 16:09

В линуксе это получаются иксы над иксами внутри иксов?

alkresin Oct 24 2018 at 16:16

Почему? К концепции X сервер/X клиент это отношения не имеет.

UFO just landed and posted this here

alkresin Oct 24 2018 at 16:39

… к которому подключаются еще клиенты.

один клиент, я об этом писал. Ну и, потом, мой GuiServer — это не иксы, так что выражение «иксы над иксами» здесь некорректно.

Shtucer Oct 24 2018 at 16:42

Если описать концепцию X-сервера в такой же "вкрации", как и ваша, разница будет нулевая.
Да, ну и чтобы два раза не вставать: если уж у вас "один сервер — один клиент", то чем объясняется выбор tcp/ip стека?

alkresin Oct 24 2018 at 16:49

Для возможности использования клиента и сервера на разных компьютерах.

Shtucer Oct 24 2018 at 17:11

Тогда я запутался окончательно. Можете привести терминологию в статье к общему знаменателю, потому что не понятно какова роль GuiServer, клиента, кто такая "основная программа работает на Linux сервере". Где кто что отрисовывает?
Диаграммку набросайте, пожалуйста. Пока, как я это понял, всё выглядит как wxWidgets, но с клиент-серверной архитектурой.

alkresin Oct 24 2018 at 20:04

Мне кажется, в статье это достаточно ясно изложено. Сервер здесь — это мой GuiServer, который предоставляет интерфейс, клиент — ваша программа на Go, C,…
Во фразе «основная программа работает на Linux сервере» имеется ввиду сервер вашей локальной сети.

Shtucer Oct 24 2018 at 20:18

Даже в этом вашем комментарии два "сервера". Вот что я понял. Старый добрый подход: молотилка данных отдельно, морда — отдельно. Это очень старый подход, вот примеры: mpd и множество его фронтэндов, из последнего — neovim и его tui и gui. Только у вас это с ног на голову. Правильно я понимаю?

alkresin Oct 24 2018 at 20:28

молотилка данных отдельно, морда — отдельно

Примерно так. Только вот насчет «с ног на голову» я не соглашусь.

Shtucer Oct 24 2018 at 20:30

Ну, возможно, и не с ног на голову. В конце концов платформа с вашим подходом тоже уже существует.

alkresin Oct 24 2018 at 20:38

А что, neovim тоже использует отдельный процесс для интерфейса?
Я его даже не видел, пользуюсь старым добрым vim.

Shtucer Oct 24 2018 at 20:45

Там как-то вот так:

Embeddable

GUIs and other applications can nvim --embed to discover the msgpack API dynamically.

И пачка проектов про это:
https://github.com/neovim/neovim/wiki/Related-projects#gui

ZyXI Oct 25 2018 at 03:28

TUI — нет. Остальные UI — да. И, кстати, может общаться и через сокеты, и через обычные pipe. Только в случае с Neovim ожидается, что GUI запустит neovim (или, теоретически, присоединится к уже запущенному), а не наоборот.

saipr Oct 24 2018 at 16:29

Этот сервер после запуска будет молча слушать определенный порт, и, получив соединение от моей программы на Golang, будет в ответ на ее запросы создавать окошки, виджеты, производить с ними манипуляции и осуществлять обратную связь при появлении каких-то событий от виджетов — словом, реализовывать для нее GUI.

А почему бы не написать такой сервер на tcl/tk?

alkresin Oct 24 2018 at 16:33

Написать можно на чем угодно. Мне кажется, я обосновал в статье свой выбор.

UFO just landed and posted this here

Shtucer Oct 24 2018 at 19:09

По-настоящему нативным для Linux решением было бы детектить текущее окружение\установленные библиотеки и на основе этого включать тот фреймворк, который для данной системы нативный.

Не могу себе представить такое. Мартышкин труд какой-то.

RPG18 Oct 24 2018 at 19:32

fbreader мог использовать gtk и qt, для отрисовки.

Shtucer Oct 24 2018 at 19:54

Gtk2 или Gtk3, Qt4 или Qt5? Даже в рамках двух фреймворков уже 4 варианта.
Судя по вот таким штукам в Makefile fbreader, он это "детектил" на этапе сборки:

ifeq "$(UI_TYPE)" "qt"
  QTSUBDIRS = src/qt/time src/qt/dialogs src/qt/view src/qt/image src/qt/util src/qt/filesystem src/qt/library src/unix/message src/qt/application-$(TARGET_ARCH)
endif

ifeq "$(UI_TYPE)" "qt4"
  QTSUBDIRS = src/qt4/time src/qt4/dialogs src/qt4/view src/qt4/image src/qt4/util src/qt4/filesystem src/qt4/library src/unix/message src/qt4/application
endif

ifeq "$(UI_TYPE)" "gtk"
  GTKSUBDIRS = src/gtk/time src/gtk/dialogs src/gtk/optionView src/gtk/image src/gtk/util src/gtk/filesystem src/gtk/library src/gtk/view src/unix/message src/gtk/application-$(TARGET_ARCH) src/gtk/pixbuf
endif

RPG18 Oct 24 2018 at 22:43

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

alkresin Oct 24 2018 at 19:58

У меня GTK2. А переключаться между GTK и QT — это, по-моему, слишком.

UFO just landed and posted this here

alkresin Oct 24 2018 at 21:16

Ну хотя бы с тем, что мой фреймворк (HwGUI), на котором реализован GuiServer, точнее, его Linux-версия, появился еще в 2005 году.
В Gnome он выглядит, кстати, вполне нормально. В KDE — не пробовал.

UFO just landed and posted this here

alkresin Oct 24 2018 at 21:24

В 2005 он появился, но модифицировался и продолжает модифицироваться до сих пор. Если вдруг появится реальная необходимость, перейду на gtk3 или 4. Пока все в порядке и с gtk2.

pfalcon Oct 24 2018 at 21:58

Идея «хороша», но не нова. www.gtk-server.org. Вы им пользуетесь? Вот то-то же, и я тоже. Но я думаю проблема в том, что народ о таком применении не думает, а когда увидит, начинает «стесняться». Так что чем больше будет таких проектов как ваш, тем лучше, сменится background. Потому что писать C/C++ байндинги для всего подряд действительно не вариант.

alkresin Oct 24 2018 at 22:25

Я о нем и не слышал. Действительно, идея та же. Серьезный продукт, судя по всему.
Но работать с ним я бы не стал, потому что использовать gtk под Windows, на мой взгляд, не лучший вариант. И выглядит несколько непривычно, и то, что надо устанавливать сам gtk везде со своей программой — сильно не нравится.

vanyas Oct 25 2018 at 05:08

А под мак по вашему ГТК норм? Очень убого будет выглядеть + тянуть гтк либы придется. Так что раз для винды нативный интерфейс сделали, то и для мак стоило бы Cocoa использовать

alkresin Oct 25 2018 at 09:04

У меня нет мака под рукой и я никогда не видел, как выглядит там gtk.

krasnov_v_i Oct 25 2018 at 08:44

А почему Qt не рассматривал? Там и сокеты есть и кросплатформенность уже решена за тебя и конструктор UI. Так же в помощь сигналы слоты, которые писали бы в сокеты события. Ну и зачем 2 соединения? Разве одно все не вытянет?

alkresin Oct 25 2018 at 09:01

QT мне не нравится по ряду причин, одна из которых — необходимость тянуть мегатонны dll со своей программой, даже самой маленькой. Для Go, кстати, уже есть фреймворк под qt.
Что касается количества соединений — можно, конечно, было бы и одним обойтись, но тогда логика взаимодействия процессов усложнилась бы. Ведь событие от GUI, которое посылает сообщение основной программе, может произойти в любой момент, в том числе во время передачи сообщения от программы к GUI или когда программа ждет ответа на свое сообщение. Разрулить все это можно, но зачем лишняя головная боль…

Shtucer Oct 25 2018 at 09:40

Для Go, кстати есть и GTK биндинги. Вот тут рассматривали как минимум один из них.
Для локального приложения tcp/ip выглядит странно, более логично было бы AF_UNIX (linux/osx) и NamedPipe (win). Но я хоть убей всё ещё не понимаю, зачем может понадобиться связка GuiServer и GuiClient на разных хостах. Как это, вообще будет выглядеть, если GuiServer на win-хосте, а клиент на osx, к примеру?
Ах, ну и Клиппер, о боже, Клиппер! :)

alkresin Oct 25 2018 at 09:54

Для Go, кстати есть и GTK биндинги.

Знаю, но я не использую gtk под Windows. Кроме того, это именно биндинги, т.е., набор функций, практически повторяющий gtk с его местами непростой структурой. В HwGUI же — обертка, которая изолирует программиста от всех деталей gtk и делает его работу проще.

Для локального приложения tcp/ip выглядит странно

Согласен. Вполне возможно, что в дальнейшем могут быть добавлены альтернативные варианты организации обмена. Реально там всего несколько небольших функций, которые за это отвечают. Через процедуру Init можно будет передавать GuiServer'у информацию, какой вариант использовать.

зачем может понадобиться связка GuiServer и GuiClient на разных хостах.

Преимущественно в тех случаях, когда на компьютере, где работает программа, нет GUI оболочки или даже монитора — я же перечислил возможные варианты.

RPG18 Oct 25 2018 at 11:04

даже самой маленькой.

Тогда Go с его статической линковкой вам не подойдет.

alkresin Oct 25 2018 at 11:10

Уже подошел. Его исполняемые файлы, конечно, великоваты на мой вкус, но все же меньше, чем суммарный вес всех dll от qt. К тому же файл именно один, что само по себе приятно.

RPG18 Oct 25 2018 at 12:45

Я что-то не понимаю, но у вас сервер написан на Си, т.е. вместо одного файла у вас два. Вам не нравится таскать gtk, но предлагаете таскать сервис.

alkresin Oct 25 2018 at 13:02

Да, всего 2 файла, основная программа и GuiServer. А теперь посчитайте, сколько у gtk или qt. Кроме того, это не единственная проблема — я уже писал об этом выше, могу повторить:
1)То, как выглядит gtk под Windows, оставляет желать лучшего.
2)Биндинги повторяют модель библиотеки, gtk или qt. Моя обертка над gtk и winapi скрывает низкоуровневые детали реализации, с ней работать проще. Впрочем, может, это потому, что я к ней привык).

RPG18 Oct 25 2018 at 13:45

> Биндинги повторяют модель библиотеки, gtk или qt.

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

pawlo16 Oct 27 2018 at 17:26

На картинках самые простые компоненты и canvas, а где можно посмотреть список доступных контролов? Интересуют таблицы, treee view, графики, layout-ы

И ещё момент — очень часто сталкиваюсь с тем, что админы выключают на локальных компах виндовз службу DNS адресов. Видимо на то есть причины. В этом случае сервер ваш работать не будет, не так ли? по этому логичнее было бы например для windows использовать именованные пайпы, shared memory либо сообщения WM_COPYDATA. Или любой другой рекомендованный способ межпроцессной коммуникации, не зависящий от запущенных служб

alkresin Oct 27 2018 at 20:09

Вот список контролов, уже прописанных в Go-пакете: label, edit, button, checkbox, radio, group, combo, bitmap, line, panel, ownbutton, splitter, updown, tree, progress bar, tab, browse. Здесь browse — это то, что вы называете таблицей, panel — то, на что можно, если надо, положить др. контролы — как тулбар, я большей частью именно в этом качестве его использую, ownbutton — кнопка, нарисованная средствами HwGUI.
Есть еще группа контролов, которые есть в HwGUI и, следавательно, будут доступны и через GuiServer, когда я напишу для этого код. В принципе, они все доступны и сейчас, если использовать xml формы.
По второму вопросу: отсутствие службы DNS никак не может повлиять на вызов локального сервера по адресу 127.0.0.1. Но об альтернативных механизмах связи я все равно буду думать — полезно иметь несколько вариантов.

alkresin Oct 27 2018 at 20:17

И еще: список всего, что есть в HwGUI, можно посмотреть в онлайн-документации, например, в списке классов

parserpro Oct 30 2018 at 16:55

А вот я бы взялся, пожалуй, за версию для Perl.

alkresin Oct 30 2018 at 17:08

Если вы всерьез, готов помочь — не в кодировании на Perl, а в том, что касается описания протокола и логики работы.

parserpro Oct 30 2018 at 18:54

Вполне серьезно. Протокол бинарный?

alkresin Oct 30 2018 at 19:57

Нет, текст: "+" <JSON строка> "\n"
Я буду выкладывать информацию вот здесь — по частям, по мере возможности.
По самому протоколу самое лучшее — запустить готовые тесты, включив журналирование, тогда все принятые сервером команды будут записываться в guiserver.log.