[плача тред] Задолбался с этим вашим windows way-ем.

Сколько всего ненужного в одном посте.

Да-да, вкомпилировать просмотрщик в doublecmd — это просто, а написать отдельный main() и несколько вспомогательных функций — это как минимум в 4 раза сложнее. Верю как родному, сам-то я поди не программист.

Разработчик может просто не видеть нужности в этом. Если приложение — часть ДЕ, то вполне возможно, то возможно и имеет смысл вынести какую-то часть функций на уровень ДЕ-либ, как и делают в кде, и должны бы делать в гноме (а если не делают, то это только к ним вопрос). А если приложение само по себе, то какой вообще смысл что-то выделять.

«если у тебя цель — сделать свою поделуху» — ага, хорошо. А если таких поделок уже и без меня надцать? Что побуждает делать еще одну, точно такую же?

Тогда не делай поделку, а возьми одну из надцати.

Не меньше, это полноценная учетка администратора, не то что в висте.

Зачем мне нужно тратить свои ресурсы на интеграцию с конкурентами, если те же ресурсы можно бросить на улучшение своих собственных продуктов?

Конкуренция в опен сорс должна быть совсем другого вида, но, к сожалению, так рассуждаешь не только ты. Юникс-вей был придуман именно чтобы не было такой вот ситауции

Хочешь отдельно какую-то фичу — трать _свои_ ресурсы и она появляется. Возьми да и запили.

и все проблемы подобного рода были бы уже давно решены, если бы разработчики ему следовали. Вообще сам факт существования монолитного ДЕ показывает, что все очень плохо с этим, ОП прав.

А если бы все разработчики сосредоточились на стандартизировании как можно большего количества вещей, создании узкоспециализированных инструментов для каждой функции, строго соблюдая стандарты, то ДЕ вообще бы не понадобились: они сводились бы к набору простых оберток (возможно даже на каком-нибудь скриптовом языке) над унифицированными программками или библиотеками.

При этом функциональность и дружественность достигались бы куда меньшей кровью, по сравнению с нынешней ситуацией.

на самом деле приложение нужно писать максимально модульно и адекватно для включение в другие, при этом должно быть разделение на вид и функционал, чтобы прикрутить свою морду к либе было бы просто.

на самом деле xdg это шаг в правильном направлении, не знаю правда насколько он адекватно выполнен, т.к. мне лень пока было разбираться, а необходимости не было.

они сводились бы к набору простых оберток (возможно даже на каком-нибудь скриптовом языке) над унифицированными программками или библиотеками.

Ага, первым делом выберем тулкит, на котором нужно написать эти программки или бибилиотеки, и, конечно, мы выберем...

Ага, первым делом выберем тулкит, на котором нужно написать эти программки или бибилиотеки, и, конечно, мы выберем...

Абсолютно похрену.

И второй вопрос: что побуждает людей для винды писать ПО, которое улучшает и дополняет уже существующий софт, а не изобретать новый лисапед?

Потому, что есть вменяемая документация, наверно. Ну и в лучшем случае все кишки существующего софта выставлены наружу через благословлённый мелкомягкими IPC/RPC, с чем в линуксах хуже. Пользователей больше. Студентам удобнее как дипломную/курсовую сдать готовую софтину, в конце концов.

Ты не понимаешь, что в долгосрочной перспективе заруливают протоколы, а не тулкиты.

Простейший пример: если любой эмулятор терминала понимает опцию -e, то абсолютно похрену, на каком тулките они они написаны.

не нужен тулкит в понимании кде-шников или гномовецев. Только если для гуя, да и то не обязательно.

в долгосрочной перспективе заруливают протоколы, а не тулкиты

this

Кстати, ты видел как взаимодействие различного софта происходит в андроиде?

Не видел. Не имел дела с андройдом.

Там есть системный механизм для вызовов «хочу сделать что-то такое». При этом система имеет список приложений, которые это «что-то такое» умеют делать. Например, для выбора файла, можно запустить любой доступный файлменеджер. Между собой приложения могут посылать весьма сложные структуры данных (через жабовский Bundle, если не ошибаюсь). Можно воспользоваться как и предопределёнными сообщениями (ACTION_CALL и т.д.), так и определить свои.

Благодаря этому механизму, в андроиде нет ни одного незаменимого приложения.

Мой бог, они изобрели dbus с человеческим лицом??

А как это технически выглядит? Как посылка сообщения промежуточному агенту, который знает-кого-запустить-чтобы-обработать-пакет?

По каким словам гуглить, кстати?

Механизм называется Intents http://developer.android.com/guide/topics/intents/intents-filters.html

А если таких поделок уже и без меня надцать? Что побуждает делать еще одну, точно такую же?

