Board.KolibriOS.org

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

Понимаешь программы бывают 2-х видов:
1) Написано чтобы работало, потому особых свистоперделок не наблюдается, из примеров: Miranda (базовая комплектация), Apollo, Total Commander, Far, Unreal Commander, Notepad++, FileZilla FTP ... в общем примеров достаточно.
2) Написано чтобы было красиво, со свистоперделками, рюшечками, раскладными подставкам для ног, встроенными холодильниками и вообще что Бог на душу положит...
Программы второй категории делятся на:
2.1) Те которые вопреки свистоперделкам (но никак не благодаря) работают: Opera, FastStone Image Viewer, Foxit, KMplayer, Tortoise SVN... в общем примеров достаточно.
2.2) Те которые благодаря свистоперделкам работают криво или жрут ресурсы немерянно. Я не буду их перечислять потому что пользователи этих программ с пеной у рта начнут доказывать что я не прав. (У ти моя пусечка, у ти моя хорошая - мы еще с тобой захватим этот поганый мир и установим в нем мир и справедлиовость по нашему разумению, которое априори самое правильное...)

andrew_programmer

Не всё так просто. Контролы могут покрывать не всю площадь окна. Если не рисовать фон, то окно окажется "дырявым". В окне вообще может быть только 2-3 контрола. Один контрол выводит сообщение пользователю, а остальные предлагают выбрать варианты действий.
Поэтому нужно отключать рисование фона под контролами, но при этом библиотека должна сама вычислять "дыры"(если они есть) и заполнять их цветом фона. Этот алгоритм пока ещё не реализован, поэтому фон под контролами отрисовываеться.

Это уже забота программиста приложения, всех вариантов заранее не предусмотришь - есть дырка вызывай 13 функцию и заливай, или вызывай 65 и заливай скином.

У меня ScrollBar так и рисуется. И ProgressBar также рисовался, только текст поверх него мигал, вот я и ввёл буферизацию. К тому же если выводить текст на ProgressBar-е масштабируемым шрифтом, то нужно производить сглаживание геометрических примитивов, чтобы шрифт казался ровным и гладким. Без буферизации изображения ScrollBar-а этого не сделать. Так что я одним решением избавился сразу от двух проблем.

Абсолютно не понял причем тут скроллбар применительно к тексту? На нем то текст не рисуется.

Если количество этих дыр велико, то нужно будет рисовать множество прямоугольников на экране, что потребует немалой загрузки процессора. Лучше уж рисовать в буфере, тем более, что у меня буферы динамические. То есть после использования(после вывода на экран) он освобождается, а не остаётся "висеть" в памяти занимая её.

Но согласись должна быть соблюдена золотая середина. Если можно обойтись без буфера (пусть даже динамически выделяемого), то почему бы и не обойтись. В BoxLib только один элемент использует буфер это MenuBar, остальные отрисовываются без взсяких буферов. Согласен, что твой прогресбар с надписью требует буферизации, но скроллбар то можно и без буфера.

andrew_programmer wrote:Не всё так просто. Контролы могут покрывать не всю площадь окна. Если не рисовать фон, то окно окажется "дырявым". В окне вообще может быть только 2-3 контрола. Один контрол выводит сообщение пользователю, а остальные предлагают выбрать варианты действий.
Поэтому нужно отключать рисование фона под контролами, но при этом библиотека должна сама вычислять "дыры"(если они есть) и заполнять их цветом фона. Этот алгоритм пока ещё не реализован, поэтому фон под контролами отрисовываеться.

По-хорошему, контролы должны быть дочерними окнами, и за тем, чтобы отрисовка фона в основном окне их не затрагивала, должен следить оконный менеджер (как сейчас он отслеживает, что отрисовка не трогает соседние окна).

Mario, что плохого в возможности менять темы оформления? GTK и QT давно умеют, и вопреки этому всё-таки работают

