dn2l - Dos Navigator для Linux

[Alex2013]

Припоминается следующий натуральный баг: если навести курсор на элемент каталога ".." и сотворить "удалить"

Там кажется есть режим "удаления с панели"(Ctrl+Del) возможно это воспринимали как реальное удаление и пугались ...

[SSerge]

Alex2013, нет. Оно реально удаляло все каталоги, включая корневой диска. Не отслеживал, поправили это в конце концов или нет.

[haword]

есть же ndn правда с закрытыми исходниками. может просто попинать его автора чтобы открыл их?)

[Alex2013]

есть же ndn правда с закрытыми исходниками. может просто попинать его автора чтобы открыл их?)

Крайние версии NDN особенно для Вин-32 редкостная гадость .

[Cheb]

У японцев есть замечательная технология следящего проектора. Который позволяет картинку высокой чёткости проецировать на движущийся объект, идеально привязываясь к нему. Уже используется для хирургии (подсветка частей органов и линий разреза) а также как виртуальный анимированный грим на актёрах в театре.
Вот когда *такое* встроят в виар-очки, чтобы кусочек картинки высокой чёткости следовал за зрачком а всё остальное было разрешением пониже - фактически создавая аналог 8к на глаз при реальных затратах 2х1к на глаз - вот тогда и наступит реальный прорыв. Потому что разрешение матриц растёт медленно и трудно, равно как и разрешение рендера у мобильных (очки жеж) устройств.

[zub]

Чето все подзаглохло?

[Alex2013]

У японцев есть замечательная технология следящего проектора. Который позволяет картинку высокой чёткости проецировать на движущийся объект, идеально привязываясь к нему. Уже используется для хирургии (подсветка частей органов и линий разреза) а также как виртуальный анимированный грим на актёрах в театре.
Вот когда *такое* встроят в виар-очки, чтобы кусочек картинки высокой чёткости следовал за зрачком а всё остальное было разрешением пониже - фактически создавая аналог 8к на глаз при реальных затратах 2х1к на глаз - вот тогда и наступит реальный прорыв. Потому что разрешение матриц растёт медленно и трудно, равно как и разрешение рендера у мобильных (очки жеж) устройств.

Уже было .... пытались сделать затворные очки с проектором (причем не на секло очков, а на специальный лист пластика или просто на стол или стену ) но выходило слишком темно и нечетко .
Зы
Cheb ты похоже темой ошибся по виртуалке это сюда ...
Виртуальная и"аргументированная" реальность. Ждем Бума?

[zub]

с офтопиком завязываем

[Alexander]

Dos Navigator для Linux нужен. Но нужно проработать сборочную среду. Сходу не компилируется.

[Alex2013]

Dos Navigator для Linux нужен.

Поделки двух-трех летней давности (но честно говоря и такие удивляют )
Есть версии NDN: GNU/Linux x64 (L64) и NDN: GNU/Linux x32 (L32)
http://ndn.muxe.com/download/
Зы

Сходу не компилируется.

ИМХО сейчас наверное проще взять FreeVision и сделать простой ДН-подобный файловий менеджер с нуля, чем мучить "легаси исходники".

[Kopa]

Dos Navigator для Linux нужен. Но нужно проработать сборочную среду. Сходу не компилируется.

Вроде собирался у меня, но сейчас уже не уверен.
Но, тот же NDN для Windows собрался без особых вопросов DN for Windows OSP 6.4.0

P.S. А, вообще, сейчас под Linux в рамках использования LiveCD, например Puppy сборки , кроме беспроблемного запуска под ней Lazarus (из 3-x Deb пакетов и подключения штатного пакета DevX.sfc (GCC) из Puppy, собрал под ним Double Commander)
запускаю собранный пакет Wine 6.10 взятый с топика на форумe Puppy (насколько он без встроенного дополнительного кода не знаю), а дальше уже под ним Far2 -> TotalCommander (и повторно Far2 для получения графического, а не терминального окружения программы)
думаю это лучше решение чем текущий вариант DN2L, DND для использования под Linux
На удивление под Wine 6.10 хорошо работает много программ (даже лучше в наблюдениях чем под Windows)

http://sendpic.org/view/1/i/tQYiYvUtB7W ... GDPnUg.png

P.S. Затраты по памяти этой сборки пакета Wine 6.10 ~400МБ при установке в RAM диск системы LiveCD и примерно столько же при старте, например начально: wine Far.exe (несовсем понятно почему по использованию памяти так сделано)
При установленной памяти в буке 4Гб памяти в Xenial Puppy 32 (Ram диск ~900Мб), Bionic Puppy, Tarhup Puppy, Fossa Puppy (~ 1,9 Гб)
При установленной памяти в буке 8Гб памяти Bionic Puppy, Tarhup Puppy, Fossa Puppy (~ 3,9 Гб Ram диск)

