Открыть список
Как стать автором
Обновить

Комментарии 65

НЛО прилетело и опубликовало эту надпись здесь
отвечая на вопрос вынесенный в заголовок «Нужен ли файловый менеджер?» — ответ однозначен — «Нужен»!
Вопрос в том каким он должен быть?
АбАснуй! :)

Все задачи реализуются в ПО, сам по себе файловый менеджер не нужен (я их ярый сторонник под win-системами). Все сферы использования компьютера можно перевести на рельсы «локально библиотеки данных» и локальных программ-сервисов (от вэб-серфинга до разработки ПО). Ключем в такой системе станет новый вид профиля, а именно профиль пользователя + все его данные (книги, медиа, программы).

Так или иначе все мои программы это делают, но только под себя. Заставить их это делать центролизованно (как на макоси сохраняются настройки ПО ~/Library/*) и все — дело в шляпе.
Заставить их это делать центролизованно (как на макоси сохраняются настройки ПО ~/Library/*) и все — дело в шляпе.
К сожалению не в шляпе, а в тюрьме. Тот, кто разрабатывает это централизованное хранилище после этого становится «ответственным за инновации», а всякое «несанкционированное взаимодействие» программ приходится делать через разные хитрые утилиты — и зачастую это получается менее удобно и менее надёжно чем через файлы и файловый менеджер…
ага, я понял. Давай те очертим круг данных, которые могут попадать в эту «библиотеку»: медиа (книги, аудио-данные, виедо-данные, картинки-фотографии), настройки ПО, контакты, календарь, почта, файлы проектов (грубо, но смысл такой: современные IDE содержат парадигму Проект, как именнованный список файлов-исходников и файлы настроек проекта (от 3d-моделированния, до разработки ПО)). Если что-то будет сверх спецефичное, будет особый тип данных как Generic, с форматом хранения в ФС /library/Application_Name/File_Or_Object_Name.

Таким способом можно уберечься от работы с парадигмой файл-фс, как мне видется.
Да все очень просто — по умолчанию все это не гибко… И гибкость эта будет с каждым разом все совершенствоваться и совершенствоваться, заставляя тем самым переходить юзеров на новые версии, изучать новые фичи и проч.
Может не совсем правильный пример, но все же: подошел недавно мужичок знакомый с телефоном Нокиа (не помню каким). Не могу говорит музыку послушать на нем, а как бы типа должен (и протягивает диск с шансоном). Иду, по привычке подключаю через ЮСБ, создаю папку «музыка», закачиваю туда… а плеер то стандартный в операционке может читать только файлы из папки MyMusic… потерял некоторое время, пока до меня дошло…
так это проблема реализации имеющегося софта с говнолокализацией.
А теперь допустим что вся та мызка должна быть в библиотеки, имя которой вам «не известно», но оно занесено в спецификацию ОСи и драйверов.

Веб-сервисы, написанные много лет назад, можно и сейчас использовать.
Мечты, мечты
Всё описанное легко реализовать в любом медиацентре, но невозможно — на PC. Просто посмотрите на ваш пример: Чтобы, скажем, утилита для записи дисков, получив на вход фильм, сравнила его размер с предложенной болванкой, сообщила пользователю, что фильм её займёт не полностью, обратилась к медиа-библиотеке и предложила, чем можно болванку «добить», максимально эффективно используя место. Реализовать это несложно — но только в случае если утилита для записи дисков имеет эту функциональность! А почему только «добивать» до упора? Можно ведь и картинку в тему нарисовать! И таких новых возможностей появляется постоянно десятки и сотни. Нужно либо чтобы программы создавались в едином центре (и все варианты взаимодействия предусматривались), либо чтобы их интерфейс был открыт (как в том же Firefox'е). Но в последнем случае всё равно идеала не будет ибо разнообразные примочки, связывающие между собой программы будут конфликтовать между собой…
Oops. На пустом месте картинки рисуются по другому — но не суть.
Не вижу противоречия. Если утилита для записи дисков умеет не только добивать болванки до упора, но и украшать их картинками, пускай сообщит об этом ОС, станет доступна через ещё одну связь.

Смысл именно в том, чтобы не отправляющая утилита *надеялась*, что принимающая умеет решать поставленную задачу, а принимающая явно сообщала всем вокруг, что она умеет.
local service system. (в аналог веб-сервисам)
Идея на пять!
Не вижу противоречия. Если утилита для записи дисков умеет не только добивать болванки до упора, но и украшать их картинками, пускай сообщит об этом ОС, станет доступна через ещё одну связь.
А если она не умеет? А если это умеет делать другая программа? А если программа для разукрашивания дисков появилась позже чем программа для их записи?

Проблема в том, что подобные «новые связи» появляются постоянно, а программы обновляются нерегулярно (а некоторые — не обновляются вообще).
все правильно! умеющие программы регистрируются в системе, что обладают определнным скоупом умений.
Вызывающая программа ищет другую программу по имеющемуся скоупу.
а чем для передачи файлов, не подойдет передача mapped file дескриптора от одного процесса другому?

вопрос в том, что надо менять программный интерфейс существующих ОС.
Передача файлов — настолько мизерная часть проблемы, что я её даже обсуждать не хочу. Эта задача проблематична на уровне создания расширяемого GUI (с CLI-программами проблем нету, но их, как я понял, автор не любит).
а пока мы с вами спорим, кто-то уже это делает (apple с яфоном, palm с pre). :)

как я понял автора, смысл не в расширяемов GUI, а вы выборе того или иного сервиса из текущей программы, с последующей передачи управления и требуемых данных новому процессу, реализующего выбранный сервис.

OLE/COM/DCOM/activeX — это какбы другой взгляд на одну проблему. Тогда это решили муторно и тяжело для конечного программиста, от сюда и не востребованность технологии на рынке (не смогли полностью реализовать функционал технологий). Сейчас на объем данных закрывают глаза, уходят от собственных форматов данных к XML-based семейству, от сюда появляются уже (!) наработанные принципы работы ПО из сети (веб-сервисы). Вопрос как всегда в том, что такую технологию проще реализовать на новой платформе (и только на ней и будут), так как тот багаж программ и наработка что волочится с давних лет так просто сбросить нельзя. Это рынок. По этому мы почти все и сидим на медленном и не оптимизированном x86 проце, а могли бы давно уйти на RISC-технологии, которые правят в рынке hand-held устройств (arm-процы в кпк, телефонах, коммуникаторах, смартфонах).
Была такая мечта у Microsoft, называлась OLE. Чтобы переиспользовать программы как компоненты, и все такое. OLE выросла и стала COM/DCOM, но всеобщее счастье так и не наступило. Для счастья надо было бы стандартизировать программные интерфейсы, но никто не захотел под «пяту» Microsoft. А в принципе, сейчас большинство программ выставляют наружу свои COM-интерфейсы, так что собрать что-то такое вполне возможно. Правда, как это будет ворочаться — еще большой вопрос.
дык еще не всегда понятно зачем, как задать сценарий работы, остановил фильм сделал скриншот. а дальше что? продолжить смотреть фильм, или этот скриншот отправить по почте, или по асикью, по моему это не облегчит жизнь, а только усложнит… куча лишних меню и диалогов, которые по большому счету нужны только тем, кто реально не умеет работать с компьютером. по моему проще потратить 5 минут и научится, чем тратить кажый раз по лишних 20 минут :)
вы путаете отказ от ФС с отказом от событийного UI.
Окно плеера: идет воспоризведение фильма, нажимаем кнопку снятия скриншота (контейнер для воспроизведения фильмов и картинок — системный, а значит весь его расширяемый функционал известен использующему ПО), фильм ставится на паузу и запускается другое ПО по работе с изображениями, расширенное функционалом по работе со скриншотами. После манипуляций с скриншотом выбираем пункт меню Save, коотрый предлагает:
1. сохранить в локальную библиотеку изображение (снабдив комментариями)
2. отправить картинку аттачем по почте (список зарешестрированных аккаунтов), IM (список аккаунтов), веб (список аккаунтов), FTP (список аккаунтов)

При выборе первого пункта можно спокойно закрыть окно просмоторщика, вернувшись к препдопследнему ПО (видео плеер) и продолжить смотреть фильм

При выборе второго пункта, открывается соовтесвующая программа с выбранным новым сообщением: для почты новое письмо, для IM выбор пользователя или группы кому отправить сообщение, для web среда разработки сайта или готовая страница аплоуда картинки (если это flickr или аналоги), для ftp — браузер ftp-директорий. По их закрытию снова возвращаемся в фильм.

Все выглядит проще, чем сохранить принтскрин, обработав его в редакторе, потом открыть нужную программу, найти в ФС картинку — отправить ее. Появляется мусор в лице не нужного файла (если идти по второй ветке юезр-кейса) и много лишних телодвижений по сохранению и открытию файла.
А куда девались Photohop, WinRar, Nero и прочее? Они ведь тоже могут работать с картинками! Вы либо получаете интерфейс «всего со всем» (тот же файловый менеджер, только менее удобный), либо выбор ограничивается чьим-топ произволом, либо вы получаете конфигурационный файл на миллион строк, который кто-то должен править. В настоящее время в Windows реализованы все эти возможности разом… Не могу сказать что это безумно удобно…
я понял вас, вопорс в регистрации ПО в системе.

Допустим установка ПО заканчивается регистрацией не файловых расщирений, а сообщениями вида:
file — image — edit
file — image — view
file — pack
file — cd burn
и т.д.

Далее при выборе скриншота, мы получаем некий объект, который обладает флагом, что он картинка. По набору таких флагов выбирается набор сервисов, удовлетворяющих этому набору.
Таким образом очерчивается круг программ! которые могут быть запущены из существующей программы, с передачей управления!..

Это уже как бы не классическая архитектура ПО, где у каждой свое адресно пространство и т.д. А некая виртуальная машина с поддержкой событийной модели.

Я сейчас отталкиваюсь не от имеющегося набора ОСей, а от общего применения персонального компьютера, а именно пользовательского интерфейса.

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

есть другое ПО, которое работает с картинками (скажем инет-браузер). Пусть при выборе какой либо картинки, в меню появляется пункт «просмотреть изображение». Как он формирует этот пункт? Опросм имеющихся сервисов и их функционала, выбирая подходящие для объектов типа Картинка, Текст, и т.д.

пользовательский UI сегодня — это набор десятка компнонентов (если опуститься ниже то примитивов еще меньше), но строили красивые и удобные продукты с разной сложностью функционала.
эээ, вы в курсе сколько программ умеют работать с картинкой? причем даже если не брать дубли, у пользователя на компе может стоять
1) какой нить создатель каталогов
2) какой нить быстрый просмоторщик
3) и тройка каких нить редакторов этих картинок

но это не все, еще куча софта умеет работать с картинками за компанию :) 1) аудио плеер для импорта обложек 2) почта 3) браузер 4) всякие офисы

а теперь добавьте к этому добру, то что часто на одном и том же компе стоят дублирующие функционал программы, поставил, попользовался, забыл не удалил, либо пользуешься из за какой нить редкой функции, как все эти программы «автоматически» установленные будут красиво работать с картинкой?
все верно! Только все это большое число программ и регистрируется как соотвествующие обработчики картинок (просмотрщики, редакторы, ...)

А пользователь сам выбирает в списке программу, а не система думает за него. Система только формирует список вызываемых программ, под соответствующие требования (список функционала, которые они должны реализовывать. Это теже данные что ПО заносит в систему при инсталяции в системе) от вызывающей программы.
Уважаемый dShell, я на вас в этом топике просто молюсь.

Пока работа не даёт мне подробно ответить на критику идеи, вы справляетесь лучше, чем смог бы я.
так идея же просто класс, просто надо ее понять, она ни на что не похоже.

самое смешное, что мы все (надеюсь), по крайней мере я, делаю нечто похожее на своих системах. Идея лежит на поверхности. Да она не совместима с прошлым наборорм программ, но она отличается только в точках соприкосновения ПО с «внешним» миром, а значит локализованно в исходном коде и поддается апдэйту.
Да она не совместима с прошлым наборорм программ, но она отличается только в точках соприкосновения ПО с «внешним» миром, а значит локализованно в исходном коде и поддается апдэйту.
Современное ПО на 90% состоит из кода, общающегося с внешним миром. Самодостаточные части (кодеки, SqlLite и т.п.) составляют мизерный процент кода.

Если писать всё с нуля — можно сделать как вы предлагаете. Android предлагает нечто похожее и проблемы, мною описанные, там явственно видны уже сейчас. А телефон — платформа гораздо более ограниченная, чем PC…
пруф-линк про 90% будте добры.

я разработчик ПО, и 90% не пахнет в моих достаточно крупных проектах.

До меня андроид пока еще не дошел. Тем паче они прошивку еще апдейтят.

Но 4 флагмана (аппл, палм, гугл и нокиа) выбрали данный вектор развития своих мобильных ОС. Это о чем либо говорит? Естественно писать с нуля, без накопленного багажа пользвательского ПО просто и легко. Предложенную идею в десктопах можно сделать только под Линуксом (и наконец-то появится что-то отличное от kde-gnome-xfce-etc, а не очередная вариация старого анекдота)
Возмем браузер:
откроем картинку щелкнем по ней правой кнопкой мыши:
1) открыть изображрение
2) копировать изображение
3) копировать ссылку на изображение
4) сохранить изображение как…
5) отправить изборажение
6) сделать фоновым
теперь меню отправить превращается см. ниже
меню открыть изображение превращается, в такой же геморой, и т.д.

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

я повторяю это возможно в закрытых системах, когда все действия так или иначе унифицированы, в открытой системе, с одним и тем же файлом можно(нужно) сделать тысячу действий, и удобнее всего это имхо в файловом менеджере, его можно улучшать, что и происходит… но заменить, ой…
есть такая парадигма в программирвоании MVC (Model-View-Control).
которая подразмуевает назвисимость от V (View, представления). Не важно в чем открывается файл, он попадает туда стандартным путем.

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

с картинкой можно сделать ограниченный набор функционала (вернемся опять к программированию). Картинка — это расширение Объекта.

Объект можно сохранить и переслать. Картинку еще можно редактировать, смотреть, сохранить в галлерею.

Программы релизуют функционал («просмотр картинки», «редактирование картинки», и т.д.).

Браузер фильтрует набор этих программ, перед тем как показать их в динамическом меню пользователю, а фильтрует он исходя из того какого типа объект выбран (в нашем случае — Картинка, а соответсвующий ей цункционал — переслать сохранить, просмотреть, редактировать). И пусть у вас будет сотня просмотрщиков и ни одного редактора — пользователь не обломится, просто у него не будет виден пункт по редактированию, а вот просмотрщиков у него будет богатый выбор.
считайте это Десктоп 2.0 что ли :)
все фишка в том — что все идет централизованно (привет Аппл), без лишних temp-файлов (это ноухау). Это по человечски, а не из теории конечных автоматов (сохраниьт файл, выбрать фыйл, провести манипуляции, сохраниьт файл...)
Картинку еще можно редактировать, смотреть, сохранить в галлерею.
А ещё можно превратить её в иконку. Или в ASCII-ART. А также распечатать. Или вставить в документ (если вы пишите обзор фильма — это же логично?). И сделать с ней ещё десятки (а то и сотни) разных действий.

И пусть у вас будет сотня просмотрщиков и ни одного редактора — пользователь не обломится, просто у него не будет виден пункт по редактированию, а вот просмотрщиков у него будет богатый выбор.
Вот прямо сейчас у меня на компьютере — примерно с полсотни программ, которые могут показать картинку и десятка два — таких, которые могут её отредактировать. И нафига мне этот «богатый выбор»? Это не помощь пользователю, а насилие над ним получается.
и где описываемая выше технология вас ограничила?

а зачем вам ваш же немаленький набор (~100) программ — я не знаю :)

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

Да и у вас очень запущенный случай, у большинства пользователей будет в случае реализации такой концепции вряд ли более одной программе на каждое действие. Все таки основная масса пользователей — лишь пользователи, а не гики/программеры/дизайнеры…
фига, возмем например кнопку «отправить»
вот у меня на компе стоят
1) зе бат которым я не пользуюсь
2) аутлук экспрес которым я не пользуюсь
3) аутлук которым я не пользуюсь
4) гмаил которым я пользуюсь…

1) квип которым пользуюсь не я
2) миранда которой я пользуюсь
3) пси которым я не пользуюсь (но нужен был)
4) квип инфернум, ставил на посмотреть, удалять без мазы :)

а яветь еще не учел другие методы «отправки»

теперь опишите мне пожайлуста меню отправить. и как это автоматически будет настраиваться?

и это только одна кнопка меню ;) «отправить»
уже отвечал на этот вопрос (еще размазанно в других комментах, автоматизма выбора програамы нет, дело не в автоматике, а в отсечении программ, которые не подходят по контексту):
herrmannelig.habrahabr.ru/blog/51578/#comment_1365557
herrmannelig.habrahabr.ru/blog/51578/#comment_1365894
herrmannelig.habrahabr.ru/blog/51578/#comment_1366056

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

очень трудно предсказать, что пользователь будет делать с объектом (это уже не фаил), следовательно по вашей системе ему нужно либо предлагать все возможные варианты, либо ограничивать… и то и другое плохо

а это даже если не касаться таких «мелочей» как: написания программ, и настройка/установка их…
конечно ограничивать функционал нельзя.

Я покажу на вашем примере, как будет выглядеть «правая кнопка» в браузере по картинке, ок?
было:
1) открыть изображрение
2) копировать изображение
3) копировать ссылку на изображение
4) сохранить изображение как…
5) отправить изборажение
6) сделать фоновым

стало:
1) открыть изображрение (просмотр его в выбираемом просмотрщике)
2) копировать изображение (копируется ссылка на объект Картинка, который хранится в ~/Library/Applications/Opera/Cache/ к примеру, дальнейшая работа будет вестись с этим е изменемым объектом, для его редактирования будет создаваться новый объект Картинка с поддержкой редактирования)
3) копировать ссылку на изображение
4) сохранить изображение в библиотеке (сохранить, добавив теги)
5) отправить изборажение (выбор IMов, e-mail аккаунтов и т.д.)
— 6) сделать фоновым (доступно из пункта 1) в просмоторщике)
Собственно проблема в том, что OLE/COM/DCOM не решает проблему, а усугубляет: вместо простого понятия файл мы получаем сложное понятие «объект» — и дальше выясняется что согласовать желания и потребности разных программ отнюдь непросто и в результате потребность в программистах не сократилась, а выросла…
Не люблю, когда прога за меня думает что делать. Как правило они угадывают совсем простые действия, а при действиях чуть более сложных пользователю придется делать телодвижений больше, чем если бы прога не пыталась угадывать мысли.

Например, взять тот же ворд с его автозаменой (будь она неладна). После точки он всегда начинает слово с большой буквы. Иногда пользователю это действительно нужно. Но стоит в середине предложения написать сокращение с точкой, как следующее слово будет начинаться с большой буквы. В итоге пользователь вынужден отменять ненужные действия, которые за него сделал ворд. Именно поэтому, например, послу установки ворда я в первую очередь вырубаю его автозамену.

Или давайте возьмем похожий на Ваш пример, но не с фильмами, а с музыкой. Вот, например, у меня музыка лежит в двух папках — «записанное» и «не записанное». В данном случае мне надо, чтобы прога брала музыку для заполнения болванки из «не записанного», а откуда она это должна узнавать? А если у меня три папки: «записанное», «не записанное», «записать, но потом» тогда прога должна брать музыку из «не записанное», а если там пусто, то «записать, но потом». И таких вариантов может быть полно, в итоге получится, что прога хочет сделать одно, а я другое.
По последнему абзацу согласен — сделать такое можно, но это будет или прога для одного человека, или людей придётся учить как жить по этому алгоритму. Нет, всё-таки это будет прога одного человека.
Вовсе нет. Если использовать профили, к которым будут привязываться данные каждого пользователя, то все будет работать отлично. Главное, не забывать переключаться на своего пользователя, когда работаете с системой…
Была такая идея в Microsoft, уже несколько раз в голову приходила Биллу. Объектно-реляционное хранилище данных. Сначала OFS, затем Storage+, затем RFS, затем WinFS называлось это чудо (ссылка на перевод статьи Поля Тюрро на TheVista.ru).

И идея была в том, чтобы все-все-все данные были не файлами, а некими абстрактными Items, которые и не файлы вовсе, а так, записи в большой-большой базе данных.

Любое приложение могло бы с этими записями работать, добавлять строгие определения новых типов Items, отношения между записями создавать/сохранять. Форматы данных были бы открытыми (прямо как ODF/OOXML) и работа пользователя с его данными сводилась бы к работе с типами данных — музыка, картинки, видео и т.д., поиск — выполнялся бы SQL-запрос по базе, легко было бы посмотреть «related items» и было бы пользователю счастье.

Да только где теперь эта WinFS?

Впрочем, если вдруг стало интересно узнать про эту идею, можете вот сию статью почитать на TheVista.ru

К сожалению, сделать продукт не получилось. И не потому, что технически сложно, а потому что нет у производителей ПО сейчас желания открыть друг другу все свои форматы, это раз. И нет возможности открыть все эти форматы, два. Либо производители уже закрыли лавочку, либо исходники потеряли.

А без открытия форматов данных так легко все эти действия в Windows сделать становится сложнее. Нужно уже как-то по другому подходить к делу. В Mac OS X вот есть, понимаете ли, Apple Script. Очень хороший, надо сказать, способ автоматизировать какие-либо действия — диск там записать или принтер по умолчанию для домашней сети установить, вот. В Windows есть PowerShell, правда. Но все это как-то не то, понимаете? Ведь большинство Windows-приложений не дают свой функционал вызывать через командную строку. Типа, а зачем, когда все равно юзер мышкой тыкать будет. Есть, правда, в Windows Vista такая штука как UI Automation, — это когда можно специальной тулой записать последовательность кликов-действий с разными приложениями, да затем эти последовательности исполнить. Кстати, это в Win3.x называлось Macrorecorder.

Вот это, кстати, вариант. Можно сделать скрипты и затем юзеру дать возможность кликнуть «выполнить сей скрипт» или «тот».

Только вот теперь возникает вопрос — а поймет ли юзер, что такое скрипты? И стоит ли овчинка выделки?

Если же нет, то надо, получается, парадигму ОС менять. А вот как, пока не ясно.

Есть одна идея, впрочем.
Сделать OS знающей о текущих делах пользователя, об условиях, в которых он находится, так сказать. Типа, контекст. Если посмотреть в определение по ISO, контекст — это «пользователь, его цели и задачи, инфраструктура (софт, оборудование, материалы), физическая среда и социальный контекст, в которых используется программный продукт». Перевод немного вольный. Взято определение из определения ISO по «эргономике».

И вот если ОС в любой момент времени знает, что делает пользователь, то ОС может уже и «сообразить», а как бы можно было помочь пользователю в этот самый момент времени.

И вот тут уже возникает боооольшущий простор для воображения. Ведь тут легко можно и скрипты написать «заранее», для наиболее частых случаев, и оболочку для каждого скрипта подписать, чтобы пользователю оставалось только кнопку «Ок» нажимать да радоваться.

Как вам такая идея, друзья?
именно, отсечение программ-сервисов по контексту текущей работы пользователя.
а выбор того или иного сервиса (или скрипта как у вас) оставить пользователю.
ага, о том и речь. Пользователь может себе спокойно выбирать, какие сервисы ему для этого нужны, прямо как в прототипе Mozilla Aurora. Кстати, оч. интересная идея, в контексте этого топика, мне кажется, самое оно.
спасибо, надо будет почитать как-нибудь!
> скачивает фильм, передаёт его медиа-библиотеке, та всё должным образом индексирует, даёт знать пользователю «Ваш фильм скачался!»

Медиа-библиотека должна быть интегрирована в файловую систему, самого понятия «медиа-библиотека» не должно существовать. Есть «видеозаписи», «аудиозаписи», «изображения», которые каталогизируются согласно метаинформации. По той же причине не нужны папки.

> Стандартные модули ввода-вывода, предоставляемые операционной системой — для того, чтобы одна маленькая утилитка (полезная, но куцая) не могла разорвать длинный конвейер работы над файлом. Программа должна уметь принимать файлы не только через меню «Открыть» или drag-n-drop, но и напрямую от другой программы, причём этот механизм её автор не должен придумывать самостоятельно с ноля. Ни одна программа не должна становиться тупиком, из которого пользователь за своим файлом может только отступить в файловый менеджер.

В никсах это давно реализовано.

> Открытые форматы файлов, понятные всем программам, участвующим в файлообороте — иначе его просто не получится реализовать.

Реализуемость сомнительна.

Ну а вообще, идеальная ФС это та, о существовании которой не подозреваешь. Единственная случай, когда человеку нужно знать о существовании такой сущности, как «файл» — работа с исходниками, в остальных случаях — это «документ», «фильм» и т. д.
В том, то и дело, что в данном случае надо отказаться от файловой системы в стандартном ее понимании. Все должно стать объектами с набором свойств.
Кстати, в Windows 7 так и сделали. На основе Windows Search сделали такую вещь, как «Libraries», — те самые библиотеки. Библиотека — это супермножество данных, построенное путем слияния подмножеств данных, где такие подмножества в Windows представлены в виде папок с файлами.

Т.е., говоря по простому, пусть у меня есть папка «Рисунки», которую я бережно храню и преумножаю на протяжении нескольких последних лет. Там накопились в основном семейные фотографии, забавные рисунки, найденные в вебе, фотки друзей, скриншоты программ, обои для рабочего стола и т.д. И есть у меня папка для Development, в которой есть подпапка Resources, в которой есть папка «Windows Longhorn», где у меня хранятся картинки, используемые для разработки.



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

В Windows 7 я просто взял стандартную библиотеку «Pictures» и подключил к ней обе эти папки, по умолчанию сохранение сделал в первую папку, и когда мне нужно в процессе разработки того или иного приложения достать картинки, я просто иду в окне «Open File» в библиотеку «Pictures», выбираю нужную папку и в ней нахожу файл. А если я еще и помню хотя бы какое-то слово или пару-тройку букв из названия картинки, то я просто в этом же диалоговом окне делаю поиск по всему содержимому библиотеки, и быстро нахожу искомое. Очень удобно, ктати.

Что, кстати, интересно, в этой библиотеке есть такая штука, Top Views называется.



Позволяет задать то, как будут показаны (визуализированы) данные в этой библиотеке. Например, можно показать фотки, сгруппированные по дате, когда их сделали:



Или, к примеру, по тегам:



собственно, можно и поиск по библиотеке делать:



Не то чтобы идеал, конечно, но, по-моему, хороший шаг в нужную сторону.

И, кстати, в Windows 7 Windows Media Player и Windows Media Center теперь пользуются этой библиотекой, а не ведут собственные. Прямо что доктор прописал.

Я эту фичу сразу после выхода Windows 7 оч.просил :) в Windows Early Feedback Program участвовал, чтобы сделала ее MS. И вот, как видите, сделали :)))))

Что скажете? :)
Именно так. Однако, для, например, видеозаписей есть сложности: на уровне формата метаданные поддерживает мало форматов (я знаю только wmv). Из-за этого надо придумывать костыли в виде хранения метаданных в отдельном файле и пихать все видео в обертку с метаданными.

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

В линуксе ситуация другия: обычному пользователю вылазить за пределы домашнего каталога практически не надо, и именно в линуксе, ИМХО, данная концепция может быть реализована в полной мере. Плюс, в линуксе нет проблем с открытостью форматов файлов.

Папки, опять же, нужны только пока пользователь имеет доступ к системным файлам.
Хм. Не могу согласиться с тем, что в Windows нельзя скрывать системные файлы: по умолчанию все системные файлы скрыты.



Для примера, описание папки (ее иконка и т.д.) хранится в файле Desktop.ini. Этот файл есть в каждой папке пользователя и везде, где вы эту иконку, к примеру, выберите для отображения папки. На скриншоте ниже показан «скрытый» системный файл. До этого файл был не виден.



По части открытости форматов файлов в Linux — в большинстве своем в Linux и в Windows, да и в Mac OS X используются одни и те же файлы — видео, рисунки, даже документы (Word, ODF, docx и т.д.). Это в любом случае нужно, иначе придется постоянно конвертировать из закрытого формата в открытый и обратно пользователям, которые работают в разных ОС. Так что Linux — не гарантия открытости форматов файлов :)

Если вспомнить недавний топик про «цели», то станет ясно, что цель всех этих форматов файлов — это все-таки донести контент до пользователя. :) А открытость — это лишь один из способов ее достичь.
> Хм. Не могу согласиться с тем, что в Windows нельзя скрывать системные файлы: по умолчанию все системные файлы скрыты.

Я имел ввиду, что ничто не мешает открыть диск C: и залезть в папку Windows. К тому же, лазить по дискам приходиться регулярно, поскольку, как я говорил выше, сидеть в административной учетке в Windows считается нормальным: диск со временем превращается в помойку.

> По части открытости форматов файлов в Linux — в большинстве своем в Linux и в Windows, да и в Mac OS X используются одни и те же файлы — видео, рисунки, даже документы (Word, ODF, docx и т.д.).

Закрытых форматов — до фига и больше. Навскидку — форматы Photoshop и Corel.

> Это в любом случае нужно, иначе придется постоянно конвертировать из закрытого формата в открытый и обратно пользователям, которые работают в разных ОС. Так что Linux — не гарантия открытости форматов файлов :)

Закрытые форматы файлов не нужны. Пусть сам софт проприетарный, но формат файла должен быть открытым.
ну, в Linux тоже ничего, кроме необходимости ввода пароля рута, не мешает зайти в /bin/ или еще куда. :) в Windows для этого UAC сделали, и если ты не админ, то любые действия, требующие админских прав, приведут к тому же эффекту, что и в Linux, — окошку с требованием ввести логин и пароль администратора компа. Конечно, то, что UAC сделали поздно (не с момента Windows 1.0), это упущение, с другой стороны. учить людей к таким ограничениям в начале возникновения рынка — не уверен, что было бы особо разумно. Но спорить тут не буду. UAC сделан не идеально, к сожалению :(

«Закрытые форматы файлов не нужны» и «формат файла должен быть открытым» — ну, никто никому ничего не должен, извините. Есть business need, будет формат открытым (как тот же PDF стал таковым), нету — не будет. Ибо когда ты автор программы, то если закон не запрещает создавать проприетарный формат, это ты решаешь, какой формат делать — открытый или нет. Я не говорю, что автор прав, если выбирает проприетарный, просто одного высказывания недостаточно. Люди разные и никто не станет делать все как один. Каждый выбирает для себя. Мне вот удобно делать в XML-формате файлы, и я счастлив, делаю. А кому-то другому нужно хоть ты тресни в бинарном формате работать. И как ты без специальной библиотеки API сделаешь формат открытым? :)

Т.е. идея благая, прямо как в WinFS. Лет эдак 5 назад сам аж фанател от этого — XML — наше все и все такое прочее. Просто если на реальный мир посмотреть, он не идеален. Многое будет меняться к лучшему, но изменить всех и вся полностью никогда не получится. :) «Всех не пересажаешь» (с) Кто-то.
> ну, в Linux тоже ничего, кроме необходимости ввода пароля рута, не мешает зайти в /bin/ или еще куда. :) в Windows для этого UAC сделали, и если ты не админ, то любые действия, требующие админских прав, приведут к тому же эффекту, что и в Linux, — окошку с требованием ввести логин и пароль администратора компа.

Это практически никогда не нужно. В винде же необходимость возникает регулярно, в итоге я отрубил UAC и дал себе админские права.

> «Закрытые форматы файлов не нужны» и «формат файла должен быть открытым» — ну, никто никому ничего не должен, извините. Есть business need, будет формат открытым (как тот же PDF стал таковым), нету — не будет. Ибо когда ты автор программы, то если закон не запрещает создавать проприетарный формат, это ты решаешь, какой формат делать — открытый или нет. Я не говорю, что автор прав, если выбирает проприетарный, просто одного высказывания недостаточно. Люди разные и никто не станет делать все как один. Каждый выбирает для себя.

Делать формат закрытым не нужно: если он популярный — то его зареверсят, если нет — то он нафиг никому не нужен.

> Мне вот удобно делать в XML-формате файлы, и я счастлив, делаю. А кому-то другому нужно хоть ты тресни в бинарном формате работать.

Совершенно не важно, написать парсер — задачка для первокурсника на неделю работы по вечерам с пивом.

> И как ты без специальной библиотеки API сделаешь формат открытым? :)

Опубликовать спецификацию.

> Лет эдак 5 назад сам аж фанател от этого — XML — наше все и все такое прочее.

XML кажется удобным ровно до тех пор, пока не выучишь LISP, потом он начинает бесить своей многословностью, а ты начинаешь вместо него использовать лисповские списки.
> Это практически никогда не нужно. В винде же необходимость возникает регулярно, в итоге я отрубил UAC и дал себе админские права.

Ну, в Винде эта фича появилась сравнительно недавно (3 года), весь УЖЕ существующий софт не перепишешь. С тем, что в Linux это технически сделано лучше, даже спорить не буду, — факт. :) Еще лет 8 назад помню, как игрался с Mandrake 7.2 и помню работу то в Root, то под обычным юзером. Сначала по привычке стал сидеть под Root'ом, а потом понял истину :)

> Опубликовать спецификацию.

Собственно, если оунер формата файла не хочет публиковать, то заставить его это сделать не так и просто. Т.е. мне нравится подход, что все можно сделать, но в реальности мы не идеальны :) Т.е. я не верю, что все можно сделать хорошо. Еще в скандинавских сказаниях была история, как сын одной из богинь Асгарда был смертельно ранен, и все боги пришли к дочери Одина, царице смерти, за жизнью для него, настолько он был прекрасен, молод и совсем не успел порадовать мир и порадоваться ему. Царица смерти предложила такое решение — если во всем мире не найдется человека, смерть сына богини которому безразлична, она отпустит его обратно в Асгард. Боги обошли почти весь мир, но «проказник» Локи, сын Одина, бог Огня, возненавидел этого сына богини за то, что его любили больше, чем Локи, и принял образ великанши, жившей на далеком берегу Миддлгарда («Земля»). Боги во главе с Одином пришли к ней и увидели ее смеющейся. Так во всем мире нашелся один человек, смерть сына богини которому была безразлична, и царица смерти забрала сына богини.

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

О чем это я? Да о том, что не верится мне, что можно всех убедить быть хорошими :( Всегда найдется свой Локи.

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

Эх, мечты.

Ладно, не хочется о грустном. По поводу XML — согласен, не панацея. :) Но неплохой шаг к интероперабельности форматов, кстати.
Кстати, эта идея очень хорошо коррелирует с идеей PhantomOS, о которой недавно был топик. Там очень много интересных идей было высказанно в комментариях. В ней как раз концепция «Все — объект» и архитектор как раз отказывается от файловой системы как таковой.
Все новое — хорошо забытое старое. Какие там объекты, какое там OLE? Зачем нагромождать. Я вот что тут придумал: пусть все сущности будут представлены файлами. И пусть будут программы эти файлы обрабатывающие. Пусть такие программы умеют куда-то писать то что у нее на выходе, а другие читать не только от пользователя, но и из файла. Назовука я это дело перенаправлением ввода/ввывода. А что если сделать так, что бы выход одной программы становился входом для другой. Давайте назовем это, ну, допустим, каналом (pipe). А ведь здорово я придумал, да? Или вроде это уже было все…
НЛО прилетело и опубликовало эту надпись здесь
>Один из возможных сценариев: торрент-клиент (или клиент мультимедийного интернет-магазина) скачивает фильм, передаёт его медиа-библиотеке, та всё должным образом индексирует, даёт знать пользователю «Ваш фильм скачался!». Пользователь говорит, что хочет фильм посмотреть, библиотека передаёт файл проигрывателю.

Боян; use miro luke.
Потеряли файл? Пытаетесь открыть его через меню «Последние документы» программы, а она говорит «Файл не найден»? Так это потому, что вы файл переименовали или переместили, пока программа была закрыта. Идите теперь в файловую систему, ищите его.
А почему бы файловой системе (ведь у неё все ходы записаны) при запуске программы не отчитаться: «Товарищ программа! За время вашего отсутствия следующие вверенные вам файлы были перемещены и переименованы…; их новое расположение…»?


А в макосе, вообще-то, так и происходит.

Создаете в программе файл, закрываете программу, перемещаете его в другую папку, переименовываете, открываете программу и в списке последних файлов ваш файл но уже с новым именем, и открывается уже из папки в которую вы его переместили.

То же самое работает при открытом файле. Его можно переименовать и переместить, а программа просто при сохранении предупреждает, что у файла имя поменялось.
Как я понимаю, все действия, которые можно выполнить с файлом с помощью зарегистрированных программ, есть в контекстном меню. Единственное, чего не достает, чтобы реализовать то, что описано в топике — это показывать это меню во всех программах, которые работают с файлами, а не только в проводнике. Во многих есть меню Файл->Свойства файла; туда же нужно добавить контекстное меню со всеми действиям: Редактировать, Открыть с помощью... и.д. Правда остаются некоторые проблемы с блокировкой файлов и наверное какие-то ещё, но, минимально, такой вариант решает задачу, и не требует переписывать ОС с нуля.
(рюшечки и свистелки можно добавить по вкусу :) )
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.