Board.KolibriOS.org

Для нового стиля скроллинга, в котором будет различный цвет треугольников и линий вокруг скроллинга думаю нужно будет найти одно из 2-х решений. В скроллинге есть 3 цвета, а значит нужно использовать их или же добавлять 4-й цвет, и тут возникает 2 варианта:
1) сделать что-бы цвет линий вокруг скроллинга вычислялся как средний цвет между фоном скроллинга и фоном ползунка
2) добавить еще один новый цвет для задания цвета линий вокруг скроллинга
В обоих случаях цвет треугольников на кнопках должен задаваться пользователем (программой)

думаю надо добавить

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!

Я произвел небольшую реорганизацию по расположению макросов в SVN ревизии 1432:
1) Все макросы и данные используемые сторонними приложениями для работы с библиотекой теперь собраны в box_lib.mac, причем эти же макросы могут и использоваться и самой библиотекой при необходимости.
2) Список всех подключаемых макросов, которые используются исключительно для компиляции самой библиотеки теперь располагается в файле bl_sys.mac

Теперь зачем это сделано.
Репозиторий SVN является по сути эталонным хранилищем и в его локальных копиях саму разработку обычно не ведут. Следовательно приходится копировать файлы какого-либо проекта в отдельную директорию и тащить в каждую такую директорию все макросы не имеет смысла. Куча файлов и 90% кода которых не использовалось собственно для компиляции сторонних приложений, а исключительно для самой BoxLib.
Теперь достаточно скопировать только box_lib.mac и и изменить путь в include.

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

SVN ревизия 1433.
Новый компонент PathShow - предназначен для отображения пути к файлу или директории, с усечением имени похожим на усечение выводимое FAR'ом, если не влазит в область выделенную для вывода. В текущем виде поддерживает оба системных шрифта, однако если добавить 3 и 4 системные шрифты (зарезервированные биты под них все еще имеются в 4-й функции), то сможет их поддерживать без переделки компонента.
Сокращение выполняется по принципу 6+3+N:

/hd0/1...example_dir/example_file
/rd/1/...example_dir/example_file

Пример использования в ctrldemo.asm - желтая полоска, теперь текст не выходит за ее пределы.

SVN ревизия 1457
Новый компонент text_editor предназначен для создания окон текстовых редакторов. В Win есть элемент CRichCtrl, а в Колибри text_editor. Можно использовать его в своих программах, но примеров использования (кроме редактора t_edit.kex) я пока не успел сделать. В t_edit.kex используются все возможные функции компонента, потому как пример для изучения он не очень подходит. Может скоро сделаю более простые примеры.

ревизия 1464
Доработал компонент text_editor, пришлось добавить в структуру 2 параметра типа dword, в связи с чем версию элемента изменил с 1 на 2. Теперь немного быстрее работает функция ted_text_add (добавление текста). Также при редактировании текста возможно расширение памяти через ф. 68.20.

---

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

SVN rev. 1479 - исправил парсинг значений из INI файла для отображения иконок в компоненте Filebrowser. На всех тестовых файлах теперь подставляется корректное значение. Ранее для более коротких расширений могла использоваться неправильная ассоциация и в результате подставлялась неправильная иконка. Просьба сообщить, если кто-нибудь заметит в OpenDialog некорректную ассоциацию иконок, не соответствующую icons.ini в последующих ночных сборках.

В ночной сборке от 22 августа (с ревизии 1576, думаю) эдитбоксы пишут "Ш" при отпускании клавиш.

Угу, в svn.1576 недосмотрел.
Fixed in svn.1579.

SVN rev. 1597 - компонент MenuBar теперь динамически использует память под хранение RAW изображения (которое было под областью отрисовки меню, до его отрисовки). Ранее код выделял память при первом обращении и она была занята постоянно. Теперь приложения использующие этот компонент уменьшат количество статично выделенной памяти, что позволит снизить растрату ОЗУ.

