Bug 24317 - [META] Невозможно по умолчанию установить приоритет открытия файлов по MIME-типу
: [META] Невозможно по умолчанию установить приоритет открытия файлов по MIME-типу
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/xdg-utils)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
: METABUG, usability
:
: 23155
  Show dependency tree
 
Reported: 2010-10-15 16:09 by
Modified: 2011-06-24 11:13 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-10-15 16:09:23
Приоритет приложений при открытии определённого типа MIME зависит от того,
когда был поставлен пакет с .desktop-файлом. Это даёт крайне неприятные
наведения, как открытие текстовых файлов в OpenOffice.org и Emacs вместо
приложения DE по умолчанию. Конечно, это можно переопределить в разных DE, но
первичное впечатление будет уже испорчено.
------- Comment #1 From 2010-10-15 16:10:27 -------
*** Bug 16208 has been marked as a duplicate of this bug. ***
------- Comment #2 From 2010-10-15 16:10:33 -------
*** Bug 21656 has been marked as a duplicate of this bug. ***
------- Comment #3 From 2010-10-15 19:28:11 -------
Эм... Я даже не знаю в какую сторону копнуть можно...
------- Comment #4 From 2010-10-15 19:52:06 -------
*** Bug 24307 has been marked as a duplicate of this bug. ***
------- Comment #5 From 2010-10-15 21:36:20 -------
>Дубль общего метабага, связанного с невозможностью выставления приложения по
умолчанию. Фактически открываться будет  в последнем установленном пакете,
имеющим этот тип MIME.

Почему бы не решить проблему запуском дополнительного пост-инстралляционного
скрипта, который бы выправлял порядок приложений для популярных типов файлов
(типа txt/mp3 и т.п)? Не совсем понятен алгоритм решения для общего случая -
для системы все приложения равны, а набор приложений может быть разным, поэтому
частный дистрибуво-специфичный хак на мой взгляд вполне уместен.
------- Comment #6 From 2010-10-15 22:18:24 -------
(В ответ на комментарий №3)
> Эм... Я даже не знаю в какую сторону копнуть можно...
Долбить FreeDesktop.org для допиливания стандарта.
------- Comment #7 From 2010-10-15 22:20:42 -------
(В ответ на комментарий №5)
> Почему бы не решить проблему запуском дополнительного пост-инстралляционного
> скрипта, который бы выправлял порядок приложений для популярных типов файлов
> (типа txt/mp3 и т.п)? Не совсем понятен алгоритм решения для общего случая -
> для системы все приложения равны, а набор приложений может быть разным, поэтому
> частный дистрибуво-специфичный хак на мой взгляд вполне уместен.
Уже обсуждали: сработает только для свежепоставленного дистрибутива. Любой
дополнительный пакет сломает это. Поэтому решать нужно весовыми коэффициентами,
но и это не сработает для пользователей одной системы, использующие разные DE.
------- Comment #8 From 2010-10-15 23:31:21 -------
>Уже обсуждали: сработает только для свежепоставленного дистрибутива. Любой
дополнительный пакет сломает это. Поэтому решать нужно весовыми коэффициентами,
но и это не сработает для пользователей одной системы, использующие разные DE.

В принципе согласен, но мне кажется бага довольно серьезная (более хорошо видно
из другого дубликата: "файлы OpenOffice'а открываются в xarchiver'е"), чтобы
ждать правильного решения от мейнстрима (могут пройти годы - я кстати,
вспоминаю, что это меня уже раздражало несколько лет назад после свежей
установки опенсуси, но после ручных изменений все забывалось, поэтому даже не
отправлял отчет).

Локальный хак со скриптом был бы очень уместен - тем более, что в установщиках
Альт-линукса выбор пакетов на этапе установки не предполагает большого
количества вариантов (как например в той же сусе, где можно пройтись галочками
по всем пакетам дистрибутива), поэтому сам скрипт можно делать не слишком
"умным" - например в юниоре в момент инсталляции гарантированно не будет
kwrite, а будет только gedit и emacs, определить приоритеты которых довольно
просто.

