Дело в том, что иконки находятся в файле icons32.png. Таким образом, надо каждый раз добавлять новую иконку в этот файл для каждого нового приложения.
Я бы хотел добавить возможность встраивания иконок в приложения. Нужно научить Icon, Software Widget и Docky добывать иконки из приложений.
Встраивание иконок в приложения
Ну... добавляй. Я писал Icon, без проблем могу помочь по разбору и пониманию кода. Увы, но на большее у меня просто нет времени. В принципе, не так много и надо(чисто для icon). Добавить обработку формата ico, добавить вытаскивание ico из ресурсов экзешника, ну и добавление функции выбора файла.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Есть некоторая идея.
Не требуется правка ядра(ядру информация об иконках реально не нужна), можно просто договориться между программами.
Идея такая:
Будем считать, что в программе сразу после заголовка следует структура:Если контрольная сумма Checksum не совпадает, то иконка либо отсутствует, либо структура не корректна.
Примеры значений Size:Так можно посчитать Checksum:
Проверка корректности структуры:
В принципе можно Checksum считать любым другим способом.
Для уже существующих программ без иконок Checksum будет не совпадать, что будет означать отсутствие иконки — так что, проблем не должно быть.
Не требуется правка ядра(ядру информация об иконках реально не нужна), можно просто договориться между программами.
Идея такая:
Будем считать, что в программе сразу после заголовка следует структура:
Code: Select all
IconStruct:
Checksum db ? ; 8 bit — контрольная сумма
Size db ? ; 8 bit — размер иконки
Pointer dd ? ; 32 bit — указатель на саму иконку
Примеры значений Size:
- для иконки размером 12x12 Size = 12
для иконки размером 16x16 Size = 16
для иконки размером 24x24 Size = 24
для иконки размером 32x32 Size = 32
и т.п.
Code: Select all
Checksum = ((Size ROL 4) OR Size) XOR Pointer[0]
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 будет не совпадать, что будет означать отсутствие иконки — так что, проблем не должно быть.
Альтернативное предложение: будем считать, что с начала файла идут заголовки (подряд друг за другом), каждый заголовок начинается с 8-байтового текстового идентификатора типа заголовка, до тех пор, пока не встретятся неизвестные 8 байт. Уже имеются известные MENUET00..MENUET02 (понятно, что такой заголовок будет первым и в единственном числе). Добавятся вышеописанные ICON12XX..ICON32XX. Кроме того, можно будет и другие типы ресурсов добавлять. Плюс ко всему, можно иметь несколько иконок разных размеров, а файловый менеджер выберет себе наиболее подходящую. После 8-байтового идентификатора можно либо сами данные располагать, либо указатель. Как договоримся.
Привет,
Извини, мне кажется подход 0CodErr сложным.
Я уже думал над этим и пришел к двум вариантам:
1. Иконки по прежнему хранятся в icons32.png, в приложениях только номер иконки (word). Подобрать номер можно тут http://prntscr.com/j5wd36
2. Хранить ini файл в котором названию приложения соответствует номер иконки.
P.S. Я уже написал функцию, которая без лишних телодвижений, так сказать одной строчкой добавляет иконки в окна С-- программ. Пример можно посмотреть в теме про Pixie через несколько минут.
Извини, мне кажется подход 0CodErr сложным.
Я уже думал над этим и пришел к двум вариантам:
1. Иконки по прежнему хранятся в icons32.png, в приложениях только номер иконки (word). Подобрать номер можно тут http://prntscr.com/j5wd36
2. Хранить ini файл в котором названию приложения соответствует номер иконки.
P.S. Я уже написал функцию, которая без лишних телодвижений, так сказать одной строчкой добавляет иконки в окна С-- программ. Пример можно посмотреть в теме про Pixie через несколько минут.
Из хаоса в космос
Ну это уж совсем полная ерунда! А сторонние разработчики как должны в твой icons32.png и ini-файл добавляться?Leency wrote:1. Иконки по прежнему хранятся в icons32.png, в приложениях только номер иконки (word). Подобрать номер можно тут http://prntscr.com/j5wd36
2. Хранить ini файл в котором названию приложения соответствует номер иконки.
Также, как и в menu.dat.
Из хаоса в космос
Причём тут menu.dat? У нас там никаких иконок нет, ни путей к ним, ни номеров http://websvn.kolibrios.org/filedetails ... 2Fmenu.datLeency wrote:Также, как и в menu.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 так между прочим.
TLV так между прочим.
В качестве другого ресурса, интересного файл-менеджеру может быть версия, описание программы, имя разработчика, короче аналог виндового ресурса - версии программы.0CodErr wrote:Вроде логично, но я не могу придумать применение другим ресурсам.
Ещё, может быть, можно было бы указать, какой программой открывать данный файл, если это файл данных. Можно без указания пути (пусть менеджер сам ищет в определённых каталогах).
Недостаток этого метода, всё-таки, это то, что программу нужно грузить в память, чтобы показать иконку, версию, и т.п. Программа может быть большая (например словарь).
Мне кажется, это не совсем правильно. Как тогда такие файлы с дополнительными данными будут обработаны в других ОС, не знающих про правила KolibriOS?tsdima wrote:Ещё, может быть, можно было бы указать, какой программой открывать данный файл, если это файл данных. Можно без указания пути (пусть менеджер сам ищет в определённых каталогах).
Да, абсолютно согласен, это — проблема. Хотя если программа не сжатая, то грузить целиком не обязательно.tsdima wrote:Недостаток этого метода, всё-таки, это то, что программу нужно грузить в память, чтобы показать иконку, версию, и т.п. Программа может быть большая (например словарь).
Ну... теоретически да. Но разве пользователю файла Readme будет не достаточно?tsdima wrote:В качестве другого ресурса, интересного файл-менеджеру может быть версия, описание программы, имя разработчика, короче аналог виндового ресурса - версии программы.
Я вообще против ожирения. Но если говорить конкретно об иконке(её наличие всё-таки было бы полезно), то можно ограничиться только 16x16, а если вдруг кто-то захочет 32x32, то увеличить будет не трудно.Ray wrote:Поощрение ожирения это плохо.
Просто ради интереса сейчас взял иконку .ico 16x16 размером 8,98 КБ (9 198 байт) и преобразовал её в .png, получился файл размером 352 байта(это ещё вместе с png header-ом).
Kpack пожмёт её примерно так же, так что, это не критично.
Это выглядит более разумным.tsdima wrote:Альтернативное предложение: будем считать, что с начала файла идут заголовки (подряд друг за другом), каждый заголовок начинается с 8-байтового текстового идентификатора типа заголовка, до тех пор, пока не встретятся неизвестные 8 байт. Уже имеются известные MENUET00..MENUET02 (понятно, что такой заголовок будет первым и в единственном числе). Добавятся вышеописанные ICON12XX..ICON32XX. Кроме того, можно будет и другие типы ресурсов добавлять. Плюс ко всему, можно иметь несколько иконок разных размеров, а файловый менеджер выберет себе наиболее подходящую. После 8-байтового идентификатора можно либо сами данные располагать, либо указатель. Как договоримся.
В конец заголовков можно дописать признак конца ресурсов, чтобы не сканировать весь файл.
Опять же, если ресурсов 0 (нет иконки) - то и сканировать не придется - это старая программа без ресурсов.
Еще можно сканировать с конца файла по тому же принципу - проще дописать ресурсы в конец, чем править компилятор/линкер ЯВУ
Не согласен. Делать ожирение прорамм, это не разумно. Иметь общий набор иконок намного удобнее и экономичнее.
А если я захочу использовать другой набор иконок, тогда мне все программы перекомпилировать? Иначе получается, что иконки внутри программ, будут висеть мёртвым грузом.
А если иконки внутри программ хранить запакованными, то нужно иметь внутри ещё и распаковщик (который занимает не мало места), или грузить распаковщик из dll (так же, занимает не мало места, только отдельно), да ещё время на распаковку тратится.
Я думаю, предложение Leency, намного разумнее и проще.В конце концов, иконку можно хранить рядом с программой, в любом удобном формате (raw, bmp, png и т.д.) - если требуется, в сжатом виде (например, kpack).
А если я захочу использовать другой набор иконок, тогда мне все программы перекомпилировать? Иначе получается, что иконки внутри программ, будут висеть мёртвым грузом.
А если иконки внутри программ хранить запакованными, то нужно иметь внутри ещё и распаковщик (который занимает не мало места), или грузить распаковщик из dll (так же, занимает не мало места, только отдельно), да ещё время на распаковку тратится.
Я думаю, предложение Leency, намного разумнее и проще.
Spoiler:
Leency wrote:Я уже думал над этим и пришел к двум вариантам:
1. Иконки по прежнему хранятся в icons32.png, в приложениях только номер иконки (word). Подобрать номер можно тут http://prntscr.com/j5wd36
2. Хранить ini файл в котором названию приложения соответствует номер иконки.
The Glass is Always Half Full!
Но зачем??? Есть ведь ядерный http://websvn.kolibrios.org/filedetails ... packer.incJohnXenox wrote:А если иконки внутри программ хранить запакованными, то нужно иметь внутри ещё и распаковщик (который занимает не мало места), или грузить распаковщик из dll (так же, занимает не мало места, только отдельно)
Выше писал уже про SysFn68.27:LoadFile http://board.kolibrios.org/viewtopic.php?p=70444#p70444
Вот как раз с помощью kpack программы и сжимаются, а значит и данные(в том числе иконки), содержащиеся в них тоже сжимаются.JohnXenox wrote:В конце концов, иконку можно хранить рядом с программой, в любом удобном формате (raw, bmp, png и т.д.) - если требуется, в сжатом виде (например, kpack).
Ага, вот производители всего на свете софта собрались и запихали все свои иконки в один файлJohnXenox wrote:Иметь общий набор
Если не очень понятно:
Я скачал программу, отредактировал файл .png, отредактировал файл .ini.
Потом мне программа стала не нужна и я её удалил. Соответственно иконка тоже стала на фиг не нужна.
Теперь мне нужно снова редактировать .png(особенно в середине файла весело и особенно из-под самой KolibriOS) и .ini.
А через какое-то время мне вдруг опять понадобилась эта программа.......
Вообще некоторые из таких программ, как панели запуска(и им подобные) позволяют указать путь к значкам. И если указать путь к исполняемому файлу, то будет взята иконка из ресурса.
В 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 0 guests