Интерфейс будущего
Aug. 9th, 2012 06:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Тут чего-то в мире пользовательских интерфейсов, который казалось на десятилетия застыл в парадигме CUA, в связи с появлением планшетов наметилось какое-то шевеление.
В связи с этим возникают мысли про то, как в принципе может пойти развитие интерфейсов на более традиционных устройств. Некоторое время назад я описал в "Детях пространства" как Карл Кроппкэ обучается работе со спейсианским ноутбуком.
Принципиальны там следующие вещи
1. Интерфейс неинтуитивный, он требует обучения. И несмотря на то что Лада прекрасно знает что Карл - образованный и весьма квалифицированный программист, она заставляет его пройти интерактивный обучающий курс.
Что курс там оказывается весьма хорошо написан - отдельный вопрос. Вот чего-чего а concept manual-ов современным интерфейсным нововведениями вроде мультитача явно не хватает.
2. В качестве отцов основателей чьи идеи были использованы в этом интерфейсе упоминаются Раскин, Вирт и Бузен.
При этом кнопка Jump на клавиатуре есть. Но испольузется не как у Раскина, а скорее как Meta в Unix или Command в MacOs. То есть не сама по себе а в сочетании с чем-то ещё. (это по поводу Раскина). У Вирта из Оберона по-моему можно позаимствовать ровно две вещи - tiled window management (который сейчас весьма популятен среди профессионалов) и выполнение команды, написанной в любом месте на экране одним кликом. Вот притащить в интерфейсы идеи Бузена, то есть Mind Mapping - штука нетривиальная.
В принципе, гипертекст со ссылками весьма близок к mind mapping, так что возможно, развитие html5-based интерфейсов туда и приведет. Но mind mapping это в первую очередь система быстрого и удобного редактирования связей между объектами.
Идеи Раскина о сплошном поиске в интернете более-менее реализованы усилиями гугля. Впрочем, идея reinventing the command line с возможностью указания поискового запроса вместок команды есть по-моему в Unity.
Кстати была еще идея экрана как бесконечного параболоида, автора которой я, к сожалению не вспомнил. Но можно считать что мой персонаж её тоже не вспомнил. То есть когда окно удаляется из фокуса внимания, оно уменьшается. И чем ближе к краю экрана, тем сильнее. Это в общем-то естественно стыкуется с mind map-ом. Окна, находящиеся на расстоянии одной ассоциации от текущего показываются уменьшенными, но так, что даже текст при желании читаем, на расстоянии двух - уже почти иконки и так далее.
И я совершенно зря не упоминул Негропонте с "активностями". Потому что далеко не все окна на экране являются именно "объектами", "документами" - статичными сущностями, которые могут измениться только по инициативе пользователя. Есть логи, чаты и тому подобные вещи, которые меняются "самопроизвольно" с точки зрения данного пользователя.
Еще интересно, что в современном мире уже приходится учитывать физическое положение устройства. То есть текущий контекст пользователя может включать не только то, что в компьютере, но и то, что вокруг него. Кстати я давно говорил, что концепция пользовательской сессии должна включать в себя не только клавиатуру, мышь и экран, но и устройства ввода-вывода звука, видеокамеру, и всякие разные гаджеты, которые пользователю может захотеться достать из кармана. Причем очевидно что в нашем мире "съемный носитель данных" уже не обязательно основная функция такого гаджета.
В общем мне кажется что идея пообсуждать каким может быть пользовательский интерфейс, если его оптимизировать не на привлекательность для покупателя, а на удобство и эффективность для человека, не поленившегося потратить довольно небольшое время на обучение, и оптимизировать более менее системно - довольно интересна.
В связи с этим возникают мысли про то, как в принципе может пойти развитие интерфейсов на более традиционных устройств. Некоторое время назад я описал в "Детях пространства" как Карл Кроппкэ обучается работе со спейсианским ноутбуком.
Принципиальны там следующие вещи
1. Интерфейс неинтуитивный, он требует обучения. И несмотря на то что Лада прекрасно знает что Карл - образованный и весьма квалифицированный программист, она заставляет его пройти интерактивный обучающий курс.
Что курс там оказывается весьма хорошо написан - отдельный вопрос. Вот чего-чего а concept manual-ов современным интерфейсным нововведениями вроде мультитача явно не хватает.
2. В качестве отцов основателей чьи идеи были использованы в этом интерфейсе упоминаются Раскин, Вирт и Бузен.
При этом кнопка Jump на клавиатуре есть. Но испольузется не как у Раскина, а скорее как Meta в Unix или Command в MacOs. То есть не сама по себе а в сочетании с чем-то ещё. (это по поводу Раскина). У Вирта из Оберона по-моему можно позаимствовать ровно две вещи - tiled window management (который сейчас весьма популятен среди профессионалов) и выполнение команды, написанной в любом месте на экране одним кликом. Вот притащить в интерфейсы идеи Бузена, то есть Mind Mapping - штука нетривиальная.
В принципе, гипертекст со ссылками весьма близок к mind mapping, так что возможно, развитие html5-based интерфейсов туда и приведет. Но mind mapping это в первую очередь система быстрого и удобного редактирования связей между объектами.
Идеи Раскина о сплошном поиске в интернете более-менее реализованы усилиями гугля. Впрочем, идея reinventing the command line с возможностью указания поискового запроса вместок команды есть по-моему в Unity.
Кстати была еще идея экрана как бесконечного параболоида, автора которой я, к сожалению не вспомнил. Но можно считать что мой персонаж её тоже не вспомнил. То есть когда окно удаляется из фокуса внимания, оно уменьшается. И чем ближе к краю экрана, тем сильнее. Это в общем-то естественно стыкуется с mind map-ом. Окна, находящиеся на расстоянии одной ассоциации от текущего показываются уменьшенными, но так, что даже текст при желании читаем, на расстоянии двух - уже почти иконки и так далее.
И я совершенно зря не упоминул Негропонте с "активностями". Потому что далеко не все окна на экране являются именно "объектами", "документами" - статичными сущностями, которые могут измениться только по инициативе пользователя. Есть логи, чаты и тому подобные вещи, которые меняются "самопроизвольно" с точки зрения данного пользователя.
Еще интересно, что в современном мире уже приходится учитывать физическое положение устройства. То есть текущий контекст пользователя может включать не только то, что в компьютере, но и то, что вокруг него. Кстати я давно говорил, что концепция пользовательской сессии должна включать в себя не только клавиатуру, мышь и экран, но и устройства ввода-вывода звука, видеокамеру, и всякие разные гаджеты, которые пользователю может захотеться достать из кармана. Причем очевидно что в нашем мире "съемный носитель данных" уже не обязательно основная функция такого гаджета.
В общем мне кажется что идея пообсуждать каким может быть пользовательский интерфейс, если его оптимизировать не на привлекательность для покупателя, а на удобство и эффективность для человека, не поленившегося потратить довольно небольшое время на обучение, и оптимизировать более менее системно - довольно интересна.
no subject
Date: 2012-08-09 03:58 pm (UTC)Слава богу, highres экраны пошли в массы. Потому что плавный зум, если у нас линии толщиной 1 пиксель, а не 2 - сделать нельзя.
no subject
Date: 2012-08-09 04:03 pm (UTC)Вычислительным ресурсам, которые сейчас тратятся на всякие визуальные эффекты по разворачиванию окошек, можно найти лучшее применение. Плавный зум это как раз примочка для привлечения покупателя, а не для увеличения эффективности работы опытного пользователя, которому эти задержки только мешают.
no subject
Date: 2012-08-09 04:10 pm (UTC)no subject
Date: 2012-08-09 06:47 pm (UTC)Последнее, кстати, можно использовать в учебных курсах по управлению интерфейсом))
(no subject)
From:(no subject)
From:no subject
Date: 2012-08-09 06:13 pm (UTC)Трать-тать-тарарать! - привычно отозвалось эхо. Возможность сделать плавный зум не зависит от того, какой толщины линии (величины пятна). Линии (пятна) вообще не обязаны иметь целочисленную толщину. На игнорировании этого здорово погорели многие создатели графики для трёхмерных игр, например, MS Train Simulator, в который я в своё время пытался играть, но забросил из-за принципиальной неизлечимости многих глупостей. В частности, они в масштабировали огни светофоров только до целочисленных величин, в результате чего стабильная видимость появляется только на примерно 200-300 м, но отдельные проблески в зависимости от попадания на решётку пикселов могут быть и с километра. Сие смотрится ужасно, и приводит к полной невозможности играть, воспринимая сигналы зрительно из трёхмерного вида, а не вспомогательного "костыльного" окошка-помощника.
Так вот, всей этой порнографии можно было бы избежать, если бы товарищи масштабировали эти объекты до нецелочисленных размеров. В принципе, это то же самое, что антиалиасинг, и во всех более-менее современных графических средствах антиалиасинг (а следовательно, и корректное масштабирование до любых дробных размеров) давно уже применяются. Другой вопрос, что нельзя ожидать читаемости, если всё отмасштабировано до размеров в разы меньше пиксела. Но конкретный масштаб - это уже несколько другой вопрос, чем плавность.
no subject
Date: 2012-08-09 07:01 pm (UTC)Но возмущение я понимаю, мне приходилось как-то возиться с графикой и очень много нахлебался, например, с такой штукой как функция отрисовки линии с антиалайзингом, в которую передаются целочисленные координаты точек! Нарисовать плавное движение стрелки прибора в данном случае оказалось невозможным.
(no subject)
From:(no subject)
From:no subject
Date: 2012-08-09 07:20 pm (UTC)> На игнорировании этого здорово погорели многие создатели графики для трёхмерных игр, например, MS Train Simulator, в который я в своё время пытался играть, но забросил из-за принципиальной неизлечимости многих глупостей. В частности, они в масштабировали огни светофоров только до целочисленных величин, в результате чего стабильная видимость появляется только на примерно 200-300 м, но отдельные проблески в зависимости от попадания на решётку пикселов могут быть и с километра.
Так. Я не обязан пересказывать сейчас всю теорию, которую знаю. Ключевые слова: gamma-correct antialiasing, hdr rendering, temporal aliasing, blooming, и вообще весь блог Timothy Lottes из nVIDIA.
Короче, со светофорами (я тоже фанат MSTS) проблема в том, что яркость пятна светофора в сотни раз больше окружающего ландшафта, и без HDR физически корректно его отрисовать нельзя, пусть там хоть 256xMSAA.
Та же фигня с рендерингом звезд и искр (но на них все ложат болт, т.к. они не влияют на игровую ситуацию)
А с линиями суть проблемы в том, что контраст линии толщиной в 1 пиксель будет сильно изменяться, когда она будет попадать в пределы одного физического пиксела - и когда ее будут антиалиасить между двумя пикселами.
Чтобы этого не было, любой сигнал с частотой выше 1 периода на 2^sqrt(2) пикселя нужно срезать нафик (==блурить). А чтобы текст и вообще картинка от этого не превращался в говно - нужен 2x запас по разрешению.
Это знают все телевизионщики, киношники, разработчики игр для приставок (особенно до появления HDTV), разработчики видеокодеков и т.д. Именно поэтому шрифт в титрах такой крупный, а видео (за исключением снятого с экрана) такое, на первый взгляд, "блюренное".
Вот, собственно, и весь сказ.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-08-09 04:40 pm (UTC)А можно вспомнить такую штуку как vi(m), интуитивный интерфейс, последнее что можно про него сказать :), тем не менее, как говорят, после изучения это одно из самых эффективных средств редактирования текстов. (Сам-то я только основные функции помню :()
no subject
Date: 2012-08-09 05:17 pm (UTC)На примере того же vim мы видим, что неинтуитиваные интерфейсы могут завоевать достаточно обширную аудиторию.
Это как раз пример эффективного интерфейса с достаточно низким порогом вхождения. Чтобы начать на нем работать не менее эффективно чем в редакторе с вордстаровсой системой команд, потребуется буквально 2-3 урока. Но для вордстарообразий это потолок, а в vim-е есть куда расти.
Собственно проблема современных интерфейсов состоит в том, что на самом деле человек осваивает не интерфейс. Он осваивает технологию решения каких-то задач с помощью компьютера. И это в любом случае требует обучения. Невозможно быстро и эффективно верстать в WYSIWYG-процессоре текстов, если не знать какую модель текста использует оно внутри. Невозможно быстро и качественно ретушировать графику в фотошопе, не имея представления о том, что такое слои и какие бывают фильтры.
А в процессе освоенгия концептуальной модели задачи заучить конкретные шорткаты и жесты - тоже можно.
Вообще задача на самом деле состоит в том, чтобы создать интерфейс, оптимальным образом позволяющий использовать компьютер как расширитель мышлерия. Увы,. прежде чем этим эффективно пользоваться, придется научиться ясно мыслить.
no subject
Date: 2012-08-09 07:04 pm (UTC)И да, научиться ясно мыслить, это было необходимо, но очень тяжело научиться.
no subject
Date: 2012-08-09 07:35 pm (UTC)Кстати, меня удивляет один момент в эргономике - сейчас людей, у которых одна раскладка, не так уж и много в процентном соотношении. А клавиатуры до сих пор делают без клавиши РУС/ЛАТ.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-08-09 08:18 pm (UTC)Но беда ещё, как мне кажется, в том, что быстрее, чем у тебя мысли появляются, их всё одно не выразишь. То есть, чтобы получать заметную выгоду от освоения иного интерфейса/метода (TeX, vim, слепой печати, телепатического интерфейса, etc.), нужно самому находиться на довольно высоком уровне, когда простой вариант начинает мешать. Что для изрядной части пользователей, натурально, не выполняется.
no subject
Date: 2012-08-09 09:07 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-08-09 05:11 pm (UTC)во-первых "довольно небольшое время" - это очень важно.
во-вторых для редкоиспользуемых вещей требования к "интуитивности" много выше.
no subject
Date: 2012-08-09 05:26 pm (UTC)Нужен достаточно естественный способ правильно сформулировать чего именно хочется. Не исключено что развитая гипертекстовая документация тут окажется полезней интуитивности.
А может нужна не документация, а запоминмание системы ассоциаций по которой в эту точку раньше приходил именно данный пользователь.
Впрочем, нынешние системы истории в полях ввода URL и подсказок в поисковых системах к этому достаточно близки.
(no subject)
From:(no subject)
From:no subject
Date: 2012-08-09 08:21 pm (UTC)Проблема подхода в том, что его адепты считают "довольно небольшим временем" месяц. Извините, в хозяйстве современного человека как-то более, чем 12*80 разных предметов.
Вторая проблема, видимо, в том, что Вы из тех людей, которые на гитаре научаются играть за 2 недели, печатать вслепую - за неделю, а водить автомобиль - за 4 дня. Но лично у меня ушло, соответственно, 1 год, 5 месяцев и месяца 2. Т.е. то, что Вы сделаете для "не поленившегося" мне времени не сэкономит и оптимальная для меня стратегия - лениться.
no subject
Date: 2012-08-09 08:51 pm (UTC)С разной обучаемостью отчасти согласен, сам не считаю себя гением, но обычно learning curve выглядит так: какое-то время оочень пологая, затуп, пока не врубился. Дальше довольно резкий скачок вверх, который становится всё более пологим. Т.е. нужно всего лишь проскочить начальный этап и дойти до какого-то минимально-приемлемого уровня, а дальше дело практики.
Поясню мысль. Что глядя на клавиатуру я первый месяц-другой медленно печатал без эффективного обучения, что вслепую я за месяц первичный затуп проскочил бы. А при условии целенаправленного обучения — за неделю. И дальше в любом случае эффективность была бы не ниже, а выше. Да, иногда эффективней лениться и пользоваться интерфейсами для чайников, но не всё так страшно.
no subject
Date: 2012-08-10 04:15 am (UTC)Вопрос в том, что результат должен этого стоить. То есть в результате обучения человек должен получить доступ к огромному миру информации и средств её обработки, и в дальнейшем конкретным методам обращения с конкретными видами информации обучаться примерно настолько же быстрее, чем поездка на машине быстрее прогулки пешком.
Ну и чтобы этот навык работы с информацией был на всю жизнь.
no subject
Date: 2012-08-09 08:58 pm (UTC)Очевидные для современного пользователя концепции, такие как double click -- если проверить на человеке без опыта использования компьютера окажутся вовсем неочевидными.
1.1. Для пользователей привыкших к разным концепциям понятие "очевидности" очень сильно отличается. Когда я вынужденно оказываюсь за машиной с виндой -- я теряюсь. И часто люди с несравнимо меньшем опытом удивленно показывают мне куда тыкать. Для них это очевидно.
Ровно также как для любого линукс-пользователя, совершенно очевидно впервые столкнувшись с новой программой первым делом набрать man . А в случае (о ужас!) его отсутствия -- запустить с опцией --help.
Вполне опытный программист, работавший до этого только в одной из нынешних распространенных систем (Linux, Windows, MacOS) будет вынужден либо читать документацию, либо обращаться с вопросами к коллегам.
2. По mind mapping -- я такую попытку видел чуть ли не лет 10 назад. Программа 'the brain', как органайзер заметок. Увы, win-only.
Сейчас, я смотрю очередной бум использования mind mapping -- например я уже сталкивался с тем, что от меня заказчик просит прислать ему какую-либо информацию в виде mindmap. Когда эта концепция станет совсем привычной, начнут делать и интерфейсы на этом принципе.
Главная мысль -- современный интерфейс должен быть "из коробки" близким и понятным для обычного windows-пользователя, но с возможностью доточить его до профессионального использования.
Хороший образ, мне кажется, как раз именно emacs. У которого главный недостаток -- дефолтные конфиги ужасны, и его невозможно использовать без напильника.
Главная проблема интерфейсов сейчас -- не обучение, а переучивание. Если ребенок впервые сталкивается с текстовым редактором, то разницы между Emacs и Word для него в сложности обучения никакой нет. Вот между vim и word -- есть (нужно понять концепцию command mode/insert mode).
no subject
Date: 2012-08-10 04:25 am (UTC)Ну а с тех пор много чего понаписано на эту тему. Я, правда смотрю на эту область довольно вяло, и инструмента, который бы лично я себе счел удобным пока не нашел. И для тех задач, где на самом деле нужен mindmap пользуюсь wiki.
Что касается сложности изучения и переучивания, то переучивать всё равно надо. Потому что на самом деле между word и emacs ничего похожено. Еmacs это редактор текста с простой, почти линейной этого текста моделью.
word - это система верстки с весьма развесистой моделью документа поддерживающей не менее двух плохо совместимых междду собой способов управления представлением - стили и физическую разметку.
Другое дело что пользователи ворда, как правило, им пользоваться не умеют.
Ворд это типичный пример инструмента, который может много, но совершенно не поощряет пользователя использовать все его возможности.
Вообще я не думаю что задача переучивания такая страшная. Судя по тому, что сделал Микрософт в 2010 по-моему офисе, и что они собираются сделать в Win8, а также что сделаи гномы в Gnome 3, пользователям "конкурирующих" продуктов переучивание грозит раз в 3-4 года. Поэтому на продукт который говорит "сейчас вам надо будет переучиться, но эти знания останутся с вами на всю жизнь" пользователи повалят как только Microsoft, Apple или какой-нидбудь опенсурсный десктоп устроит очередную революцию под лозунгом "забудьте все, чему научились, у нас теперь все новое и лучше".
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-08-12 09:08 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-08-12 09:18 pm (UTC)Вообще "щупательные" интерфейсы при всей их псевдоинтуитивности вне вещественной среды очень редко толком работают - наскидку мне только мультитачевое растягивание картинок вспоминается. "Словесные" команды гораздо интереснее в этом плане. Другое дело, что набор команд должен иметь несколько более логичный, чем в emacs (в котором у меня уже раза три опускались руки при попытках как-то разумно установить хоткеи).
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-08-12 09:59 pm (UTC)Второе - изоморфизм интерфейсов. Елси у нас есть "тыкательный", командный и "хоткейный" интерфейсы - любая возможность: а) должна быть доступна в любом из них (для хоткейного - должна быть возможность задания хоткея), б) должен быть легкий и стандартный способ посмотреть соответствие - "как это сделать мышью" и "какую команду я запустил хоткеем" в) разумеется, это всё должно быть программно доступно стандартным образом
Третье - принципиальное - мы, понятное дело, даём механизм - но нужно дать(очень) хорошую дефолтную policy. И здесь всё становится интересным, так как для сколько-нибудь сложной системы я боюсь представить, каков будет объём работы для формирования этой самой policy. Поэтому - именно как базовое требование к такой системе - нужно сразу вкручивать механизм коллаборации - обмена настройками, их комбинирования и т.д - с минимальной морокой для пользователя. Тогда сообща можно будет выработать какие-то разумные пресеты. Кстати, необходимое требование для этого - невозможность притащить в систему неэффектиыне "стандарты" из уже существующего софта. Из этого, кстати, следует неоходимость ведином стандарте конфигов, который можно мержить/делить, обрабатывать автоматическими средствами т.д. При этом никто не мешает ему оставаться текстовым - но вот структурным стать придётся. И иметь метаинформацию a-la DTD или схему - тоже.
Четвёртое - сквозная документируемость. Если мы хотим,чтобы люди сопользовали возможности - они должны быть в состоянии найти их и понять,что это. В помянутых мной выше "DTD" к конфигам документация к отдельным настройкам должна быть вбита настолько, чтобы этим легче было пользоваться, чем не пользоваться. Для любой функции софта - справка опять-таки должна вызываться стандратным образом - ну это очевидно, хотя от man пора уходить к гипертексту как минимум. Вообще - документируемость надо поддреживать, конечно, административно - силами команды, развивающей систему.
Пятое. Компонентность. Витусу не понравится, пожалуй... Любой софт реализует явно опсианный интерфейс (собственно, документируется именно он). И в норме сторонний софт не интересуется конкретной реализацией интерфейса. Хочешь плеер - на тебе плеер. Какой- не прицнипально. А вот "плеер, поддерживающий проигрывание сетевых потоков" - это уже более широкий интерфейс - в общем, тут стоит с COM драть - аккуратно, конечно.
Взаимодейтсвует всё это по шине. Которая идёт через диспетчер, релизующий нынешний функционал D-Bus (ну там, запуск по требованию, рассказы что доступно и тому подобное) - а кроме того - привязку релизаций к интерфейсам и выбор дефолтной для кадого интерфейса - в смысле выбор пользователем. Еще одна его функция - это навороченная система мониторинга и при необходимости модификации сообщений по всем мыслимым критериям. Да, разумеется - "текстовые" клиенты для работы с этой шиной обязательны. Но внутренняя тиипизация (a-la protobufs) сообщений и возможность структурированно с ними работать из разнообразных ЯП - тоже обязательны. Потому что это заставляет делать продуманные интерфейсы и уменьшает шансы отправить чушь, которая будет невесть как интерпретирована.
А вот на шине мы уже можем реализовать много чего - сессии (древовидные, где дочерние сессии наследуют и переопределяют свойтсва родительской - и все свои настройки софт загружает/хранит именно в сессиях), определение стандартных хоткеев, способы реализации "акивных зон" (global menu - как пример), само собой - нормально настраиваемые нотификейшны (по пачке признаков - класс, интерфейс-отправитель, софт-отправитель, текст и т.п. - можно настроить реакцию), стандартные диалоги открытия/сохранения файлов (об этом дальше) и т.п.
Дальше. Документы. То, что мы сейчас имеем - с древовидными каталогами - для пользовательских данных пригодно мало. Вроде как хорошие результаты покахывает теговая организация - когда документ протсо находится в пачке произвольных категорий (и для эстетов - обладает пачкой произвольных признаков). Если у нас стандартные системные способы указать софту какой документ открыть и куда сохранить - этодело довольно спокойно реализуется поверх POSIX. Тогда становятся возможными всякие интерресные штуки вроде версионности, организованной средствами системы - то есть вобщем случае (без учета оптимизаций) компонент может вообще не знать, версионируется данныйдокумент или нет. Ну и разные средства доступа к удалённым харнилищам так же интегрируются.
Такие вот намётки.
no subject
Date: 2012-08-13 12:32 am (UTC)Microsoft на этом себе лоб успешно разбила. У них денег и квалификации управленцев чтобы решить эту проблему не хватило.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-08-13 03:28 am (UTC)Что касается взаимодействия "всего этого" по шине, то тут по-моему несколько хитрее. Даже у DBus шин - две. Системная и сессионная. А нужно, видимо, больше. Возможно достаточно хорошо будет ложиться в мозги концепция, когда с каждым логическим крупным объектом, с которым работают несколько компонент, будет связана своя шина, по которой эти компоненты обмениваются управляющей информацией, Но ни в коем случае не надо передавать по шине крупные куски данных. Только ссылки на них.
Таким образом, кроме шины есть еще возможность взаимодействия между компонентами путем работы с общими объектом данных (например документом или pixmap).
Очевидно, что встраивание интерфейса одной компоненты во фрейм в интерфейсей другой - это третий способ взаимодействия, не сводящийся к первым двум.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From: