Комментарии 135
А под OS X?
Тоже был бы рад версии для мака
Я такую штуку для мака джва все 6 лет как маком начал пользоваться, жду. Надеюсь, это не первоапрельская шутка :). Уже и классический дос навигатор под досбоксом ставил, и миднайт коммандер, и даже альтернативные графические шеллы пробовал — а все не то. Работа с большим количеством файлов на маке — тот еще pain in the ass. Проще расшарить в досбоксе и на PC открыть тот самый Dos navigator…
А под os X, кроме mc, есть подобный far? А то уже руки чешутся сделать форк Деодара, но, чую, знаний не хватить портировать.
Если вы возьметёсь, то я буду с вами няньчится как с младенцем и вы справитесь! Всего то надо переписать один GLXWIN. Создание окна, вывод текста, трансфер событий мыли и клавы. Ну может ещё клипборд и отловка ресайза окна. Остальное Node.js сделает.
Как раз Far это реально. Но не нативный, а через wine.
Far
Как вариант гляньте Files. Хоть еще сыроват, но развивается плюс автор возможно русскоговорящий (исходя из фамилии).
Вся ценность подобного файлменеджера в запуске в консоли. Отдельным приложением хватает Finder (с плагином XtraFinder).
Спасибо, клевая штука. Не без недостатков, но лучше, чем другие. Скажите, как вы ее нашли? У меня так и не получилось найти ее в гугле, даже зная название проекта.
Да, русскоговорящий.
если позволительно поставить X11 то скорее всего соберётся
Кнопка «Давай», улыбнула.
Понимаю желание написать альтернативу mc, но на javascript-то за что?
Ну и захардкоженые надписи на русском — это несерьезно.
Ну и захардкоженые надписи на русском — это несерьезно.
вы себе противоречите, «JavaScript» и «захардкоженые» в одном предложении?
Вам понятие «хардкод» незнакомо?
Оно возникло в компилируемых средах, но дело не в нём, а в том, что человек не написал: «строковые константы в функции создания диалогового окна не соответствуют промышленым стандартам», а написал, что русский язык это несерьёзно, и это с ником Unforgiven. Да и вопрос про JavaScript заранее задан в холиварном формате. Можно ли всерьёз в таком случае отвечать про стиль програмирования.
Холиварную часть можно и проигнорировать.
На тему локализации — неужели действительно нужно написать полэкрана занудной речи, чтобы рассказать о потенциальной возможности использования софта пользователями с другим родным языком?
Одно дело — править переведенные строки, тонко размазанные по всему коду, другое — подменить один конфиг.
Претензия к нику мне не ясна и отдает переходом на личности.
На тему локализации — неужели действительно нужно написать полэкрана занудной речи, чтобы рассказать о потенциальной возможности использования софта пользователями с другим родным языком?
Одно дело — править переведенные строки, тонко размазанные по всему коду, другое — подменить один конфиг.
Претензия к нику мне не ясна и отдает переходом на личности.
Это и есть переход на личность. Вы маскируете под деловые вопросы свои эмоциональные претензии на превосходство. Походя оскорбляя сразу два языка, самый популярный язык програмирования последних лет JavaScript и государственый язык РФ.
Вам всего лишь говорили, что не нужно хардкодить один язык. Если проект с амбициями — нужно вынести все в локали, чтобы новые языки было добавлять легко.
«Коммандная строка» в справке и отсутствие половины знаков препинания в «зачем.букф» оскорбляет великий и могучий куда больше)
Хоспади, что вы несёте? >_<
UPD: Почитал комменты дальше. Автор производит впечатление воинствующего ватника.
UPD: Почитал комменты дальше. Автор производит впечатление воинствующего ватника.
Может быть возникло и в компилируемых, но оно никак не относится к компилируемости/скриптовости конкретного ЯП. Хардкод — это, например, намертво вшитые в код константы (строковые, числовые), которые никак кроме редактирования кода не изменить.
Человек написал, что хардкод, который ещё и только на русском несерьёзен. Причём тут ник не понятно.
Про JavaScript на самом деле очень больная тема. «Всё, что может быть написано на JS, должно быть написано на нём».
Чем Вами обоснован выбор ЯП для написания этого приложения? Почему не что-то из привычного для разработчиков для написания системных и десктопных приложений (C, C++, Qt)?
Человек написал, что хардкод, который ещё и только на русском несерьёзен. Причём тут ник не понятно.
Про JavaScript на самом деле очень больная тема. «Всё, что может быть написано на JS, должно быть написано на нём».
Чем Вами обоснован выбор ЯП для написания этого приложения? Почему не что-то из привычного для разработчиков для написания системных и десктопных приложений (C, C++, Qt)?
Очень странный у вас вопрос. Вы спрашиваете — «привычного для разработчиков», ну так и надо спрашивать у «привычных разработчиков», почему они деодар не написали. Может автор на сях ничего кроме хелло ворда не писал, смысл ему начинать на нем?
deleted
уважаемый, не подменяйте смысл. сравните «привычного для разработчиков» и «привычного для разработчиков для написания системных и десктопных приложений».
Может автор на сях ничего кроме хелло ворда не писал, смысл ему начинать на нем?смысл тогда ему лезть в разработку GUI приложений под ОС?
Я не подмняю понятия. Есть конкретный человек, который хорошо знает этот язык. Вот он и написал деодар на нем. Не знаю, хорошо ли получилось, плохо ли, но мы имеем то, что имеем. Программа есть и она работает. Если есть претензии к работе программы, то нужно называть уже их, а не ругать яваскрипт.
>>смысл тогда ему лезть в разработку GUI приложений под ОС?
А вы считаете что в этом нет смысла? Почему?
>>смысл тогда ему лезть в разработку GUI приложений под ОС?
А вы считаете что в этом нет смысла? Почему?
для JavaScript написано немыслимое количество модулей, на одном только npmjs их 60000. Можно взять любой и прикрутить к Деодар и он будет делать всё что вы пожелаете. На новый год Stackoverflow сделало опрос, что в IT вызывает у вас excitement на 2014 год, кажется 38 процентов с большим отрывом назвали Node.js.
Кстати, действительно, а можно ли сменить язык на английский? Имхо было бы привычнее и проще.
И еще момент — умеет ли он работать с архивами?
И еще момент — умеет ли он работать с архивами?
Нет ничего проще чем привыкать к русскому языку.
Ну что тут сказать можно. Продолжайте дальше писать приложения с таким подходом к англоязычному населению Земли, больше работы настоящим профессионалам :)
А зачем мне ваше англоязычное население? А я ему зачем? Англоязычному населению Деодар не нужен, их с детства учат емаксом пользоваться и маны читать. А наших детей с детства учат пользоваться двухпанельником и турбо паскалем. Менталитет-с.
Затем, что это больший охват аудитории проектом и больший шанс на формирование своего комьюнити у проекта.
Конечно не нужен, он же только на русском. Знаете, как злит, когда на Гитхабе видишь проекты или книги, например, чисто на японском (китайском) языках и ты не понимаешь ничего, а перевод гуглом много не даёт?
Что же Вам мешает пользоваться емаксом и что Midnight Commander'ом? Менталитет?
То есть Вы маны не читаете? :)
Англоязычному населению Деодар не нужен, их с детства учат емаксом пользоваться
А наших детей с детства учат пользоваться двухпанельником и турбо паскалем.
Конечно не нужен, он же только на русском. Знаете, как злит, когда на Гитхабе видишь проекты или книги, например, чисто на японском (китайском) языках и ты не понимаешь ничего, а перевод гуглом много не даёт?
Что же Вам мешает пользоваться емаксом и что Midnight Commander'ом? Менталитет?
маны читать
То есть Вы маны не читаете? :)
как-то сложновато будет привыкать к слову «Скачок» заместо фразы «Быстрый переход»
НЛО прилетело и опубликовало эту надпись здесь
Думаю если програма вам полезна, редактор вам кажется удобным, и сердце радуется что не надо пользоваться дольфинами и набирать ls 500 раз на дню, то уже отредактировать js файл под свой любимый язык не составит труда.
архивов пока нет.
Да какая разница, на чем оно написано, лишь бы хорошо работало. Скриншоты впечатляют.
Если вы ещё не просекли, как яваскрипт захватывает все вообще доступные области программирования, то скоро почувствуете.
Я бы сказал, написать не альтернативу mc, а клон Фара.
И почему бы не на JavaScript?
И почему бы не на JavaScript?
заинтригован. смесь mc, vi в одном приложении на node.js?!
будет чем заняться на выходных
будет чем заняться на выходных
А в обычной консоли (н.п. через putty+ssh) такое чудо возможно запустить?
Ндаа
Я думал это веб-приложение. А так, пхе :-(
Намекаете, что я переоценил способности Хабровчан пользоваться git и собирать програмы из исходников? Или вы просто не заметили слово Линукс?
Намекаю, что если бы оно было бы с веб интерфейсом, было бы что-то интересное и новое.
Те разработчики, что пользуются vagrant/packer и подобными системами, смогли бы использовать его на ровне с cloud9.
А сейчас не ясна его ЦА и отличия от других подобных систем.
Те разработчики, что пользуются vagrant/packer и подобными системами, смогли бы использовать его на ровне с cloud9.
А сейчас не ясна его ЦА и отличия от других подобных систем.
Но есть же люди с молоком матери впитавшие работу в ортодоксальном двухпанельнике? Есть же дети, которые ещё ничего не умеют, но хотят поставить линукс и там хоть что то начать делать. Есть же люди привыкшие к редактору Дельфи и Нотепаду++?
\_________/ линукоиды
\_______/ русскоязычные
\_____/ использующие mc
\___/ которые недовольны mc
\_/ готовые использовать менеджер не в терминале а в отдельном окне
Намекаете как бэ, что профит уменьшится? Недавно же был на хабре популярный пост, что успешные стартапы не бегают за широкой аудиторией, а фанатично пытаются сделать счастливыми маленькое ядро пользователей. Пусть оно будет крохотное, пусть это будет даже три человека.
Я расстроен, что мне ваше решение не подходит.
Вы про вебинтерфейс? Ну он кстати, вполне возможен, я не раз о нём думал и даже мечтал. Но пока не ясно, каковы области применения. Правда, была мысль, что двухпанельник может быть применяем на PaaS и облаках. А то так надоели эти вечно изобретаемые монетизаторами панели управления, CMS-ы и прочие юзабилити шедевры. Я целый день убил пытаясь завести проект на OpenShift. А в результате, что? Только спам шлют.
Я использую:
— packer для сборки образов на digitalocean и для vagrant;
— chef для настройки этих образов;
— cloud9 как ide внутри этих образов.
В итоге я получаю готовую виртуалку для разработки со всеми зависимостями, с ide и очень похожую на production окружение, которую я могу запускать как на любом ноутбуке, так и оставить в облаке. Веб версия файлового менеджера была бы кстати в моем случае.
— packer для сборки образов на digitalocean и для vagrant;
— chef для настройки этих образов;
— cloud9 как ide внутри этих образов.
В итоге я получаю готовую виртуалку для разработки со всеми зависимостями, с ide и очень похожую на production окружение, которую я могу запускать как на любом ноутбуке, так и оставить в облаке. Веб версия файлового менеджера была бы кстати в моем случае.
Думаю вам бы подошел веб файл менеджер для таких целей.
Вы могли бы поделится инструкцией сборки и разворачивания образов с cloud9? Или готовым образом?
По-поводу приложения, Деодар очень заинтересовал своим внешним видом и тем, что он написан на JavaScript/Node.js.
К сожалению завести его с первого раза не получилось.
Буду рад, если автор мне поможет с этим.
А вообще очень интересный проект, надеюсь автор не утратит энтузиазм, и будет продолжать улучшать приложение и упрощать его установку. Ожидайте пул риквестов ;).
Вы могли бы поделится инструкцией сборки и разворачивания образов с cloud9? Или готовым образом?
По-поводу приложения, Деодар очень заинтересовал своим внешним видом и тем, что он написан на JavaScript/Node.js.
К сожалению завести его с первого раза не получилось.
Буду рад, если автор мне поможет с этим.
А вообще очень интересный проект, надеюсь автор не утратит энтузиазм, и будет продолжать улучшать приложение и упрощать его установку. Ожидайте пул риквестов ;).
▲
▲ ▲
▲ ▲
А синяя тема редактора, наподобие Far+Colorer с дефолтными настройками, есть?
Снимаю шляпу, очень основательный подход к делу! Такой проект должен жить. Поэтому, позволю себе пару-тройку советов.
1) Используйте линтер. У вас попадается опасный код. Код без точек с запятой вообще не должен существовать.
2) Сделайте файлы локализации. Дате людям, не знающим JS, локализовать ваш продукт.
3) Сделайте английский вариант сайта проекта. Уверяю вас, за ломанный английский вас никто ругать не будет, но англоязычная аудитория в разы (а то и десятки раз) больше. Вы получите массу поддержки и фидбэка (а то и job offer-ы). Это просто захватывает.
Уверен (и эта уверенность базируется на личном опыте), если выполнить эти (не очень простые) требования, то ваш софт легко войдёт в основные дистрибутивы и обретёт всемирное признание, а вы получите массу удовольствия от общения с открытыми, квалифицированными и просто приятными людьми по всему миру. Успехов!
1) Используйте линтер. У вас попадается опасный код. Код без точек с запятой вообще не должен существовать.
Пример
function a() {
return 'ok'
}
function b() {
return // тут JavaScript сам поставит ";", это же легко словить не только в return
'ok'
}
console.log(a()); // ok
console.log(b()); // undefined2) Сделайте файлы локализации. Дате людям, не знающим JS, локализовать ваш продукт.
Мой опыт
У меня есть крошечный проектик, переведённый на 10(!) языков. Причём, среди переводчиков были и программисты, и люди типа «моей бабушке очень нравится ваша игра и я хотел бы для неё перевести её на каталонский, я ничего не понимаю в Qt, что мне делать?» У вас должен быть готов простой ответ для таких людей.
3) Сделайте английский вариант сайта проекта. Уверяю вас, за ломанный английский вас никто ругать не будет, но англоязычная аудитория в разы (а то и десятки раз) больше. Вы получите массу поддержки и фидбэка (а то и job offer-ы). Это просто захватывает.
Уверен (и эта уверенность базируется на личном опыте), если выполнить эти (не очень простые) требования, то ваш софт легко войдёт в основные дистрибутивы и обретёт всемирное признание, а вы получите массу удовольствия от общения с открытыми, квалифицированными и просто приятными людьми по всему миру. Успехов!
Спасибо, очень приятно слышать ободряющие слова. Но позволю себе разъяснить свою позицию. С 1999 по 2009 год у меня был свой международный проект, и локализованый на много языков, а мои клиенты американские и английские писатели, в основном, не всегда замечали, что мой английский не так хорош как их. Но теперь я лучше буду в стороне от всех этих игр в обслуживание золотого милиарда, и лучше попробую сделать будущим поколениям руских програмистов хороший понятный инструмент, они смогут писать сервисы на JS, програмировать на асме и питоне, и делать, что им захочется. А вы про джоб-офферы. Да пусть они катятся в ад эти джоб-оферы стартапы, монетизация и кастомер база.
Ваша позиция понятна, и, конечно, имеет право на существование. Но мне кажется, что это какая-то искусственная аскета. Деление на наших и не-наших, мне представляется не естественным и не современным. (Нет, конечно, газопроводы или танки вполне уместно делить на наши и не наши, но софт…) Думаю, и наши дети бы только выиграли бы если ваш софт включили в дистрибутивы. Дело, конечно, ваше, но вы всё же не принимайте поспешных решений и не ограничивайте себя там, где в этом нет никакой необходимости.
Тут, имхо, дело не в том что продукт фиг переведешь на другой язык — дело в том, что не выносить строки и константы во всякие отдельные конфиги и файлы локализации (даже пускай он будет один) — плохо. Например, через 5 лет использования вашего продукта я найду опечатку в какой-то строке и захочу исправить. Почему же я должен искать ее поиском по всему коду, вместо того чтобы быстро пофиксить в отдельном файле?
Если кто-нибудь пройдется по исходникам и локализует это дело на английский (по-человечески, т.е. с подстройкой под локаль) — вы возмете такой pull request?
Может просто не переносить содержимое return?
Точки с запятой не делают мир лучше :-)
Точки с запятой не делают мир лучше :-)
Пример
function a() {
return 'ok';
}
function b() {
return;
'ok';
}
console.log(a()); // ok
console.log(b()); // undefined
«Перенести 1 штук»!
function plural_str(i, str1, str2, str3){
function plural (a){
if ( a % 10 == 1 && a % 100 != 11 ) return 0;
else if ( a % 10 >= 2 && a % 10 <= 4 && ( a % 100 < 10 || a % 100 >= 20)) return 1;
else return 2;
}
switch (plural(i)) {
case 0: return str1;
case 1: return str2;
default: return str3;
}
}
НЛО прилетело и опубликовало эту надпись здесь
Ну надо же.
Сделал человек неплохую вещь, возможно со своими недостатками, а ему карму опустили за то что сделано «не по фен-шую».
Вы первые версии популярных ныне программ никогда не видели что ли?
Сделал человек неплохую вещь, возможно со своими недостатками, а ему карму опустили за то что сделано «не по фен-шую».
Вы первые версии популярных ныне программ никогда не видели что ли?
Кстати, да. Сообщество отнеслось к разработчику не по справедливости.
Особенно угнетают претензии к выбору языка программирования.
JavaScript — это Бейсик сего дня! (В хорошем смысле.) Так что я этот выбор одобряю.
Особенно угнетают претензии к выбору языка программирования.
JavaScript — это Бейсик сего дня! (В хорошем смысле.) Так что я этот выбор одобряю.
Карму думаю опустили за высказывания по поводу иностранцев. А сама вещь очень даже, очень и очень.
Еще понятно, когда какую-то поделку представляют как «инновацию». Автор же этого не утверждает.
Ну не хочет человек переводить. Да, плохо. Так ведь open source же! Разве не в том идея открытого кода, чтобы можно было взять и допилить, если чего-то не устраивает? А люди что-то требовать начинают вместо этого.
Ну не хочет человек переводить. Да, плохо. Так ведь open source же! Разве не в том идея открытого кода, чтобы можно было взять и допилить, если чего-то не устраивает? А люди что-то требовать начинают вместо этого.
НЛО прилетело и опубликовало эту надпись здесь
Где вы такое увидели? Я вижу, что комментарии автора переполнены иронией и сарказмом, но где вы нашли махровый патриотизм-то?
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, вы воспринимаете все слишком буквально. Первые 2 — просто стеб.
Суть же в
Суть же в
Да пусть они катятся в ад эти джоб-оферы стартапы, монетизация и кастомер база.и
успешные стартапы не бегают за широкой аудиторией, а фанатично пытаются сделать счастливыми маленькое ядро пользователей. Пусть оно будет крохотное, пусть это будет даже три человека.
Да у него, откровенно говоря, и русский-то хреновый какой-то.
Это еще без пропущенных букв. Это не переход на личности ни в коей мере. Просто констатация факта.
Такая попытка была сделана, но трудность в том, что Npm не так удобен_запятая_ когда речь идёт о пэкеджах_запятая_ в которых есть С++ код. В Деодаре таких два своих и один сторон_еще_одна_н_ий покач-то (пока что). Со-временем (Со временем) удастся_запятая_ конечно_запятая_ всё соединить и оттестировать на основных дистрибах, но это требует человеко-часов, которых не хватает пока даже на локализцию (или я бы таки назвал это глобализацию)
Это еще без пропущенных букв. Это не переход на личности ни в коей мере. Просто констатация факта.
Подозреваю, карму опустили не за то, что «не по фен-шую», а за стиль общения и реагирования на замечания.
Как установить из исходников
Просто оставлю это здесь. На русском, раз уже Вы такой hater :D
... git clone https://github.com/exebook/deodar cd deodar git clone https://github.com/exebook/glxwin git clone https://github.com/exebook/x11clip git clone https://github.com/exebook/dnaof git clone https://github.com/exebook/intervision ...
Просто оставлю это здесь. На русском, раз уже Вы такой hater :D
Подмодули Git — довольно хорошо, но ещё получше было бы рекомендовать употребление пакетов npm, чтобы всё делалось через «npm install --production» в подкаталоге «deodar». В мире Node.js почти никто не пользуется подмодулями Git для этой цели.
Непременно бы порекомендовал, но на node.js не пишу, в силу этого с экосистемой знаком не в той степени, чтобы позволить себе раздавать советы :) Благодарю за дополнение :)
Такая попытка была сделана, но трудность в том, что Npm не так удобен когда речь идёт о пэкеджах в которых есть С++ код. В Деодаре таких два своих и один стороний покач-то. Со-временем удастся конечно всё соединить и оттестировать на основных дистрибах, но это требует человеко-часов, которых не хватает пока даже на локализцию (или я бы таки назвал это глобализацию)
А почему не
?
git clone --recursive [repo]?
Спасибо. Проблевался. Пошел опять обедать.
[irony] Я так понимаю, это файловый менеджер для BolgenOS? [/irony]
Файл «установка.букв» меня поразил как формой, так и содержанием. =)
Но автору и статье поставил по плюсу, ибо начинание хорошее. И ещё я рад, что файлы исходников названы по-английски… Когда проект начнёт поддерживать запуск из консоли и OS X, обязательно попробую его на вкус «по полной».
Но автору и статье поставил по плюсу, ибо начинание хорошее. И ещё я рад, что файлы исходников названы по-английски… Когда проект начнёт поддерживать запуск из консоли и OS X, обязательно попробую его на вкус «по полной».
лампово!
А если копировать с правой панели на левую, прогрессбар идёт слева направо или справа налево?
Вспомнился чей-то гениальный твит: «Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.»
Всякое приложение, которое может быть написано на языке JavaScript, будет со временем написано на языке JavaScript. (Закон Этвуда.)
Вот это прозрение Этвуда — гениальное прозрение.
А вон тот твит — скорее троллинг, и вряд ли более.
Вот это прозрение Этвуда — гениальное прозрение.
А вон тот твит — скорее троллинг, и вряд ли более.
Это как любое литературное произведение будет со временем пересказано на фене.
На самом деле функционал для первой публичной версии чрезвычайно огромен. Причем на этом проекте видно, языки шагнули действительно далеко. То, что раньше делалось сверхусилиями на ассемблере и си (тот же Волков и Нортон коммандер) сейчас делается из подручных средств на скриптовых языках. Страшно представить, во что может вылиться этот проект, если он сохронит четкую структуру. Это не Vi с его нетстандартным синтаксисом файлов настроек и загадочным интерфейсом. Это не миднайт коммандер с хардкодным сишным кодом. Тут все примитивно и просто.
я правильно понимаю. что в браузере пока не получится это дело запустить? хочется браузерный файл-менеджер типа Фара.
p.s. не стоит делать скриншоты в полупрозрачном окне. это затрудняет читабельность и сбивает с столку.
p.s. не стоит делать скриншоты в полупрозрачном окне. это затрудняет читабельность и сбивает с столку.
нет, в основном потому, что не ясно какие файлы он будет менеджерить этот файл менеджер, из браузера. то есть к нему понадобится и сервер (backend) опять же, что за сервер, на вашем домашнем компе, телефоне, в облаке, на гитхабе, в сервисах гугл?
это все как раз понятно. на том же Node можно достаточно легко написать бекенд который наружу будет выставлять API для работы с файлами. Из менеджера надо будет только дергать соотв. вызовы асинхронно. Вопрос как раз в том — получится ли легко заменить слой работы с файлами локально, на слой работы с API.
На мой взгляд получилась бы классная и востребованная штука. На всех хостингах, что я видел, встречается довольно кривая версия а-ля Проводника Windows.
На мой взгляд получилась бы классная и востребованная штука. На всех хостингах, что я видел, встречается довольно кривая версия а-ля Проводника Windows.
Внезапно я понял о чём вы думаете, когда вы употребили слово хостинг. А то всё не складывалось в голове. Учитывая что у ноды медленые вызовы к файловой системе и так асинхроные, то конечно их можно вполне сделать суб-апи и подключать, что то удалёное. Сейчас прям за одну ночь врятли, но в принципе реально. Другой вопрос возникает, а зачем браузер, точно так же можно подключится к ремотному серверу и из Node.js приложения каковым является Deodar. Это просто вопрос, я подозреваю, что причин найдётся, хоть интеграция в сайт хостера…
Я уже говорил об этом, но, на всякий случай, повторюсь (думаю, не все читают всю нить комментариев),
что подобная вещь под браузер существует. Это, конечно, не Фар. Но лучше многих аналогов.
У Deodar же, своя ниша, немного другая, но не менее нужная, как мне кажется.
В прочем, в будущем возможно появится возможность и в браузере Deodar запускать, но тут есть очень много подводных камней, поэтому, думаю, должно пройти какое-то время.
что подобная вещь под браузер существует. Это, конечно, не Фар. Но лучше многих аналогов.
У Deodar же, своя ниша, немного другая, но не менее нужная, как мне кажется.
В прочем, в будущем возможно появится возможность и в браузере Deodar запускать, но тут есть очень много подводных камней, поэтому, думаю, должно пройти какое-то время.
НЛО прилетело и опубликовало эту надпись здесь
Холливар про русский язык и наш «двухпанельный» менталитет как-то затмил обсуждение самого продукта (и оно понятно). «Скачек» — я считаю это отличная фича. Вообще кажется что работа проделана большая.
Вот что меня действительно напрягает, так это то, что везде разные среды, и вместо того, чтобы сделать что-то максимально кроссплатформенное, со сквозной архитектурой, работающее и в браузере и в консоли и в окне и по ssh, и в облаке и на маке и на линуксе и на винде и на планшете, и как приложение и как сервис, и как клиент-сервер и локально, и главное — работает одинаково и привычно повсеместно, но нет же, автор делает нечто, что работает в его тепличных условиях, с бантиком сбоку, это конечно все героически, но нужна архитектура. Например, сделать API файлового менеджера, специфицировать его и опубликовать (а и просто найти такое API, возможно соответствующий RFC есть, я не встречал, но не удивлюсь, если есть), сделать это API доступным локально и по сети, через AJAX/JSON, сделать браузерный-клиент и консольный клиент (запускаемый локально и рендерящий все локально) и этот же консольный клиент будет доступен по SSH.
Спасибо, я разделяю ваше видение. Но, что более может соответствовать указаному вами направлению, чем написание програмы на языка JavaScript? Это же и есть шаг в данном направлении.
Вы увлеклись разукрашиванием, оупенджиэлем, х11, шрифтами и другими плюшками, это все увело от универсальности, и самое главное преимущество JavaScript почти полностью нивелировалось. Код организован с большой связанностью, прямо допотопный турбовижен развели в коде, я сам Дэлфовиц с 1996 года, но сейчас уже так писать нельзя, и переносить это на JS. Я удивляюсь, что ни где не увидел SendMessage(hwnd, WM_PAINT, 0, 0); Про связанность кода: например TDeleteDialog обращается к glxwin, вместо того, чтобы отвязать через паттерн «интерфейс». Я понимаю, что в JS нет интерфейсов в чистом виде, но язык JS словно пластилин, все можно сделать, Вы же сделали реализацию классов, кстати, очень странную и лишнюю в этом проекте, тут бы объектов хватило, и прототипного наследования с головой. Про константы строковые я уже не говорю, выше уже перегнули палку по этому поводу. Я больше расстроен, что все монолитное, и нет провайдеров, например, провайдеров рендеринга, провайдеров дисковых операций и т.д. Если бы были провайдеры, реализованные как интерфейсы, то можно было бы специфицировать, какие методы должны быть у провайдера рендеринга и можно было бы написать несколько рендереров, реализовав набор классов, кто-то бы сделал рендерер консольный, кто-то вебовский. А так нет возможности вклиниться в код, все связано намертво суперклеем. Я вот фанатик-фундаменталист двухпанельных менеджеров, сначала VC, потом FARа и пишу код в них уже почти 20 лет, на любых языках, и мне вот, честно говоря, имея желание сделать из этого кроссплатформенное приложение по приведенной выше архитектуре, проще начать писать с нуля, вот честное слово.
Ой радость какая, спасибо порадовали. Приятно, что вы посмотрели код, и не ограничились морщением носа на обнаруженые скелеты в шкафу строковые константы. Ваши замечания вполне естественны, для человека, который не поговорил со мной хотя бы часик, чтобы понять, что за кажущейся неадекватной внешностью кода всё по сути вполне «провайдерное», как вы изволили выразится, то что вы говорите на эту тему, предлагаете, — оно есть. Есть конечно и косяки, вы нашли (и это делает вам честь) самый одеозный из них, но это не паттерн, это конкретный временый хак, просто надо откуда то взять execSync чтобы удалить файл, а его нет. Конечно надо иметь универсальный интерфейс удаления, но его нет лишь по недостатку времени и… и по одному чисто практичному принципу которым я пользуюсь, да простится мне это, а именно не создавать обощающего интерфейса пока не будет ряда пользователей (участков кода обращающихся к нему). Есть, знаете выражение, преждевременая оптимизация мать всех зол, так же и с преждевременым обобщением. Мне не составляет труда в любой момент найти все glxwin.execSync('rm ' + name) и заменить на что-то общее. Весь проект-то 5500 строк! Ну куда сейчас писать обощающий провайдер удаления, когда всё что связано с удалением занимает 45 строк, включая создание окна, отбработку событий в нём и собствено удаления списка выделеных объектов?
Можно бы много намодулить и наобобщать, но для кого? Вы, вообще, первый человек, кто посмотрел в код и что то о нём сказал. Если вы захотите совместо потрудится, мы всегда найдём общее, но пока таких людей нет, не ясно под кого подстраиваться, кому что может понадобится и у кого какие представления. Может появится человек который жаждет под браузер сделать коммандер, тогда будут одни приоритеты, а вдруг появится человек который хочет работать над текстовым редактором, чтобы он был удобнее для питона, тогда другие приоритеты. Сейчас никого нет, и никто не жаждет сотрудничества, так что приоритет пока другой: как можно быстрее исполнить самые основные функции для ежедневной работы и отладить всё ориентируясь на постояных пользователей, а он пока один — я сам. Мне самому и русских названий хватает и многих других ограничений.
Что по «разукрашиванию, опенжлю, шрифтам» так это всё вынесено в один модуль, тот самый glxwin который сконструирован так чтобы быть тем самым провайдером и быть заменяем на что угодно. И я им не увлекался, я его написал скрипя зубами и не спя по нескольку дней. Потому что писать под линукс (х11) очень трудно, у нас этим мало кто занимается, найти инфу крайне трудно, не смотря на пресловутые маны на всё. Это не дельфи и не SendMessage которым в универе учат. Файл glxwin.js пример этого API и если бы вы в нём разобрались, а это всего 100 строк! Надо переписать всего 100 строк чтобы портировать под другой провайдер графики и сообщений. Конечно, этого я ещё не делал, и там наверняка вскроется несколько хардожных зависимостей, но это опять же не паттерн, а недоделка из за спешки. Хоть под WinAPI я бы и сам переписал, но 1) для этого надо поставитьвинду и вычеркнуть несколько дней из жизни и 2) надо постояно запускать винду чтобы каждый раз проверять как оно там продолжает ли работать, то есть тестировать, мне это пока не под силу.
Что по «странной реализации классов», то тут просто слишком фундаментальный вопрос чтобы тяп ляп и заклеймить. Я могу подробно и разными способами, хоть абстрактно, хоть на пальцах, хоть умными словами computer science объяснить почему dnaof() была сделана и почему она такая класная библиотека классов и почему без неё трудно сделать Интервидение. (если ну очень кратко, то прототипное наследование не обеспечивает анонимный вызов super/inherited метода то есть вместо this.dna() приходится писать TView.draw(), это не только мне лично неудобно, это приводит к фундаментальным ограничениям по компоновке иерархии классов приложения).
Давайте посмотрим более базово, вот вы фанатик-фундаменталист двухпанельников и дельфовец с 1996 года и я такой же, только начинавший с турбо паскаля 5.0, и если мы не поймём друг друга то какие шансы вообще у людей понять друг друга? Если вы «напишете с нуля» потому что вам мой код кажется уродством не соответсвующему ничему хорошему, то я когда увижу ваш код, наверняка буду так же удивлён степенью его соответствия моим представлениям. Надо уметь как-то преодолевать это и уметь сотрудничать и подстраиваться. Для начала, хотя бы иметь привычку слушать, спрашивать, разъяснять свою позицию, а не ставить сразу двойки и «с нуля чесслово». Вдруг человек с которым вы говорите обо многом подумал и не с потолка принимал решения и имеет какие-от основания к выбраным путям, а не только школолота тупая, неадекват, и боевой валенок, перегибатель палок как тут меня заклеймили.
Ой многабукф
Можно бы много намодулить и наобобщать, но для кого? Вы, вообще, первый человек, кто посмотрел в код и что то о нём сказал. Если вы захотите совместо потрудится, мы всегда найдём общее, но пока таких людей нет, не ясно под кого подстраиваться, кому что может понадобится и у кого какие представления. Может появится человек который жаждет под браузер сделать коммандер, тогда будут одни приоритеты, а вдруг появится человек который хочет работать над текстовым редактором, чтобы он был удобнее для питона, тогда другие приоритеты. Сейчас никого нет, и никто не жаждет сотрудничества, так что приоритет пока другой: как можно быстрее исполнить самые основные функции для ежедневной работы и отладить всё ориентируясь на постояных пользователей, а он пока один — я сам. Мне самому и русских названий хватает и многих других ограничений.
Что по «разукрашиванию, опенжлю, шрифтам» так это всё вынесено в один модуль, тот самый glxwin который сконструирован так чтобы быть тем самым провайдером и быть заменяем на что угодно. И я им не увлекался, я его написал скрипя зубами и не спя по нескольку дней. Потому что писать под линукс (х11) очень трудно, у нас этим мало кто занимается, найти инфу крайне трудно, не смотря на пресловутые маны на всё. Это не дельфи и не SendMessage которым в универе учат. Файл glxwin.js пример этого API и если бы вы в нём разобрались, а это всего 100 строк! Надо переписать всего 100 строк чтобы портировать под другой провайдер графики и сообщений. Конечно, этого я ещё не делал, и там наверняка вскроется несколько хардожных зависимостей, но это опять же не паттерн, а недоделка из за спешки. Хоть под WinAPI я бы и сам переписал, но 1) для этого надо поставитьвинду и вычеркнуть несколько дней из жизни и 2) надо постояно запускать винду чтобы каждый раз проверять как оно там продолжает ли работать, то есть тестировать, мне это пока не под силу.
Что по «странной реализации классов», то тут просто слишком фундаментальный вопрос чтобы тяп ляп и заклеймить. Я могу подробно и разными способами, хоть абстрактно, хоть на пальцах, хоть умными словами computer science объяснить почему dnaof() была сделана и почему она такая класная библиотека классов и почему без неё трудно сделать Интервидение. (если ну очень кратко, то прототипное наследование не обеспечивает анонимный вызов super/inherited метода то есть вместо this.dna() приходится писать TView.draw(), это не только мне лично неудобно, это приводит к фундаментальным ограничениям по компоновке иерархии классов приложения).
Давайте посмотрим более базово, вот вы фанатик-фундаменталист двухпанельников и дельфовец с 1996 года и я такой же, только начинавший с турбо паскаля 5.0, и если мы не поймём друг друга то какие шансы вообще у людей понять друг друга? Если вы «напишете с нуля» потому что вам мой код кажется уродством не соответсвующему ничему хорошему, то я когда увижу ваш код, наверняка буду так же удивлён степенью его соответствия моим представлениям. Надо уметь как-то преодолевать это и уметь сотрудничать и подстраиваться. Для начала, хотя бы иметь привычку слушать, спрашивать, разъяснять свою позицию, а не ставить сразу двойки и «с нуля чесслово». Вдруг человек с которым вы говорите обо многом подумал и не с потолка принимал решения и имеет какие-от основания к выбраным путям, а не только школолота тупая, неадекват, и боевой валенок, перегибатель палок как тут меня заклеймили.
Ой многабукф
Вы, безусловно, имели все основания сделать именно так, а не иначе, даже если я или вы сами этих оснований не осознаете. Мы не можем охватить пониманием всех причин наших решений и действий, потому, что не можем полностью проанализировать и объяснить даже один момент существования. И вот эту свою неосведомленность о причинах, обуславливающих наш выбор, и называем свободой воли. А меру неосведомленности о причинах будущих событий, называем вероятностью, непредсказуемостью или энтропией, она обратно пропорциональна информации, которую мы имеем. Каждое мгновение времени, каждое действие имеет бесконечное количество причин и бесконечное количество следствий. Информация об этих взаимодействиях и причинно-следственных связях бесконечно велика. Чтобы объяснить одно мгновение — нужна вечность. Один человек анализирует одну малую часть причин и строит свое представление о событии или предмете, а другой — другую часть, и строит свое понимание. Друг с другом они могут спорить бесконечно, пока их методы анализа, набор анализируемых фактов, весь их предыдущий опыт и багаж знаний, не совпадут. А как совпадут, то противоречие между ними исчезнет.
Я говорю, странная реализация, понимая зачем она нужна, и что вы хотели сделать override/inherited, как это положено в ООП, мало кто ощущает необходимость в этом, для JS, но она есть, я согласен. А вот реализация содержит очень много лишнего. Ну нет классов в JS, а наследование и вызов методов предка можно сделать не для класса, а для функции, это реализуется 7 строками:
Посмотрите паттерн, использующий этот подход, который, кстати, мало кто понимает: http://habrahabr.ru/post/183188/ Это и есть паттерн для провадеров или модулей, объединенных общим интерфейсом. Вот в этом проекте можно посмотреть пример https://github.com/tshemsedinov/impress/tree/master/lib Тут impress.security.js — это интерфейс, а impress.security.mongodb.js — это реализация. Или db.js — интерфейс, а db.mongodb.js — реализация. Конечно, это не чистуй паттерн интерфейсов, и не классический паттерн наследования, но для JS так удобно делать API, и я сейчас уже называю это провайдерами, чтобы не путаться в терминах с теми, кто понимает под интерфейсами нечто классическое. А в JS через примеси можно сделать красивее и проще. Примеси — это замечательный инструмент непрямого наследования, который в дэлфях реализовывался через отправку оконных сообщений, у кого оконный обработчик умеет обрабатывать CM_DIALOGKEY, тот, не зависимо от предка реализует одну их функциональностей диалогового окна.
Конечно, писать TFileList = kindof(TList) для паскалиста/дэлфиста приятнее, но в JS, для экземпляров (т.е. для объектов) гораздо лучше использовать голые структуры данных, без методов. Например просто files = []; а методы оставить в активном классе, построенном как API: например fsUtils.copy(files, destination); Вот я и предлагаю строить всю функциональность, как API, а данные держать отдельно, тогда данные можно будет сереалиховать в JSON и десериализовать, высылать по сети или делать с ними другие операции, как над чистыми данными.
Сделать сетевую и браузерную версию, реализацию для управлением распределенными серверами приложений мне будет интересно, у меня и команда есть и все это можно сделать достаточно быстро, но только после того, как локальный скелет будет отвязан от рендеринга и от операционной системы, когда в panel.js рядом с TFilePanel не будет лежать function blend(color, level, back), а вместе с function visibleChar© они отправятся в какой-то deodarUtils.js, когда шеловские команды не будут передаваться в модуль glxwin на исполнение а в конце строки будет стоять точки с запятыми и будут изжиты атавизмы турбовижена, который погиб смертью храбрых еще в XX веке, передав дэлфистам заповедь никогда не делать тех ошибок, которые он совершал. Такая двухпанельная штука очень нужна, например, для одновременной правки на двух десятках серверов одного js файла, который сразу же подхватится серверами приложений для исполнения, для навигации по кластеру этих серверов, для поиска в распределенном хранилище файлов, и для других операций, для которых нет сейчас удобных средств вообще. Но для этого должна появиться спецификация провайдеров:
1. Провайдер для работы с файловой системой
1.1. Реализация для локальной ФС с запросами к модулю fs из node.js
1.2. Реализация для удаленной ФС с запросами к провайдеру сетевого транспорта (любому)
1.3. Реализация для браузеров с запросами к Html5 FileApi
1.4. Другие реализации, по работе с smb, ftp, mongodb gridFS, hadoop HDFS, git, dropbox, да чем угодно, это смогут расширять люди сами
2. Провайдер сетевого транспорта
2.1. Реализация клиента и сервера для HTTP/AJAX/JSON для node.js
2.2. Реализация клиента и сервера для HTTP/AJAX/JSON для браузеров
2.3. Реализация клиента и сервера для веб сокетов для node.js
2.4. Реализация клиента и сервера для веб сокетов для браузеров
3. Провайдер рендеринга
3.1. Реализация рендеринга в консоли
3.2. Реализация рендеринга для OpenGL
3.3. Реализация рендеринга для MacOS
3.4. Реализация рендеринга для Windows и т.д. и т.п.
4. Провайдер редактора
5. Провайдер локализации
6. Провайдер конфигурации
7. Провайдер логирования (вот мне нужно, например, логировать весь доступ)
8. Провайдер аутентификации (мне нужно иметь возможность регулировать политики доступа к распеределенным файловым системам помимо того, что дает стандартная политика ФС в посиксе)
9. И другие провайдеры, не все сразу конечно, но идея, думаю ясна.
Мне, кстати, так и не удалось запустить проект, работаю на CentOS 6.5 (64бит). И в линуховом мире фрагментация очень большая, а JavaScript нам нужен именно для того, чтобы перодолеть эту фрагментацию. Так что, я надеюсь, что вы меня услышите и тогда проект будет не только для личного пользования, и у вас появятся еще пользователи, носители других языков, китайского, хинди, арабского и работающие на маках, винде, спектрумах, поисках и андроидах )))
Я говорю, странная реализация, понимая зачем она нужна, и что вы хотели сделать override/inherited, как это положено в ООП, мало кто ощущает необходимость в этом, для JS, но она есть, я согласен. А вот реализация содержит очень много лишнего. Ну нет классов в JS, а наследование и вызов методов предка можно сделать не для класса, а для функции, это реализуется 7 строками:
Function.prototype.override = function(fn) {
var superFunction = this;
return function() {
this.inherited = superFunction;
return fn.apply(this, arguments);
}
}
Посмотрите паттерн, использующий этот подход, который, кстати, мало кто понимает: http://habrahabr.ru/post/183188/ Это и есть паттерн для провадеров или модулей, объединенных общим интерфейсом. Вот в этом проекте можно посмотреть пример https://github.com/tshemsedinov/impress/tree/master/lib Тут impress.security.js — это интерфейс, а impress.security.mongodb.js — это реализация. Или db.js — интерфейс, а db.mongodb.js — реализация. Конечно, это не чистуй паттерн интерфейсов, и не классический паттерн наследования, но для JS так удобно делать API, и я сейчас уже называю это провайдерами, чтобы не путаться в терминах с теми, кто понимает под интерфейсами нечто классическое. А в JS через примеси можно сделать красивее и проще. Примеси — это замечательный инструмент непрямого наследования, который в дэлфях реализовывался через отправку оконных сообщений, у кого оконный обработчик умеет обрабатывать CM_DIALOGKEY, тот, не зависимо от предка реализует одну их функциональностей диалогового окна.
Конечно, писать TFileList = kindof(TList) для паскалиста/дэлфиста приятнее, но в JS, для экземпляров (т.е. для объектов) гораздо лучше использовать голые структуры данных, без методов. Например просто files = []; а методы оставить в активном классе, построенном как API: например fsUtils.copy(files, destination); Вот я и предлагаю строить всю функциональность, как API, а данные держать отдельно, тогда данные можно будет сереалиховать в JSON и десериализовать, высылать по сети или делать с ними другие операции, как над чистыми данными.
Сделать сетевую и браузерную версию, реализацию для управлением распределенными серверами приложений мне будет интересно, у меня и команда есть и все это можно сделать достаточно быстро, но только после того, как локальный скелет будет отвязан от рендеринга и от операционной системы, когда в panel.js рядом с TFilePanel не будет лежать function blend(color, level, back), а вместе с function visibleChar© они отправятся в какой-то deodarUtils.js, когда шеловские команды не будут передаваться в модуль glxwin на исполнение а в конце строки будет стоять точки с запятыми и будут изжиты атавизмы турбовижена, который погиб смертью храбрых еще в XX веке, передав дэлфистам заповедь никогда не делать тех ошибок, которые он совершал. Такая двухпанельная штука очень нужна, например, для одновременной правки на двух десятках серверов одного js файла, который сразу же подхватится серверами приложений для исполнения, для навигации по кластеру этих серверов, для поиска в распределенном хранилище файлов, и для других операций, для которых нет сейчас удобных средств вообще. Но для этого должна появиться спецификация провайдеров:
1. Провайдер для работы с файловой системой
1.1. Реализация для локальной ФС с запросами к модулю fs из node.js
1.2. Реализация для удаленной ФС с запросами к провайдеру сетевого транспорта (любому)
1.3. Реализация для браузеров с запросами к Html5 FileApi
1.4. Другие реализации, по работе с smb, ftp, mongodb gridFS, hadoop HDFS, git, dropbox, да чем угодно, это смогут расширять люди сами
2. Провайдер сетевого транспорта
2.1. Реализация клиента и сервера для HTTP/AJAX/JSON для node.js
2.2. Реализация клиента и сервера для HTTP/AJAX/JSON для браузеров
2.3. Реализация клиента и сервера для веб сокетов для node.js
2.4. Реализация клиента и сервера для веб сокетов для браузеров
3. Провайдер рендеринга
3.1. Реализация рендеринга в консоли
3.2. Реализация рендеринга для OpenGL
3.3. Реализация рендеринга для MacOS
3.4. Реализация рендеринга для Windows и т.д. и т.п.
4. Провайдер редактора
5. Провайдер локализации
6. Провайдер конфигурации
7. Провайдер логирования (вот мне нужно, например, логировать весь доступ)
8. Провайдер аутентификации (мне нужно иметь возможность регулировать политики доступа к распеределенным файловым системам помимо того, что дает стандартная политика ФС в посиксе)
9. И другие провайдеры, не все сразу конечно, но идея, думаю ясна.
Мне, кстати, так и не удалось запустить проект, работаю на CentOS 6.5 (64бит). И в линуховом мире фрагментация очень большая, а JavaScript нам нужен именно для того, чтобы перодолеть эту фрагментацию. Так что, я надеюсь, что вы меня услышите и тогда проект будет не только для личного пользования, и у вас появятся еще пользователи, носители других языков, китайского, хинди, арабского и работающие на маках, винде, спектрумах, поисках и андроидах )))
Спасибо за ответ. Постараюсь вас услышать. Несомненно, то, что вы говорите стоит иметь ввиду. Жаль вам не удалось запустить программу, создали бы issue на гитхаб, если бы нашли время и силы. Люди уже запустившие на CentOS были. Кажется, дело было в том, что на Redhat-потомках(деривативах) fc-list работает не так как на Убунтах.
И да, ну затравили человека, отнеситесь к его работе конструктивно и с уважением, если он не прав, то помогите ему понять в чем именно и как это можно исправить, имейте терпение. Вот зачем вы минусуете другие его сообщения, которые уже ни как не относится к флейму сверху, во это его сообщение, например. Проделана грандиозная работа, может человек устал, сидел по ночам, дайте перевести дух и проявите великодушие и уважение.
Хм, я как-то начал писать двухпанельник на AppJS, но забил. Автору респект, конечно, но с таким подходом и градусом неадеквата это школолоподелка, не более. Для практики и набора опыта сойдёт, конечно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рабочая среда «Деодар» для Линукс