T>>А ты с более-менее единообразными-то работал?..
T>>(имеется в виду Apple)

G>А что, для Apple есть программы?

сколько угодно

Здравствуйте, Cyberax, Вы писали:

C>Например, в более другой системе печати может по-другому работать разбиение на страницы. А это потребует от приложения переразбивки документа и т.п.

Если система печати будет иметь более развитый интерфейс, чем базовое приложение (например, уметь работать со слоями), то эти функции будут недоступны (disable)При этом программа будет работать. Таким образом навороченная САПР печать может быть использована для печати простых bmp, а сложнейшие САПР файлы будут печататься (с минимальными настройками) даже в таких простых приложениях, как Paint.
То есть модули будут делать свою работу без дополнительной настройки.

C>В тот же richedit не получится добавить, скажем, поддержку векторной графики — приложение не поймёт.

Это потому, что richedit не для того сделан. А вот в броузеры и всевозможные просмоторщики поддержку векторной графики добавить можно.
Сейчас, если мы научились читать векторный формат, к примеру svg, то чтобы добавить его в популярные приложения, нужно писать РАЗНЫЕ плагины к каждому из них. Один плагин для IE, другой для Total Commander, третий для IrfanView, четвертый для ACDSee, пятый для Photoshop.
А если они все будут использовать стандартный интерфейс "графический_файл" — то можно будет обойтись ОДНИМ плагином. Причем когда некая компания захочет создать собственный векторный формат, то за базовый интерфейс она возьмёт тот же "графический_файл" — и их формат автоматически будет поддержан популярными программами.

Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:

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

Здравствуйте, deniok, Вы писали:

G>>В вебе (HTML+CSS+JS+XML) стандартизация существует и очень успешно. Но все в итоге уприается в реализацию стандартов разными вендорами.

Данная проблема решается, так как речь идет о создании единой системы под эгидой одной ОРГАНИЗАЦИИ. Программисты будут писать модули "для себя" и "для всех. Модули "для всех" будут проверяться в рамках ОРГАНИЗАЦИИ, подписываться и затем ставится для общего доступа — для продажи или freeware. Впрочем, это уже тонкости.

D>Беспроблемная замена модуля A на модуль B возможна, только если их базовая функциональность идентична, а отличие только в рюшечках. Либо если они практически изолированны от остальной системы; ну так я и нынче могу снести Microsoft Office и поставить Star Office, в чём проблема?

Проблема в том, что MS Office не читает PSD, а Photoshop не читает Doc. Когда будет стандарт модуля проверки офрографии, то можно писать новую программу с его использованием, а затем приобрести готовый модуль, причем для любого языка.

Здравствуйте, Young_Pioneer, Вы писали:

Y_P>Здравствуйте, deniok, Вы писали:

G>>>В вебе (HTML+CSS+JS+XML) стандартизация существует и очень успешно. Но все в итоге уприается в реализацию стандартов разными вендорами.

Y_P>Данная проблема решается, так как речь идет о создании единой системы под эгидой одной ОРГАНИЗАЦИИ. Программисты будут писать модули "для себя" и "для всех. Модули "для всех" будут проверяться в рамках ОРГАНИЗАЦИИ, подписываться и затем ставится для общего доступа — для продажи или freeware. Впрочем, это уже тонкости.

ОК, позволь рассказать тебе "байку из жизни": есть тут фирмочка под названием MS, в конце прошлого века они решили замахнуться на рынок ERP, был у них задуман некий project Green, супермега-ERP, даже речь шла о некоем едином фреймворке для построения разных корпоративных систем. Купили они несколько конторок под это дело (Соломон, Навижн, ГрейтПлейнс и ещё что-то вроде). И пришли в итоге к тому, что стали выпускать чуток допиленные продукты тех конторок, которые они купили (и линейка микрософт динамикс состоит далеко не из одного продукта).
Теперь вопрос — мелкософт — это одна организация или нет?

Y_P>Проблема в том, что MS Office не читает PSD, а Photoshop не читает Doc. Когда будет стандарт модуля проверки офрографии, то можно писать новую программу с его использованием, а затем приобрести готовый модуль, причем для любого языка.

aspell?

YP>Каждая программа будет состоять из файлов-модулей — похоже на нынешние .dll библиотеки. Главное отличие — интерфейсная часть основных модулей — стандартизована,

