Bug 24317

*** Bug 16208 has been marked as a duplicate of this bug. ***

*** Bug 21656 has been marked as a duplicate of this bug. ***

Эм... Я даже не знаю в какую сторону копнуть можно...

*** Bug 24307 has been marked as a duplicate of this bug. ***

>Дубль общего метабага, связанного с невозможностью выставления приложения по
умолчанию. Фактически открываться будет  в последнем установленном пакете,
имеющим этот тип MIME.

Почему бы не решить проблему запуском дополнительного пост-инстралляционного скрипта, который бы выправлял порядок приложений для популярных типов файлов (типа txt/mp3 и т.п)? Не совсем понятен алгоритм решения для общего случая - для системы все приложения равны, а набор приложений может быть разным, поэтому частный дистрибуво-специфичный хак на мой взгляд вполне уместен.

(В ответ на комментарий №3)
> Эм... Я даже не знаю в какую сторону копнуть можно...
Долбить FreeDesktop.org для допиливания стандарта.

(В ответ на комментарий №5)
> Почему бы не решить проблему запуском дополнительного пост-инстралляционного
> скрипта, который бы выправлял порядок приложений для популярных типов файлов
> (типа txt/mp3 и т.п)? Не совсем понятен алгоритм решения для общего случая -
> для системы все приложения равны, а набор приложений может быть разным, поэтому
> частный дистрибуво-специфичный хак на мой взгляд вполне уместен.
Уже обсуждали: сработает только для свежепоставленного дистрибутива. Любой дополнительный пакет сломает это. Поэтому решать нужно весовыми коэффициентами, но и это не сработает для пользователей одной системы, использующие разные DE.

>Уже обсуждали: сработает только для свежепоставленного дистрибутива. Любой
дополнительный пакет сломает это. Поэтому решать нужно весовыми коэффициентами,
но и это не сработает для пользователей одной системы, использующие разные DE.

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

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

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

В принципе, этого уже достаточно, я так думаю.

Согласен, доводы по поводу installer-feature приведены убедительные.

(В ответ на комментарий №9)
> Согласен, доводы по поводу installer-feature приведены убедительные.
Убедительно будет, если результат не будет затрагивать любую другую среду, кроме той, для которой предназначен. Т.е., если устанавливались умолчания для GNOME, то на XFCE это повлиять не должно.

>Убедительно будет, если результат не будет затрагивать любую другую среду,
кроме той, для которой предназначен. Т.е., если устанавливались умолчания для
GNOME, то на XFCE это повлиять не должно.

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

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

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

Даже если дистрибутив будет позволять на этапе установки использовать несколько сред одновременно (в линейке альтов настолько я знаю таких нет), обычно в таких случаях на этапе уставноки же предлагается выбирать, какая среда будет для пользователя основной (в сусе можно выбирать между гномом и кде) - на основе этого выбора инсталлер будет выбирать правильный профиль mime-приоритетов.

(В ответ на комментарий №11)
> любом случае пользователю придется идти на компромисс
Да нифига подобного! Отдельно для каждой следы можно сделать и в системных и в пользовательских каталогах. (Исключая случаи когда впадлу или руки-крюки)

(In reply to comment #12)
> (В ответ на комментарий №11)
> > любом случае пользователю придется идти на компромисс
> Да нифига подобного! Отдельно для каждой следы можно сделать и в системных и в
> пользовательских каталогах. 

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


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

Эта к чему вообще ремарка?

(В ответ на комментарий №13)
> > > в любом случае пользователю придется идти на компромисс
> Каким образом замечательная возможность иметь отдельные настройки
> mime-приоритетов для разных сред противоречит изначальной идее создания модуля
> инсталлера, который бы эти приоритеты корректировал?
Вашим утверждением.

> >(Исключая случаи когда впадлу или руки-крюки)
> Эта к чему вообще ремарка?
К тому, что _уже_ сделали через одно место.

(In reply to comment #14)
> (В ответ на комментарий №13)
> > > > в любом случае пользователю придется идти на компромисс
> > Каким образом замечательная возможность иметь отдельные настройки
> > mime-приоритетов для разных сред противоречит изначальной идее создания модуля
> > инсталлера, который бы эти приоритеты корректировал?
> Вашим утверждением.
> 

В коменте 11 про компромиссы во-первых было не утверждение, а предположение; а во-вторых оно все равно ни коим образом не влияет на первоначальный список аргументов в пользу создания модуля инсталлера. Если действительно можно иметь настройки mime-приоритетов для каждой среды - замечательно - пусть этот модуль будет их корректировать для каждой среды отдельно (при этом для разных сред будут использоваться разные профили приоритетов) - это уже детали реализации.

(В ответ на комментарий №15)
> В коменте 11 про компромиссы во-первых было не утверждение, а предположение;
Словосочетание "в любом случае" для вас означает предположение? Тогда без меня.

(In reply to comment #16)
> (В ответ на комментарий №15)
> > В коменте 11 про компромиссы во-первых было не утверждение, а предположение;
> Словосочетание "в любом случае" для вас означает предположение? Тогда без меня.

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

Вы читаете предложения с середины? или может дойдя до середины забываете то, с чего оно начиналось? а может вам просто нравится намеренно выхватывать слова из контекста и флудить не попытавшись разобраться в сути вопроса? пожалуй действительно лучше без вас.

В более правильных GNOME-ах есть /etc/gnome/defaults.list
Продолжайте дальше толочь воду в ступе.

(В ответ на комментарий №18)
> В более правильных GNOME-ах есть /etc/gnome/defaults.list
> Продолжайте дальше толочь воду в ступе.
И кто его будет заполнять? И что делать с DE неарийского происхождения?

(В ответ на комментарий №19)
> > В более правильных GNOME-ах есть /etc/gnome/defaults.list
> И кто его будет заполнять?
Мантейнер пакета с этим файлом.

> И что делать с DE неарийского происхождения?
То же самое, но в другом каталоге.

(В ответ на комментарий №9)
> Согласен, доводы по поводу installer-feature приведены убедительные.

+1

Кстати, не это ли нам нужно: xdg-mime: correct install text to use type/subtype.
В новом rc1: http://cgit.freedesktop.org/portland/xdg-utils/tree/ChangeLog?id=v1.1.0-rc1

Все, что то предлагалось или реализовано сейчас (кроме того, что предложил я):
а) изврат
б) не работает при использовании 2-х разных сред 2-мя разными пользователями на одной системе

(В ответ на комментарий №23)
> Все, что то предлагалось или реализовано сейчас (кроме того, что предложил я):
#18?

(В ответ на комментарий №24)
> #18?
Да. И #20

2viy@: Игорь, это можно считать исправленным?

(В ответ на комментарий №26)
> 2viy@: Игорь, это можно считать исправленным?

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