Board.KolibriOS.org

Ведётся ли разработка лэйаутов в libGUI? (просто если нет, я ей наверное займусь)

Управление размером и положением control-ов предполагается делать через контейнеры и control-лы spacer-ы, которые будут разделять control-лы. Также, если control не будет расположен в контейнере, то его положение будет задаваться абсолютными координатами.
vkos, у тебя есть опыт разработки GUI библиотек?

И кроме того, ширина - это всё-таки width, а не wigth.

Да, описка вышла.

Слово finition означает finishing?

finit-ограничивать.

PS: в примере main есть глюк - при перемещении области со скроллами остаются следы на предыдущем месте, которые исчезают при полной перерисовке)

Скорее всего ты используешь старую версию библиотеки и возможно старую версию примеров. У меня таких глюков давно нет(после буферизации некоторых control-ов).

Теперь о главном.
Возможно у кого-то возник вопрос, почему дальше не пишутся control-ы и почему появилась пауза в разработке.
Архитектура библиотеки libGUI(так сказать её движок) до конца не сформирован. Все control-ы, которые есть в библиотеке, я сделал только для проверки некоторых возможностей движка. Сейчас в развитии движка наметился следующий этап. Как уже писал в этой теме Diamond, необходимо, чтобы почти у каждого control-а было своё окно, куда он отрисовывает себя (некоторые control-ы могут не иметь окон, потому что они просто будут им не нужны). В KolibriOS один поток может иметь только одно окно. Пока не будем обращать внимания, что количество потоков в KolibriOS ограничено цифрой 255.
Для управления control-окнами необходимо эффективно управлять потоками и соответственно их окнами. Необходим оконный стек с выравненными по глубине окнами. Должно быть окно, которые всегда будет ниже всех(для фона десктопа и иконок), также самое верхнее окно, которое всегда будет поверх остальных(самым верхним окном могут быть разные окна). Ну и между ними окна выровненные по глубине. При изменении положения окна, которое не является верхним, нужно восстанавливать фон на старом месте не перерисовкой всех нижележащих по глубине окон а восстановлением фона с использованием буферизации. В KolibriOS активированное окно автоматически становиться как бы самым верхним по глубине. То есть переместить окно, не сделав его автоматически самым верхним - невозможно.
В общем придётся мне делать control-окна исходя из того, что сейчас есть в ядре, а потом уже думать как сделать правильную реализацию работы с окнами. Конечно нужно посмотреть на реализацию в других системах.
Никуда не денешься, но придётся попробовать изменить действующий оконный менеджер в ядре(естественно советуясь со всеми разработчиками KolibriOS). Пока что я занят другими задачами(а задач у меня предостаточно), как только смогу - переключусь на libGUI и оконную систему.

vkos, у тебя есть опыт разработки GUI библиотек?

Есть, хотя и не очень удачный.

Скорее всего ты используешь старую версию библиотеки и возможно старую версию примеров.

Примеры последние выложенные, а библиотека последняя из бинарных (т.к. собранная мной не работает).

Никуда не денешься, но придётся попробовать изменить действующий оконный менеджер в ядре(естественно советуясь со всеми разработчиками KolibriOS)

У меня была другая идея (и может я её когда-нибудь реализую, если к тому времени никто не сделает нормальный оконный менеджер). Сделать 2 программы-сервера, которая будет рисовать напрямую в видеопамять, и оконный менеджер, работающий поверх первого сервера. Простые же программы могут обращаться к оконному менеджеру. Для совместимости со старыми программами (если она будет уж так нужна) можно написать костыль в ядре, перенаправляющий запросы на оконный менеджер.
Также есть промежуточный вариант - сделать сервер всех окон, но тогда преимущество только в том, что работать с окнами приложениям будет проще.

finit-ограничивать.

По-английски?

Кстати, по какой лицензии распространяется libGUI?

У меня пока нет времени думать над лицензиями.Наверное GPL или BSD. Не до лицензий мне сейчас.

