Проверил, работает. Спасибо, весьма оперативно.Попробуй эту версию
MultiArc
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
Кто-нибудь может проверить открытие d MultiArc 1.4.3.160 инсталлятора GIMP 2.8.22? Чё-т никак... Конфиг.
Как там насчет Юникода? Практичных причин для использования Multiarc и так особо много не найти, но без Юникода он так окаменелостью и остаётся.
И заодно: нелишне бы уже спустя столько-то лет с выхода Висты учитывать, что по-умолчанию ini в папке Тотала хранить не положено. Там в простом виде (по %COMMANDER_INI%) двух строчек же достаточно.
И заодно: нелишне бы уже спустя столько-то лет с выхода Висты учитывать, что по-умолчанию ini в папке Тотала хранить не положено. Там в простом виде (по %COMMANDER_INI%) двух строчек же достаточно.
helb
Честно говоря, я не совсем понял цель предыдущего поста. Если у вас не особо много причин для использования Multiarc, то у других они вполне могут быть в достаточном количестве. Даже без Юникода. А что касается INI-файлов, у меня, например, определённый набор INI-файлов лежит в папке TC, но multiarc.ini — в папке плагина. Безотносительно к тому, что там кому положено по умолчанию.
Честно говоря, я не совсем понял цель предыдущего поста. Если у вас не особо много причин для использования Multiarc, то у других они вполне могут быть в достаточном количестве. Даже без Юникода. А что касается INI-файлов, у меня, например, определённый набор INI-файлов лежит в папке TC, но multiarc.ini — в папке плагина. Безотносительно к тому, что там кому положено по умолчанию.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Avada
Раньше уже просили помимо 64-битности Юникод прикрутить. Я свой голос добавляю.
Видимо именно из-за многообразия возможностей и сверхполезности, плагин уже полтора десятка лет заброшен, и только у одного MVV руки дошли что-то с ним сделать для личного использования. А в годы его активной жизни 9/10 аддонов к нему были к форматам, которые в живой природе большинство не видело вообще, а случаи когда всё-таки видело можно по пальцам пересчитать.
Немного — значит немного, не ноль. И одной достаточно. Я для открытия и распаковки VMDK/VDI/VHD через 7zip приспособил, там отсутствие Юникода особо не помешает. Для всех других вариантов которые можно было бы сделать полуподдержка меня не интересует.
Конфигурация уже давно по-умолчанию хранится в профиле пользователя. Тотал совершенно без проблем поддерживает работу с UAC без прав записи к собственной папке, и только в силу особой консервативности автор до сих не поменял в инсталляторе путь с корня C: на Program Files. Поддержка конфига и в профиле и внутри каталога TC — это две гребаные дополнительные строчки кода; и у большинства плагинов, выходивших или обновлявшихся в этом десятилетии, она есть.
Раньше уже просили помимо 64-битности Юникод прикрутить. Я свой голос добавляю.
Видимо именно из-за многообразия возможностей и сверхполезности, плагин уже полтора десятка лет заброшен, и только у одного MVV руки дошли что-то с ним сделать для личного использования. А в годы его активной жизни 9/10 аддонов к нему были к форматам, которые в живой природе большинство не видело вообще, а случаи когда всё-таки видело можно по пальцам пересчитать.
Немного — значит немного, не ноль. И одной достаточно. Я для открытия и распаковки VMDK/VDI/VHD через 7zip приспособил, там отсутствие Юникода особо не помешает. Для всех других вариантов которые можно было бы сделать полуподдержка меня не интересует.
Конфигурация уже давно по-умолчанию хранится в профиле пользователя. Тотал совершенно без проблем поддерживает работу с UAC без прав записи к собственной папке, и только в силу особой консервативности автор до сих не поменял в инсталляторе путь с корня C: на Program Files. Поддержка конфига и в профиле и внутри каталога TC — это две гребаные дополнительные строчки кода; и у большинства плагинов, выходивших или обновлявшихся в этом десятилетии, она есть.
helb
Конфигурация TC хранилась и хранится там, где это удобно пользователю. Это обсуждалось многократно, и тратить на это время снова у меня нет ни малейшего желания. Полезность или бесполезность плагинов к заброшенности очень часто не имеет никакого отношения. Вариант MVV — это не "что-то", а полноценная поддержка, и делался он не "для личного использоваания", а для многих людей. Лично у меня из дюжины форматов в конфиге ненужного нет ни одного. Да и раньше пустышек не держал. А как и чем вы решаете свои проблемы — ваше дело, к данной теме отношения не имеющее.
Конфигурация TC хранилась и хранится там, где это удобно пользователю. Это обсуждалось многократно, и тратить на это время снова у меня нет ни малейшего желания. Полезность или бесполезность плагинов к заброшенности очень часто не имеет никакого отношения. Вариант MVV — это не "что-то", а полноценная поддержка, и делался он не "для личного использоваания", а для многих людей. Лично у меня из дюжины форматов в конфиге ненужного нет ни одного. Да и раньше пустышек не держал. А как и чем вы решаете свои проблемы — ваше дело, к данной теме отношения не имеющее.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Avada
Речь не про конфигурацию TC, а про конфигурацию плагинов, которая при правильном дизайне должна храниться примерно там же где и конфиг основной программы. В отличие от неадаптированных плагинов, работа которых частично ломается если TC установить в Program Files, самому Тоталу и актуальным плагинам без разницы портабельный он или нет и куда установлен.
И про изначальные намерения MVV — были ли у него прямо с первой же секунды планы публично и официально продолжать разработку, или же всё-таки он для себя делал и уже позднее решил поделиться с сообществом и затратить дополнительные усилия связанные с этим — оставьте право ему самому высказываться.
Речь не про конфигурацию TC, а про конфигурацию плагинов, которая при правильном дизайне должна храниться примерно там же где и конфиг основной программы. В отличие от неадаптированных плагинов, работа которых частично ломается если TC установить в Program Files, самому Тоталу и актуальным плагинам без разницы портабельный он или нет и куда установлен.
И про изначальные намерения MVV — были ли у него прямо с первой же секунды планы публично и официально продолжать разработку, или же всё-таки он для себя делал и уже позднее решил поделиться с сообществом и затратить дополнительные усилия связанные с этим — оставьте право ему самому высказываться.
helb
То, что конфигурация плагинов должна храниться там же, где основной конфиг, есть ваша личная точка зрения, которую очень многие на этом форуме и за его пределами категорически не разделяют. Первоначальные намерения МVV меня не особо интересуют и к делу, собственно говоря, никакого отношения не имеют. Реально значимым из всего вышесказанного является только запрос на Юникод. Реализуем ли он — вопрос другой, здесь действительно хорошо бы высказаться нынешнему разработчику. Хотя кое-какие намёки уже были и ранее (раз, два).
То, что конфигурация плагинов должна храниться там же, где основной конфиг, есть ваша личная точка зрения, которую очень многие на этом форуме и за его пределами категорически не разделяют. Первоначальные намерения МVV меня не особо интересуют и к делу, собственно говоря, никакого отношения не имеют. Реально значимым из всего вышесказанного является только запрос на Юникод. Реализуем ли он — вопрос другой, здесь действительно хорошо бы высказаться нынешнему разработчику. Хотя кое-какие намёки уже были и ранее (раз, два).
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Если опустить специфичный случай портабельности, код(+статические данные) и динамические данные должны быть разнесены, и это не мое мнение, а грамотный современный дизайн ПО. Дочерние модули должны уважать политику родительских, а не совать свои данные куда им заблагорассудится — это тоже правило, а не мнение.
Флуд начали разводить вы, отвечая на пост не вам адресованный, как обычно не удосужившись даже попытаться понять написанное. И я вас в продолжении этого поддерживать не буду.
То что я написал в первом посте, целиком релевантно:
А) Отсутствие Юникода сильно снижает потенциальную полезность плагина
Б) Плагин не в состоянии менять свои собственные настройки, если ТС установлен в Program Files
Флуд начали разводить вы, отвечая на пост не вам адресованный, как обычно не удосужившись даже попытаться понять написанное. И я вас в продолжении этого поддерживать не буду.
То что я написал в первом посте, целиком релевантно:
А) Отсутствие Юникода сильно снижает потенциальную полезность плагина
Б) Плагин не в состоянии менять свои собственные настройки, если ТС установлен в Program Files
helb
Во-первых, выбирайте выражения: я вас во флуде не обвинял, а вот оффтоп вы разводите несомненно — и с большим упорством. (Если бы в первом посте формулировки запроса были те же, что в последнем, возражений не было бы никаких. Но и там, и позже, было слишком много всякого другого.) Во-вторых, свой первый пост вы персонально никому не адресовали, и ответить на него вправе был любой. В-третьих, по существу вопроса (про Юникод) MVV уже отвечал — см. ссылки. Если вы действительно полагаете, что в ответ на все эти наезды (а ничем иным они пор факту не являются) будет сообщено нечто другое — ждите ответа. Мне с вами больше объясняться неинтересно.
Во-первых, выбирайте выражения: я вас во флуде не обвинял, а вот оффтоп вы разводите несомненно — и с большим упорством. (Если бы в первом посте формулировки запроса были те же, что в последнем, возражений не было бы никаких. Но и там, и позже, было слишком много всякого другого.) Во-вторых, свой первый пост вы персонально никому не адресовали, и ответить на него вправе был любой. В-третьих, по существу вопроса (про Юникод) MVV уже отвечал — см. ссылки. Если вы действительно полагаете, что в ответ на все эти наезды (а ничем иным они пор факту не являются) будет сообщено нечто другое — ждите ответа. Мне с вами больше объясняться неинтересно.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Насчёт расположения файла конфигурации уже было сказано, и в тотале этот вопрос давно решён. Если при установке тотала выбрано хранить файлы конфигурации в профиле пользователя, то и файлы конфигурации плагинов тотал будет хранить там же, в том числе файл pkplugin.ini для архиваторных плагинов. MultiArc по умолчанию использует этот файл, но также позволяет использовать конфиг в своей папке, если такой файл будет создан пользователем вручную.
Насчёт юникодности тоже уже было сказано, даже со ссылками на старые посты. Консоль заточена под однобайтную кодировку, и подавляющее большинство консольных приложений выводят текст именно в однобайтной кодировке. Соответственно и подавляющее большинство консольных архиваторов, для которых нет нормальных WCX-плагинов, являются древними и неюникодными или просто неюникодными, следовательно, переделывать MultiArc для добавления юникодности нет совершенно никакого смысла. Если есть примеры реально полезных консольных юникодных архиваторов - приводи, посмотрим.
А насчёт мотивов - я до сих пор использую 32-битный тотал, т.к. необходимости в 64-битном просто нет, и собирал 64-битный MultiArc только потому, что он был нужен людям, и изначально совершенно не планировал в нём что-либо дорабатывать.
Насчёт юникодности тоже уже было сказано, даже со ссылками на старые посты. Консоль заточена под однобайтную кодировку, и подавляющее большинство консольных приложений выводят текст именно в однобайтной кодировке. Соответственно и подавляющее большинство консольных архиваторов, для которых нет нормальных WCX-плагинов, являются древними и неюникодными или просто неюникодными, следовательно, переделывать MultiArc для добавления юникодности нет совершенно никакого смысла. Если есть примеры реально полезных консольных юникодных архиваторов - приводи, посмотрим.
А насчёт мотивов - я до сих пор использую 32-битный тотал, т.к. необходимости в 64-битном просто нет, и собирал 64-битный MultiArc только потому, что он был нужен людям, и изначально совершенно не планировал в нём что-либо дорабатывать.
MVV
Может что-то там и решено, но похоже не совсем. У меня pkplugin.ini в профиле нет, сам тотал его не создавал, даже ручное создание его ничего не меняет — как был пустым так и остаётся. Multiarc всё равно не сохраняет свои настройки, только ручное создание multiarc.ini в профиле и хардлинка на него в папке плагина решает проблему, как и ранее с другими «старомодными» плагинами (FontView, QuickSearch Extended).
Посты по ссылкам я и раньше читал: один несколько не соответствует реалиям, второй содержит опасливое «наверное» — и я прекрасно понимаю откуда это всеобщее нежелание лезть в это местами непредсказуемое болото конверсии берётся :)
Консоль на самом деле не заточена вообще-то. Вся «заточенность» там только в том, что очень конкретный conhost.exe отображает юникодные символы в виде затычек (а ConEmu это легко решает), при этом честно и полноценно обрабатывая во всём прочем. Для самих программ же ситуация ровно такая же как и для GUI-приложений — всё на совести автора.
Сейчас скорее обратный вопрос актуален — сложнее найти современные консольные приложения (это вообще не обязательно архиваторы — мелко мыслите :) ) которые с Юникодом не дружат. Для всяких старых и/или экзотических архивов плагин уже не особо актуален на практике: встречаются редко (если вообще), необходимость чего-то кроме извлечения скорее нулевая, и тот же Universal Extractor работу выполняет надежнее, поддерживает уйму всего сразу и конфигурации не требует.
Примеры? Тот же упомянутый 7zip для виртуальных дисков хотя бы. Но главное любые скриптовые языки, с помощью которых можно творить что угодно, а multiarc'у давать в удобоваримом виде.
Я бы, собственно, (если бы не отсутствие времени) сделал бы какой-нибудь ScriptArc.wcx похожим образом работающий, но существенно проще, с жестко заданным синтаксисом и именно на работу через скрипты заточенным.
Может что-то там и решено, но похоже не совсем. У меня pkplugin.ini в профиле нет, сам тотал его не создавал, даже ручное создание его ничего не меняет — как был пустым так и остаётся. Multiarc всё равно не сохраняет свои настройки, только ручное создание multiarc.ini в профиле и хардлинка на него в папке плагина решает проблему, как и ранее с другими «старомодными» плагинами (FontView, QuickSearch Extended).
Посты по ссылкам я и раньше читал: один несколько не соответствует реалиям, второй содержит опасливое «наверное» — и я прекрасно понимаю откуда это всеобщее нежелание лезть в это местами непредсказуемое болото конверсии берётся :)
Консоль на самом деле не заточена вообще-то. Вся «заточенность» там только в том, что очень конкретный conhost.exe отображает юникодные символы в виде затычек (а ConEmu это легко решает), при этом честно и полноценно обрабатывая во всём прочем. Для самих программ же ситуация ровно такая же как и для GUI-приложений — всё на совести автора.
Сейчас скорее обратный вопрос актуален — сложнее найти современные консольные приложения (это вообще не обязательно архиваторы — мелко мыслите :) ) которые с Юникодом не дружат. Для всяких старых и/или экзотических архивов плагин уже не особо актуален на практике: встречаются редко (если вообще), необходимость чего-то кроме извлечения скорее нулевая, и тот же Universal Extractor работу выполняет надежнее, поддерживает уйму всего сразу и конфигурации не требует.
Примеры? Тот же упомянутый 7zip для виртуальных дисков хотя бы. Но главное любые скриптовые языки, с помощью которых можно творить что угодно, а multiarc'у давать в удобоваримом виде.
Я бы, собственно, (если бы не отсутствие времени) сделал бы какой-нибудь ScriptArc.wcx похожим образом работающий, но существенно проще, с жестко заданным синтаксисом и именно на работу через скрипты заточенным.
Что ж, признаю, MultiArc действительно игнорирует конфиг, предлагаемый тоталом, и всегда работает с конфигом в своей папке, и в целом это даже хорошо, т.к. его конфиг может быть огромным и в ходе обычной работы с плагином нужен только на чтение, хотя, конечно, было бы хорошо при отсутствии конфига создавать его рядом с тоталовским, если тот лежит не в папке тотала.Multiarc всё равно не сохраняет свои настройки, только ручное создание multiarc.ini в профиле и хардлинка на него в папке плагина решает проблему, как и ранее с другими «старомодными» плагинами (FontView, QuickSearch Extended).
Ну, сами по себе пайпы не заточены, но когда подавляющее большинство программ ожидают текст на входе и выходе других программ, программы, выводящие что-то иное, создают кашу из кодировок. Например, при запуске cmd.exe /u мы получаем двухбайтный юникод от встроенных команд интерпретатора, но по-прежнему однобайтную кодировку от всех внешних программ, в итоге в общем выводе получается микс фрагментов с текстом в однобайтной и двухбайтной кодировке.Консоль на самом деле не заточена вообще-то. Вся «заточенность» там только в том, что очень конкретный conhost.exe отображает юникодные символы в виде затычек (а ConEmu это легко решает), при этом честно и полноценно обрабатывая во всём прочем. Для самих программ же ситуация ровно такая же как и для GUI-приложений — всё на совести автора.
На входе - да, но на выходе? Разве что в кодировке UTF-8, т.к. двухбайтный юникод в консоли - дикость, и то микс кодировок UTF-8 и однобайтной OEM может доставить проблем.Сейчас скорее обратный вопрос актуален — сложнее найти современные консольные приложения (это вообще не обязательно архиваторы — мелко мыслите) которые с Юникодом не дружат.