https://m.opennet.dev/openforum/vsluhforumID3/63006.html Вышел XYZCommander 0.0.3 (http://xyzcmd.syhpoon.name/), третий релиз нового консольного файлового менеджера для *nix систем, написаного на языке Python и, кроме библиотеки urwid (http://excess.org/urwid/), не использующего внешних зависимостей. Исходные тексты проекта распространяются в рамках лицензии LGPL.<br><br><br>&lt;img src="http://www.opennet.ru/opennews/pics_base/25038_1263762022.jpg" align=right&gt;&lt;/img&gt;Основные возможности:<br><br><br>- Интеграция с Python окружением: настройки приложения можно менять "на лету" через консоль управления; все конфигурационные файлы представляют собой скрипты на языке Python, для упрощения используется специальный набор конфигурационных функций;<br>- С помощью системы конфигурирования можно настраивать собственные действия, переопределять операции (alias), создавать внутренние команды, а также изменять управляющие комбинации клавиш;<br>- Система плагинов позволяет расширять функциональность без модификации ядра приложения;<br>- Возможность создавать собственные фун...<br><br>URL: http://xyzcmd. https://m.opennet.dev/openforum/vsluhforumID3/63006.html#138 Fri, 22 Jan 2010 09:57:48 GMT &gt;Да ради Бога, никто ж не заставляет пользоваться ;) <br>&gt;Кому будет интересно, тот разберётся в конфигах. <br><br>Или найдет что-то более соответствующее своим хотелкам, и это будет чаще.<br><br> https://m.opennet.dev/openforum/vsluhforumID3/63006.html#137 Thu, 21 Jan 2010 23:57:15 GMT Это не мой проект. Я лишь привел альтернытивные критерии по отношению к банальным критериям потребительской полезности и функциональности.<br><br>&gt;С другой стороны, если функционалом программы является, по сути, навигация по каталогам,<br><br>Если целью является создание именно средство для навигации по каталогам, тогда все конечно уже решено.<br><br>Если целью является создание более абстрактного интерфейса для облегчения полу-ручных операций типа "источник-назначение", для работы с абстрактными _парами_ объектов и в качестве логического продолжения абстраткных потоковых моделей и композиций автоматов, на базе которых построены утилиты и консоль Юникса. Тогда лучше не спешить с определением, где именно может возникнуть узкое место.<br><br>Отправной точкой в любом случае является интерфейс пользователя. Иначе зачем вообще нужны эти две панели. Вопрос к чему этот интерфейс планируктся прикладывать. Просто к файловой системе? Однако ФС сама по себе является абстрактной моделью данных.<br><br>В качестве примера можно привести Far и https://m.opennet.dev/openforum/vsluhforumID3/63006.html#136 Thu, 21 Jan 2010 22:52:58 GMT С другой стороны, если функционалом программы является, по сути, навигация по каталогам, и есть явное узкое место, почему бы его не убрать? И это совсем не потакание или ещё что, нельзя же заняв круговую оборону сидеть и принимать в штыки любое предложение со стороны пользователей ( я не про конфиги :), только ради принципа что разработчику виднее. Я прислушиваюсь к пожеланиям, но стараюсь фильтровать по собственным критериям ценности.<br> https://m.opennet.dev/openforum/vsluhforumID3/63006.html#135 Thu, 21 Jan 2010 22:08:52 GMT Попробуем еще рассуждать от противного.<br><br>Был, знаете ли, раньше один такой мыслитель и практик по имени Противный. Его именем потом и назвали этот вид рассуждений.<br><br>Кроме того, следует всегда иметь в виду, что "противно" - от слова "против". А вовсе не от слова "уродливо", как это многие воспринимают. Поэтому если кому-то противны вы и то, что вы делаете, из этого вовсе не следует, что у вас какие-то проблемы. Скорее это проблемы у него, что он не может ужиться с тем, что вы что-то делаете по-своему. Что вы что-то делаете против его мнеия и при этом хорошо себя чувствуете.<br><br>Поэтому многие спешат поставить знак равенства между противным и уродливым. Однако если спешить с каждым соглашаться, как раз скорее всего уродство и получится.<br><br>Так вот, рассуждения от Противного.<br><br>Насколько ценнее станет ваша разработка, если она научится быстро открывать каталоги. И будет иметь тривиальные и примитивные конфиги. Таких приложений и так очень много. Насколько они ценны?<br><br>В том-то и дело, что это очень хорошо и https://m.opennet.dev/openforum/vsluhforumID3/63006.html#134 Thu, 21 Jan 2010 13:01:46 GMT &gt;[оверквотинг удален]<br>&gt;<br>&gt;Всякое там кеширование еще захочется вставить и пошло-поехало все это между собой <br>&gt;перевязывать. А сложность растет комбинаторно, если не предпринимать мер по развязке <br>&gt;подсистем. <br>&gt;<br>&gt;Пользователям, вечно жалующимся на скорость, все равно никогда не угодите и впечатление <br>&gt;на них никогда не произведете, потому что они всегда лучше знают, <br>&gt;как надо было делать. А вот проглядеть изящные решения очень легко, <br>&gt;если слишком торопиться с оптимизацией. А обратно откатывать - пользователи еще <br>&gt;сильнее жаловаться начнут, что их любимый функционал убрали. <br><br>Ну собственно ленивая вычитка как раз один из таких известных паттернов, когда есть большое количество данных но одновременно отображается только небольшое их подмножество, и вычитывать файлы по мере надобности вполне приемлемое решение, оно никак не повлияет на внешний функционал но существенно увеличит скорость входа в каталоги с большим количеством файлов.<br>Этот тикет у меня чуть ли ни с первой версии висит ещё :)<br><br> https://m.opennet.dev/openforum/vsluhforumID3/63006.html#133 Thu, 21 Jan 2010 12:46:52 GMT &gt;Ну даже mc не моментально входит в каталоги с большим количеством файлов, а тут уж прйдётся только такими окольными путями оптимизировать. <br><br>Вот окольными путями здесь лучше не надо. А то получится то, о чем уже шла речь выше про оптимизацию.<br><br>Уже существует достаточное количество хорошо зарекомендовавших себя паттернов, связанных с разделением данных и представлений.<br><br>Тем более, в двухпанельном редакторе интерфейс достаточно фиксированный.<br><br>Общая суть - не создавать структуры, которые _безусловно_ отражаются на объекты в другой системе. А создавать только такие структуры, которые манипулируют исключительно объектами, явно участвующими в процессах разрабатываемой системы. В любом случае это будет вызывать усложнение. Вопрос, на каком уровне обобщения. Частности и конкретика - это тоже конечно очень хорошо, только этого слишком быстро станет очень много.<br><br>Всякое там кеширование еще захочется вставить и пошло-поехало все это между собой перевязывать. А сложность растет комбинаторно, если не предприним https://m.opennet.dev/openforum/vsluhforumID3/63006.html#132 Thu, 21 Jan 2010 12:20:38 GMT &gt;Не, ну если доброй половине софта хватит вообще key=value, то почему бы эту часть /etc не причесать под одну гребенку? <br><br>Потому что ответ вы уже сами дали ниже.<br><br>&gt;Только не в мерзостном виде аля gconf, а чем-то хорошем, типа /sys. <br><br>Предложите такой способ на все случаи жизни "причесать под одну гребенку", чтобы гарантированно при этом не получить очередную "мерзость". Или вы думаете, что глупые разработчики заранее планировали, "создатим-ка мы такую мерзость". Нет, также как и вы с горячим энтузиазизмом хотели "причесать все под одну гребенку".<br><br>Текстовы файлы - это уже и есть "под одну гребенку".<br><br>&gt;Чтобы "бинарности" (ну, понимаете о чем я, думаю) там было не больше чем в текстовом файле на ext3.<br><br>Нет, я не понимаю о чем вы. Попробуйте поточнее сформулировать свои мысли в контексте тех реалий, которые существуют в вычислительной технике и формальных системах, а не в виде смутных образов, существующих в вашем сознании. Только судя по вашим представлениям, скорее всего запутаетесь.<br><br>&gt;А где не подх https://m.opennet.dev/openforum/vsluhforumID3/63006.html#131 Thu, 21 Jan 2010 10:26:09 GMT Не, ну если доброй половине софта хватит вообще key=value, то почему бы эту часть /etc не причесать под одну гребенку?<br><br>Только не в мерзостном виде аля gconf, а чем-то хорошем, типа /sys. Чтобы "бинарности" (ну, понимаете о чем я, думаю) там было не больше чем в текстовом файле на ext3.<br><br>А где не подходит - то, разумеется, не делать глупостей и не запихивать. И, вроде как, все хорошо становится.<br> https://m.opennet.dev/openforum/vsluhforumID3/63006.html#130 Thu, 21 Jan 2010 00:31:24 GMT А потому что все наши - и автор, и maintainer и коммиттер :)<br>