Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Dec 14, 2019 2:48 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 400 posts ]  Go to page Previous 16 7 8 9 1027 Next
Author Message
PostPosted: Thu Feb 18, 2010 9:05 pm 
Offline
User avatar

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


Top
   
PostPosted: Thu Feb 18, 2010 11:12 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
думаю надо добавить

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


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

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

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


Top
   
PostPosted: Mon Mar 15, 2010 10:50 pm 
SVN ревизия 1433.
Новый компонент PathShow - предназначен для отображения пути к файлу или директории, с усечением имени похожим на усечение выводимое FAR'ом, если не влазит в область выделенную для вывода. В текущем виде поддерживает оба системных шрифта, однако если добавить 3 и 4 системные шрифты (зарезервированные биты под них все еще имеются в 4-й функции), то сможет их поддерживать без переделки компонента.
Сокращение выполняется по принципу 6+3+N:
Code:
/hd0/1...example_dir/example_file
/rd/1/...example_dir/example_file

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


Top
   
PostPosted: Thu Apr 29, 2010 9:34 pm 
Offline
User avatar

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


Top
   
PostPosted: Mon May 17, 2010 8:01 pm 
Offline
User avatar

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


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


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


Top
   
PostPosted: Mon Aug 23, 2010 12:30 am 
Offline
Mentor
User avatar

Joined: Mon Oct 19, 2009 10:58 am
Posts: 442
В ночной сборке от 22 августа (с ревизии 1576, думаю) эдитбоксы пишут "Ш" при отпускании клавиш.


Top
   
PostPosted: Mon Aug 23, 2010 2:27 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
dunkaist wrote:
В ночной сборке от 22 августа (с ревизии 1576, думаю) эдитбоксы пишут "Ш" при отпускании клавиш.

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


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

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


Top
   
PostPosted: Mon Aug 30, 2010 7:56 pm 
Offline
User avatar

Joined: Sat Feb 20, 2010 1:27 pm
Posts: 41
Mario wrote:
Теперь приложения использующие этот компонент уменьшат количество статично выделенной памяти

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

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


Top
   
PostPosted: Mon Aug 30, 2010 8:21 pm 
konstantin_666. wrote:
Mario wrote:
Теперь приложения использующие этот компонент уменьшат количество статично выделенной памяти

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

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

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


Top
   
PostPosted: Wed Sep 01, 2010 11:12 pm 
Offline
User avatar

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


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


Top
   
PostPosted: Thu Sep 02, 2010 12:29 am 
Offline
User avatar

Joined: Mon Oct 27, 2008 10:10 pm
Posts: 813
Такое изменение потребует следующих действий:
1) Пристыковки buf2d к box_lib для этого макрос @use_library нужно будет заменить на
Code:
@use_library_mem mem.Alloc,mem.Free,mem.ReAlloc, dll.Load

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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 400 posts ]  Go to page Previous 16 7 8 9 1027 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited