С днем рождения, Haiku!
RISC 18 августа, 2010 - 23:55.
Ровно девять лет назад зародился проект OpenBeOS, который впоследствии был переименован во всем нам известную Haiku. Многие скептически относились к проекту, но всё же, он живет своей жизнью. Haiku все ещё находится на стадии разработки, но за последний год вышло уже две альфа версии, и скоро, я думаю, нас ждет третья альфа. Появились новые разработчики, и сообщество пользователей существенно возросло. Будем надеяться на то, что Haiku и дальше будет развиваться и через пару лет выйдет стабильный релиз R1.
Пожелаем всего самого наилучшего проекту. С днем рождения, Haiku!
Десять
Десять лет прошло! Офигеть! Пойду напьюсь.
Девять. ;)
Девять. ;)
Ай дую пиво,
Ай дую пиво, Ай ловъю кайф -виртуальный бокал за здравие!
Мало ли,
Мало ли, что там на заборах пишут. Кому и воскресная поделка релиз. Альфа альфе рознь. Для начала хорошо бы с фактурой ознакомиться.
А оно стало?!
А оно стало?!
Не знаю; более
Не знаю; более жуткой самоделки, чем Бубунта, я ещё не видел. По мне, так пользоваться можно только Мандривой, и то если другого выхода нет.
А ядро — да, пишут :) Ну и флаг им в руки.
За 9 лет Haiku
За 9 лет Haiku успела устареть. За время её разработки в неё не добавлено существенных изменений по сравнению с BeOS. В основном добавления — это фичи, от которых мало пользы.
В её системе пользовательского интерфейса нет нормальной поддержки альфа канала(та, что есть — это костыли, которые усложняют разработку, последствия использования этих костылей даже видны, если внимательно присмотреться), элементы пользовательского интерфейса не могут пересекаться(такая возможность есть везде, даже в Windows), не гибкая система передачи сообщений.
Также нет чёткого описания бинарного интерфейса(ABI), отсутствие которого осложняет разработку под Haiku не на С++. В Windows COM чётко описан и есть примеры и биндинги для разных языков программирования.
На
На что не хватило? И какое отношение это имеет к утверждению выше? Если никакого, то вы просто демогог, переходящий на личности.
Если намного
Если намного лучшая совместимость с posix это «малопользительная фича» — то от всей души желаю вам поработать с чем–то таким–же латаным перелатанным и полным легаси–заплаток какой была БеОСина на момент её конца. Цель, поставленная для версии R1 — воссоздание БеОС R5. А все улучшения, мешающие этой задаче откладываются и пойдут в разработку после релиза. И это правильно.
В чём претензии к сообщениям?
ABI — серая зона стандарта cpp. Проблема биндингов решаема сборкой их с нужной версией компилятора. Да и кто сказал, что нету чёткого описания? Сорсы гцц вам в руки.
> Если намного
> Если намного лучшая совместимость с posix это «малопользительная фича»
Я другое имел в виду. Различные расширения API и добавление программ, серверов, от которых мало толку. Например Layout API, Notification server.
> А все улучшения, мешающие этой задаче откладываются и пойдут в разработку после релиза.
Но на практике почему–то это не так. Когда ещё есть серьёзные баги в ядре и файловой системе, добавляют фичи.
> В чём претензии к сообщениям?
Видели вы хоть один нормальный редактор форм, работающий под Haiku? Я нет. Проблема в том, что ограничить функциональность контролов и переадресовывать сообщения со всеми последствиями проблематично.
> Проблема биндингов решаема сборкой их с нужной версией компилятора.
Всмысле? Другие языки программирования обычно имеют другой компилятор, а зачастую ещё и свой формат объектных файлов и линкер. Как вы их соберёте с помощью GCC?
Но на практике
Но на практике почему–то это не так. Когда ещё есть серьёзные баги в ядре и файловой системе, добавляют фичи.
Разработчиков, способных решать проблемы в ядре меньше чем нам хотелось–бы и они вряд–ли занимаются интеграцией попап–серверов вместо работы над проблемами кернела. Иными словами добавление фич не тормозит развитие общей задачи.
Видели вы хоть один нормальный редактор форм, работающий под Haiku? Я нет. Проблема в том, что ограничить функциональность контролов и переадресовывать сообщения со всеми последствиями проблематично.
Полагаю проблема в том, что потенциальный разработчик такой системы не понимает глубины задачи и мутно представляет возможности, которые ему дает архитектура. А те, кто мог–бы понять — заняты на более важных для данного момента задачах. Например несмотря на то, что АПИ уже содержит возможность архивирования/восстановления тех–же форм в/из BMessage — такого рода ресурсы не формализированы в том–же RDEF, хотя казалось–бы идея лежит прямо под носом — бери и реализуй. Просто этим сейчас никто серъёзно не занимается кроме «энтузиастов с моторчиками в попе» — а последние начинают сразу–же лепить дельфоподобное — и закономерно ломают зубы о слишком «неограниченые» возможности. А редактор форм, по моему, надо начинать именно с формализации их формата в RDEF и доработки компилятора ресурсов. Это та база, которая придаст «официальный» статус гипотетическому редактору форм.
Всмысле? Другие языки программирования обычно имеют другой компилятор, а зачастую ещё и свой формат объектных файлов и линкер. Как вы их соберёте с помощью GCC?
биндинги — суть враппер вокруг основного АПИ, собираемый родным компилятором системы и выводящий интерфейсы для работы с этим АПИ из других систем разработки в понятном оным системам виде. Остальное уже их проблемы.
> Полагаю
> Полагаю проблема вВтом, чтоВпотенциальный разработчик такой системы неВпонимает глубины задачи иВмутно представляет возможности, которые емуВдает архитектура. АВте, ктоВмог–бы понятьВ— заняты наВболее важных дляВданного момента задачах. Например несмотря наВто, чтоВАПИ ужеВсодержит возможность архивирования/восстановления тех–же форм в/из BMessage
К чему всё это? С сохранением форм какраз никаких проблем нет. Я имел в виду визуальный редактор. Тоесть чтобы была возможность выделять, масштабировать и таскать кнопки и прочие контролы по форме мышкой, нажимая на них. Желательно ещё чтобы при двойном клике редактировался контрол, т. е. например на кнопке редактировался её текст. Для примера, как это работает, посмотрите редактор форм Qt или BlackBox.
Никакие исходники ресурсов такому редактору вообще не нужны. Более того при нормальном редакторе ресурсов никакой компилятор ресурсов в 90% случаев вообще не нужен.
Большинство
Большинство ссылок битые… Что конкретно смотреть?
Вот потому и не
Вот потому и не по зубам пока беосное АПИ для ваятелей визуальных редакторов, потому как думают что достаточно сделать «как в Qt Designer» а понимания того, что стены нужно ставить на прочный фундамент нету.
> потому
> потому как думают что достаточно сделать «как в Qt Designer» а понимания того, что стены нужно ставить на прочный фундамент нету.
Конкретнее и без сравнений можно? Чем редактирование в Qt Designer не то?
Тем,
Тем, что он заточен под Qt. Портированное решение останется портированным решением как на него скины не натягивай. А мы говорим про БеАПИ.
Вы меня
Вы меня не поняли.
Я говорю не про использование Qt, а про создание редактора со схожим функционалом, но с помощью Haiku API.
1. По поводу
1. По поводу костылей — писал прозрачные репликанты на рабочий стол, всё контролы нормально перекрываются, огород не городил. Что я делал неправильно?
2. «не гибкая система передачи сообщений» — Мдя. Я шоке. Куда гайке со своим BMessage по сравнению с офигительно гибкими win32 сообщениями, которые могут передать окну аж целых два параметра — LPARAM и WPARAM.
> 1. По поводу
> 1. По поводу костылей — писал прозрачные репликанты на рабочий стол, всё контролы нормально перекрываются, огород не городил. Что я делал неправильно?
Конкретнее можно? Как писал?
При вставки в Container из примеров BeOS прозрачность работает?
Двойной прорисовки не наблюдается(это когда объект рисуется 2 и более раз на одном месте, как последствия более тёмная тень например)?
Ввод мыши нормально работает при пересечении?
Зачастую прозрачность в Haiku работает странно:
Фон рисуется на рабочем столе, но не на репликантах. Прозрачность «руки» вырезает репликант. При вставки в Container вместо прозрачности в ней баг отрисовки в виде отпечатывания на месте прозрачности всего, что было поверх(окон например).
> 2. «не гибкая система передачи сообщений»
Не гибкая система передачи сообщений, а не формата самих сообщений. Сообщение шлётся сразу виду, на который произведён ввод минуя контейнеры. Чтобы например заблокировать ввод на вид в контейнере и перенаправить его на сам контейнер потребуется применение костылей.
Ещё в Windows можно нарисовать окно куда угодно. Пошли ему сообщение отрисовки с нужным дескриптором и оно нарисует.
Ну,
Ну, с прозрачностью фона решение есть, простое и лёгкое. Берётся кусок Desktop Wallpaper под окном программы (или репликанта — это неважно) и помещается подложкой в это окно, и апдейтится при перетаскивании / изменении размера. Разумеется, это workaround, но раз под репликантом всё равно ничего не должно быть, то этот способ замечательно сработает.
Это костыль,
Это костыль, причём кривой.
> Берётся кусок Desktop Wallpaper
Т. е. если окно программы поверх другого, то всёравно должен показываться фон экрана?
Ну, в Linux
Ну, в Linux это так и было сделано. «Прозрачный» терминал konsole в KDE 3 на самом деле прозрачный, но видно под ним только wallpaper, а не расположенные под ним окна других программ.
Но под репликантами не должно быть окон других программ, поэтому там этот костыль будет работать.
> Но под
> Но под репликантами не должно быть окон других программ
Зато под ним могут быть иконки и другие репликанеы.
Нее.. рисовать
Нее.. рисовать самому подложку это как раз костыл.
Всё намного проще, просто надо внимательнее читать бибук.
Ну вот например — http://img819.imageshack.us/img819/5901/35566822425eb276ce77.jpg
Совершенно честная прозрачность, репликант вообще ничего не знает о волпапере.
> Всё намного
> Всё намного проще, просто надо внимательнее читать бибук.
Разве это не в Haiku добавили?
Можете показать результат вставки вшего репликанта в Container и таскания какого–нибудь окна поверх?
Видео заснять
Видео заснять и на ютуб?
И да, это и в BeOS работало.
Скриншота
Скриншота достаточно.
Вот что я заметил у себя:
Виндовое окошко нарисовано в WonderBrush, если что.
http://www.youtube.com/watch?
http://www.youtube.com/watch?v=v_5HtDVzJTA
На видео виден
На видео виден баг с инверсией ввода мыши. Т. е. когда таскаешь репликант, то таскается самый нижний из них. Должно быть наоборот. Скорее всего где–то в appserver или libbe не в ту сторону итерация видов. Она должна быть с конца в начало.
В моей реализации ГИП(я пока назал его xGui. Используется в рамках проекта движка и редактора составных документов) я тоже с этим столкнулся.
На рабочем столе репликанты отрисовываются относительно нормально. Но в своих контейнерах(например программа Container из набора примеров от разработчиков BeOS) они ведут себя как на скрине выше.
Тебе
Тебе про козла — ты про барана. Не уходи от темы, мы вроде как про альфа–канал говорили.
На рабочем
На рабочем столе всё относительно нормально, но на других контейнерах проблемы. По крайней мере в коде альфа отрисовки из OverlayImage. У вас похожий код отрисовки?
Возможно есть двойная отрисовка(на OverlayImage это наблюдается).
Никаких
Никаких оверлеев, никакой двойной отрисовки.
> Никаких
> Никаких оверлеев
???
OverlayImage — это новый репликант в Haiku, который показывает картинки. http://dev.haiku–os.org/browser/haiku/trunk/src/apps/overlayimage
У вас такая же отриовка альфа канала?
void
OverlayView::Draw(BRect)
{
SetDrawingMode(B_OP_ALPHA);
SetViewColor(B_TRANSPARENT_COLOR);
if (fBitmap)
DrawBitmap(fBitmap, B_ORIGIN);
}
> никакой двойной отрисовки.
Не факт. Чтобы убедится в её отсутстви нужно сделать скрин репликанта на белом фоне и сравнить с оригинальной картинкой на репликанте на томже фоне. Желательно чтобы на картинке была тень.
Я подумал
Я подумал сначала, что ты говоришь о SetViewOverlay().
Теперь по–поводу этого кода. Да вывод делается практически так же, но мне непонятно почему SetViewColor(B_TRANSPARENT_COLOR); находится в функции Draw(), ему место в AttachedToWindow(), ну или на худой конец в конструкторе. Да и не B_TRANSPARENT_COLOR а B_TRANSPARENT_32_BIT.
Кстати, баги
Кстати, баги тут нету — тут есть просто моя лень.
Я не дописал одну строчку в обработчик MouseDown ;) из за чего у репликантов границы прямоуголные — отсюда и небольшой глючок при таскании.
Я другое имел
Я другое имел в виду. Попробуй поставить 2 репликанта один поверх другого, чтобы была большая площадь пересечения и потаскай за эту область. Будет таскаться нижний репликант.
Вместо того,
Вместо того, чтобы тут жаловаться всем о злой судьбе, пошел бы в трак и козла запостил.
Постил.
Постил. Разработчики сказали, что виды вообще не должны пересекаться, пересечение даёт неопределённое поведение и вообще пересечение видов не нужно. И закрыли тикет как невалидный.
Переоткрой
Переоткрой и грамотно объясни свою позицию.
Это тикет #6246.
Это тикет #6246. Убедить я врятли смогу. Да и в английском не силён.
Блин, развели
Блин, развели мы тут флудилище.
С днём варенья Хайка!
PS: Подписывайся на майл–листы и учи английский. В противном случае не жалуйся.
Может нужен
Может нужен скриншот, лучше показывающий проблему? Видео с репликантами 3deyes'a не подойдет?
Проблема
Проблема на самом деле гораздо глубже — отсутсвие управляемого z–ордера. Этот баг с перекрытием просто следствие.
Может это уже
Может это уже в отдельной теме обсуждать?
Кстати какая
Кстати какая ревизия?
Какая
Какая разница?
На видео — 37609, а скриншотик, который я выше выкладывал, был сделан ещё в 28242.
С Днём
С Днём Рождения. Ждём ебилдов??
отрадно каждый
отрадно каждый год видеть поздравления. думаю дождусь и релиза
Согласен,
Согласен, действительно отрадно. Но релиза дождаться я все–же не особо надеюсь.
а когда
а когда помирать то собрался?)..ухухух…
Вычисления
Вычисления на мобилках? Я что–то пропустил? Случилась аккумуляторная революция и они теперь в режиме 100%–ой загрузки неделями работают?
Отправить комментарий