Нельзя объять необъятное

Здравствуйте, Young_Pioneer, Вы писали:

Y_P>Проблема в том, что MS Office не читает PSD, а Photoshop не читает Doc. Когда будет стандарт модуля проверки офрографии, то можно писать новую программу с его использованием, а затем приобрести готовый модуль, причем для любого языка.

По-моему мир уже ушел существенно дальше твоих грез. Я вот пишу это письмо из-под веб-интерфейса, а firefox проверяет орфографию: русскую, английскую + пункт "добавить словари". Я не понимаю, какую и чью проблему решит такой стандарт?

На всякий случай напомню, что чтобы принять любой международный стандарт надо создать рабочую группу, пройти кучу национальных и наднациональных бюрократий, утрясти массу юридических вопросов, потратить в совокупности миллионы долларов и много человеко-лет. Там, где это реально нужно — стандарты принимаются, несмотря на все эти издержки. Вот ты, скажем, готов потратить волонтером хотя бы полгода своей жизни, чтобы поучаствовать в принятии хотя бы одного из перечисленных стандартов? Или хотя бы отдать на это сумму, эквивалентную твоей полугодовой зарплате?

Здравствуйте, Курилка, Вы писали:

К>ОК, позволь рассказать тебе "байку из жизни": есть тут фирмочка под названием MS, в конце прошлого века они решили замахнуться на рынок ERP, был у них задуман некий project Green, супермега-ERP, даже речь шла о некоем едином фреймворке для построения разных корпоративных систем. Купили они несколько конторок под это дело (Соломон, Навижн, ГрейтПлейнс и ещё что-то вроде). И пришли в итоге к тому, что стали выпускать чуток допиленные продукты тех конторок, которые они купили (и линейка микрософт динамикс состоит далеко не из одного продукта).

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

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Курилка, Вы писали:

К>>ОК, позволь рассказать тебе "байку из жизни": есть тут фирмочка под названием MS, в конце прошлого века они решили замахнуться на рынок ERP, был у них задуман некий project Green, супермега-ERP, даже речь шла о некоем едином фреймворке для построения разных корпоративных систем. Купили они несколько конторок под это дело (Соломон, Навижн, ГрейтПлейнс и ещё что-то вроде). И пришли в итоге к тому, что стали выпускать чуток допиленные продукты тех конторок, которые они купили (и линейка микрософт динамикс состоит далеко не из одного продукта).

N>Это не значит, что никакой работы по интеграции этих систем не ведется. Просто они изначально были совсем непохожи, и их сведение вместе требует немалой работы. Кое-какие части уже переиспользуются в нескольких проектах.

Ну яж вроде не говорил, что работ не было. Просто исходная идея (насколько я понимаю), была как раз близка к заявленной в топике "стандартизации", но вот на практике ситуация оказалась несколько отличной от ожидаемого.
Да и в принципе я очень не уверен, что имеет смысл подводить "под одну гребёнку" автоматизацию какого-нибудь магазана, торгующего водкой, и, скажем, Камаза, хотя некие базовые элементы стандартизовать стоит.

Здравствуйте, YoungPioneer, Вы писали:

YP>Просьба оценить идею:

YP>Каждая программа будет состоять из файлов-модулей — похоже на нынешние .dll библиотеки. Главное отличие — интерфейсная часть основных модулей — стандартизована, подобно тому, как сейчас стандартизованы интерфейсы составных частей компьютера — процессор, жесткий диск и т.д.Любой производитель может начать выпуск мониторов, причем работать они будут даже без нового драйвера — в Windows предусмотрен "стандартный монитор".

[Skip]

YP>Заранее благодарен за комментарии.

Com-модель изобрел. Молодец.
Примерно так же Микулин в свое время изобрел турбореактивный двигатель.
Радостный примчался к своему учителю. Тот его восторга не оценил, и отправил учиться.
Эпизод описан в книжке "Жизнь Бережкова" (в www.lib.ru есть).

Здравствуйте, thesz, Вы писали:

ЕЧ>>>Пользователь будет видеть едино оформленные программы, с похожим интерфейсом, справкой, плюс схожий функционал начнет работать единообразно. Затраты на обучение новым программам сократятся до минимума.
D>>Я, как пользователь, могу лишь заметить, что единообразные программы надоедают до чертиков. Мне разнообразные нравятся, мне уже пора на свалку истории?

