я разработчик ПО, и 90% не пахнет в моих достаточно крупных проектах.
До меня андроид пока еще не дошел. Тем паче они прошивку еще апдейтят.
Но 4 флагмана (аппл, палм, гугл и нокиа) выбрали данный вектор развития своих мобильных ОС. Это о чем либо говорит? Естественно писать с нуля, без накопленного багажа пользвательского ПО просто и легко. Предложенную идею в десктопах можно сделать только под Линуксом (и наконец-то появится что-то отличное от kde-gnome-xfce-etc, а не очередная вариация старого анекдота)
Я покажу на вашем примере, как будет выглядеть «правая кнопка» в браузере по картинке, ок?
было:
1) открыть изображрение
2) копировать изображение
3) копировать ссылку на изображение
4) сохранить изображение как…
5) отправить изборажение
6) сделать фоновым
стало:
1) открыть изображрение (просмотр его в выбираемом просмотрщике)
2) копировать изображение (копируется ссылка на объект Картинка, который хранится в ~/Library/Applications/Opera/Cache/ к примеру, дальнейшая работа будет вестись с этим е изменемым объектом, для его редактирования будет создаваться новый объект Картинка с поддержкой редактирования)
3) копировать ссылку на изображение
4) сохранить изображение в библиотеке (сохранить, добавив теги)
5) отправить изборажение (выбор IMов, e-mail аккаунтов и т.д.)
— 6) сделать фоновым (доступно из пункта 1) в просмоторщике)
именно, отсечение программ-сервисов по контексту текущей работы пользователя.
а выбор того или иного сервиса (или скрипта как у вас) оставить пользователю.
п.с.: набижали минусяторы, а я их боюсь, так как моя писька еще маленькая (один голос и я не смогу голосовать, еще один и я буду писать раз в 5 минут), если останутся вопросы, отвечу по личке.
все фишка в том — что все идет централизованно (привет Аппл), без лишних temp-файлов (это ноухау). Это по человечски, а не из теории конечных автоматов (сохраниьт файл, выбрать фыйл, провести манипуляции, сохраниьт файл...)
есть такая парадигма в программирвоании MVC (Model-View-Control).
которая подразмуевает назвисимость от V (View, представления). Не важно в чем открывается файл, он попадает туда стандартным путем.
а вы сейчас предлагаете все смешать в одну кучу, как это есть сейчас.
с картинкой можно сделать ограниченный набор функционала (вернемся опять к программированию). Картинка — это расширение Объекта.
Объект можно сохранить и переслать. Картинку еще можно редактировать, смотреть, сохранить в галлерею.
Программы релизуют функционал («просмотр картинки», «редактирование картинки», и т.д.).
Браузер фильтрует набор этих программ, перед тем как показать их в динамическом меню пользователю, а фильтрует он исходя из того какого типа объект выбран (в нашем случае — Картинка, а соответсвующий ей цункционал — переслать сохранить, просмотреть, редактировать). И пусть у вас будет сотня просмотрщиков и ни одного редактора — пользователь не обломится, просто у него не будет виден пункт по редактированию, а вот просмотрщиков у него будет богатый выбор.
считайте это Десктоп 2.0 что ли :)
так идея же просто класс, просто надо ее понять, она ни на что не похоже.
самое смешное, что мы все (надеюсь), по крайней мере я, делаю нечто похожее на своих системах. Идея лежит на поверхности. Да она не совместима с прошлым наборорм программ, но она отличается только в точках соприкосновения ПО с «внешним» миром, а значит локализованно в исходном коде и поддается апдэйту.
так это проблема реализации имеющегося софта с говнолокализацией.
А теперь допустим что вся та мызка должна быть в библиотеки, имя которой вам «не известно», но оно занесено в спецификацию ОСи и драйверов.
Веб-сервисы, написанные много лет назад, можно и сейчас использовать.
все верно! Только все это большое число программ и регистрируется как соотвествующие обработчики картинок (просмотрщики, редакторы, ...)
А пользователь сам выбирает в списке программу, а не система думает за него. Система только формирует список вызываемых программ, под соответствующие требования (список функционала, которые они должны реализовывать. Это теже данные что ПО заносит в систему при инсталяции в системе) от вызывающей программы.
я теперь вас не понимаю :)
есть ПО, которое может смотреть картинки (допустим)
оно при интсталяции регистриуется соответсвующим образом (автоматически, на всякий случай уточню).
есть другое ПО, которое работает с картинками (скажем инет-браузер). Пусть при выборе какой либо картинки, в меню появляется пункт «просмотреть изображение». Как он формирует этот пункт? Опросм имеющихся сервисов и их функционала, выбирая подходящие для объектов типа Картинка, Текст, и т.д.
пользовательский UI сегодня — это набор десятка компнонентов (если опуститься ниже то примитивов еще меньше), но строили красивые и удобные продукты с разной сложностью функционала.
все правильно! умеющие программы регистрируются в системе, что обладают определнным скоупом умений.
Вызывающая программа ищет другую программу по имеющемуся скоупу.
Допустим установка ПО заканчивается регистрацией не файловых расщирений, а сообщениями вида:
file — image — edit
file — image — view
file — pack
file — cd burn
и т.д.
Далее при выборе скриншота, мы получаем некий объект, который обладает флагом, что он картинка. По набору таких флагов выбирается набор сервисов, удовлетворяющих этому набору.
Таким образом очерчивается круг программ! которые могут быть запущены из существующей программы, с передачей управления!..
Это уже как бы не классическая архитектура ПО, где у каждой свое адресно пространство и т.д. А некая виртуальная машина с поддержкой событийной модели.
Я сейчас отталкиваюсь не от имеющегося набора ОСей, а от общего применения персонального компьютера, а именно пользовательского интерфейса.
п.с.: в винде конфигурационный файл, он же реестр, достигает размеров в 10 мб на рабочей машине.
ага, я понял. Давай те очертим круг данных, которые могут попадать в эту «библиотеку»: медиа (книги, аудио-данные, виедо-данные, картинки-фотографии), настройки ПО, контакты, календарь, почта, файлы проектов (грубо, но смысл такой: современные IDE содержат парадигму Проект, как именнованный список файлов-исходников и файлы настроек проекта (от 3d-моделированния, до разработки ПО)). Если что-то будет сверх спецефичное, будет особый тип данных как Generic, с форматом хранения в ФС /library/Application_Name/File_Or_Object_Name.
Таким способом можно уберечься от работы с парадигмой файл-фс, как мне видется.
а пока мы с вами спорим, кто-то уже это делает (apple с яфоном, palm с pre). :)
как я понял автора, смысл не в расширяемов GUI, а вы выборе того или иного сервиса из текущей программы, с последующей передачи управления и требуемых данных новому процессу, реализующего выбранный сервис.
OLE/COM/DCOM/activeX — это какбы другой взгляд на одну проблему. Тогда это решили муторно и тяжело для конечного программиста, от сюда и не востребованность технологии на рынке (не смогли полностью реализовать функционал технологий). Сейчас на объем данных закрывают глаза, уходят от собственных форматов данных к XML-based семейству, от сюда появляются уже (!) наработанные принципы работы ПО из сети (веб-сервисы). Вопрос как всегда в том, что такую технологию проще реализовать на новой платформе (и только на ней и будут), так как тот багаж программ и наработка что волочится с давних лет так просто сбросить нельзя. Это рынок. По этому мы почти все и сидим на медленном и не оптимизированном x86 проце, а могли бы давно уйти на RISC-технологии, которые правят в рынке hand-held устройств (arm-процы в кпк, телефонах, коммуникаторах, смартфонах).
вы путаете отказ от ФС с отказом от событийного UI.
Окно плеера: идет воспоризведение фильма, нажимаем кнопку снятия скриншота (контейнер для воспроизведения фильмов и картинок — системный, а значит весь его расширяемый функционал известен использующему ПО), фильм ставится на паузу и запускается другое ПО по работе с изображениями, расширенное функционалом по работе со скриншотами. После манипуляций с скриншотом выбираем пункт меню Save, коотрый предлагает:
1. сохранить в локальную библиотеку изображение (снабдив комментариями)
2. отправить картинку аттачем по почте (список зарешестрированных аккаунтов), IM (список аккаунтов), веб (список аккаунтов), FTP (список аккаунтов)
При выборе первого пункта можно спокойно закрыть окно просмоторщика, вернувшись к препдопследнему ПО (видео плеер) и продолжить смотреть фильм
При выборе второго пункта, открывается соовтесвующая программа с выбранным новым сообщением: для почты новое письмо, для IM выбор пользователя или группы кому отправить сообщение, для web среда разработки сайта или готовая страница аплоуда картинки (если это flickr или аналоги), для ftp — браузер ftp-директорий. По их закрытию снова возвращаемся в фильм.
Все выглядит проще, чем сохранить принтскрин, обработав его в редакторе, потом открыть нужную программу, найти в ФС картинку — отправить ее. Появляется мусор в лице не нужного файла (если идти по второй ветке юезр-кейса) и много лишних телодвижений по сохранению и открытию файла.
п.с.: дико не удобно сделана скачка либ и доков.
я разработчик ПО, и 90% не пахнет в моих достаточно крупных проектах.
До меня андроид пока еще не дошел. Тем паче они прошивку еще апдейтят.
Но 4 флагмана (аппл, палм, гугл и нокиа) выбрали данный вектор развития своих мобильных ОС. Это о чем либо говорит? Естественно писать с нуля, без накопленного багажа пользвательского ПО просто и легко. Предложенную идею в десктопах можно сделать только под Линуксом (и наконец-то появится что-то отличное от kde-gnome-xfce-etc, а не очередная вариация старого анекдота)
а зачем вам ваш же немаленький набор (~100) программ — я не знаю :)
описываемая технология не огрничивает вас ни в выбираем инструменте и ни в возможных манипуляциях над той же картинкой.
Я покажу на вашем примере, как будет выглядеть «правая кнопка» в браузере по картинке, ок?
было:
1) открыть изображрение
2) копировать изображение
3) копировать ссылку на изображение
4) сохранить изображение как…
5) отправить изборажение
6) сделать фоновым
стало:
1) открыть изображрение (просмотр его в выбираемом просмотрщике)
2) копировать изображение (копируется ссылка на объект Картинка, который хранится в ~/Library/Applications/Opera/Cache/ к примеру, дальнейшая работа будет вестись с этим е изменемым объектом, для его редактирования будет создаваться новый объект Картинка с поддержкой редактирования)
3) копировать ссылку на изображение
4) сохранить изображение в библиотеке (сохранить, добавив теги)
5) отправить изборажение (выбор IMов, e-mail аккаунтов и т.д.)
— 6) сделать фоновым (доступно из пункта 1) в просмоторщике)
а выбор того или иного сервиса (или скрипта как у вас) оставить пользователю.
herrmannelig.habrahabr.ru/blog/51578/#comment_1365557
herrmannelig.habrahabr.ru/blog/51578/#comment_1365894
herrmannelig.habrahabr.ru/blog/51578/#comment_1366056
п.с.: набижали минусяторы, а я их боюсь, так как моя писька еще маленькая (один голос и я не смогу голосовать, еще один и я буду писать раз в 5 минут), если останутся вопросы, отвечу по личке.
которая подразмуевает назвисимость от V (View, представления). Не важно в чем открывается файл, он попадает туда стандартным путем.
а вы сейчас предлагаете все смешать в одну кучу, как это есть сейчас.
с картинкой можно сделать ограниченный набор функционала (вернемся опять к программированию). Картинка — это расширение Объекта.
Объект можно сохранить и переслать. Картинку еще можно редактировать, смотреть, сохранить в галлерею.
Программы релизуют функционал («просмотр картинки», «редактирование картинки», и т.д.).
Браузер фильтрует набор этих программ, перед тем как показать их в динамическом меню пользователю, а фильтрует он исходя из того какого типа объект выбран (в нашем случае — Картинка, а соответсвующий ей цункционал — переслать сохранить, просмотреть, редактировать). И пусть у вас будет сотня просмотрщиков и ни одного редактора — пользователь не обломится, просто у него не будет виден пункт по редактированию, а вот просмотрщиков у него будет богатый выбор.
считайте это Десктоп 2.0 что ли :)
самое смешное, что мы все (надеюсь), по крайней мере я, делаю нечто похожее на своих системах. Идея лежит на поверхности. Да она не совместима с прошлым наборорм программ, но она отличается только в точках соприкосновения ПО с «внешним» миром, а значит локализованно в исходном коде и поддается апдэйту.
А теперь допустим что вся та мызка должна быть в библиотеки, имя которой вам «не известно», но оно занесено в спецификацию ОСи и драйверов.
Веб-сервисы, написанные много лет назад, можно и сейчас использовать.
А пользователь сам выбирает в списке программу, а не система думает за него. Система только формирует список вызываемых программ, под соответствующие требования (список функционала, которые они должны реализовывать. Это теже данные что ПО заносит в систему при инсталяции в системе) от вызывающей программы.
есть ПО, которое может смотреть картинки (допустим)
оно при интсталяции регистриуется соответсвующим образом (автоматически, на всякий случай уточню).
есть другое ПО, которое работает с картинками (скажем инет-браузер). Пусть при выборе какой либо картинки, в меню появляется пункт «просмотреть изображение». Как он формирует этот пункт? Опросм имеющихся сервисов и их функционала, выбирая подходящие для объектов типа Картинка, Текст, и т.д.
пользовательский UI сегодня — это набор десятка компнонентов (если опуститься ниже то примитивов еще меньше), но строили красивые и удобные продукты с разной сложностью функционала.
Вызывающая программа ищет другую программу по имеющемуся скоупу.
Допустим установка ПО заканчивается регистрацией не файловых расщирений, а сообщениями вида:
file — image — edit
file — image — view
file — pack
file — cd burn
и т.д.
Далее при выборе скриншота, мы получаем некий объект, который обладает флагом, что он картинка. По набору таких флагов выбирается набор сервисов, удовлетворяющих этому набору.
Таким образом очерчивается круг программ! которые могут быть запущены из существующей программы, с передачей управления!..
Это уже как бы не классическая архитектура ПО, где у каждой свое адресно пространство и т.д. А некая виртуальная машина с поддержкой событийной модели.
Я сейчас отталкиваюсь не от имеющегося набора ОСей, а от общего применения персонального компьютера, а именно пользовательского интерфейса.
п.с.: в винде конфигурационный файл, он же реестр, достигает размеров в 10 мб на рабочей машине.
Таким способом можно уберечься от работы с парадигмой файл-фс, как мне видется.
как я понял автора, смысл не в расширяемов GUI, а вы выборе того или иного сервиса из текущей программы, с последующей передачи управления и требуемых данных новому процессу, реализующего выбранный сервис.
OLE/COM/DCOM/activeX — это какбы другой взгляд на одну проблему. Тогда это решили муторно и тяжело для конечного программиста, от сюда и не востребованность технологии на рынке (не смогли полностью реализовать функционал технологий). Сейчас на объем данных закрывают глаза, уходят от собственных форматов данных к XML-based семейству, от сюда появляются уже (!) наработанные принципы работы ПО из сети (веб-сервисы). Вопрос как всегда в том, что такую технологию проще реализовать на новой платформе (и только на ней и будут), так как тот багаж программ и наработка что волочится с давних лет так просто сбросить нельзя. Это рынок. По этому мы почти все и сидим на медленном и не оптимизированном x86 проце, а могли бы давно уйти на RISC-технологии, которые правят в рынке hand-held устройств (arm-процы в кпк, телефонах, коммуникаторах, смартфонах).
Окно плеера: идет воспоризведение фильма, нажимаем кнопку снятия скриншота (контейнер для воспроизведения фильмов и картинок — системный, а значит весь его расширяемый функционал известен использующему ПО), фильм ставится на паузу и запускается другое ПО по работе с изображениями, расширенное функционалом по работе со скриншотами. После манипуляций с скриншотом выбираем пункт меню Save, коотрый предлагает:
1. сохранить в локальную библиотеку изображение (снабдив комментариями)
2. отправить картинку аттачем по почте (список зарешестрированных аккаунтов), IM (список аккаунтов), веб (список аккаунтов), FTP (список аккаунтов)
При выборе первого пункта можно спокойно закрыть окно просмоторщика, вернувшись к препдопследнему ПО (видео плеер) и продолжить смотреть фильм
При выборе второго пункта, открывается соовтесвующая программа с выбранным новым сообщением: для почты новое письмо, для IM выбор пользователя или группы кому отправить сообщение, для web среда разработки сайта или готовая страница аплоуда картинки (если это flickr или аналоги), для ftp — браузер ftp-директорий. По их закрытию снова возвращаемся в фильм.
Все выглядит проще, чем сохранить принтскрин, обработав его в редакторе, потом открыть нужную программу, найти в ФС картинку — отправить ее. Появляется мусор в лице не нужного файла (если идти по второй ветке юезр-кейса) и много лишних телодвижений по сохранению и открытию файла.