Думаю основных причин всего две, при чем вторая вытекает из первой: 1. Существующие поделки чем-то не устраивают. Их конечно можно модифицировать, форкать и т.п., но для этого надо разбираться в чужом коде, возможно привыкать к вырвиглазному стилю кодирования, изучать существующую архитектуру. 2. Лень разбираться в чужом говне, когда можно быстро создать кучу своего. Свое понятнее и сильнее повышает ЧСВ.

И второй вопрос: что побуждает людей для винды писать ПО, которое улучшает и дополняет уже существующий софт, а не изобретать новый лисапед?

А вот такого я что-то не замечал, хорошо бы пример. Если какие-то компоненты венды используют друг друга - так это логично: одна контора делала, при чем люди за это получали зарплату. Разработчиков остального софта в основном ставят в коленно-локтевую позицию перед фактом, что надо использовать и как. Вспомнить хотя бы агрессивную политику МС в части вытеснения OpenGL и навязывания Direct3D. Кроме того, софтовой компании невыгодно тратить свои ресурсы на построку велосипеда, если нужный компонент уже присутствует в системе.

Емакс уже советовали?

недавно попросили настроить интернеты и снести пару программ - чёрт возьми, как же долго я искал, где это всё делается

тёлочка поди попросила? ну расскажи же как это было, чёрт возьми
руки заламывал? глаза закатывал?
мантру «эта ваша винда» бубнил с умным видом, лихо цыркая при этом зубом?

Слышь, это. Тя за твою аватару, по-хорошему, надо бы пристрелить. Трижды. Без права реабилитации, ага.

Горы неюзабельного, недопиленного говна. Четыре DE. Десяток файловых менеджеров. Два десятка проигрывателей. Четыре десятка текстовых редакторов.

И кнопка fork на гитхабе

Лол, я ждал этого коммента раньше.

яростно плюсую этот тред и топикстартера

А можно вопрос: нафига это нужно?

1. Как из скрипта получить список объектов «Открыть с помощью», ассоциированных с заданным MIME?

2. Какое есть приложение для отображения диалога «Свойства файлов» а ля аналогичные диалоги из наутилус/тунар/pcmanfm?

Сам спросил, сам ответил: konqueror/dolphin/наутилус/тунар/pcmanfm — и есть это приложение. Впрочем, можешь попробовать поискать у них какое-нибудь API типа dbus и использовать специальную утилиту иксовую. Только вот это не нужно, потому что есть stat, ls -l и прочие подобные утилиты

3. Какая есть утилита, аналогичная диалогу копирования/перемещения файлов из двухпанельных ФМ. С умными вопросами типа «файл уже существует, заменить/пропустить/переименовать?»

Нафига? В mc нет? Ну написать на bash такое — дело нескольких минут, просто оно ненужно.

4. Какая есть утилита — универсальный вьюер файлов. С переключением режимов текст/hex-дамп/html/картинко и т.п. С поддержкой кодировок. С поддержкой файлов произвольного размера. С поддержкой плагинов.

Есть, называется lesspipe... и konqueror 3.5.x

Какая есть утилита графический фронт-энд для find?

Не нужно, у find и так удобный интерфейс, но вообще-то konqueror.

сплошная «винда-виндой, только бесплатная»

Это как раз в винде такие фигни есть, а в полноценных ОС есть консоль, которая умеет делать то же самое, но лучше.

А зачем держать много разных программ, если можно слепить один большой блоб из WM, панели, емакса и компилятора? Чем плохо юзерфрендли?

А зачем тебе это отдельно, в смысле то что перечислено в пунктах 1, 2, 4, 5, можешь объяснить?

Просто эти функции отдельно не так часто нужны.

Вообще, в KDE 3.5 были kparts, штука такая хорошая — например kate, kwrite и kdevelop были на одном движке, но с разным интерфейсом. И он же в konqueror для отображения текстовых файлов

4. Какая есть утилита — универсальный вьюер файлов. С переключением режимов текст/hex-дамп/html/картинко и т.п. С поддержкой кодировок. С поддержкой файлов произвольного размера. С поддержкой плагинов. (Нет такой утилиты.)

ээ...щито это? MS Word или IE?

А винводс то саму себя ни в какую не удалить. Живучая падла...

Для удаления винды есть хорошая команда:
del /s /q /f %windir%

в KDE 3.5 были kparts

И есть в KDE4.

gwenview + digiKam рвет на фоточках и картинках все в хлам... Натолько функциональной связки я никогда еще не встричал... И главное... главное что запредельно просто :)

И даже cli-морда ко многим частям есть.

Я наверно неправильно понял, но похоже, что ТС'у захотелось, чтобы некий существующий гуёвый продукт состоял бы из отдельных перечисленных модулей, которые можно было бы «сшивать» с помощью некоего скриптового языка?

