OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 13 Ноябрь, 2019 23:17

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 124 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 29 Июль, 2010 11:36 
Аватара пользователя

Зарегистрирован: Среда, 29 Март, 2006 12:09
Сообщения: 495
Правильно ли я понимаю, что в случае прямого обращения к X-серверу вся отрисовка и обработка ложится на плечи программы? Т.е. window manager тут даже не поможет? (речь идет о кнопках, полях ввода и т.д., т.е. об этдельных виджетах?)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 08:18 

Зарегистрирован: Суббота, 06 Июнь, 2009 07:52
Сообщения: 329
Димыч писал(а):
Тогда уж XCB наверное...
Я исхожу из того, что GUI в Linux – это связка Иксов и оконного менеджера. Они реализуют стандартную клиент-серверную модель. Поэтому, нужно добиться, чтобы ВВ использовал любой оконный менеджер. Вообще, трудозатраты по выделению какой-то одной библиотеки считаю не оправданными. Особенно, такой большой проект, как Qt, обладает избыточностью и своими зависимостями даже в Linux’e. А если написать в Linux’e модуль ВВ с использованием Qt, а потом пытаться запустить его под Windows, то библиотека и туда потянет всякое разное(cygwin, например). Да ещё конфигурация в системе. Что не для простого пользователя. В этом смысле уж лучше самое нативное – xlib. Но всё это кажется морально устаревшим. С хсв пока не разбирался, но вот эта часть
Цитата:
People wanting to implement higher level applications can use xcb-util.
XCB is built atop an XML description of the X core protocol and common extension protocols called XML/XCB. This protocol can be used in other interesting ways.
To aid in porting applications, you can configure Xlib to use XCB for the transport layer. We call this Xlib/XCB.
кажется интересной.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Июль, 2010 09:56 
Аватара пользователя

Зарегистрирован: Среда, 29 Март, 2006 12:09
Сообщения: 495
Читал документацию по протоколу, много думал.

ББ является высокоуровневой средой. Она старательно абстрагируется от ОС везде, где это возможно. Это раз.
ББ на Windows уже реализована (нет необходимости переписывать). Это два. И, наконец, третье. Необходимость тащить за собой всю библиотеку Qt или wx нет. Никто не отменял статическую сборку в одну (пусть и немаленькую) библиотеку, если уж так надо.

Вопрос, все-таки, в трудозатратах.
Как я уже ранее писал, объектные модели ББ и Qt/wx если не совпадают, то очень близки друг другу, а потому могут быть относительно легко совмещены. Я слабо себе представляю работу только с протоколом Х11, поскольку это тащит за собой и графику, и обработку сообщений. Потенциальный объем работ в случае обращения к протоколу считаю огромным, а потому [для меня] неприемлимым.

Когда работы [мною] будут продолжены, [мои] усилия будут направлены на Qt (или, что уже менее вероятно, на wx). Если кто-то захочет продолжить работы в другом направлении, буду только рад.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Август, 2010 18:38 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1162
Откуда: Tel-Aviv
Я по-прежнему считаю, что следует держать курс с прицелом на использование современных технологий. В данном случае, на платформу .NET/Mono . Она представляет собой развитую инфраструктуру. В отличие от неё, реализация на протоколе X не будет иметь никакой перспективы и уж про графический интерфейс, и подавно, лучше не говорить.
Вот только поддержки .NET в Блэкбоксе ещё нет (включая генерацию исполняемого кода). Зато она есть в Gardens Point Component Pascal.

Время от времени пополняю страницу BlackBox: Porting subsystem Hosts to Linux, в которой собираю список функциональности, необходимой для переноса на X11.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Август, 2010 18:59 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Роман М. писал(а):
Я по-прежнему считаю, что следует держать курс с прицелом на использование современных технологий. В данном случае, на платформу .NET/Mono . Она представляет собой развитую инфраструктуру.

OK. Какой GUI вы предлагаете использовать на Mono?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Август, 2010 21:00 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Димыч писал(а):
ББ является высокоуровневой средой. Она старательно абстрагируется от ОС везде, где это возможно. Это раз.

Именно поэтому X11 и лучше. Поясню -- X11 протокол также абстрагируется от ОС. Полностью. Т.о. нам будет совершенно всё равно где запускаться, под linux, bsd, или даже windows (да, x-server под винду занимает страшно много -- около трех мегабайт ;-) ). И нам все равно, установлен там Qt или нет. Поддерживается ли там Qt вообще. В случае с wxWidgets мы до кучи под линуксом обычно имеем зависимость от Gtk.

