Bug 24317 - [META] Невозможно по умолчанию установить приоритет открытия файлов по MIME-типу
Summary: [META] Невозможно по умолчанию установить приоритет открытия файлов по MIME-типу
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: xdg-utils (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: viy
QA Contact: qa-sisyphus
URL:
Keywords: METABUG, usability
: 16208 21656 24307 (view as bug list)
Depends on:
Blocks: 23155
  Show dependency tree
 
Reported: 2010-10-15 16:09 MSD by Andrey Cherepanov
Modified: 2011-06-24 11:13 MSK (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Cherepanov 2010-10-15 16:09:23 MSD
Приоритет приложений при открытии определённого типа MIME зависит от того, когда был поставлен пакет с .desktop-файлом. Это даёт крайне неприятные наведения, как открытие текстовых файлов в OpenOffice.org и Emacs вместо приложения DE по умолчанию. Конечно, это можно переопределить в разных DE, но первичное впечатление будет уже испорчено.
Comment 1 Andrey Cherepanov 2010-10-15 16:10:27 MSD
*** Bug 16208 has been marked as a duplicate of this bug. ***
Comment 2 Andrey Cherepanov 2010-10-15 16:10:33 MSD
*** Bug 21656 has been marked as a duplicate of this bug. ***
Comment 3 Radik Usupov 2010-10-15 19:28:11 MSD
Эм... Я даже не знаю в какую сторону копнуть можно...
Comment 4 Andrey Cherepanov 2010-10-15 19:52:06 MSD
*** Bug 24307 has been marked as a duplicate of this bug. ***
Comment 5 Anton Moiseev 2010-10-15 21:36:20 MSD
>Дубль общего метабага, связанного с невозможностью выставления приложения по
умолчанию. Фактически открываться будет  в последнем установленном пакете,
имеющим этот тип MIME.

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

+1
Comment 22 Radik Usupov 2011-01-14 18:53:09 MSK
Кстати, не это ли нам нужно: 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 Sergey V Turchin 2011-01-14 18:59:49 MSK
Все, что то предлагалось или реализовано сейчас (кроме того, что предложил я):
а) изврат
б) не работает при использовании 2-х разных сред 2-мя разными пользователями на одной системе
Comment 24 Radik Usupov 2011-01-14 19:16:30 MSK
(В ответ на комментарий №23)
> Все, что то предлагалось или реализовано сейчас (кроме того, что предложил я):
#18?
Comment 25 Sergey V Turchin 2011-01-14 20:25:54 MSK
(В ответ на комментарий №24)
> #18?
Да. И #20
Comment 26 AEN 2011-06-24 03:23:20 MSK
2viy@: Игорь, это можно считать исправленным?
Comment 27 viy 2011-06-24 11:13:39 MSK
(В ответ на комментарий №26)
> 2viy@: Игорь, это можно считать исправленным?

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