Не разобрался только как мне пробросить русский язык в Wine 6.10 в таком варианте запуска под LiveCD Puppy.
Думаю, возможно, это разрешить как то с помощью использования программы http://nncron.ru/index_ru.shtml (бесплатной для некомерческого использования для стран бывшего USSR и способом регистрации описанным в рускоязычном help.chm)

[unxed]

Чето все подзаглохло?

Ну это ж для фана всё делалось. Есть настроение — пилю. Нет настроения — не пилю :)

Сейчас вот решил с другой стороны зайти: сначала пересадить Free Vision на UTF-8. Без этого дальнейшая работа всё равно бессмысленна, т.к. кому нужен файловый менеджер, работающий в однобайтной кодировке? А UTF-8 версия Free Vision имела бы ценность и сама по себе, как отдельная полезная штука. Может, IDE научили бы понимать русский в UTF-8, наконец :)

Дело это оказалось сравнительно несложное, в целом оно уже запускается и даже интерфейс показывает. Вот тут исходники:
https://github.com/unxed/fv_utf8

Собирать для экспериментов нужно testapp.pas.

Принцип адаптации под UTF-8 я использовал тот же, который у magiblot в его сишной UTF-8 адаптации Turbo Vision:
https://github.com/magiblot/tvision

А именно, ячейка экранного буфера просто увеличена до 4 байтов (вернее сказать, до 8: 4 на UTF-8-символ и 4 на цвет — задел на RGBA в перспективе) — с соответствующими изменениями везде, где это необходимо. Пока выглядит вплоне жизнеспособным подходом: за день удалось от полного экрана крякозябр дойти до стадии сносно отрисовывающегося интерфейса и отображающего русский в UTF-8 редактора.

ИМХО сейчас наверное проще взять FreeVision и сделать простой ДН-подобный файловий менеджер с нуля, чем мучить "легаси исходники".

В этом рассуждении, безусловно, есть доля смысла. Однако Free Vision сначала надо для UTF-8 адаптировать. Вот когда это будет готово, можно будет и правда сделать простенький файловый менеджер, повторяющий иерархию классов DN, и пилить понемногу его, опционально перетаскивая туда отдельные лицензионно чистые кусочки из DN, если в этом будет смысл.

[zub]

Отличные новости!
ДН еще ФПЦ не собирается?

[unxed]

ДН еще ФПЦ не собирается?

Пока нет. Там очень много Virtual Pascal-специфичного кода, и надо, похоже, делать реимплементацию RTL VP, чтоб всё это работало. Сделать её, конечно, можно, но это надо настроение и время. Плюс там своя кастомная Turbo Vision, сделанная на базе проприетарного борландовского кода (напоминаю, исходники паскалевого turbo vision никогда не были свободными), так что я подумал: если уж пересаживать на Free Vision — то уже на UTF-8-ный сразу лучше, когда он готов будет.

[unxed]

Тут выяснилось, что во Free Pascal'е уже сделали адаптацию Free Vision под юникод. Ждёт мержа в основную ветку. Пожалуй, стоит дождаться, когда вмержат, и работать с этой версией уже дальше. Детали тут: https://gitlab.com/freepascal.org/fpc/s ... _833019965

Добавлено спустя 9 часов 37 минут 12 секунд:
Связался с автором этой адаптации, уточнил текущий статус. В целом там всё готово, осталось протестировать на платформах кроме Windows и Linux, и можно мержить в main. Расписал подробности реализации и текущий статус здесь: https://wiki.freepascal.org/Free_Vision#Unicode_version

По поводу DN теперь такой план:

1. Дождаться выхода Ubuntu 22.04/Mint 21, потому что юникодной Free Vision нужен FPC 3.2, а у меня пока системный 3.0.4, и собирать весь паскаль из исходников мне лень. Тем более, выйдут они уже довольно скоро.

2. Сделать на базе юникодной Free Vision простой двухпанельник, повторяющий иерархию и имена классов DN.

3. Дальше на этот каркас уже можно будет навешивать более продвинутый функционал DN, либо перенося из него соответствующий код (при условии лицензионной чистоты, без всяких там заимствований из RTL VP и Borland'овского кода), либо реализуя с нуля — уж что проще будет. Цель в любом случае в воспроизведении 1:1 UX DN, насколько возможно с учётом разницы платформ, юникода и востребованности определенных фич на современных системах (скажем, образы дискет едва ли так уж важны нынче).

Такой подход выглядит перспективнее, чем пересаживать оригинальный DN сразу весь целиком на другой компилятор, другую RTL и ещё с однобайтных кодовых страниц на юникод до кучи. А, главное, при таком подходе на каждом этапе будет собирающаяся и работающая программа, которую можно будет использовать хотя бы на уровне базового функционала. Это куда веселее, чем огромный объем кода, который собирается только на треть, и даже до стадии способности отрисовать свой интерфейс худо-бедно не дошёл ещё.