Ну, дык я и говрю - если автору не лень будет отлаживать это дело то хорошо, а если будет написано исключительно ради красоты и плевать на стабильность. производительность и потребление памяти, то печально будет.

В данном случае радует серьёзное отношение автора к делу. Так что сделает, скорее всего, хорошо))
А в идеале хорошо бы для Колибри вообще новую графическую оболочку...

Согласен, что твой прогресбар с надписью требует буферизации, но скроллбар то можно и без буфера.

Он и рисуется без буфера. Я имел ввиду, что рисуется он на экране без всяких лишних перерисовок. При первичной отрисовке рисуется весь контрол. Потом рисуются только меняющиеся части. То есть полоса до ползунка с одной стороны, ползунок и полоса после ползунка.

По-хорошему, контролы должны быть дочерними окнами, и за тем, чтобы отрисовка фона в основном окне их не затрагивала, должен следить оконный менеджер (как сейчас он отслеживает, что отрисовка не трогает соседние окна).

Только не при том оконном менеджере, который сейчас есть в Колибри. Он восстанавливает фон под окном полной перерисовкой всех нижележащих окон(хоть и не затрагивая перекрывающиеся области). Проведите эксперимент. Запустите, например, файловый менеджер. Поверх него поместите окно Tinypad-а. А потом быстро походите по его менюшкам. В результате увидите мигания при перерисовке окон, расположенных под меню. И это на современном компьютере. Я когда проделал это на старом, то наблюдал крайне неприятное слайд-шоу. Из-за примитивного метода восстановления фона под окнами, возникают мигания при перерисовке и сами меню выбираются медленно.
В windows и linux мы не наблюдаем миганий и тормозов. Незнаю насчёт windows, но в linux для отрисовки исползуется буферизация. Оконный менеджер Kolibri позволяет экономить память, но при этом возникают проблемы со скоростью работы и качеством перерисовки. Как говорят ,"палка о двух концах". Хочешь экономить память, рисуй без буфера, но с мерцаниями, хочеш мез мерцаний - используй буффер. Кстати, в VESA курсор нужно рисовать не напрямую на экране, а в буфере, накладывая его изображение на часть скопированного в память изображения фона. И выводить наложенный курсор на экран. Так и делает X-сервер. Потому там курсор в VESA и не мигает.

Атауальпа

А в идеале хорошо бы для Колибри вообще новую графическую оболочку...

Термин "Графическая оболочка" используется, если рисованием графики и окон в системе руководит процесс, работающий в user-mode, а не ядро операционной системы. В KolibrOS отрисовкой графичиских объектов и управлением окнами занимается ядро операционной системы. То есть графика встроена в ядро и никакой оболочки нет.

"То есть графика встроена в ядро и никакой оболочки нет." то что нет никакой оболочки, не значит что нельзя создать новую (она сама по себе будет новой), так что в словах Атауальпы никакой ошибки нет, и я к ним присоединяюсь)

andrew_programmer
У меня конструктивное предложение - возможно имеет смысл переместить libGUI в папку libraries, которая находится рядом. Все таки логичней соблюдать некоторые правила, чтобы уменьшить рост энтропии.

Я о том же самом подумал. Думаю буду вносить новые изменения в библиотеку и перемещу её в папку libraries. Делать перенос в папку отдельной ревизией что-то не хочется.

Хорошая работа. Main впечатлила.

Почему KlbInWin не может загрузить библиотеку - я не знаю.

Странно библиотека прерасно грузится KlbInWin, надо только положить её в директорию lib, в той папке которую ты выделил под рамдиск.

Странно библиотека прерасно грузится KlbInWin, надо только положить её в директорию lib, в той папке которую ты выделил под рамдиск.

У меня не работает. Наверное из-за Windows. Она у меня ужасно глючит. Каждый второй запуск приводит к внезапному вылетанию в перезагрузку. А переустановить windows нельзя иначе у меня grub затрёться и я не смогу грузить linux.

У меня тоже не работало (я перешёл с Windows на MacOS).