Board.KolibriOS.org

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

Я бы хотел добавить возможность встраивания иконок в приложения. Нужно научить Icon, Software Widget и Docky добывать иконки из приложений.

Ну... добавляй. Я писал Icon, без проблем могу помочь по разбору и пониманию кода. Увы, но на большее у меня просто нет времени. В принципе, не так много и надо(чисто для icon). Добавить обработку формата ico, добавить вытаскивание ico из ресурсов экзешника, ну и добавление функции выбора файла.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

Есть некоторая идея.
Не требуется правка ядра(ядру информация об иконках реально не нужна), можно просто договориться между программами.

Идея такая:
Будем считать, что в программе сразу после заголовка следует структура:

IconStruct:
Checksum db ? ;  8 bit — контрольная сумма
Size     db ? ;  8 bit — размер иконки
Pointer  dd ? ; 32 bit — указатель на саму иконку

Если контрольная сумма Checksum не совпадает, то иконка либо отсутствует, либо структура не корректна.

Примеры значений Size:

для иконки размером 12x12 Size = 12
для иконки размером 16x16 Size = 16
для иконки размером 24x24 Size = 24
для иконки размером 32x32 Size = 32
и т.п.

Вычисление Checksum можно сделать по примеру libimg (((Width ROL 16) OR Height) XOR Data[0]) аналогично:

Checksum = ((Size ROL 4) OR Size) XOR Pointer[0]

Так можно посчитать Checksum:

GetCheckSum:  
        mov    al, [Size]
        rol    al, 4
        or     al, [Size]
        xor    al, [Pointer]
        mov    [Checksum], al

Проверка корректности структуры:

  Pointer <= FileSize("program.kex") - Size * Size * 4 // 4 — 32-ух битная иконка, 4 байта на пиксель
  GetCheckSum идентично значению Checksum в структуре IconStruct

В принципе можно Checksum считать любым другим способом.
Для уже существующих программ без иконок Checksum будет не совпадать, что будет означать отсутствие иконки — так что, проблем не должно быть.

Альтернативное предложение: будем считать, что с начала файла идут заголовки (подряд друг за другом), каждый заголовок начинается с 8-байтового текстового идентификатора типа заголовка, до тех пор, пока не встретятся неизвестные 8 байт. Уже имеются известные MENUET00..MENUET02 (понятно, что такой заголовок будет первым и в единственном числе). Добавятся вышеописанные ICON12XX..ICON32XX. Кроме того, можно будет и другие типы ресурсов добавлять. Плюс ко всему, можно иметь несколько иконок разных размеров, а файловый менеджер выберет себе наиболее подходящую. После 8-байтового идентификатора можно либо сами данные располагать, либо указатель. Как договоримся.

Привет,
Извини, мне кажется подход 0CodErr сложным.

Я уже думал над этим и пришел к двум вариантам:
1. Иконки по прежнему хранятся в icons32.png, в приложениях только номер иконки (word). Подобрать номер можно тут http://prntscr.com/j5wd36
2. Хранить ini файл в котором названию приложения соответствует номер иконки.

P.S. Я уже написал функцию, которая без лишних телодвижений, так сказать одной строчкой добавляет иконки в окна С-- программ. Пример можно посмотреть в теме про Pixie через несколько минут.

_________________
Звиздеть не мешки ворочать

Ну это уж совсем полная ерунда! А сторонние разработчики как должны в твой icons32.png и ini-файл добавляться?

Также, как и в menu.dat.

_________________
Звиздеть не мешки ворочать

Причём тут menu.dat? У нас там никаких иконок нет, ни путей к ним, ни номеров http://websvn.kolibrios.org/filedetails ... 2Fmenu.dat
Твоё предложение звучит как: Мне сложно сделать по-нормальному, поэтому буду делать "через одно место".
Как раз твой подход и является менее рациональным.
Как минимум, тебе придётся грузить библиотеку libini(которая ещё что-то грузит, вроде libio), а также libimg(которая тоже что-то грузит, вроде archiver) или cnv_png.
А между тем, изображение, встроенное в программу, прекрасно сожмётся kpack-ом и разожмётся(SysFn68.27:LoadFile) и без твоих лишних телодвижений.
Это не считая того, что идея с одним файлом для всех иконок в корне не верная.
Иконка принадлежит самой программе, а вовсе не системе(файловому менеджеру, файлам настроек, каким-либо ещё файлам).
Я как разработчик, распространяя программу, просто включаю в неё иконку. В следующей версии иконка может измениться, при этом в предыдущей версии она останется прежней.

