В EasyTag в .desktop файле, MimeType прописан следующей строкой: MimeType=audio/x-mp3;application/ogg;x-directory/normal; В итоге, в mimeinfo.cache для типа "x-directory/normal" easytag попадает первым по сравнению с Thunar и Nautilus и на все команды из внешних приложений (вроде Firefox) открывается именно EasyTag.
На самом деле у такой ассоциации есть свой смысл: EasyTag действительно умеет работать с каталогами. Хорошо бы исправить способ определения обработчика по умолчанию, но пока неясно, как это делать. Добровольцы-исследователи welcome.
Полностью согласен с Алексеем - easytag действительно работает с каталогами также, как с отдельными файлами, потому x-directory/normal оправдан. надо разбираться в сортировке.
Коллеги, давайте посмотрим этот вопрос в другом ключе: Сейчас, эта проблема. И вызывает трудности даже у достаточно подготовленных пользователей. Убрав её (например, на время, пока не найдем верного решения) мы ее исправим, но получим лишь небольшую проблему (даже не проблему, а небольшое неудобство) для пользователей EasyTag если они захотят открывать папку с помощью него. Эта проблема легко обходится.
Если сейчас сделать workaround, то нормального исправления не будет ещё долго.
> Если сейчас сделать workaround, то нормального исправления не будет ещё долго. 1.5 месяца прошло... Судя по всему, если исправления не будет никакого. :) Так может сделать workaround?
удаление mime типа создаст новую багу, которую тоже придется чинить. нет, решаться должно только через приоритетах mime типах. к сожалению на исследования у меня времени нет и не будет до конца года :( потому прошу помощи. заапрувить/дать acl/дать nmu всегда смогу.
Ну хорошо. Может sed'ом пробегаться после установки? Что-то типа, sed -i 's/easytag\.desktop\;\(.*\)\;/\1\;easytag\.desktop\;/' /usr/share/applications/mimeinfo.cache Т.е просто ставим easytag.desktop в конец ассоциации (тут я не доработал что это нужно учесть только для типа 'x-directory/normal'). Что скажет уважаемая Team?
Придумал следующий скрипт: sed -i 's/x-directory\/normal\(.*\?\)easytag.desktop;\(.*\);/x-directory\/normal\1\2;easytag.desktop;/' /usr/share/applications/mimeinfo.cache Отрабатывает как надо на локальных данных (даже если что-то стоит впереди easytag в списке, это оставляет на месте а easytag.desktop переносит в конец списка), но увы в post секции это не срабатывает. Есть идеи почему?
Потому что после отработки всех post-скриптов выполняются файловые триггеры. Дальше продолжать?
> Потому что после отработки всех post-скриптов выполняются файловые триггеры. Дальше продолжать? Понятно. Идея тупиковая. Если я правильно понял, обновление mimeinfo.cache происходит постоянно после установки каких-либо пакетов, так? Тогда вся идея с сортировкой бессмысленна - все равно easytag потом будет попадать первым в список x-directory/normal. Поэтому я еще раз предлагаю убрать эту ассоциацию из easytag. В ином случае, как бы мне этого не хотелось, придется собирать пакет в Сизиф с новым именем. :(
(В ответ на комментарий №10) в данный момент я в свободные минуты курю http://freedesktop.org/ на предмет сортировки меню и desktop файлов. докурился пока только до того, что файл-ассоциации могут иметь приоритет. где его расставлять и как я пока не понял, продолжаю вдумчивое вкуривание. > обновление mimeinfo.cache происходит постоянно после установки каких-либо пакетов, так? да. это результат работы update-desktop-files. обновлять надо не его, а easytag.desktop. workaround для данного пакета есть - изменить файл-ассоциацию для easytag в своём каталоге. как это сделать я пока тоже ищу. > В ином случае, как бы мне этого не хотелось, придется собирать пакет в Сизиф с > новым именем. :( войны мантейнеров? это будет интересно. это не решение. более того, найденное вами "решение" с mimeinfo.cache показывает, что делать - делаете, а вот что - не имеете представления. я структуру меню/файл-связей и вообще freedesktop не знаю и пока не буду знать - лечения не будет. узнать я могу либо из документации, либо из объяснений, в том числе ваших. предлагаю поучиться, а не воевать.
> workaround для данного пакета есть - изменить файл-ассоциацию для easytag в своём каталоге. как это сделать я пока тоже ищу. Понятно. Скопировал в .local/share/applications/ файлы easytag.desktop и Thunar-folder-handler.desktop и убрал из первого ассоциацию с x-directory/normal, потом, выполнил update-desktop-database ~/.local/share/applications/ - и теперь везде где нужно Thunar открывает файлы (собственно, в спецификации только это и указано по поводу приоритетов). Для себя, я workaround нашел и теперь мне баг становится не интересен. Спасибо! :)
(В ответ на комментарий №12) > теперь везде где нужно Thunar открывает файлы (собственно, в спецификации > только это и указано по поводу приоритетов). прекрасно! > Для себя, я workaround нашел и теперь мне баг становится не интересен. > Спасибо! :) грустно. бага тогда до нового года провисит точно.
Перевешиваю на более подходящий для этой темы пакет.
(В ответ на комментарий №14) > Перевешиваю на более подходящий для этой темы пакет. Не надо на него больше перевешивать. Выбирайте из easytag, gnome-menus и Thunar P.S. В KDE4 не воспроизводиться (easytag давно стоит и у пользователя ничего не трогано для этого).
Ассоциации файлов не имеют отношения ко gnome-menus, это вопрос того, что записано в desktop-database. zerg@, а каким образом устанавливается приоритет ассоциаций в KDE4?
(В ответ на комментарий №16) > Ассоциации файлов не имеют отношения ко gnome-menus, это вопрос того, что > записано в desktop-database. Это поведение -- продукт обработки меню и маймов Речь-то вообще о чем? XFCE? > zerg@, а каким образом устанавливается приоритет > ассоциаций в KDE4? Как везде. В Dolphin, например, Categories=Qt;KDE;System;FileManager; MimeType=inode/directory; InitialPreference=10 Хотя ни ShowOnlyIn ни NotShowIn не указано. Возможно и в нем и в Thunar нужно что-то из них указать, но, как-минимум, с KDE4/Dolphin ничто пока вперед не лезет
Так же можно извратиться, сделав 2 desktop-файла: а) сделать 2 desktop-файла Один .desktop для всех (без понтов), а 2-й ShowOnlyIn=XFCE,InitialPreference=10 б) 1 desktop-файл с InitialPreference=10,NotShowIn=Всех;Перечислить;
А еще у меня есть патчики для поддержки параметров X-KDE-InitilalPreference и X-KDE4-InitilalPreference Для KDE* они простые, если найдете подобное для того, о чем речь, то решение упрощается
Очень интересно. Видимо, ключиком InitialPreference задаётся приоритет приложения для обработки MIME-типа? Не знал об этом. С другой стороны, в списке ключей в desktop-файлах ключа InitialPreference я не нашёл. Более того, согласно http://standards.freedesktop.org/desktop-entry-spec/1.0/ar01s07.html, "There should be no priority for MIME Types in this field, or any form of priority in the desktop file. Priority for applications is handled external to the .desktop files." Резюме: можно попытаться решить вопрос через ключ InitialPreference, но 1) видимо, придётся для этого патчить все графические среды, использующие механизм desktop-файлов для привязки приложений; 2) это не то что не описанное, а противоречащее спецификации поведение. Интересно, где fd.o-шники предлагают хранить приоритеты вместо desktop-файлов...
В любом случае, похоже, это проблема конкретных приложений, т.е. Nautilus и Thunar в случае inode/directory. (забыл ответить: проблема проявляется и в GNOME, и в XFCE)
Блин, точно! InitialPreference -- KDE-шное :-( http://standards.freedesktop.org/desktop-entry-spec/latest/apb.html Тогда только весла сушить :-(
(In reply to comment #22) > Блин, точно! InitialPreference -- KDE-шное :-( > http://standards.freedesktop.org/desktop-entry-spec/latest/apb.html > > Тогда только весла сушить :-( То есть это не проблема конкретных приложений, а проблема спецификации и утилит, ее обслуживаюзщих?
Боюсь предположить, что на самом деле это может стать проблемой конечного пользователя ;-)
IMHO лучше поискать патчи для реализации InitialPreference
На fd.o было такое вот обсуждение: http://lists.freedesktop.org/archives/xdg/2008-January/009109.html (и далее по треду). Честно говоря, у меня сейчас читать его времени нет, но по-моему, там говорят про то, что нам нужно. В частности, кстати, упоминается некий файл defaults.list, который я у себя в .local/share/applications когда-то даже видел.
~/.local/share/applications/defaults.list не положишь в системный каталог
(В ответ на комментарий №27) > ~/.local/share/applications/defaults.list не положишь в системный каталог Разве что в /usr/share/gnome/куда/нибудь и в /usr/share/xfce/куда/нибудь
Вообще-то .local/share/applications - это, по уже другой спецификации (xdg-base-dir), пользовательский аналог /usr/share/applications. Так что /usr/share/applications/defaults.list должен работать. Другой вопрос, как.
(В ответ на комментарий №29) > /usr/share/applications/defaults.list Такого файла быть не должно. См. #28
(In reply to comment #30) > (В ответ на комментарий №29) > > /usr/share/applications/defaults.list > Такого файла быть не должно. См. #28 Для такого пользовательского безобразия, вроде бы, есть специальный пакет, иль с его помощью вопрос не решить?
(В ответ на комментарий №31) > (In reply to comment #30) > > (В ответ на комментарий №29) > > > /usr/share/applications/defaults.list > > Такого файла быть не должно. См. #28 > Для такого пользовательского безобразия Пользовательское находиться в пользовательском каталоге. Если появиться /usr/share/applications/defaults.list, мне придется запаковать его в altlinux-menus в пустом виде, чтоб никто не зарился.
Согласно http://lists.freedesktop.org/archives/xdg/2009-August/010873.html существование файла /usr/share/applications/defaults.list вполне закономерно, единственное что он используется в Gnome (и наверное Xfce), а в KDE - InitialPreference. Может быть, стоит пересмотреть возможность фикса данного бага с помощью defaults.list?
Если коротко, то будет так, как я написал в #32 Если очень хочется, то /usr/share/gnome/applications/defaults.list или любое другое место, о котором будут знать только те, у кого проблема.
