Board.KolibriOS.org

Занимаясь прикручиванием OpenDialog к приложениям, дошла очередь и до приложения Icon. Я думал просто прикрутить к приложению OpenDialog, но посмотрев на размер занимаемый программой в памяти (более 600 Кб) я полез смотреть код и честно говоря он мне не очень нравится. В свое время менеджер иконок был объединен с собственно самой программой ради экономии пространства на рамдиске. Такое объединение вылилось в распухание кода. К тому же в приложении используется статичное выделение памяти - т.е. надо или не надо но 600 килобайт будут потрачены.

Хотя если прикинуть при текущем максимальном количестве иконок в 48 штук (кстати сказать их реально используется еще меньше - около 27), максимальные потребности памяти в структурах данных такие: 48*32*32*4 (4 байта = 32 бита = 24 бита цвет и 8 бит альфа-канал) = 192 Кб + 4 Кб (выводимый буфер в котором фон смешивается с самой иконкой учитывая альфа-канал) = 196 Кб. Это собственно на данные.
Еще если прикинуть размер занимаемый OpenDialog в памяти (учитывая все загруженные библиотеки) 152 Кб, но Icon не будет содержать менеджер иконок, а это значит минус Box_Lib. Пусть для самого худшего случая будет 100 Кб. Далее на каждую иконку будем динамически выделять стек (не важно мультипоточный или не мультипоточный Icon - промежуточные данные все равно нужно где-то хранить) в 4 Кб, потому что менеджер памяти ядра меньше не может выделить из-за архитектурных особенностей центрального процессора. 48*4=192 Кб.

Итого получаем размер 192+100+192=484 Кб и это в самом худшем случае, когда присутствуют все 48 иконок. При 27 иконках будет 192+100+108=400 Кб. В любом случае меньше текущего Icon. Но это опять же наихудший прогноз, скорее всего память будет потребляться еще меньше.

Из возможных плюсов новой реализации:
1) Иконки глубиной цвета в 24 бита и альфа каналом, пожатые в PNG, который к слову сжимает в большинстве случаев лучше чем GIF.
2) Можно сделать регулируемым размер иконок. Какие пользователь положил, такие система и выведет. Разумеется в разумных пределах - иконки 128*128 могут попросту не влезть на рамдиск..
3) Можно вернуть эффект вращения иконок и сделать его опциональным. Это потребует около 8 Кб на данные вращающейся иконки при размере 32*32.
4) Можно попытаться реализовать все в одном потоке - хотя это очень непросто с текущими возможностями ядра.

Собственно мне нужна помощь в подборе полноцветных иконок и подготовка их в формате 24+8 бит. Такое можно сделать например в Gimp. Я могу и сам попробовать сделать, но дизайнер из меня не важный, да и время отнимает. Можно даже несколько наборов иконок сделать и положить их потом в архив дистрибутива, чтобы пользователю было из чего выбирать, также как например со скинами окошек.

32-х битные иконки - это здорово!
Думаю, можно невозбранно взять свободный набор иконок. Например, oxygen (по лицензиям gpl или ccsa).
А можно и самим нарисовать. В конце концов, теперь не нужно будет ограничиваться 256 цветами для всех иконок, и поэтому наборы иконок будет делать гораздо проще.
Готов предложить свою посильную помощь

в гимпе не силён... на фотошопе попробую нарисовать чё-нить

Думаю что для рисования иконок удобно использовать программу Inkscape http://ru.wikipedia.org/wiki/Inkscape . Ее я использовал для рисования игры Nu_pogodi. Она создает изображения в векторном формате, которые можно экспортировать в png (с прозрачностью). Могу в случае необходимости нарисовать иконку по образцу, дизайнер из меня слабый.
Векторные редакторы при изменении размеров какраз то что нужно, в отличие от растровых.

Mario
возможность использования полноцветных изображений в качестве иконок и возвращение эффекта вращения это ИМХО здорово. а зачем делать ICON однопоточным?

Рад что тема вызвала живой отклик, жду готовые иконки.

Albom
В принципе не обязательно это делать, но с другой стороны у нас только 256 возможных потоков в текущей системе и один из них всегда занят самим ядром. Конечно при нормальной работе исчерпать 255 потоков сложно. В общем нужно подумать.

Мне кажется, что 255 потоков могут закончиться очень даже быстро... Сейчас в моем linux'е запущено около 160 процессов, хотя не запушен ни десяток шеллов, ни eclipse, ни куча редакторов с множеством внешних фильтров.
Я конечно понимаю, что понятие "unixway" к Колибри неприменимо.
Но 30 процессов на иконки - это как-то многовато...

Наборк иконок из всем известной GNOME. Для любителей.
http://www.iconspedia.com/dload.php?up_id=60229
Под лицензией GPL, в архиве список авторов и иконки 32x32, 48x48 и 64x64

Спасибо для экспериментов как раз.

Мне подумалось... Один поток - одно окно?
То есть запуск программы иконкой приведет к "всплыванию" всех иконок над окнами. Правильно понимаю?

Если не исхитрятся и делать обычными методами, то да. Я пока не придумал как это можно сделать.

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

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

Veliant wrote:На сколько знаю можно же рисовать на фоновом изображении через системный вызов?

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

Хотя лично мне идея отрисовки иконок из отдельного приложения не нравится.
Этим должно заниматься ядро, а "менеджер иконок" мог бы лишь менять дефолтные настройки посредством редактирования системной базы данных

Mario

Надо добавить два новых вызова. Первый для отрисовки в пределах рабочего стола с двумя опциями - перед всеми окнами и за всеми окнами.

Это позволит сделать отрисовку всех иконок в один поток и перетаскивание иконок c отрисовкой.

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