vkos wrote:Цитата:finit-ограничивать.По-английски?

<--- dictd_www.mova.org_slovnyk_en-ru --->
finite
finite
ограничен
ограниченный
ущербленный


<--- en-ru-bars --->
finite
1> ограниченный, имеющий предел

2> _мат. ограниченный, конечный

3> _грам. личный (о глаголе)
<--- quick_english-russian --->
finite
ограниченный

Albom
Ну так finite, а не finit.

vkos
Ну так никто и не спорит! finite - так finite. это прилагательное. если глагол, то:

<--- dictd_www.mova.org_slovnyk_ru-en --->
ограничивать
ограничивать
abridge
astrict
bind
bound
circumscribe
confine
conscribe
constrain
determine
limit
pinfold
restrain
restrict
specialize
straiten
terminate

Попытался скомпилировать пример (ассемблерный button.inc), получил сообщение от fasm об отсутствии libGUI.inc
Можно ли его получить?

Видал такой в одном из старых архивов.
: Почему бы не использовать boxlib?

: Мне хотелось попробовать LibGUI, желания юзать её в каком-то приложении целенаправленно не было.

А вообще я буду очень благодарен, если кто-нибудь вынесет из tinypad'a код меню и оформит его в виде библиотеки (или части либы). Причем так, что бы можно было назначать callback функцию на пункт меню.

Тоже самое относится к выводу текста с помощью нестандартных шрифтов (так, как это реализовано в shell и kfar)

Я думаю если бы Михаил имел время, желание и главное это было бы достаточно просто, то он бы сам вынес меню в библиотеку. На самом деле компоненты изначально не предназначенные для выделения в библиотеку (например, реализованные в виде макроса) очень сложно потом выделить - возникает куча неучтенных мест. Я к примеру очень долго выковыривал компоненты scrollbar и filebrowser из KFM, чтобы вставить в Box_Lib. Иногда компонент проще написать заново и от языка разработки тут мало что зависит.

В Box_Lib кстати содержит меню, которое есть в двух приложениях: zSea и OpenDialog.

Mario, эммммм, а rtreader/heed им ведь пользуются вроде? Или нет?
И вопрос: boxlib овскому меню такой стиль, как в tinypad не придашь? Больно он мне понравился.

maximYCH wrote:rtreader/heed им ведь пользуются вроде? Или нет?

Да, не учел - не я прикручивал, так что тупо забыл, что они тоже используют.

maximYCH wrote:И вопрос: boxlib овскому меню такой стиль, как в tinypad не придашь? Больно он мне понравился.

Нет. Что в Тинипад, что в Box_Lib компоненты рисуются программно и это требует переделки кода отрисовывающего внешний вид. Была идея сделать поддержку RAW, но поскольку для меня гламур свистоперделки чувство прекрасного красивости дизайна стоят на последнем месте, то будет это еще не скоро.

Хм, т.е. грубо говоря, если я сейчас прикручу boxlibовское меню к animage, то потом, при желании, если переписать код меню boxlib в стиль tinypad, получится требуемый стиль?

З.Ы. Если с меню вопрос решен, то просьба про вывод шрифтом 8x16 остается актуальной. Очень актуальной.

maximYCH wrote:Хм, т.е. грубо говоря, если я сейчас прикручу boxlibовское меню к animage, то потом, при желании, если переписать код меню boxlib в стиль tinypad, получится требуемый стиль?

У Box_Lib есть свой стиль, который продиктован скоростью вывода. Если кому-то нужны красивости, то он может написать свой компонент и добавить его в бибилотеку. Я против изменения текущего.

maximYCH wrote:З.Ы. Если с меню вопрос решен, то просьба про вывод шрифтом 8x16 остается актуальной. Очень актуальной.

я этим вопросом не занимаюсь.

З.Ы. Просьба больше не оффтопить - есть специализированные темы, там и нужно писать.