Icon - менеджер иконок рабочего стола

...
  • 1) Баг исправлен.
    2) Баг в функции удаления секции в libini. Теперь менее не актуален. Раньше для изменения иконки удалялась секция и создавалась заново, теперь удаление секции нужно только в случае удаления иконки, то есть баг будет проявляться гораздо реже.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • 1) Да, теперь иконки отображаются.
    2) Если это баг библиотеки, то нужно исправлять библиотеку. Хотя удаление и создание секции на каждый чих тоже был не верный подход - хорошо, что исправил.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Нужно было либо создать функцию переименования секции либо удалять+создавать секцию, чтобы переименовать иконку. Теперь проще с переименовывать стало.
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • Скажите, а реально ли изменить название иконки "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, остальные имеют значение по умолчанию.
    Attachments
    NEWLNK.ZIP (4.12 KiB)
    Downloaded 326 times
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • GerdtR wrote:Теперь icon принимает IPC-сообщение о том, что нужно создать иконку.
    Не самая лучшая идея использовать эту функцию, хотя для ICON ее скорость не критична, но она с большой долей вероятности будет выпилина в будущем.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • А чем её заменить? Я просто хотел добавить возможность отправить на рабочий стол иконку из того же Eolite, например, или инсталятора (ну, в будущем).
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • GerdtR wrote:А чем её заменить?
    Пока вариант есть только с именованой памятью ф.68.22, 68.23.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Именованную область надо постоянно проверять на наличие запроса на создание новой иконки, а это значит, что нужен бесконечный цикл с некой паузой, значит реакция опять таки будет не мгновенна... IPC медленно, говорите?
    Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
  • GerdtR wrote:Именованную область надо постоянно проверять на наличие запроса на создание новой иконки, а это значит, что нужен бесконечный цикл с некой паузой, значит реакция опять таки будет не мгновенна... IPC медленно, говорите?
    IPC медленно по сравнению с тем как оно теоретически должно работать. Через именованную память намного проще получить большой объем данных.
    А вообще либо ядро, либо приложение осуществляет "бесконечный цикл с некой паузой" и затраты есть всегда.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:А вообще либо ядро, либо приложение осуществляет "бесконечный цикл с некой паузой" и затраты есть всегда.
    Это не так. Ядро может положить поток в список спящих и вообще его не трогать, пока другой поток не попросит его разбудить. Если, конечно, потоки сообщают ядру, чего они хотят, а не пытаются крутить свой собственный цикл ожидания.
    Сделаем мир лучше!
  • CleverMouse
    Я не стану отрицать очевидную вещь - реализация со стороны ядра почти всегда эффективней. Однако это не меняет того факта, что текущая реализация IPC медленная и не самая удобная для передачи больших объемов данных.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Who is online

    Users browsing this forum: Bing [Bot] and 2 guests