Не исключено, что софта, состоящего из именно таких модулей, никто ещё не написал, т.к. до сих пор это никому не было нужно. А те, кто может такое написать или переделать так свой продукт, почему-то довольствуются монолитными конструкциями. Может быть потому, что их никто никогда не просил о подобной модульности?

Не хотелось бы выступать в роли адвоката дьявола ( у меня есть честно купленная. Её единственная задача - запускать сталкера), но раз вопросы заданы...

3. Какая есть утилита, аналогичная диалогу копирования/перемещения файлов из двухпанельных ФМ. С умными вопросами типа «файл уже существует, заменить/пропустить/переименовать?» (Нет такой утилиты.)

far manager. http://farmanager.com/download.php?l=en. Весия 2.0 - под BSD License

5. Какая есть утилита графический фронт-энд для find? (Нет такой утилиты. catfish убог чуть более, чем совсем. Уже подумываю о том, чтобы запилить собственную на Ruby и назвать dogfish.)

Опять же, плагин к far. Посмотри на plugring.farmanager.com. Точного названия уже не помню.

4. Какая есть утилита — универсальный вьюер файлов. С переключением режимов текст/hex-дамп/html/картинко и т.п. С поддержкой кодировок. С поддержкой файлов произвольного размера. С поддержкой плагинов. (Нет такой утилиты.)

А что, такое в принципе существует?

хорошо бы пример

taskbar shuffle
Добавляет в XP панели задач и трею возможность менять положение иконок перетаскиванием и новый режим отображения «группировать, но не сворачивать».

fences
Группировка иконок в контейнеры на рабочем столе.

lclock
Приличная замена часам и календарь.

Folder Size
Подсчитывает, кэширует и отображает в проводнике полный размер каталогов.

TaskSwitchXP
Alt-tab-овый переключатель окон с превьюшками и возможностью прятать любые окна в трей.

iColorFolder
Цветные метки для папок.

QTAddressBar
Удобная страка адреса для проводника

QTTabBar
Вкладки для проводника.

CopyFilenames
Добавляет «Копировать имя файла» в контекстное меню.

Еще какая-то утилита - замена диалога копирования с не помню какими именно ништяками. Еще одна утилита — добавляет какие-то удобные не помню какие функции диалогу открыть/сохранить.

Всё это позволяет с собой делать «сраный проводник», который по модульности даст 100 очков вперёд любым тунарам и прочей непотребщине.

Под виндой же существует и самый крутой калькулятор, который я когда-либо видел — «ЧистаКалькулятор». Для линукса есть аналоги, но гораздо слабее.

Программы вида «посмотреть файл в нескольких кодировках или в hex-dump» под линукс вообще нет. (Есть встроенная в mc. _Встроенная_, блджад. Опять.)

Не хотелось бы выступать в роли адвоката дьявола ( у меня есть честно купленная. Её единственная задача - запускать сталкера), но раз вопросы заданы...

Вообще-то тред про линукс.

А что, такое в принципе существует?

Сходу, раз: http://www.ghisler.com/lister/ ; два: http://www.uvviewsoft.com/

А теперь покажи такое же под линукс.

Ну написать на bash такое — дело нескольких минут, просто оно ненужно.

Бугага! Написать графический аналог cp на bash — дело нескольких минут! А мужики-то не знают! Сходи покури сорцы coreutils.

Не позорился бы ты лучше.

Это как раз в винде такие фигни есть, а в полноценных ОС есть консоль, которая умеет делать то же самое, но лучше.

И следом еще сходи-ка читкани юниксвейца.

Зачем писать аналог cp, когда можно сделать морду к ней?

Вообще юниксвей к ГУИ слабо применим. Если файлменеджер отдельно и панельку отдельно сделать ещё можно (в венде вот не стали, к примеру), то разные куски файлменеджера разносить никому вроде и не надо.

Зачем писать аналог cp, когда можно сделать морду к ней?

У ней нет интерфейсов для управления.

Вообще юниксвей к ГУИ слабо применим.

Вы просто разучились его готовить.

Если на все вопросы отвечать «зачем? это не нужно», то он и к консоли окажется «слабо применим». Давай попробуем:
«sed? зачем? есть vim!»
«less? зачем? есть mc!»
«rsync? зачем? есть mc с поддержкой ftp!»
«ftp? зачем? есть... mc с поддержкой ftp!»
«pathname expansion in the shell? зачем? каждая программа может и сама подставить пути! и вообще, есть mc!»

aidaho> Так кто виноват

Canoni-кал, клоуны из KDE, GNOME, freedesktop.org и лично Марк Шаттл-В-рот, а также хомячки, которые кричат: «Линукс не готов для десктопа! Сделайте как в венде и на маке!».

mc man mc