T>А ты с более-менее единообразными-то работал?..

T>(имеется в виду Apple)

Я старый человек... нет не так.

В свое время пользовалась популярностью библиотека turboVision.
Это чтобы окошки-менюшки в ДОС-е рисовать.
Программы выглядели настолько одинаково, что пользователь забывал в какой программе он находится.
Обучению это не сильно помогало. Ну да, выпадающее меню всегда сверху. Ну и что?
Ведь то, что означает каждое действие все равно нужно было учить.

A>В свое время пользовалась популярностью библиотека turboVision.
A>Это чтобы окошки-менюшки в ДОС-е рисовать.
A>Программы выглядели настолько одинаково, что пользователь забывал в какой программе он находится.
A>Обучению это не сильно помогало. Ну да, выпадающее меню всегда сверху. Ну и что?
A>Ведь то, что означает каждое действие все равно нужно было учить.

Есть такое понятие — «принцип наиманьшего удивления». Единообразность (не одинкоаовсть!) инетерфейсов как раз способствуе такому принципу

YP>>Просьба оценить идею:
D>Идея хорошая. Возможно каждому читающему этот форум она в том или ином виде приходила (я, например, на полном серьёзе в своё время прикидывал способы реализации).
D>Скажу сразу. Главная проблема в том, что индустрия ещё не готова к этому. Пока вершиной программистской мысли считается ФП, ничего не изменится.

Па-апрашу развернуть!

Здравствуйте, Young_Pioneer, Вы писали:

C>>Например, в более другой системе печати может по-другому работать разбиение на страницы. А это потребует от приложения переразбивки документа и т.п.
Y_P>Если система печати будет иметь более развитый интерфейс, чем базовое приложение (например, уметь работать со слоями), то эти функции будут недоступны (disable)При этом программа будет работать. Таким образом навороченная САПР печать может быть использована для печати простых bmp, а сложнейшие САПР файлы будут печататься (с минимальными настройками) даже в таких простых приложениях, как Paint.
Ну вот. Опять. Ты хочешь сделать заранее самую идеальную возможную печатную систему, у которой просто программы будут отключать ненужные функции.

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

C>>В тот же richedit не получится добавить, скажем, поддержку векторной графики — приложение не поймёт.
Y_P>Это потому, что richedit не для того сделан. А вот в броузеры и всевозможные просмоторщики поддержку векторной графики добавить можно.
Ты опять сбиваешься.

Твоя идея: делаем суперкастомизуемую систему, так чтоб пользователь мог нажать правой клавишей на любое поле ввода и вместо него воткнуть красивое поле ввода с поддержкой векторной графики и встроенным в виде пасхального яйца Doom3, использущим это поле ввода для savegame'ов.

Только оказывается, что это поле ввода используется внутри приложения в текстовом виде. И попытка туда добавить графику приведёт к краху. Вот и закончилась эта история.

