Это легко сделано для единственного типа файла, как отвечено в том, Как связать тип файла в Вине с исходным приложением?, путем создания a .reg
для желаемого типа файла. Но это для AVI только. Я использую некоторые винные приложения (uTorrent, Soulseek, Eudora, для именования некоторых), который может запустить широкий спектр файлов. Почтовые вложения, например, могут быть JPG, DOC, PDF, PPS... его невозможное (и не желательные) для разыскивания всех возможных типов файлов, которые можно получить в электронном письме или загрузке в потоке.
Так я neeed решение быть более универсальным и широким. Мне нужна ассоциация файлов для удостаивания независимо от того, что исходное приложение в настоящее время настраивается. И я хочу, чтобы это было сделано для всех типов файлов, настроенных в моей системе.
Я уже выяснил, как сделать решение универсальным. Просто заменяя запущенное приложение в .reg
для winebrowser
, как это:
[HKEY_CLASSES_ROOT\.pdf]
@="PDFfile"
"Content Type"="application/pdf"
[HKEY_CLASSES_ROOT\PDFfile\Shell\Open\command]
@="C:\\windows\\system32\\winebrowser.exe \"%1\""
Я протестировал это, и это работает правильно. С тех пор winebrowser использование xdg-open
как бэкенд, и преобразовывает мой путь окон к Unix один, корректное (Linux), приложение запускается.
Таким образом, мне нужен "пакет" updater к реестру вина, виду a wine-update-associations
скрипт, который я могу запустить каждый раз, когда новое приложение установлено. Возможно, инструмент, который может:
Хитрая часть: я искал МНОГО для нахождения информации о том, как ассоциация сделана в Ubuntu 10.10 вперед, и документация недостаточна и сбивает с толку по меньшей мере. Freedesktop.org не имеет никакой полной спецификации, и даже документы Gnome являются устаревшими. До сих пор я собрал 4 файла, которые содержат информацию об ассоциации, но я невежествен, на котором (или почему) для использования, или как можно использовать их для генерации .reg
файл:
~/.local/share/applications/mimeapps.list
~/.local/share/applications/miminfo.cache
/usr/share/applications/miminfo.cache
/etc/gnome/defaults.list
Любая справка, сценарий или объяснение значительно ценились бы!
Спасибо!
Несколько лет спустя, я сделал маленькую утилиту, которая сканирует базу данных MIME (и система и пользователь), и зарегистрируйте все известные собственные типы пантомимы в реестре Windows.
Это использует xdg-open
открыть файл, если существует (собственное) приложение по умолчанию для того типа пантомимы, иначе использует packagekit
искать пакет, который может обработать тот файл (точно так же, как то, что Наутилус делает). Так мое начальное требование регистрации только расширения, которые имеют установленное, исходное приложение, больше были не нужны. Однако ранняя версия сценария действительно фильтровала только такие типы. Отрывок, который позволил, был:
perl -e '
use strict; use warnings;
use File::MimeInfo::Magic; use File::MimeInfo::Applications;
while (my $line = <STDIN>) {
chomp($line);
my ($ext, $mime) = (split/\t/, $line);
my ($def, @apps) = mime_applications_all($mime);
print "$line\n" if ($def || @apps)
}'
По умолчанию мой сценарий только регистрирует собственные типы, которые не имеют никакого обработчика в реестре окон, но он может также переопределить такие ассоциации (таким образом, например, jpeg файлы открыты в собственном средстве просмотра вместо винного браузера Геккона по умолчанию). Это может также проигнорировать некоторые расширения, даже если у них нет обработчика в окнах.
Это старается изо всех сил быть winemenubuilder-дружественным, означая все ассоциации, которые это создает, не публикуется как собственные ассоциации (или как x-wine-extension mimetypes) winemenubuilder, который был бы ужасен и потенциально вызвал бы циклы. Это очень хитро и еще прекрасно, особенно с расширениями смешанного случая (.C и.c, например)
Тем не менее я надеюсь, что этот сценарий является helful для всех:
https://github.com/MestreLion/wine-tools/blob/master/wine-import-extensions
Приветствующиеся улучшения!
Править:
Существует винная ошибка об этом - который является большим количеством улучшения, чем ошибка. Точка должна иметь ShellExecute
звонить xdg-open
, и если не найденный, ищите гнома и kde значения по умолчанию. Необходимо смочь применить патч и наконец иметь волшебство :-). Это решение является более чистым, поскольку ему не нужно питание с реестром.
Чтобы быть больше завершенное вот - то, как исправить и скомпилировать вино из источника.
РЕДАКТИРОВАНИЕ КОНЦА
Я обновляю винный реестр со сценарием ниже для добавления списка типов общего файла.
Можно расширить список для добавления большего количества типов.
Это использует /usr/bin/gnome-open
в gstart.exe
файл, таким образом, это не будет работать на рабочие столы негнома, как.
Вставьте это conf_wine.sh
:
#!/bin/bash
SRC=~
WINE=~/.wine
REG=$WINE/system.reg
GSTART=gstart.exe
GSTART_TARGET=$WINE/drive_c
EXE_TARGET=$WINE/drive_c/windows
FNKEY=/tmp/"key"$(date +%F_%H-%M-%S)".reg"
[ -e $FNKEY ] && { echo "temporary key file exists..try again"; exit 1; }
echo "copying gstart.exe"
cp $SRC/$GSTART $GSTART_TARGET
chmod +x $GSTART_TARGET
echo "backing up the registry"
cp $REG $REG.$(date +%F_%H-%M-%S).old
echo "setting new wine registry keys"
for i in http doc docx ppt pptx xls xlsx odt ods xml txt pdf odt svg zip ; do {
echo "setting $i"
key='[HKEY_CLASSES_ROOT\.'$i']
@="'$i'file"
"Content Type"="application/'$i'"
[HKEY_CLASSES_ROOT\'$i'file\Shell\Open\command]
@="C:\\gstart.exe \"%1\""'
echo "$key" > $FNKEY
regedit $FNKEY
}
done
echo "done"
gstart.exe
сценарий удара.. и мост к обоим мирам:
#!/bin/bash
OPEN_HANDLER=/usr/bin/gnome-open
# logging, optional
LOG=$HOME/.wine/gstart.exe-log.$(id -u -n)
echo "[ $(date) ] $# argument(s) received: '$@'" > $LOG
# convert the path
RESULT=$(winepath "$@" 2> /dev/null)
echo "$OPEN_HANDLER $RESULT" >> $LOG
TMP=$TMPDIR
TEMP=$TMPDIR
# finally open the file
$OPEN_HANDLER "$RESULT"
Примечания:
gstart.exe
в Вашем текущем рабочем каталоге перед выполнением conf_wine.sh
поскольку это скопирует его в .wine
папка.gstart.exe
не должен находиться в c:\
.Вино FAQ: Как я связываю собственную программу с типом файла в Вине?
Я собрал Информацию повсеместно и нашел, что следующее работает:
Я создал файл под названием ~/.wine/drive_c/gstart.exe
со следующим:
#!/bin/bash
OPEN_HANDLER=/usr/bin/xdg-open
# logging, optional
LOG=$HOME/.wine/gstart.exe-log.$(id -u -n)
echo "[ $(date) ] $# argument(s) received: '$@'" > $LOG
# convert the path
RESULT=$(winepath "$@" 2> /dev/null)
echo "$OPEN_HANDLER $RESULT" >> $LOG
TMP=$TMPDIR
TEMP=$TMPDIR
# finally open the file
$OPEN_HANDLER "$RESULT"
Затем: Созданный файл под названием linuxnative.reg в моем ~ / мусорное ведро
со следующим:
REGEDIT4
[HKEY_CLASSES_ROOT\.doc]
@="linuxnative"
"Content Type"="application/linuxnative"
[HKEY_CLASSES_ROOT\.rtf]
@="linuxnative"
"Content Type"="application/linuxnative"
[HKEY_CLASSES_ROOT\.odt]
@="linuxnative"
"Content Type"="application/linuxnative"
[HKEY_CLASSES_ROOT\.pdf]
@="linuxnative"
"Content Type"="application/linuxnative"
[HKEY_CLASSES_ROOT\.tif]
@="linuxnative"
"Content Type"="application/linuxnative"
[HKEY_CLASSES_ROOT\.doc]
@="linuxnative"
"Content Type"="application/linuxnative"
[HKEY_CLASSES_ROOT\.docx]
@="linuxnative"
"Content Type"="application/linuxnative"
[HKEY_CLASSES_ROOT\.jpg]
@="linuxnative"
"Content Type"="application/linuxnative"
[HKEY_CLASSES_ROOT\linuxnative]
[HKEY_CLASSES_ROOT\linuxnative\shell]
[HKEY_CLASSES_ROOT\linuxnative\shell\open]
[HKEY_CLASSES_ROOT\linuxnative\shell\open\command]
@="c:\\gstart.exe \"%1\""
затем Вы делаете a
regedit linuxnative.reg
Надеюсь, это поможет.