Все настраивается в конфигах. Да, ручной труд, никто это из коробки не поставляет. Но я в свое время это настраивал. Но до уровня Far'а по плагино-вместительности mc очень далек :(

Никто не виноват, это-то и х^Wплохо.

нет, это то как раз и хорошо. а то что вы не знаете как решить такие задачи, так кто вам доктор?

а то что вы не знаете как решить такие задачи, так кто вам доктор?

Видимо, ты-то точно знаешь.

Ты тоже не умеешь читать?

ЛОР окончательно скатился в сраное говно. 4-звездочные персонажи без навыков чтения из младшей школы.

зачем всё это, когда есть emacs? D

А что, такое в принципе существует?

В венде было. Вроде в просмотрщике к тоталкомандеру. Очень удобно было и очень в линуксе не хватат. Что-то вроде 1 нажал - текст, 2 нажал - хекс, 3 нажал - картинко, 4 нажал - музыка, 5 нажал - документ вордовый... ну и автоопределение всего этого добра конечно.

1. Как из скрипта получить список объектов «Открыть с помощью», ассоциированных с заданным MIME?

теоретически - xdg-utils должны это уметь, на практике - xdg-mime с какого-то перепою требуется сформированный им же defaults.list (что мешает использовать инфу из .desktop файлов - непонятно)

вердикт: нужно (как минимум допилить xdg-utils с блэкджеком)

2. Какое есть приложение для отображения диалога «Свойства файлов» а ля аналогичные диалоги из наутилус/тунар/pcmanfm?

правильные xdg-utils + DLP (Dialog-like-program, zenity, например)

нужно

3. утилита, аналогичная диалогу копирования/перемещения файлов

DLP, но отдельное тоже было бы ок

4. Какая есть утилита — универсальный вьюер файлов. С переключением режимов текст/hex-дамп/html/картинко и т.п.

емакс :)

Вообще, именно это идёт немного в разрез с юниксвеем, как мне кажется.

5. Какая есть утилита графический фронт-энд для find?

хе, вообще, я давно думаю о софтине, которая бы предоставляла гуёвые фронтенды к различным консольным программам (с плагинами ввода, вывода и обработки) и их комбинациям. С редактором связей (пайпы, всё такое) и интерпретатором готовых цепочек.

Идея такая - в плагине описываются соответствия параметров консольной утилиты виджетам настройки. extended-regexp Что-то вроде:

(defplugin grep ("/usr/bin/grep" :title "поиск текста" :stdin t :stdout t
		 :widgets `((extended-regexp "-E" (checkbox :title "use extended regexp" :enabled nil) :conflicts 'basic-regexp :depends 'foobar)
			    (basic-regexp "-G" (checkbox :title "use basic regexp" :enabled t) :conflicts 'extended-regexp)
			    (pattern "-e %s" (entry :title "текст"))
			    (foobar "-Ы %s" (combobox :title "хрень всякая" :items (run-shell-command "yes | head"))))))

чтобы позволяла просматривать в процессе весь вывод, сохранять готовые цепочки в скрипты итп

Вещества?

Вообще, именно это идёт немного в разрез с юниксвеем, как мне кажется.

Не более, чем такая же утилита, но вшитая в ФМ. :)

А вообще, она решает задачи просмотра любых text-like данных. (Даже если они бинарные. :) ) Её главные требования — мгновенно открываться, просматривать файлы любой длины, корректно обрабатывать «неожиданные» для текстового потока символы («\0»), на лету переключать кодировки, уметь hex-режим, выделять-копировать текст. А, ну и еще: всё операции должны быть на хоткеях. К текстовому редактору, сам понимаешь, совсем другие требования. Ништяки типа показа картинок тоже хороши, но это уже не основные фичи.

Что-то вроде:

Сложно сказать, насколько это жизненно. Может и взлетит.

Что касается find, то мои требования к фронт-энду таковы:

1. Иметь поля ввода для всех условий, которые умеет find.
2. Заполнять таблицу результатов в реальном времени по мере поступления данных.
3. Отображать индикатор хода поиска. («Searching in /some/path»)
4. Запоминать между перезапусками историю условий: каталоги, маски, даты и т.п.
5. Уметь по дефолту с найденными файлами делать хотя бы два действия: открыть дефолтным приложением и открыть в ФМ каталог с файлом. Плюс возможность добавлять собственные пункты в контекстное меню.
6. Уметь приостановить/продолжить поиск.
7. Переключаться между двумя видами показа результатов: таблица и обычный построчный список в многострочном поле ввода.

Как видишь, ничего сложного, но писать всё это — довольно муторно.

Не более, чем такая же утилита, но вшитая в ФМ. :)

ну вот тут мне видится утилита, которая умеет вызывать утилиты, которые открывают файл в нужном виде