Аргумент с поломкой порядка после доустановки новых приложений справедлив, но
мне кажется он не является достаточным поводом для того, чтобы отклонить
вариант с пост-инсталляционным хаком по многим причинам:
- Проблема проявляет себя сразу же после установки системы. Это фактически
гарантированный повод для интегратора немного покраснеть за систему - типа
"сейчас все поправим" - и при этом рождает необходимость пробежаться вручную по
настройкам приоритетов для каждого миме-типа, про которые он знает (сейчас
известно txt и офисные файлы судя по отчетам выше) - причем для каждого
пользователя - в результате - смазанность первого впечатления от системы
(которое очень важно).
- Доустановка новых приложений, которые бы редактировали файлы txt или doc/odt
во-первых маловероятна - если чего-то и нехватает в дефолтной поставке, то
обычно не текстовых редакторов.
- Во-вторых, доустановка поломает ассоциацию только для одного типа файлов, а
не для всех сразу.
- В-третьих, ручная доустановка уже предполагает некоторую модификацию системы
- пользователь знает, что за программу он ставит и поэтому если его текстовый
файл начнет открываться в kwrite, а не в привычном gedit, его такое положение
дел не удивит (ведь знал же сам, что устанавливает kwrite) - в случае свежей
инсталляции неправильные ассоциации вызывают однозначно негативную реакцию.
- В-четвертых, доустановка скорее всего будет производиться уже позднее - после
первого знакомства с системой - поэтому "первое впечатление" уже избегает
угрозы.
- Для создания скрипта не требуется ожидать продвижения стандарта и дальнейшей
его реализации в апстриме проектов (это не один год точно) - его можно сделать
в рамках личных приоритетов. При этом его не требуется внедрять в апстрим-код
проектов (в которых к хакам могут отноститься не очень хорошо) - он лежит от
них всех сбоку - по сути может являться внутренней частью инсталлятора, который
и так и так каким-то образом кастомизирует дефолтную систему.

В принципе, этого уже достаточно, я так думаю.
------- Comment #9 From 2010-10-16 10:32:38 -------
Согласен, доводы по поводу installer-feature приведены убедительные.
------- Comment #10 From 2010-10-18 15:19:00 -------
(В ответ на комментарий №9)
> Согласен, доводы по поводу installer-feature приведены убедительные.
Убедительно будет, если результат не будет затрагивать любую другую среду,
кроме той, для которой предназначен. Т.е., если устанавливались умолчания для
GNOME, то на XFCE это повлиять не должно.
------- Comment #11 From 2010-10-18 19:15:19 -------
>Убедительно будет, если результат не будет затрагивать любую другую среду,
кроме той, для которой предназначен. Т.е., если устанавливались умолчания для
GNOME, то на XFCE это повлиять не должно.

Не могу проверить, являются ли настройки для миме-приоритетов глобальными для
всей системы, или хранятся отдельно для каждой среды. Подозреваю, что все-таки
первый вариант, так что в случае с множественными средами на одной машине в
любом случае пользователю придется идти на компромисс - какая-то среда будет
основной и глобальные приоритеты mime-приложений будут выставлены для нее.

Вопрос же корректной первоначальной конфигурации разных дистрибутивов с разными
средами решается созданием разных профилей mime-приоритетов для разных сред.
Напирмер, для гнома будет файл txt_mime_priorities_gnome.xml, для xfce
txt_mime_priorities_xfce.xml и т.п.

Инсталлер дистрибутива, основанного на гноме, будет испольвать gnome-профили,
на xfce - профили для xfce.

