Board.KolibriOS.org

То, что сделано поистине потрясающе. За короткое время, я так понял, написано много компонентов, которые до этого на ассемблере писались очень долго... но были написаны Марио. Это касается скролла и динамической кнопки (прогресс бара нет). И теперь, я не понимаю зачем дублировать компоненты и плодить разные интерфейсы.
P.S. Загрука процессора на скрине)

P.S. Загрука процессора на скрине)

Потому что были запущены програмные таймеры, вызывающие перерисовку ProgressBar-а каждые 50 миллисекунд.
Хотя загрузку можно и уменьшить. Есть идеи. Надо будет поэкспериментировать.

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

Кто нибудь знает готовые алгоритмы выделения кучи малого размера по 48-128 байт?
А то сейчас под структуры в 20-140 байт выделяется одна страница в 4096 байт. Это расточительство.

ЕМНИП был когдато менеджер памяти приложений, но вроде бы он на 64 функцию был завязан.
Можно написать свой менеджер памяти приложений. Работа правда нетривиальная и может занять немало времени.
А что мешает статически использовать области данных? В бинарник оно все равно не вставляется.

вызывающие перерисовку ProgressBar-а каждые 50 миллисекунд.

Весьма сомнительное решение, мы (форумное программистское сообщество) вроде начали отходить от такого подхода. Если не было события со стороны пользователя, системы или других приложений, то зачем?

Leency

которые до этого на ассемблере писались очень долго... но были написаны Марио. Это касается скролла и динамической кнопки (прогресс бара нет)

Поправка!
1) Долго писались не компоненты, а zSea. На самый сложный компонент - ScrollBar ушло максимум 1,5 месяца. MenuBar- 1 месяц, DinamicButton - 2 недели. Однако надо учитывать, что работал я далеко не каждый день, в среднем по 1-1,5 часа на один реальный день пришлось.
2) Написать код для единственного приложения это одно, а вот продумать, реализовать и отладить универсальный стык для применения во многих приложениях - задача немного более сложная, но решаемая.
3) Прогресс бар есть - нужен всего лишь перенос кода из KFM с минимальными изменениями, будет сразу после FileBrowser (текущий прогресс 50-60%).
4) Спрашивать автора зачем он пишет код - ИМХО бессмыслено. Потому что хочет!

Весьма сомнительное решение, мы (форумное программистское сообщество) вроде начали отходить от такого подхода. Если не было события со стороны пользователя, системы или других приложений, то зачем?

Можно обновлять прогресс бар и 1 раз после изменений значения прогресса. В библиотеке много чего предусмотрено. Всё зависит от конкретного случая. Просто обновление по таймеру даёт возможность добавить анимацию прогресса как в Ubuntu, для тех кому очень нравиться красота.

А что мешает статически использовать области данных? В бинарник оно все равно не вставляется.

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

Просто обновление по таймеру даёт возможность добавить анимацию прогресса как в Ubuntu, для тех кому очень нравиться красота

Палка о двух концах - на слабых машинах (да даже на нормальных) используя лишь Vesa режим получится не очень хорошо.
А вообще у меня ALT Linux работает с выкрученными по минимуму эффектами и не колышит, что GTS250.

Если использовать libGUI при написании интернет браузера, то там контролы будут динамически создаваться и динамически удаляться после закрытия страницы.

... при реализации MDI - однако не скоро будет.

Жаль, что примеры не запускаются под KlbInWin ...

Жаль, что примеры не запускаются под KlbInWin ...

Ну это уже не моя вина. Я писал код под настоящую систему. Под ней код работает.
Почему KlbInWin не может загрузить библиотеку - я не знаю. Возможно из-за того, что эта библиотека на самом деле объектный файл формата COFF, а не чисто правильно написанная DLL формата COFF.
Это вопрос к diamond-у.

в демке с одной кнопкой надпись "Кликни мой" ("мое"? "мою"?) странновата.. // по скриншотам супер) по количеству кода в примере - тоже) ждемс ассемблерного SDK..

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

Обновление библиотеки libGUI.

1)Контролы ScrolledWindow и ProgressBar отрисовываются в буфере перед выводом на экран(выводятся как картинка). В результате исчезли мигания при скроллинге контролов.
2)Теперь даже при отрисове ProgressBar-а по таймеру уровень загрузки процессора почти нулевой.
3) Оптимизация по размеру и скорости(отрисовка контролов) исправления некоторых багов(связаны с рисованием контролов).

Ну и в доказательство своих слов привожу скриншот.

Перерисовка и загрузка процессора очень порадовала. На счёт дизайна, то меня очень впечатлил дизайн ХайкуОС:
http://www.solargate.ru/files/u2/024_2_haiku.png скролл
http://revolf.free.fr/beos/shots/shot_h ... rd_001.png скролл
http://1.bp.blogspot.com/_Yldyc-8fvoc/S ... Haiku3.png кнопочки
Однако, не стоит забывать что у нас не Виндлоус и не Хайку, потому надо оставаться самим собой. К тому же, мне нравится оригинальный дизайн кнопок Колибри и скролла из БоксЛиб. Кстати, последний можно склонировать.

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

andrew_programmer
Чтобы не было моргания надо окно без заливки фона отрисовывать и выводить элементы последовательно для контрола, например скроллбар отрисовывать: верхняя кнопка, верхний промежуток, бегунок, нижний промежуток, нижняя кнопка. Т.е. нельзя рисовать сразу весь фон, а потом поверх него бегунок, потому что получается чередование контрасных цветов и с какой бы скоростью не производилась отрисовка будет моргание. Если правильно вывести, то необходимость в буфере отпадает.

andrew_programmer wrote:Нам нужен какой-то свой дизайн(или несколько дизайнов с возможностью их менять).

Да, возможность менять темы нужна обязательно!

Mario

Чтобы не было моргания надо окно без заливки фона отрисовывать и выводить

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

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

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

Если правильно вывести, то необходимость в буфере отпадает.

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