Вроде логично, но я не могу придумать применение другим ресурсам.
Если иконку может захотеть отображать файловый менеджер, то курсоры, звуковые файлы и текст используется только самим приложением.Тоже думал про размеры.
Вообще у нас некоторые программы весят меньше самой иконки Но не суть в принципе.
Преобразовать иконку из 16x16 в 32x32(если нужна именно такого размера) — элементарно.
А вот наоборот(вообще из большей в меньшую) — может получиться не очень.
Может быть тогда массив структур?

struct IconStruct
  Checksum db ? 
  Size     db ? 
  Pointer  dd ? 
ends

IconStruct1 IconStruct ..., ..., ...
IconStruct2 IconStruct ..., ..., ...
IconStruct3 IconStruct ..., ..., ...
.............................................

Поощрение ожирения это плохо.
TLV так между прочим.

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

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

Мне кажется, это не совсем правильно. Как тогда такие файлы с дополнительными данными будут обработаны в других ОС, не знающих про правила KolibriOS?
Да, абсолютно согласен, это — проблема. Хотя если программа не сжатая, то грузить целиком не обязательно.
Ну... теоретически да. Но разве пользователю файла Readme будет не достаточно?
Я вообще против ожирения. Но если говорить конкретно об иконке(её наличие всё-таки было бы полезно), то можно ограничиться только 16x16, а если вдруг кто-то захочет 32x32, то увеличить будет не трудно.
Просто ради интереса сейчас взял иконку .ico 16x16 размером 8,98 КБ (9 198 байт) и преобразовал её в .png, получился файл размером 352 байта(это ещё вместе с png header-ом).
Kpack пожмёт её примерно так же, так что, это не критично.

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

Опять же, если ресурсов 0 (нет иконки) - то и сканировать не придется - это старая программа без ресурсов.

Еще можно сканировать с конца файла по тому же принципу - проще дописать ресурсы в конец, чем править компилятор/линкер ЯВУ

Не согласен. Делать ожирение прорамм, это не разумно. Иметь общий набор иконок намного удобнее и экономичнее.
А если я захочу использовать другой набор иконок, тогда мне все программы перекомпилировать? Иначе получается, что иконки внутри программ, будут висеть мёртвым грузом.
А если иконки внутри программ хранить запакованными, то нужно иметь внутри ещё и распаковщик (который занимает не мало места), или грузить распаковщик из dll (так же, занимает не мало места, только отдельно), да ещё время на распаковку тратится.

Я думаю, предложение Leency, намного разумнее и проще.
В конце концов, иконку можно хранить рядом с программой, в любом удобном формате (raw, bmp, png и т.д.) - если требуется, в сжатом виде (например, kpack).

_________________
The Glass is Always Half Full!

Но зачем??? Есть ведь ядерный http://websvn.kolibrios.org/filedetails ... packer.inc
Выше писал уже про SysFn68.27:LoadFile viewtopic.php?p=70444#p70444
Вот как раз с помощью kpack программы и сжимаются, а значит и данные(в том числе иконки), содержащиеся в них тоже сжимаются.
Ага, вот производители всего на свете софта собрались и запихали все свои иконки в один файл
Если не очень понятно:
Я скачал программу, отредактировал файл .png, отредактировал файл .ini.
Потом мне программа стала не нужна и я её удалил. Соответственно иконка тоже стала на фиг не нужна.
Теперь мне нужно снова редактировать .png(особенно в середине файла весело и особенно из-под самой KolibriOS) и .ini.
А через какое-то время мне вдруг опять понадобилась эта программа.......

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

В TopPanel viewtopic.php?f=9&t=2255 задумана аналогичная возможность: сейчас поддерживается только путь непосредственно к изображению, но можно в будущем расширить до возможности загрузки ресурса.

А вот в Icon viewtopic.php?f=48&t=1515&start=435#p60682 у нас ситуация странная — выбрать можно только из заранее определённого ограниченного количества иконок. А что если я хочу какую-то другую не из того списка?