Comments 60
UFO just landed and posted this here
Думаю, что скорость выполнения здесь не критична. Создание GUI-объектов — это ведь не сложный вычислительный процесс в длинном цикле. В реальной программе замедление должно быть практически незаметно.
UFO just landed and posted this here
Не очень понял про таблицу настроек, ну а прогресс бар — там же не секундные задержки будут.
Для повышения скорости предусмотрены функции BeginPacket(), EndPacket(), которые позволяют отправлять группу сообщений — для создания окна, например, со всеми его виджетами и их свойствами, как один пакет. Кроме того, некоторые обработчики событий можно передать серверу — я об этом писал.
Для повышения скорости предусмотрены функции BeginPacket(), EndPacket(), которые позволяют отправлять группу сообщений — для создания окна, например, со всеми его виджетами и их свойствами, как один пакет. Кроме того, некоторые обработчики событий можно передать серверу — я об этом писал.
Пример из жизни. Делаю интерфейс к базе данных и вывожу табличку с тысячами записями.
Ну так вы эти тысячи записей не по одной будете передавать, и, наверное, не сразу все. Все зависит от реализации, можно сделать достаточно быстро.
Я как фрондендер ожидаю, что все это на себя возьмет фреймворк, как например Qt
И здесь вы можете просто передать двумерный массив строк и GuiServer все возьмет на себя. Для этого есть функция BrwSetArray().
Вообще не вариант. В ui фреймворке должен быть model/view, что бы view подтягивала данные по мере необходимости, а не загружать всё.
Модели могут быть разные, правила устанавливаем мы сами. Но я подумаю над вашим предложением.
Реализация подобной таблицы (browse) в HwGUI достаточно гибка, модели поведения можно создавать самые разные. По умолчанию два варианта — переданный массив данных или dbf файл, локальный или через соответствующую СУБД, Ads или LetoDB. Но подставив другие обработчики событий, можно реализовать и что-то еще для своих нужд. Эти другие предопределенные варианты можно будет задать в GuiServer, а из программы выбирать нужный.
Реализация подобной таблицы (browse) в HwGUI достаточно гибка, модели поведения можно создавать самые разные. По умолчанию два варианта — переданный массив данных или dbf файл, локальный или через соответствующую СУБД, Ads или LetoDB. Но подставив другие обработчики событий, можно реализовать и что-то еще для своих нужд. Эти другие предопределенные варианты можно будет задать в GuiServer, а из программы выбирать нужный.
А что с Drag'n'Drop?
А где примеры использования на Go?
В линуксе это получаются иксы над иксами внутри иксов?
Почему? К концепции X сервер/X клиент это отношения не имеет.
UFO just landed and posted this here
… к которому подключаются еще клиенты.
один клиент, я об этом писал. Ну и, потом, мой GuiServer — это не иксы, так что выражение «иксы над иксами» здесь некорректно.
Если описать концепцию X-сервера в такой же "вкрации", как и ваша, разница будет нулевая.
Да, ну и чтобы два раза не вставать: если уж у вас "один сервер — один клиент", то чем объясняется выбор tcp/ip стека?
Для возможности использования клиента и сервера на разных компьютерах.
Тогда я запутался окончательно. Можете привести терминологию в статье к общему знаменателю, потому что не понятно какова роль GuiServer, клиента, кто такая "основная программа работает на Linux сервере". Где кто что отрисовывает?
Диаграммку набросайте, пожалуйста. Пока, как я это понял, всё выглядит как wxWidgets, но с клиент-серверной архитектурой.
Мне кажется, в статье это достаточно ясно изложено. Сервер здесь — это мой GuiServer, который предоставляет интерфейс, клиент — ваша программа на Go, C,…
Во фразе «основная программа работает на Linux сервере» имеется ввиду сервер вашей локальной сети.
Во фразе «основная программа работает на Linux сервере» имеется ввиду сервер вашей локальной сети.
Даже в этом вашем комментарии два "сервера". Вот что я понял. Старый добрый подход: молотилка данных отдельно, морда — отдельно. Это очень старый подход, вот примеры: mpd и множество его фронтэндов, из последнего — neovim и его tui и gui. Только у вас это с ног на голову. Правильно я понимаю?
молотилка данных отдельно, морда — отдельно
Примерно так. Только вот насчет «с ног на голову» я не соглашусь.
Ну, возможно, и не с ног на голову. В конце концов платформа с вашим подходом тоже уже существует.
А что, neovim тоже использует отдельный процесс для интерфейса?
Я его даже не видел, пользуюсь старым добрым vim.
Я его даже не видел, пользуюсь старым добрым vim.
Там как-то вот так:
Embeddable
GUIs and other applications can nvim --embed to discover the msgpack API dynamically.
И пачка проектов про это:
https://github.com/neovim/neovim/wiki/Related-projects#gui
TUI — нет. Остальные UI — да. И, кстати, может общаться и через сокеты, и через обычные pipe. Только в случае с Neovim ожидается, что GUI запустит neovim (или, теоретически, присоединится к уже запущенному), а не наоборот.
Этот сервер после запуска будет молча слушать определенный порт, и, получив соединение от моей программы на Golang, будет в ответ на ее запросы создавать окошки, виджеты, производить с ними манипуляции и осуществлять обратную связь при появлении каких-то событий от виджетов — словом, реализовывать для нее GUI.
А почему бы не написать такой сервер на tcl/tk?
Написать можно на чем угодно. Мне кажется, я обосновал в статье свой выбор.
UFO just landed and posted this here
По-настоящему нативным для Linux решением было бы детектить текущее окружение\установленные библиотеки и на основе этого включать тот фреймворк, который для данной системы нативный.
Не могу себе представить такое. Мартышкин труд какой-то.
fbreader мог использовать gtk и qt, для отрисовки.
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У меня GTK2. А переключаться между GTK и QT — это, по-моему, слишком.
Идея «хороша», но не нова. www.gtk-server.org. Вы им пользуетесь? Вот то-то же, и я тоже. Но я думаю проблема в том, что народ о таком применении не думает, а когда увидит, начинает «стесняться». Так что чем больше будет таких проектов как ваш, тем лучше, сменится background. Потому что писать C/C++ байндинги для всего подряд действительно не вариант.
Я о нем и не слышал. Действительно, идея та же. Серьезный продукт, судя по всему.
Но работать с ним я бы не стал, потому что использовать gtk под Windows, на мой взгляд, не лучший вариант. И выглядит несколько непривычно, и то, что надо устанавливать сам gtk везде со своей программой — сильно не нравится.
Но работать с ним я бы не стал, потому что использовать gtk под Windows, на мой взгляд, не лучший вариант. И выглядит несколько непривычно, и то, что надо устанавливать сам gtk везде со своей программой — сильно не нравится.
А почему Qt не рассматривал? Там и сокеты есть и кросплатформенность уже решена за тебя и конструктор UI. Так же в помощь сигналы слоты, которые писали бы в сокеты события. Ну и зачем 2 соединения? Разве одно все не вытянет?
QT мне не нравится по ряду причин, одна из которых — необходимость тянуть мегатонны dll со своей программой, даже самой маленькой. Для Go, кстати, уже есть фреймворк под qt.
Что касается количества соединений — можно, конечно, было бы и одним обойтись, но тогда логика взаимодействия процессов усложнилась бы. Ведь событие от GUI, которое посылает сообщение основной программе, может произойти в любой момент, в том числе во время передачи сообщения от программы к GUI или когда программа ждет ответа на свое сообщение. Разрулить все это можно, но зачем лишняя головная боль…
Что касается количества соединений — можно, конечно, было бы и одним обойтись, но тогда логика взаимодействия процессов усложнилась бы. Ведь событие от GUI, которое посылает сообщение основной программе, может произойти в любой момент, в том числе во время передачи сообщения от программы к GUI или когда программа ждет ответа на свое сообщение. Разрулить все это можно, но зачем лишняя головная боль…
Для Go, кстати есть и GTK биндинги. Вот тут рассматривали как минимум один из них.
Для локального приложения tcp/ip выглядит странно, более логично было бы AF_UNIX (linux/osx) и NamedPipe (win). Но я хоть убей всё ещё не понимаю, зачем может понадобиться связка GuiServer и GuiClient на разных хостах. Как это, вообще будет выглядеть, если GuiServer на win-хосте, а клиент на osx, к примеру?
Ах, ну и Клиппер, о боже, Клиппер! :)
Для Go, кстати есть и GTK биндинги.
Знаю, но я не использую gtk под Windows. Кроме того, это именно биндинги, т.е., набор функций, практически повторяющий gtk с его местами непростой структурой. В HwGUI же — обертка, которая изолирует программиста от всех деталей gtk и делает его работу проще.
Для локального приложения tcp/ip выглядит странно
Согласен. Вполне возможно, что в дальнейшем могут быть добавлены альтернативные варианты организации обмена. Реально там всего несколько небольших функций, которые за это отвечают. Через процедуру Init можно будет передавать GuiServer'у информацию, какой вариант использовать.
зачем может понадобиться связка GuiServer и GuiClient на разных хостах.Преимущественно в тех случаях, когда на компьютере, где работает программа, нет GUI оболочки или даже монитора — я же перечислил возможные варианты.
даже самой маленькой.
Тогда Go с его статической линковкой вам не подойдет.
Уже подошел. Его исполняемые файлы, конечно, великоваты на мой вкус, но все же меньше, чем суммарный вес всех dll от qt. К тому же файл именно один, что само по себе приятно.
Я что-то не понимаю, но у вас сервер написан на Си, т.е. вместо одного файла у вас два. Вам не нравится таскать gtk, но предлагаете таскать сервис.
Да, всего 2 файла, основная программа и GuiServer. А теперь посчитайте, сколько у gtk или qt. Кроме того, это не единственная проблема — я уже писал об этом выше, могу повторить:
1)То, как выглядит gtk под Windows, оставляет желать лучшего.
2)Биндинги повторяют модель библиотеки, gtk или qt. Моя обертка над gtk и winapi скрывает низкоуровневые детали реализации, с ней работать проще. Впрочем, может, это потому, что я к ней привык).
1)То, как выглядит gtk под Windows, оставляет желать лучшего.
2)Биндинги повторяют модель библиотеки, gtk или qt. Моя обертка над gtk и winapi скрывает низкоуровневые детали реализации, с ней работать проще. Впрочем, может, это потому, что я к ней привык).
На картинках самые простые компоненты и canvas, а где можно посмотреть список доступных контролов? Интересуют таблицы, treee view, графики, layout-ы
И ещё момент — очень часто сталкиваюсь с тем, что админы выключают на локальных компах виндовз службу DNS адресов. Видимо на то есть причины. В этом случае сервер ваш работать не будет, не так ли? по этому логичнее было бы например для windows использовать именованные пайпы, shared memory либо сообщения WM_COPYDATA. Или любой другой рекомендованный способ межпроцессной коммуникации, не зависящий от запущенных служб
И ещё момент — очень часто сталкиваюсь с тем, что админы выключают на локальных компах виндовз службу DNS адресов. Видимо на то есть причины. В этом случае сервер ваш работать не будет, не так ли? по этому логичнее было бы например для windows использовать именованные пайпы, shared memory либо сообщения WM_COPYDATA. Или любой другой рекомендованный способ межпроцессной коммуникации, не зависящий от запущенных служб
Вот список контролов, уже прописанных в 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. Но об альтернативных механизмах связи я все равно буду думать — полезно иметь несколько вариантов.
Есть еще группа контролов, которые есть в HwGUI и, следавательно, будут доступны и через GuiServer, когда я напишу для этого код. В принципе, они все доступны и сейчас, если использовать xml формы.
По второму вопросу: отсутствие службы DNS никак не может повлиять на вызов локального сервера по адресу 127.0.0.1. Но об альтернативных механизмах связи я все равно буду думать — полезно иметь несколько вариантов.
И еще: список всего, что есть в HwGUI, можно посмотреть в онлайн-документации, например, в списке классов
А вот я бы взялся, пожалуй, за версию для Perl.
Если вы всерьез, готов помочь — не в кодировании на Perl, а в том, что касается описания протокола и логики работы.
Вполне серьезно. Протокол бинарный?
Нет, текст: "+" <JSON строка> "\n"
Я буду выкладывать информацию вот здесь — по частям, по мере возможности.
По самому протоколу самое лучшее — запустить готовые тесты, включив журналирование, тогда все принятые сервером команды будут записываться в guiserver.log.
Я буду выкладывать информацию вот здесь — по частям, по мере возможности.
По самому протоколу самое лучшее — запустить готовые тесты, включив журналирование, тогда все принятые сервером команды будут записываться в guiserver.log.
Sign up to leave a comment.
GUI-фреймворки — на поток