Y_P>А если они все будут использовать стандартный интерфейс "графический_файл" — то можно будет обойтись ОДНИМ плагином. Причем когда некая компания захочет создать собственный векторный формат, то за базовый интерфейс она возьмёт тот же "графический_файл" — и их формат автоматически будет поддержан популярными программами.
Это уже было давно придумано и даже сделано, и называется OLE (ещё из подобного OpenDoc на Mac'ах был, ну и HyperCard оттуда же). Там есть и compound document'ы и встраивание приложений, и вообще много чего ещё.

Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Young_Pioneer, Вы писали:

Y_P>>Проблема в том, что MS Office не читает PSD, а Photoshop не читает Doc. Когда будет стандарт модуля проверки офрографии, то можно писать новую программу с его использованием, а затем приобрести готовый модуль, причем для любого языка.

D>По-моему мир уже ушел существенно дальше твоих грез. Я вот пишу это письмо из-под веб-интерфейса, а firefox проверяет орфографию: русскую, английскую + пункт "добавить словари". Я не понимаю, какую и чью проблему решит такой стандарт?

в данном случае проблема уже решена, насколько я помню
openoffice, firefox и компания скооперировались и сделали hunspell
общую систему проверки орфографии

Здравствуйте, Zhendos, Вы писали:

Z>в данном случае проблема уже решена, насколько я помню
Z>openoffice, firefox и компания скооперировались и сделали hunspell
Z>общую систему проверки орфографии

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

Здравствуйте, deniok, Вы писали:


D>Ну так это же продукт, а не стандарт; в данной дискуссии предполагается что кто-то теперь должен еще совершить какие-то довольно затратные действия по обеспечению фиксирования и стандартизации интерфейса взаимодействия проверялка/проверяемое.

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

D>Что с моей точки зрения действительно повысит лёгкость замены модуля проверки орфографии на другой, но в то же время снизит потенциал развития обоих модулей, поскольку на них налагается необходимость поддержки доп.требований. Что, по-моему, существенно превышает выгоды неустановленных лиц от замены.


Проблема решаема, также как решаема проблема цветной печати на черно-белом принтере — будет работать только то, что поддержано.
К примеру, в стандарте "системе_первода_1" нет поддержки озвучки текста, но некий производитель (пусть будет Promt) его добавил. Его модуль будет работать в старых приложениях (назовем MS Office 2012), хотя без озвучки. Promt обращается в ОРГАНИЗАЦИЮ с предложением расширить стандарт до "система_перевода_2" — с включение озвучки текста. MS Office 2013 поддержит новый интерфейс и озвучка заработает автоматически.
Озвучка текста может быть рекомендуемым, но необязательным интерфейсом "система_перевода_2". В этом случае некая компания SimpleTranslator создает свой модуль на основе "система_перевода_2" без озвучки — и MS Office 20013 будет корректно работать и с ним.

Таким образом, стандарты не станут эдаким "прокрустовым ложем", мешающим нормальному развитию ПО.

Рассмотрите ситуацию: программа не содержит пользовательский интерфейс главной формы "в себе", а выдаёт его в виде xml, при этом модуль, написанный сторонней компанией, СПЕЦИАЛИЗИРУЮЩЕЙСЯ ИМЕННО НА ПОЛЬЗОВАТЕЛЬСКОМ ИНТЕРФЕЙСЕ, создаст на основе этого xml: меню, тулбары, панели. При этом пользователь (не программист, а именно пользователь!) сможет изменить модуль интерфейса на другой — и выбрать ribbon, тулбары, а может ему больше понравится просто дерево вместо меню.
При этом программисты наконец будут создавать новые технологии, а не решать проблемы, которыми в тот же момент занимаются еще тысячи других программистов — вроде правильной расстановки элементов на форме.

Здравствуйте, thesz, Вы писали:

T>Па-апрашу развернуть!

Не, я не тролль

Здравствуйте, Cyberax, Вы писали:

C>Ну вот. Опять. Ты хочешь сделать заранее самую идеальную возможную печатную систему, у которой просто программы будут отключать ненужные функции.

Печатные системы будут делать профессиональные производители печатных систем.
Конкретный пример: есть реальный клиент, который хочет видеть нашу печать в Visio, чтобы можно было печатать большие изображения с разбивкой на листы. В принципе, это можно сделать через драйвер принтера (интерфейс драйвер, несмотря на свою сложность, используется очень часто, например для создания pdf), но в будущем хотелось бы иметь более простой метод.

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

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

C>Твоя идея: делаем суперкастомизуемую систему, так чтоб пользователь мог нажать правой клавишей на любое поле ввода и вместо него воткнуть красивое поле ввода с поддержкой векторной графики и встроенным в виде пасхального яйца Doom3, использущим это поле ввода для savegame'ов.

"Кастомизация" как раз не главное. И "куда угодно что угодно" воткнуть пользователь не сможет — на это есть программисты. При этом есть некоторые модули программ, которые можно заменить на "более хорошие" либо добавить дополнительные: например, добавлять поддержку новых форматов файлов.
Эти модули:
-загрузка и сохранение из/в определенный формат (можно добавлять модули)
-пользовательский интерфейс (можно заменять модули)
— печать (можно добавлять / заменять модули)
— общие алгоритмы: перевод, шифрование, векторизация растра и т.д.
многие из таких модулей уже сейчас делаются профессионалами и продаются в виде компонентов либо исходников. Только без каких-либо СТАНДАРТОВ.

COM даёт богатые возможности совместного использования компонентов программ и иногда методы тотальной "кастомизации" самих программ. Мы тоже делаем COM компоненты, и клиенты-ПРОГРАММИСТЫ легко вставляют их в свои программы. Но НЕТ СТАНДАРТА, чтобы написать компонент, который вставится во все профессиональные программы, которым может понадобится этот функционал. COM, конечно, может быть использован как база для реализации идеи модулей, но лучше создать новую технологию.

Y_P>>А если они все будут использовать стандартный интерфейс "графический_файл" — то можно будет обойтись ОДНИМ плагином. Причем когда некая компания захочет создать собственный векторный формат, то за базовый интерфейс она возьмёт тот же "графический_файл" — и их формат автоматически будет поддержан популярными программами.

C>Это уже было давно придумано и даже сделано, и называется OLE

То есть можно сделать COM объект, читающий простенький растровый формат '*.abc' и такие программы, как MS Office, Google Chrome, Photoshop, AutoCAD, 1C и другие "поймут" этот COM объект и будут открывать *.abc подобно *.bmp? Один плагин для всех?

Здравствуйте, Young_Pioneer, Вы писали:

Y_P>>>А если они все будут использовать стандартный интерфейс "графический_файл" — то можно будет обойтись ОДНИМ плагином. Причем когда некая компания захочет создать собственный векторный формат, то за базовый интерфейс она возьмёт тот же "графический_файл" — и их формат автоматически будет поддержан популярными программами.
C>>Это уже было давно придумано и даже сделано, и называется OLE
Y_P>То есть можно сделать COM объект, читающий простенький растровый формат '*.abc' и такие программы, как MS Office, Google Chrome, Photoshop, AutoCAD, 1C и другие "поймут" этот COM объект и будут открывать *.abc подобно *.bmp? Один плагин для всех?

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

C>>Твоя идея: делаем суперкастомизуемую систему, так чтоб пользователь мог нажать правой клавишей на любое поле ввода и вместо него воткнуть красивое поле ввода с поддержкой векторной графики и встроенным в виде пасхального яйца Doom3, использущим это поле ввода для savegame'ов.

Y_P>"Кастомизация" как раз не главное. И "куда угодно что угодно" воткнуть пользователь не сможет — на это есть программисты. При этом есть некоторые модули программ, которые можно заменить на "более хорошие" либо добавить дополнительные: например, добавлять поддержку новых форматов файлов.
Y_P>Эти модули:
Y_P>-загрузка и сохранение из/в определенный формат (можно добавлять модули)
Y_P>-пользовательский интерфейс (можно заменять модули)
Y_P>- печать (можно добавлять / заменять модули)
Y_P>- общие алгоритмы: перевод, шифрование, векторизация растра и т.д.
Y_P>многие из таких модулей уже сейчас делаются профессионалами и продаются в виде компонентов либо исходников. Только без каких-либо СТАНДАРТОВ.

Y_P>COM даёт богатые возможности совместного использования компонентов программ и иногда методы тотальной "кастомизации" самих программ. Мы тоже делаем COM компоненты, и клиенты-ПРОГРАММИСТЫ легко вставляют их в свои программы. Но НЕТ СТАНДАРТА, чтобы написать компонент, который вставится во все профессиональные программы, которым может понадобится этот функционал. COM, конечно, может быть использован как база для реализации идеи модулей, но лучше создать новую технологию.

А! Наконец-то я понял. Тебе нужна своя открытая операционная система — только так можно встроить что угодно во что угодно. Ну так такие есть давно — тот же линукс в куче разновидностей. (При чём, думаю, возможностей одного только оконного менеджера по типу KDE тебе не хватит, нужна именно OS. Но потом все ненужные функциональные возможности надо будет спрятать этим самым оконным менеджером — по типу того, как это сделано в Xandros и его icewm). Ну а что так сложно — извини, ты сам захотел стандарты для всего. Осталась малость — убедить остальных использовать такой механизм Кстати, сама MS приложит максимум усилий, чтоб такого не случилось — отчасти оттого, что не захочет пускать сторонний народ вглубь своей архитектуры больше, чем это сделано сейчас, отчасти оттого, что тогда она уж точно потеряет доминирующее положение на рынке софта.

PS. Возможно, Oberon BlackBox в действительности то, что ты хочешь. Там много интересных идей, но сомневаюсь, что они когда-нибудь станут стандартами, или просто получать хотя бы небольшое распространение.