2) Кажется, Вы помогли выловить один баг. Я его раньше иногда встречал, но никак не получалось повторить. В libini где-то, видимо, ещё ошибка и при подобном изменении портиться ini-файл(взгляните в icon.ini на секцию [board]).
1) В образе старый вариант icon.ini, а он, разумеется не подходит. В свн я заменил на новый, что-то ещё надо сделать, что бы в образ попал именно новый icon.ini?
Icon - менеджер иконок рабочего стола
-
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
1) Баг исправлен.
2) Баг в функции удаления секции в libini. Теперь менее не актуален. Раньше для изменения иконки удалялась секция и создавалась заново, теперь удаление секции нужно только в случае удаления иконки, то есть баг будет проявляться гораздо реже.
2) Баг в функции удаления секции в libini. Теперь менее не актуален. Раньше для изменения иконки удалялась секция и создавалась заново, теперь удаление секции нужно только в случае удаления иконки, то есть баг будет проявляться гораздо реже.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
1) Да, теперь иконки отображаются.
2) Если это баг библиотеки, то нужно исправлять библиотеку. Хотя удаление и создание секции на каждый чих тоже был не верный подход - хорошо, что исправил.
2) Если это баг библиотеки, то нужно исправлять библиотеку. Хотя удаление и создание секции на каждый чих тоже был не верный подход - хорошо, что исправил.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Нужно было либо создать функцию переименования секции либо удалять+создавать секцию, чтобы переименовать иконку. Теперь проще с переименовывать стало.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Скажите, а реально ли изменить название иконки "DOCPAK" на "Документация"?
Не все, кто пользуется Операционными Системами знают английский. Читателей этого пака может стать немного больше...
Заранее спасибо!
Не все, кто пользуется Операционными Системами знают английский. Читателей этого пака может стать немного больше...
Заранее спасибо!
Хм, 12 букв... многовато, больше 11 нельзя. Хотя поправить ограничение недолго (вроде, правки одних констант достаточно будет), но я пока точно этим не займусь, интернета почти нет.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Документац. Сделать такое несложно, но ведь тогда нужно еще перевести и на другие языки.
Теперь icon принимает IPC-сообщение о том, что нужно создать иконку. Формат сообщения такой:
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, остальные имеют значение по умолчанию.
Spoiler:
dd Xdd Y
asciiz Icon
asciiz Name
asciiz Path
asciiz Params
-x 128 -y 256 -icon 3 -name "MyLink" -path "/rd/1/run" -param my params
После ключа -icon идёт номер нужной иконки (кавычки не нужны), параметры -name и -path обязательно заключаются в двойные ковычки, а всё, что после ключа -param это параметры иконки (сделал так, потому что в параметре к иконке тоже могут быть ковычки, так что -param обязательно последний из ключей). Из всех ключей обязательный только -path, остальные имеют значение по умолчанию.
- Attachments
-
-
NEWLNK.ZIP (4.12 KiB)Downloaded 334 times
-
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Не самая лучшая идея использовать эту функцию, хотя для ICON ее скорость не критична, но она с большой долей вероятности будет выпилина в будущем.GerdtR wrote:Теперь icon принимает IPC-сообщение о том, что нужно создать иконку.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
А чем её заменить? Я просто хотел добавить возможность отправить на рабочий стол иконку из того же Eolite, например, или инсталятора (ну, в будущем).
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Пока вариант есть только с именованой памятью ф.68.22, 68.23.GerdtR wrote:А чем её заменить?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Именованную область надо постоянно проверять на наличие запроса на создание новой иконки, а это значит, что нужен бесконечный цикл с некой паузой, значит реакция опять таки будет не мгновенна... IPC медленно, говорите?
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
IPC медленно по сравнению с тем как оно теоретически должно работать. Через именованную память намного проще получить большой объем данных.GerdtR wrote:Именованную область надо постоянно проверять на наличие запроса на создание новой иконки, а это значит, что нужен бесконечный цикл с некой паузой, значит реакция опять таки будет не мгновенна... IPC медленно, говорите?
А вообще либо ядро, либо приложение осуществляет "бесконечный цикл с некой паузой" и затраты есть всегда.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Это не так. Ядро может положить поток в список спящих и вообще его не трогать, пока другой поток не попросит его разбудить. Если, конечно, потоки сообщают ядру, чего они хотят, а не пытаются крутить свой собственный цикл ожидания.Mario_r4 wrote:А вообще либо ядро, либо приложение осуществляет "бесконечный цикл с некой паузой" и затраты есть всегда.
Сделаем мир лучше!
CleverMouse
Я не стану отрицать очевидную вещь - реализация со стороны ядра почти всегда эффективней. Однако это не меняет того факта, что текущая реализация IPC медленная и не самая удобная для передачи больших объемов данных.
Я не стану отрицать очевидную вещь - реализация со стороны ядра почти всегда эффективней. Однако это не меняет того факта, что текущая реализация IPC медленная и не самая удобная для передачи больших объемов данных.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Who is online
Users browsing this forum: No registered users and 2 guests