Board.KolibriOS.org

2) Кажется, Вы помогли выловить один баг. Я его раньше иногда встречал, но никак не получалось повторить. В libini где-то, видимо, ещё ошибка и при подобном изменении портиться ini-файл(взгляните в icon.ini на секцию [board]).
1) В образе старый вариант icon.ini, а он, разумеется не подходит. В свн я заменил на новый, что-то ещё надо сделать, что бы в образ попал именно новый icon.ini?

1) Баг исправлен.
2) Баг в функции удаления секции в libini. Теперь менее не актуален. Раньше для изменения иконки удалялась секция и создавалась заново, теперь удаление секции нужно только в случае удаления иконки, то есть баг будет проявляться гораздо реже.

1) Да, теперь иконки отображаются.
2) Если это баг библиотеки, то нужно исправлять библиотеку. Хотя удаление и создание секции на каждый чих тоже был не верный подход - хорошо, что исправил.

Нужно было либо создать функцию переименования секции либо удалять+создавать секцию, чтобы переименовать иконку. Теперь проще с переименовывать стало.

Скажите, а реально ли изменить название иконки "DOCPAK" на "Документация"?
Не все, кто пользуется Операционными Системами знают английский. Читателей этого пака может стать немного больше...
Заранее спасибо!

Хм, 12 букв... многовато, больше 11 нельзя. Хотя поправить ограничение недолго (вроде, правки одних констант достаточно будет), но я пока точно этим не займусь, интернета почти нет.

Документац. Сделать такое несложно, но ведь тогда нужно еще перевести и на другие языки.

Теперь icon принимает IPC-сообщение о том, что нужно создать иконку. Формат сообщения такой:

Spoiler:

dd X
dd Y
asciiz Icon
asciiz Name
asciiz Path
asciiz Params

Сообщения принимает самый первый поток @icon (и PID у него будет, разумеется, наименьший). Ниже прилагаю программу, берущую на себя всю работу с IPC и поиском процесса @icon. Принимает данные в параметрах, например:
-x 128 -y 256 -icon 3 -name "MyLink" -path "/rd/1/run" -param my params
После ключа -icon идёт номер нужной иконки (кавычки не нужны), параметры -name и -path обязательно заключаются в двойные ковычки, а всё, что после ключа -param это параметры иконки (сделал так, потому что в параметре к иконке тоже могут быть ковычки, так что -param обязательно последний из ключей). Из всех ключей обязательный только -path, остальные имеют значение по умолчанию.

GerdtR wrote:Теперь icon принимает IPC-сообщение о том, что нужно создать иконку.

Не самая лучшая идея использовать эту функцию, хотя для ICON ее скорость не критична, но она с большой долей вероятности будет выпилина в будущем.

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

GerdtR wrote:А чем её заменить?

Пока вариант есть только с именованой памятью ф.68.22, 68.23.

Именованную область надо постоянно проверять на наличие запроса на создание новой иконки, а это значит, что нужен бесконечный цикл с некой паузой, значит реакция опять таки будет не мгновенна... IPC медленно, говорите?

GerdtR wrote:Именованную область надо постоянно проверять на наличие запроса на создание новой иконки, а это значит, что нужен бесконечный цикл с некой паузой, значит реакция опять таки будет не мгновенна... IPC медленно, говорите?

IPC медленно по сравнению с тем как оно теоретически должно работать. Через именованную память намного проще получить большой объем данных.
А вообще либо ядро, либо приложение осуществляет "бесконечный цикл с некой паузой" и затраты есть всегда.

Mario_r4 wrote:А вообще либо ядро, либо приложение осуществляет "бесконечный цикл с некой паузой" и затраты есть всегда.

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

CleverMouse
Я не стану отрицать очевидную вещь - реализация со стороны ядра почти всегда эффективней. Однако это не меняет того факта, что текущая реализация IPC медленная и не самая удобная для передачи больших объемов данных.