Димыч писал(а):
ББ на Windows уже реализована (нет необходимости переписывать). Это два. И, наконец, третье. Необходимость тащить за собой всю библиотеку Qt или wx нет. Никто не отменял статическую сборку в одну (пусть и немаленькую) библиотеку, если уж так надо.

Проблема не в объемах дистрибутива. Проблема в дополнительной сложности отладки. В случае трапа имея в качестве подложки Qt мы имеем длиннющий call-stack и мутные потроха жирной системы. В случае тарпа при использовании X11, мы имеем короткий, целиком обероновский стэк. В ББ его можно инспектировать вдоль и поперек.

Димыч писал(а):
Вопрос, все-таки, в трудозатратах.

Вопрос в постановке задачи. Если нужна времянка, то пойдет любой биндинг к любой сишноплюсовой библиотеке. Если нужно что-то более глоабальнонадежное, или же просто хочется поисследовать "пределы гибкости" среды, то лучше лепить своё на X11. Благо X11 намного по идеалогии ближе к WinAPI (в плане гуя) нежели WinAPI к Qt например. В WinAPI также нет никаких виджетов (кроме самых примитивных и которыми никто в общем то и не пользуется. кнопка, чекбокс и т.п. пишутся за две недели всем скопом. Еще недели две-три -- на виджет для полноценного редактирования текста, аля RichEdit).

Димыч писал(а):
Я слабо себе представляю работу только с протоколом Х11, поскольку это тащит за собой и графику, и обработку сообщений.

Что подразумевается под графикой? Рисование линий, всяких разных иных примитивов, вывод текста, поддержка шрифтов -- есть в X11. Виджеты свои лепить нужно будет в любом случае.

Что подразумевается под обработкой сообщений, и где там сложность?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Август, 2010 15:26 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Господа, я идиот таки. Как я не вспомнил про эту библиотеку? Ведь пользовались же ею. Для промышленных решений.

Зовётся оно: The Nano-X Window System: http://www.microwindows.org/

Примечательно оно тем, что:
1) крайне лекговесно (потребляет около 300 Кб).
2) Умеет работать как через X11, так и на прямую в фреймбуфер, что актуально на встраиваемых решениях (где мы это и применяли).
3) Имеет 2 API (пользоваться можно любым): X11-подобным и WinAPI.

Цитата:
here are two APIs implemented in the system, a Win32 API and an Xlib-like API.

Основные контролы имеются.

Т.о. если в BB не используются злостные хаки WinAPI'шные для гуя, то портирование на Nano-x должны быть весьма простым.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Август, 2010 15:50 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1162
Откуда: Tel-Aviv
Так как Блэкбокс планируется переносить не на embedded-устройства, то надо ориентироваться на общепринятые desktop-менеджеры. Мне, как пользователю, а не только как разработчику, важно комфортно работать в графических средах, таких GNOME/KDE и не ощущать себя ущербным.
Кроме того, надо подумать ещё и об интеграции с графической средой линукса, включая буфер обмена и прочее.
Если перенести Блэкбокс на линукс с помощью таких библиотек, как Nano-X, то он напрочь отобьёт охоту разрабатывать на нём.

С точки зрения среды разработки могу поставить в пример NetBeans - примерно такой я себе и представляю для Блэкбокса.
В Mono для разработки GUI можно использовать Windows.Forms/GTK#/wxNet и другие GUI-toolkits.

Привязка к мейнстрим ничуть не плоха. Она даёт некоторую стабильность и долгосрочность. Так что я за вариант связки с .NET . Благо, GPCP уже имеет им пользоваться, что даёт некоторую уверенность в относительной простоте подгона для ББ.

Как дополнительные варианты, привязка к GTK+(проще из-за чистого С) / Qt.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Август, 2010 16:00 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Роман М. писал(а):
Так как Блэкбокс планируется переносить не на embedded-устройства, то надо ориентироваться на общепринятые desktop-менеджеры.

А при чем тут десктоп-менеджеры? У менеджеров совсем другая задача, к граф. тулкитам они отношения не имеют.
Роман М. писал(а):
Мне, как пользователю, а не только как разработчику, важно комфортно работать в графических средах, таких GNOME/KDE и не ощущать себя ущербным.

И какие проблемы? Не будет вам ущербности от этого. Значительной :-)
А вариант BB на nano-x действительно интересен так или иначе. Ибо у него могут быть реальные применения. Промышленные. Хм. Надо же. Как долго до меня эта комбинация доходила. Дошла как раз в тот момент, когда оно мне уже в общем то и не нужно. Но судя по всему, тем же Метасистемам это может оказаться полезным.
Цитата:
Кроме того, надо подумать ещё и об интеграции с графической средой линукса, включая буфер обмена и прочее.

C этим как раз проблем нет.