К примеру в OpenDialog резервирование буфера самого большого меню "Select disk" у меня занимало 28 Кб и они всегда были выделены статично, теперь они освобождаются как только меню схлопывается. Общее накопление буферов в приложении давало немалый вес к объему занимаемому приложением.

... и увеличат нагрузку на процессор.

_________________
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда.

1) Если замеришь и докажешь увеличение нагрузки хотя бы в 1 % - я откачу изменения. Если нет, в следующий раз мотивируй более сильно свои претензии.
2) Своим заявлением ты час выразил недоверие не только мне, но и автору текущего менеджера памяти ядра.
3) Если бы включил МОСК и подумал, то понял бы что в конкретный момент времени из всех окон в системе активным является только одно, а из всех меню в этом окне только то на которое пользователь кликнул. Причем операции по перераспределению памяти происходят исключительно в моменты раскрывания и схлопывания меню. Надо очень быстро кликать мышкой по менюшкам, чтобы вообще хоть как то нагрузить менеджер памяти, а уж об измерении такой загрузки задумываться вообще сложно.

З.Ы. Я как ни посмотрю - в какой теме не появишься только и делаешь, что бурчишь и споришь со всеми почти. Месячные что ли?

У меня появилась идея по усовершенствованию библиотеки box_lib, подобные мысли я читал на форуме в теме про libGui. Идея такова, присоединить к библиотеке box_lib одну из библиотек работающих с графическими буферами (на данный момент таких библиотек я знаю 2: buf2d (моя) и pixlib). Что это в итоге может дать:
1) каждый элемент сможет создавать свой буфер (аналог контекста окна в Win), в который элемент сможет себя рисовать в фоновом режиме
2) при выводе сложных элементов на экран уменьшится мерцание, т.к. буфер будет выводится весь сразу системной ф. 7.
При этом прийдеться менять код библиотеки box_lib и коды прорисовки тех элементов, которые будут работать с экраном через буфер. Каково мнение колектива, стоит ли начинать подобные преобразования. (Думаю в большинстве случаев многие скажут: "делай что хочешь, никто никого не держит")

Надо подумать в каких случаях это целесообразно:
1) это потратит дополнительную память на буфер. В идеале было бы хорошо предусмотреть переключение использовать или не использовать буфер - это актуально для тех компьютеров где мало памяти.
2) не всегда нужно выводить заново всю область - иначе это повысит нагрузку на отрисовку. Нужно придумать как выводить только ту область, которая изменилась в буфере.
3) Такой буфер точно актуален при наличии масштабируемых шрифтов. Вот там он действительно пригодится - изображение усложнится значительно.
4) Желательна минимальная переделка существующих приложений или вообще ее отсутствие. Box_Lib уже во многих приложениях используется и каждое дополнительное их изменение отнимает время от других дел.

Такое изменение потребует следующих действий:
1) Пристыковки buf2d к box_lib для этого макрос @use_library нужно будет заменить на

@use_library_mem mem.Alloc,mem.Free,mem.ReAlloc, dll.Load

Можно сделать, что-бы указатель на функцию dll.Load был по умолчанию равен 0 и в случае использования макроса @use_library он меняться не будет. Старые элементы на этот 0-й указатель реагировать не будут, а новые использующие буфер восприймут его как указание работать без буфера. Потому на приложения использующие не измененные элементы этот этап никак не повлияет.
2) По мере необходимости менять коды конкретных элементов. В код элемента нужно будет добавить указатель на структуру буфера и возможно стиль, который будет указывать использовать ли буфер или нет. Структура буфера возможно будет создаваться динамически (тогда будет меньше изменений в вызывающей программе), а может будет статично сидеть в программе (тогда будет больше изменений в вызывающей программе). Тут параллельно должны меняться коды всех приложений использующих меняющиеся элементы, потому буферизировать можно редко используемые элементы, что позволит делать меньше изменений. Когда появится больше свободного времени и желание, тогда можно будет буферизировать часто встречаемые элементы (например editbox).

Есть еще одно преимущество использования буфера, а именно координаты рисуемых в буфере объектов будут задаватся без учета свойств top и left самого элемента управления.