Встраивание иконок в приложения

All that makes Kolibri beautiful outside while we are working inside
  • Ну... добавляй. Я писал Icon, без проблем могу помочь по разбору и пониманию кода. Увы, но на большее у меня просто нет времени. В принципе, не так много и надо(чисто для icon). Добавить обработку формата ico, добавить вытаскивание ico из ресурсов экзешника, ну и добавление функции выбора файла.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • Есть некоторая идея.
    Не требуется правка ядра(ядру информация об иконках реально не нужна), можно просто договориться между программами.

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

    Code: Select all

    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]) аналогично:

    Code: Select all

    Checksum = ((Size ROL 4) OR Size) XOR Pointer[0]
    Так можно посчитать Checksum:

    Code: Select all

    GetCheckSum:  
            mov    al, [Size]
            rol    al, 4
            or     al, [Size]
            xor    al, [Pointer]
            mov    [Checksum], al
    
    Проверка корректности структуры:

    Code: Select all

      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 через несколько минут.
    Из хаоса в космос
  • Leency wrote:1. Иконки по прежнему хранятся в icons32.png, в приложениях только номер иконки (word). Подобрать номер можно тут http://prntscr.com/j5wd36
    2. Хранить ini файл в котором названию приложения соответствует номер иконки.
    Ну это уж совсем полная ерунда! А сторонние разработчики как должны в твой icons32.png и ini-файл добавляться?
  • Также, как и в menu.dat.
    Из хаоса в космос
  • Leency wrote:Также, как и в menu.dat.
    Причём тут menu.dat? У нас там никаких иконок нет, ни путей к ним, ни номеров http://websvn.kolibrios.org/filedetails ... 2Fmenu.dat
    Leency wrote:Извини, мне кажется подход 0CodErr сложным.
    Твоё предложение звучит как: Мне сложно сделать по-нормальному, поэтому буду делать "через одно место".
    Как раз твой подход и является менее рациональным.
    Как минимум, тебе придётся грузить библиотеку libini(которая ещё что-то грузит, вроде libio), а также libimg(которая тоже что-то грузит, вроде archiver) или cnv_png.
    А между тем, изображение, встроенное в программу, прекрасно сожмётся kpack-ом и разожмётся(SysFn68.27:LoadFile) и без твоих лишних телодвижений.
    Это не считая того, что идея с одним файлом для всех иконок в корне не верная.
    Иконка принадлежит самой программе, а вовсе не системе(файловому менеджеру, файлам настроек, каким-либо ещё файлам).
    Я как разработчик, распространяя программу, просто включаю в неё иконку. В следующей версии иконка может измениться, при этом в предыдущей версии она останется прежней.
  • tsdima wrote:можно будет и другие типы ресурсов добавлять
    Вроде логично, но я не могу придумать применение другим ресурсам.
    Если иконку может захотеть отображать файловый менеджер, то курсоры, звуковые файлы и текст используется только самим приложением.
    tsdima wrote:Плюс ко всему, можно иметь несколько иконок разных размеров, а файловый менеджер выберет себе наиболее подходящую.
    Тоже думал про размеры.
    Вообще у нас некоторые программы весят меньше самой иконки :) Но не суть в принципе.
    Преобразовать иконку из 16x16 в 32x32(если нужна именно такого размера) — элементарно.
    А вот наоборот(вообще из большей в меньшую) — может получиться не очень.
    Может быть тогда массив структур?

    Code: Select all

    struct IconStruct
      Checksum db ? 
      Size     db ? 
      Pointer  dd ? 
    ends
    
    IconStruct1 IconStruct ..., ..., ...
    IconStruct2 IconStruct ..., ..., ...
    IconStruct3 IconStruct ..., ..., ...
    .............................................
  • Поощрение ожирения это плохо.
    TLV так между прочим.
  • 0CodErr wrote:Вроде логично, но я не могу придумать применение другим ресурсам.
    В качестве другого ресурса, интересного файл-менеджеру может быть версия, описание программы, имя разработчика, короче аналог виндового ресурса - версии программы.
    Ещё, может быть, можно было бы указать, какой программой открывать данный файл, если это файл данных. Можно без указания пути (пусть менеджер сам ищет в определённых каталогах).

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

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

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

    Я думаю, предложение Leency, намного разумнее и проще.
    Spoiler:
    Leency wrote:Я уже думал над этим и пришел к двум вариантам:
    1. Иконки по прежнему хранятся в icons32.png, в приложениях только номер иконки (word). Подобрать номер можно тут http://prntscr.com/j5wd36
    2. Хранить ini файл в котором названию приложения соответствует номер иконки.
    В конце концов, иконку можно хранить рядом с программой, в любом удобном формате (raw, bmp, png и т.д.) - если требуется, в сжатом виде (например, kpack).
    The Glass is Always Half Full! :mrgreen:
  • JohnXenox wrote:А если иконки внутри программ хранить запакованными, то нужно иметь внутри ещё и распаковщик (который занимает не мало места), или грузить распаковщик из dll (так же, занимает не мало места, только отдельно)
    Но зачем??? :shock: Есть ведь ядерный http://websvn.kolibrios.org/filedetails ... packer.inc
    Выше писал уже про SysFn68.27:LoadFile http://board.kolibrios.org/viewtopic.php?p=70444#p70444
    JohnXenox wrote:В конце концов, иконку можно хранить рядом с программой, в любом удобном формате (raw, bmp, png и т.д.) - если требуется, в сжатом виде (например, kpack).
    Вот как раз с помощью kpack программы и сжимаются, а значит и данные(в том числе иконки), содержащиеся в них тоже сжимаются.
    JohnXenox wrote:Иметь общий набор
    Ага, вот производители всего на свете софта собрались и запихали все свои иконки в один файл :lol: :lol: :lol:
    Если не очень понятно:
    Я скачал программу, отредактировал файл .png, отредактировал файл .ini.
    Потом мне программа стала не нужна и я её удалил. Соответственно иконка тоже стала на фиг не нужна.
    Теперь мне нужно снова редактировать .png(особенно в середине файла весело и особенно из-под самой KolibriOS) и .ini.
    А через какое-то время мне вдруг опять понадобилась эта программа....... :mrgreen:

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

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

    А вот в Icon http://board.kolibrios.org/viewtopic.ph ... 435#p60682 у нас ситуация странная — выбрать можно только из заранее определённого ограниченного количества иконок. А что если я хочу какую-то другую не из того списка?
  • Who is online

    Users browsing this forum: No registered users and 7 guests