Цитата:
Если перенести Блэкбокс на линукс с помощью таких библиотек, как Nano-X, то он напрочь отобьёт охоту разрабатывать на нём.

С чего бы? Кстати, а вы удосужились хотя бы пройти по ссылке и посмотреть что это такое? Например ваш любимый KDE и другие Qt приложения вполне себе запускаются на nano-X без модификации исходников.

Цитата:
С точки зрения среды разработки могу поставить в пример NetBeans - примерно такой я себе и представляю для Блэкбокса.

А, т.е. вы таки за реализацию X11 протокола и написании BB-GUI на чистых иксах? Ибо именно так написан netbeans. Так работает Swing. У нетбинзы нет зависимостей ни от gtk ни от qt, ни, тем более, Gnome или KDE. Всё что ей нужно -- jre и начилие X11 сервера к которому можно было бы прицепиться.

Цитата:
В Mono для разработки GUI можно использовать Windows.Forms/GTK#/wxNet и другие GUI-toolkits.

WinForms не вариант. Это убого и глючно. GTK# это не вариант уже для .нета. wxNet вообще не нужен :-)

Цитата:
Привязка к мейнстрим ничуть не плоха. Она даёт некоторую стабильность и долгосрочность. Так что я за вариант связки с .NET . Благо, GPCP уже имеет им пользоваться, что даёт некоторую уверенность в относительной простоте подгона для ББ.

Реализуйте BB на GPCP + .net/java :-)
Язык то один. Должно легко портироваться :-D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Август, 2010 21:22 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
Alexey Veselovsky писал(а):
Т.о. если в BB не используются злостные хаки WinAPI'шные для гуя, то портирование на Nano-x должны быть весьма простым.
Любопытно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 12:32 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Роман М. писал(а):
Так как Блэкбокс планируется переносить не на embedded-устройства, то надо ориентироваться на общепринятые desktop-менеджеры.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 12:36 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Господа, я идиот таки. Как я не вспомнил про эту библиотеку? Ведь пользовались же ею. Для промышленных решений.
Зовётся оно: The Nano-X Window System: http://www.microwindows.org/
...
Т.о. если в BB не используются злостные хаки WinAPI'шные для гуя, то портирование на Nano-x должны быть весьма простым.


Это интересно, спасибо (когда-то уже видел, кстати).

Тут штука в том, что реализация ББ сильно ориентирована на MDI и его модель оконности. Как раз чисто графика не вызывает вопросов, она локализовано.
А в X-ах, насколько я понимаю, как раз оконные абстракции очень сокращены, всё идёт выше специальными менеджерами, так?

Вот те же меню взять..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 13:44 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Это интересно, спасибо (когда-то уже видел, кстати).

Тут штука в том, что реализация ББ сильно ориентирована на MDI и его модель оконности. Как раз чисто графика не вызывает вопросов, она локализовано.
А в X-ах, насколько я понимаю, как раз оконные абстракции очень сокращены, всё идёт выше специальными менеджерами, так?

Вот те же меню взять..


В X11, как и в WinAPI есть понятие "дочернее окно", как же без него? Например кнопка в WinAPI это дочернее окно, окошка на котором лежит. В этом плане в X11 возможности те же. Окна по сути своей образуют дерево, корнем которого является root window, как и в винде (там при создании окна также задаешь хэндл родителя, если родитель это root window, то в WinAPI нужно передать NULL).

Но сам X-сервер не занимается отрисовкой заголовков окон, их рамок, изменением размеров окон. Если запустить просто X11, затем запустить ваш любимый X11-клиент (например браузер FireFox). то будет отлично видно что окно вот оно, есть, но заголовка нет, нет рамки, переместить окно нельзя, равно как и изменить его размер. В принципе всё это может делать приложение само. Либо может быть третье приложение (которое является обычным X11-клиентом, т.е. также работает через тот же протокол), которое вокруг окон будет рисовать рамочки, заголовки, кнопочки свернуть, развернуть, закрыть, перемешать окна когда пользователь тащит за заголовок мышкой, изменять размеры окон и т.п. Такое приложение называется оконным менеджером.

Ясно что таковое приложение может рисовать рамки и вообще работать только с окнами которые являются дочерними root window, с их дочками он работать не может по простой причине -- как он отличит скажем кнопку (которое окно), или другой виджет, от "окон-документов" для которых нужно рисовать рамочки и прочее? Никак.

Соответственно MDI должно быть реализовано самим приложением. Всегда. Т.е. внутри приложения должен быть свой "оконный менеджер" который натравливается уже на нужные дочерние окна и который уже им меняет размеры, рисует заголовочки и прочее, прочее.