Даже если дистрибутив будет позволять на этапе установки использовать несколько
сред одновременно (в линейке альтов настолько я знаю таких нет), обычно в таких
случаях на этапе уставноки же предлагается выбирать, какая среда будет для
пользователя основной (в сусе можно выбирать между гномом и кде) - на основе
этого выбора инсталлер будет выбирать правильный профиль mime-приоритетов.
------- Comment #12 From 2010-10-18 19:29:19 -------
(В ответ на комментарий №11)
> любом случае пользователю придется идти на компромисс
Да нифига подобного! Отдельно для каждой следы можно сделать и в системных и в
пользовательских каталогах. (Исключая случаи когда впадлу или руки-крюки)
------- Comment #13 From 2010-10-19 02:46:32 -------
(In reply to comment #12)
> (В ответ на комментарий №11)
> > любом случае пользователю придется идти на компромисс
> Да нифига подобного! Отдельно для каждой следы можно сделать и в системных и в
> пользовательских каталогах. 

Каким образом замечательная возможность иметь отдельные настройки
mime-приоритетов для разных сред противоречит изначальной идее создания модуля
инсталлера, который бы эти приоритеты корректировал?


>(Исключая случаи когда впадлу или руки-крюки)

Эта к чему вообще ремарка?
------- Comment #14 From 2010-10-19 14:03:06 -------
(В ответ на комментарий №13)
> > > в любом случае пользователю придется идти на компромисс
> Каким образом замечательная возможность иметь отдельные настройки
> mime-приоритетов для разных сред противоречит изначальной идее создания модуля
> инсталлера, который бы эти приоритеты корректировал?
Вашим утверждением.

> >(Исключая случаи когда впадлу или руки-крюки)
> Эта к чему вообще ремарка?
К тому, что _уже_ сделали через одно место.
------- Comment #15 From 2010-10-19 14:22:46 -------
(In reply to comment #14)
> (В ответ на комментарий №13)
> > > > в любом случае пользователю придется идти на компромисс
> > Каким образом замечательная возможность иметь отдельные настройки
> > mime-приоритетов для разных сред противоречит изначальной идее создания модуля
> > инсталлера, который бы эти приоритеты корректировал?
> Вашим утверждением.
> 

В коменте 11 про компромиссы во-первых было не утверждение, а предположение; а
во-вторых оно все равно ни коим образом не влияет на первоначальный список
аргументов в пользу создания модуля инсталлера. Если действительно можно иметь
настройки mime-приоритетов для каждой среды - замечательно - пусть этот модуль
будет их корректировать для каждой среды отдельно (при этом для разных сред
будут использоваться разные профили приоритетов) - это уже детали реализации.
------- Comment #16 From 2010-10-19 14:44:24 -------
(В ответ на комментарий №15)
> В коменте 11 про компромиссы во-первых было не утверждение, а предположение;
Словосочетание "в любом случае" для вас означает предположение? Тогда без меня.
------- Comment #17 From 2010-10-19 15:01:24 -------
(In reply to comment #16)
> (В ответ на комментарий №15)
> > В коменте 11 про компромиссы во-первых было не утверждение, а предположение;
> Словосочетание "в любом случае" для вас означает предположение? Тогда без меня.

>Подозреваю, что все-таки первый вариант, .. в любом случае пользователю
___Подозреваю___

Вы читаете предложения с середины? или может дойдя до середины забываете то, с
чего оно начиналось? а может вам просто нравится намеренно выхватывать слова из
контекста и флудить не попытавшись разобраться в сути вопроса? пожалуй
действительно лучше без вас.
------- Comment #18 From 2010-10-26 15:55:46 -------
В более правильных GNOME-ах есть /etc/gnome/defaults.list
Продолжайте дальше толочь воду в ступе.
------- Comment #19 From 2010-10-26 22:46:30 -------
(В ответ на комментарий №18)
> В более правильных GNOME-ах есть /etc/gnome/defaults.list
> Продолжайте дальше толочь воду в ступе.
И кто его будет заполнять? И что делать с DE неарийского происхождения?
------- Comment #20 From 2010-11-13 15:32:42 -------
(В ответ на комментарий №19)
> > В более правильных GNOME-ах есть /etc/gnome/defaults.list
> И кто его будет заполнять?
Мантейнер пакета с этим файлом.

> И что делать с DE неарийского происхождения?
То же самое, но в другом каталоге.
------- Comment #21 From 2011-01-14 18:51:25 -------
(В ответ на комментарий №9)
> Согласен, доводы по поводу installer-feature приведены убедительные.

+1
------- Comment #22 From 2011-01-14 18:53:09 -------
Кстати, не это ли нам нужно: xdg-mime: correct install text to use
type/subtype.
В новом rc1:
http://cgit.freedesktop.org/portland/xdg-utils/tree/ChangeLog?id=v1.1.0-rc1
------- Comment #23 From 2011-01-14 18:59:49 -------
Все, что то предлагалось или реализовано сейчас (кроме того, что предложил я):
а) изврат
б) не работает при использовании 2-х разных сред 2-мя разными пользователями на
одной системе
------- Comment #24 From 2011-01-14 19:16:30 -------
(В ответ на комментарий №23)
> Все, что то предлагалось или реализовано сейчас (кроме того, что предложил я):
#18?
------- Comment #25 From 2011-01-14 20:25:54 -------
(В ответ на комментарий №24)
> #18?
Да. И #20
------- Comment #26 From 2011-06-24 03:23:20 -------
2viy@: Игорь, это можно считать исправленным?
------- Comment #27 From 2011-06-24 11:13:39 -------
(В ответ на комментарий №26)
> 2viy@: Игорь, это можно считать исправленным?

да, теперь задача расстановки приоритетов MIME возложена на пакет
altlinux-mime-defaults.