С менюшками тоже всё просто -- то, которое pop-up, это просто окно, что в винде что в x11, при чем, оно является дочерним окном root window, а не окна того приложения откуда оно выскочило. В самом протоколе X11 понятия "меню" нет, ибо не нужно. Есть окно. И на этой абстракции реализуй что хочешь. Да, никакие менеджеры меню не реализуют (а как они это реализовали бы?). Это функциональность самого приложения. Всегда.

Соответственно реализация MDI на X11 (или где угодно ещё, где есть абстракция под названием "окно" с наличием привязки к родителю) сводится к реализации простейшего оконного менеджера внутри программы. Трудоемкость задачи -- от одного дня до рабочей недели. Строк кода -- от 500 строк до 3000. Ориентировочно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 14:17 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
А зачем MDI? Мышь не всегда корректно работать будет?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 14:35 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Valery Solovey писал(а):
А зачем MDI? Мышь не всегда корректно работать будет?

Ничего не понял. Какая связь между мышкой и MDI?
MDI нужно затем, что весь интерфейс BB построен на MDI :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 17:48 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
И зачем в ББ MDI? Без него же удобнее. Правда, в ББ мышь обрабатывается оригинально, и без MDI есть вероятность получить проблемы (правда, я не вникал в суть и могу ошибаться).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 18:16 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Valery Solovey писал(а):
И зачем в ББ MDI? Без него же удобнее. Правда, в ББ мышь обрабатывается оригинально, и без MDI есть вероятность получить проблемы (правда, я не вникал в суть и могу ошибаться).

Если мы хотим получить тот же ББ, что и в винде (а мы хотим, ибо единообразие), то без MDI никак. Если хочется переиначить у ББ интерфейс, то следует это сделать вначале в винде. Это удобней, быстрее и всё равно придется делать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 18:21 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
В принципе, можно и без MDI - какой-то фреймовый интерфейс + открытие отдельных окон, но это же надо придумать и опробовать.. Задача отдельная, действительно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Август, 2010 18:57 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
В принципе, можно и без MDI - какой-то фреймовый интерфейс + открытие отдельных окон, но это же надо придумать и опробовать.. Задача отдельная, действительно.

Всё новое -- хорошо забытое старое. Вспоминаем какой был интерфейс в ОС Оберон Вирта. Там были как раз не перекрывающиеся окна (ибо лишняя, не удобная сущность, и, к стати, к этому все и пришли совсем недавно. не полностью (для root window системы перекрытие окон осталось, хотя.. см. тайловые менеджеры, тот же XMonad например (самый популярный из них, и, кстати, писаный на Haskell'e), и немного не так (появились т.н. табы, перспективы и т.п., но тем не менее.). Пощупать, адаптировать в плане идеи и реализовать. Но реализовывать, опять же, в первую очередь под WinAPI. Ибо там это будет намного быстрее т.к. инфраструктура вся готова. Быстрее получится сделать прототип чтобы защупать руками и понять насколько это удобно получается, а где надо подпилить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Август, 2010 11:54 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1162
Откуда: Tel-Aviv
Илья Ермаков писал(а):
Роман М. писал(а):
Так как Блэкбокс планируется переносить не на embedded-устройства, то надо ориентироваться на общепринятые desktop-менеджеры.
Надо ориентироваться на минимизацию зависимостей и не потерять преимущество полной автономности от окружения.

Для начала нужно определиться с целевой аудиторией Блэкбокса. Если будет использоваться только для разработки программного обеспечения для, скажем, ПВО, то тогда привязка к GTK+ неоправдана (с оговоркой: ведь среда разработки и среда исполнения - не всегда одна и та же). Вполне реален вариант, когда разработка ведётся на обычных рабочих машинах, а программа исполняется на embedded-устройствах с особыми требованиями, в которых графика и вовсе не нужна.

Зависимость от GTK+ не приведёт к необходимости дополнительных установки пакетов GTK, так как от него зависит множество других пакетов, используемых как в проекте десктоп-менеджера GNOME, так и в Xfce и во многих других проектах. Таким образом, можно считать, что библиотеки GTK+ будут присутствовать на графической линукс системе с достаточно большой вероятностью и на них можно расчитывать при разработке графической части Hosts.

Беря развитые библиотеки как основу для графической платформы ББ, мы достигаем стабильности и живучести проекта. А излишний минимализм приводит к тому, что в итоге неудобно пользоваться и это сильно мешает привычной работе в среде разработки.
Если ориентироваться на "голый" X, то придётся писать свою графическую подсистему. Но вряд ли она будет столь эргономична, как Qt/GTK+. В добавок, потребуется приложить много усилий для разработки такой прослойки.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 124 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB