Здравствуйте, <Аноним>, Вы писали:

А>Маленькая ремарка, чтобы не терять нить рассуждений: Изначально рассуждалось о необходимости унификации GUI API в принципе, не привязываясь к конкретным ОС. Основная мысь была в том, что было бы неплохо иметь универсальный API для написания GUI приложений под любую ось, реализующей данный стандарт в числе своих API.
Проблема в том, что очень трудно прийти к единому мнению по поводу состава GUI API. Либо этот стандарт невозможно будет реализовать на устройствах с невысокими способностями, либо он будет очень ограничен и все станут пользоваться расширениями. Которые тут же убьют всю идею унификации.

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, Шахтер, Вы писали:

Ш>>Только не так, как сделан POSIX. Чур чур меня. Эта недоделка не может быть образцом.
А>(Ремарка: после стольких лет продвижения своих стандартов, мелкомягкие с гордостью заявили, что их новая ОС совместима со стандартом POSIX. Может не все так плохо, как ты говоришь?)

По поводу POSIX а. Это очень слабый прикладной интерфейс. WinAPI его перекрывает многократно. Его поддержка в Windows -- дань совместимости со старым кодом. Разрабатывать новый софт для виндом на POSIX е -- нонсенс.

А>Ни кто не призывает к слепому копированию, тщательный отбор и четкое обоснование, только после этого написание стандарта. Что-то вроде RFC — собирается кучка спецов и творят, результат выностится на всеобщее обсуждение. Некоторое время спустя, стандарт дорабатывается с учетом конструктивной критики и снова обсуждается, до тех пор пока не исчезнет конструктивная критика. После этого кандидат в стандарты можно начать использовать, а по прошествии некоторого времени вновь подвергнуть ревизии, с учетом практического опыта его использования.

C RFC работаю плотно, знаю их не понаслышке -- это ещё хуже, чем POSIX. Что не удивительно. Банда отцов маньяков не способна породить ничего лучше, чем Фредди Крюгер.
Вообще, действительно хорошие технологии и идею, если вспомнить историю компьютерной индустрии, были плодом работы одного, в крайнем случае нескольких человек, тесно работавших вместе и, самое главное, не оглядовавшихся ни на что.

Ш>>API Win32
А>Если победит концепция виртуальных машин, то о WinAPI можно будет говорить только как о платформе для любительских поделок, а о людях пишущих на чистом API будут говорить как сейчас говорять об ASM программистах. (Сами АСМ программисты станут вообще легендой.)

Я не верю в волшебные палочки. Место будет всему.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, <Аноним>, Вы писали:

А>Набрел тут на спор о продолжении поддержки MFC вендором и потянуло пофилософствовать.
А>Собственно вопрос:
А>Не настала ли пора для систематизации знаний по программированию GUI? Речь идет не о том, как писать функции, реализующие отдельные элементы интерфейса, а о том какие функции должны быть реализованы. Сделать с гуем примерно тоже что сделано со стандартными сишными либами в POSIX стандарте. Как MFC фактически служит промышленным станфартом для программирования UI под вынь сейчас, так и подобный стандарт мог бы стать универсальным стандартом в будущем.

Только не так, как сделан POSIX. Чур чур меня. Эта недоделка не может быть образцом.

А>Все что в общем то требуется — отделить функции для реализации интерфейса, от кучи сервисных функций, которые к UI не имеют ни какого отношения.
А>Даешь появление libc.dll, stl.dll, ole.dll и т.д. и т.п.!!!
А>Даешь появление легкого и шустрого фраймворка для получения нэтивного бинаря, а кто против пусть пишет на Джаба!!!

API Win32

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Аноним, Вы писали:

<>

X Windows ?

Здравствуйте, Аноним, Вы писали:

А>Собственно вопрос:
А>Не настала ли пора для систематизации знаний по программированию GUI?
А>Все что в общем то требуется — отделить функции для реализации интерфейса, от кучи сервисных функций, которые к UI не имеют ни какого отношения.
А>Даешь появление libc.dll, stl.dll, ole.dll и т.д. и т.п.!!!
А>Даешь появление легкого и шустрого фраймворка для получения нэтивного бинаря, а кто против пусть пишет на Джаба!!!
Ага! А в Ява интерфейс как раз стандартизирован — целые тонны интерфейсных классов реализованы.
А стандартизация давно уже существует — только на юниксовых системах. Поищите ссылки по слову MOTIF — это как раз либа интерфейса — платформенно-независимого. Или в Яве посмотрите классы — она как раз на основе идеологии мотифа делалась.

Набрел тут на спор о продолжении поддержки MFC вендором и потянуло пофилософствовать.
Собственно вопрос:
Не настала ли пора для систематизации знаний по программированию GUI? Речь идет не о том, как писать функции, реализующие отдельные элементы интерфейса, а о том какие функции должны быть реализованы. Сделать с гуем примерно тоже что сделано со стандартными сишными либами в POSIX стандарте. Как MFC фактически служит промышленным станфартом для программирования UI под вынь сейчас, так и подобный стандарт мог бы стать универсальным стандартом в будущем.

Все что в общем то требуется — отделить функции для реализации интерфейса, от кучи сервисных функций, которые к UI не имеют ни какого отношения.
Даешь появление libc.dll, stl.dll, ole.dll и т.д. и т.п.!!!
Даешь появление легкого и шустрого фраймворка для получения нэтивного бинаря, а кто против пусть пишет на Джаба!!!

Здравствуйте, Аноним, Вы писали:

либами в POSIX стандарте. Как MFC фактически служит промышленным станфартом для программирования UI под вынь сейчас, так и подобный стандарт мог бы стать универсальным стандартом в будущем.

Сиё очень-очень спорно батенька

А>Все что в общем то требуется — отделить функции для реализации интерфейса, от кучи сервисных функций, которые к UI не имеют ни какого отношения.
А>Даешь появление libc.dll, stl.dll, ole.dll и т.д. и т.п.!!!
А>Даешь появление легкого и шустрого фраймворка для получения нэтивного бинаря, а кто против пусть пишет на Джаба!!!

Давай!

А> Как MFC фактически служит промышленным станфартом для программирования UI под вынь сейчас, так и подобный стандарт мог бы стать универсальным стандартом в будущем.

XAML и будет, через два года.

А>Даешь появление libc.dll, stl.dll, ole.dll и т.д. и т.п.!!!
А>Даешь появление легкого и шустрого фраймворка для получения нэтивного бинаря, а кто против пусть пишет на Джаба!!!

Не нэтивного, а дотнетовского
Нэтивные бинари скоро все отправятся "в страну Мальборо".

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

M>XAML и будет, через два года.
А почитать об этом где нибудь можно?

M>Не нэтивного, а дотнетовского
M>Нэтивные бинари скоро все отправятся "в страну Мальборо".
А я против, хотя у меня и стоит 2 диска по 120 гиг, добавлять допалнительную програмную прослойку я не хочу. Если раньше програмирование было трудным, но интересным делом, открывающим большой простор и для разработки и для оптимизации существующего кода, то теперь это просто шаманство какое-то. Запустил визард, он тебе сгенирил нечто, при достаточной доле везения и небольшой практике это можно заставить работать, но как это будет работать — отдельная история. Еще раз — даеш нетивный код, ламерам от программирования — смерть в корчах, программирование — высокое исскуство а не ремесло.

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

Ш>Только не так, как сделан POSIX. Чур чур меня. Эта недоделка не может быть образцом.
(Ремарка: после стольких лет продвижения своих стандартов, мелкомягкие с гордостью заявили, что их новая ОС совместима со стандартом POSIX. Может не все так плохо, как ты говоришь?)
Ни кто не призывает к слепому копированию, тщательный отбор и четкое обоснование, только после этого написание стандарта. Что-то вроде RFC — собирается кучка спецов и творят, результат выностится на всеобщее обсуждение. Некоторое время спустя, стандарт дорабатывается с учетом конструктивной критики и снова обсуждается, до тех пор пока не исчезнет конструктивная критика. После этого кандидат в стандарты можно начать использовать, а по прошествии некоторого времени вновь подвергнуть ревизии, с учетом практического опыта его использования.
Ш>API Win32
Если победит концепция виртуальных машин, то о WinAPI можно будет говорить только как о платформе для любительских поделок, а о людях пишущих на чистом API будут говорить как сейчас говорять об ASM программистах. (Сами АСМ программисты станут вообще легендой.)

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

L>либами в POSIX стандарте. Как MFC фактически служит промышленным станфартом для программирования UI под вынь сейчас, так и подобный стандарт мог бы стать универсальным стандартом в будущем.

L>Сиё очень-очень спорно батенька
Собственно что спорно, то что MFC, дефакто, стандарт для программирования под Win, или то, что MFC требует капитальной переработки и удаления некоторых частей кода, актуальных только для обеспечения обратной совместимости.

L>Давай!
Самому слабо, квалификация маловата, хотя с удовольствием принял бы участие в подобном проекте и как кодер, и как тестер. Что касается последнего, то есть хороший практический опыт подобной работы, правда не софтверных библиотек, а готовых приложений.

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

Ш>C RFC работаю плотно, знаю их не понаслышке -- это ещё хуже, чем POSIX. Что не удивительно. Банда отцов маньяков не способна породить ничего лучше, чем Фредди Крюгер.
Ш>Вообще, действительно хорошие технологии и идею, если вспомнить историю компьютерной индустрии, были плодом работы одного, в крайнем случае нескольких человек, тесно работавших вместе и, самое главное, не оглядовавшихся ни на что.
Не следует понимать мои слова буквально, я не призываю тащить POSIX или RFC в программирование для GUI. Я говорю только о необходимости критического анализа данной области человеческой деятельности. И опыт по написанию подобных стандартов есть, POSIX и RFC.
Отцы маньяки должны иметь нетривиальный опыт в данной предметной области, чтобы порадить что либо ценное. Одному человеку, чтобы сделать что-либо заметное, нужно иметь как минимум талант, а еще лучше — быть гением. Времена одиночек прошли. Люди, которых мы называем отцами основателями программирования — счастливчики, которым повезло оказаться в нужном месте в нужное время. Им выпало счастье творить, ни на кого не оглядываясь, и результат их работы был очень востребован. Сейчас все иначе, дистанция между теоретиками и практиками значительно больше, а все полезное, найденное в теории программирования далеко не сразу попадает в жизнь.

Ш>Я не верю в волшебные палочки. Место будет всему.
Как много ты знаеш проектов написанных на ASM? Я думаю, удельный вес таких проектов врядли перевалит за 5% от общей массы публикуемого софта. Я боюсь, что программирование с использованием системных вызовов (читай WinAPI) постигнет та же участь, его задавит рынок.

Здравствуйте, Аноним, Вы писали:

А>А я против, хотя у меня и стоит 2 диска по 120 гиг, добавлять допалнительную програмную прослойку я не хочу. Если раньше програмирование было трудным, но интересным делом, открывающим большой простор и для разработки и для оптимизации существующего кода, то теперь это просто шаманство какое-то. Запустил визард, он тебе сгенирил нечто, при достаточной доле везения и небольшой практике это можно заставить работать, но как это будет работать — отдельная история. Еще раз — даеш нетивный код, ламерам от программирования — смерть в корчах, программирование — высокое исскуство а не ремесло.

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

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

Ш>Здравствуйте, <Аноним>, Вы писали:

А>>Здравствуйте, Шахтер, Вы писали:

Ш>>>Только не так, как сделан POSIX. Чур чур меня. Эта недоделка не может быть образцом.
А>>(Ремарка: после стольких лет продвижения своих стандартов, мелкомягкие с гордостью заявили, что их новая ОС совместима со стандартом POSIX. Может не все так плохо, как ты говоришь?)

Ш>По поводу POSIX а. Это очень слабый прикладной интерфейс. WinAPI его перекрывает многократно. Его поддержка в Windows -- дань совместимости со старым кодом. Разрабатывать новый софт для виндом на POSIX е -- нонсенс.

Чем оно его перекрывает?
Количеством функций? Объёмом MSDN'а?
Да, POSIX не покрывает всех аспектов взаимодействия программы и API, но то, что он покрывает, он делает это вполне приемлимо. По крайней мере я бы предпочёл использовать классику, а не регулярно меняющиеся велосипеды от MS.

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

_>К чему такие воинственные кличи? Очень даже ремесло. А для идейных товарищей: приходим домой, берем банку пива и творим высокое искусство
Неделю назад закончил разгребать одно такое творение, очень хотелось напится.

Здравствуйте, Аноним, Вы писали:

А>Неделю назад закончил разгребать одно такое творение, очень хотелось напится.

Дык, в любом случае, виноваты ж не язык или платформа, а радиус кривизны рук ваятеля, ИМХО.

M>>XAML и будет, через два года.
А>А почитать об этом где нибудь можно?

Полная документация longhorn.msdn.microsoft.com
Статьи в более живом стиле в MSDN, в частности в MSDN Magazine за последние два месяца должно быть.

Ищи Longhorn и XAML, там уже много всего есть.

XAML и связанные с ним библиотеки разрывают MFC просто на 300 маленьких медвежат. По гибкости и стройности в десять раз круче. А по визуальным наворотам так вообще MFC рядом не паслось.


M>>Не нэтивного, а дотнетовского
M>>Нэтивные бинари скоро все отправятся "в страну Мальборо".
А>А я против, хотя у меня и стоит 2 диска по 120 гиг, добавлять допалнительную програмную прослойку я не хочу.

В следующей версии Windows, то есть через 2 года максимум, GUI будет чисто дотнетовским. Это означает, что нэтивные приложения как раз и будут работать "через прослойку".

Хотя Win32 будет работать, но окна "в стиле Win32" будут смотреться на фоне новых приложений как 16-битные окна в наше время.

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

Ш>По поводу POSIX а. Его поддержка в Windows -- дань совместимости со старым кодом.
Ш>
Где-то встречал версию, что его появление в NT — дань какому-то формальному требованию правительства. Не более. Кажется, у Соломона и Руссиновича, точно не помню.

Здравствуйте, mihailik, Вы писали:
M>XAML и связанные с ним библиотеки разрывают MFC просто на 300 маленьких медвежат. По гибкости и стройности в десять раз круче. А по визуальным наворотам так вообще MFC рядом не паслось.
Маленькая ремарка, чтобы не терять нить рассуждений: Изначально рассуждалось о необходимости унификации GUI API в принципе, не привязываясь к конкретным ОС. Основная мысь была в том, что было бы неплохо иметь универсальный API для написания GUI приложений под любую ось, реализующей данный стандарт в числе своих API.
Какой ценой эта красота будет достигнута? Ось прирастет еще на пару тройку сотен метров, принципиально не делая ничего нового. К сожалению MS уже давно не утруждает себя зачисткой кода, с этим, я думаю, согласятся многие, кто копался в кишках графической подсистемы винды. Кардинально, можно будет что-то улучшить, только отказавшись от обратной совместимости с версиями API ниже Win32. После подобной зачистки можно будет говорить о создании FrameWork для программирования под Win. (Глядишь и справка в VC будет отделена от пусть и очень ценных, но так иногда затрудняющих поиск, справочных статей.

M>В следующей версии Windows, то есть через 2 года максимум, GUI будет чисто дотнетовским. Это означает, что нэтивные приложения как раз и будут работать "через прослойку".
Выглядеть это будет несомненно красиво, чего у MS не отнимешь, так это в эффектности их творений. Если оглянуться назад: Какое расстояние между релизами ОС от мелкософта? От 3.11 до 95 — года 4-5, от 95 до 98 менее 2 лет, 98 — 2000 мене двух лет, 2000 до 2003 около года. Очень хочется надеятся, что с лонгхорном поступят иначе. Хочется надеятся, что весь код будет как следует проверен, и почищен от рудиментов прежних версий. Очень хочется надеятся, что все части ОС, критичные к безопасности машины и данных будет выверен и иправлен действительно профи высшего класса.
MS, к стати, могла бы выступить инициатором создания лицензионно чистого API подобного рода, и обеспечить его поддержку не на уровне мидлваре а на уровне ядра в своих ОС, что имело бы и коммерческий смысл для них самих.

M>Хотя Win32 будет работать, но окна "в стиле Win32" будут смотреться на фоне новых приложений как 16-битные окна в наше время, все зависит от того, какой ценой.
Народ уже сейчас наловчился делать свои окна похожими, хоть на XP, хоть на KDE, хоть на XFree, а если очень хочется,
то и ни на кого не похожими.

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

А>>Неделю назад закончил разгребать одно такое творение, очень хотелось напится.

_>Дык, в любом случае, виноваты ж не язык или платформа, а радиус кривизны рук ваятеля, ИМХО.

В VC такой ваятель не смог бы закончить свой гроб с музыкой, и у меня год спустя было бы меньше головняков с его творением. Одно из достоинств Студии от МS — достаточная жесткость к реализации программистких идей, что означает большее участие мозгов и в постановке задачи, и планировании ее реализации. Не в обиду дельфицам будет сказано, эта среда поощиряет делитанство и небрежность в реализации задания.

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

_>Дык, в любом случае, виноваты ж не язык или платформа, а радиус кривизны рук ваятеля, ИМХО.

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

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

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

_>>Дык, в любом случае, виноваты ж не язык или платформа, а радиус кривизны рук ваятеля, ИМХО.

К>По поводу радиуса кривизны... Получается, что чем прямее руки, тем шире обхват

ну это зависит от... ежели постулируем длину рук константной, то да. а ежели у нас еще и гибкость рук играет?
"жесткими" прямыми руками дерево хрен обхватишь а вот кривыми — так очень даже хорошо, ежели их радиус кривизны соответствует кривизне дерева %)

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

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

Это возвращает нас к спору о кривизне рук програмера.
Я не вижу не преодолимых трудностей для реализации подобной идеи. Если коротко о структуре:
1. Апи для взаимодействия с железом, через драйвер или на прямую. Назовем это к примеру кодеком, название не существенно.
2. Базовый объект: За основу имеет смысл взять такое понятие как обасть экрана. Событийная модель такого объекта, в первом приближении: получение, потеря фокуса ввода, обработчики клавиатуры и мыши, обработчик события отрисовки, сколеры, диспетчерезация событий для своих элементов. Более простая схема управления атрибутами элемента: что явно не переопределено, берется от элемента, владеющего данным. Сюда же можно встроить поддержку скинов, хотя и не обязательно именно здесь.
3. На основе этого класса строим базовые элементы интерфейса, будь то едиты, меню, статус бары, прогресс бары, статики, и что там еще, что я забыл.

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

Требования к реализации: Не использовать RTTI, по причине зависимости таких вещей от конкретных реализаций компиляторов, разными производителями. Не использовать системно, или аппаратно зависимых вещей, за исключением реализации кодеков.

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

Здравствуйте, <Аноним>, Вы писали:

А>Это возвращает нас к спору о кривизне рук програмера.
А>Я не вижу не преодолимых трудностей для реализации подобной идеи. Если коротко о структуре:
А>1. Апи для взаимодействия с железом, через драйвер или на прямую. Назовем это к примеру кодеком, название не существенно.

GDK

А>2. Базовый объект: За основу имеет смысл взять такое понятие как обасть экрана. Событийная модель такого объекта, в первом приближении: получение, потеря фокуса ввода, обработчики клавиатуры и мыши, обработчик события отрисовки, сколеры, диспетчерезация событий для своих элементов. Более простая схема управления атрибутами элемента: что явно не переопределено, берется от элемента, владеющего данным. Сюда же можно встроить поддержку скинов, хотя и не обязательно именно здесь.

Widget

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

Стандартные Widget-ы.

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

Не знаю как с этим в GTK. В QT наверняка что-то есть (но если и есть, то, видимо, гораздо слабее, чем в Виндах), KDE-шные части неплохо друг с другом интегрируются.

А>Требования к реализации: Не использовать RTTI, по причине зависимости таких вещей от конкретных реализаций компиляторов, разными производителями. Не использовать системно, или аппаратно зависимых вещей, за исключением реализации кодеков.

gobject — объекты на C. RTTI, наследование, и.т.д

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

Все это частично или полностью есть в GTK. Правда, он ограниченно кроссплатформенный. Под X-ы — стабильная версия, под Win32 — не очень.

Наверное, QT тоже все это более-менее реализует (не знаком).

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

WF>Здравствуйте, <Аноним>, Вы писали:
WF>GDK
Как насчет полноценного порта под Win, не притягивания за уши через cygwin, или WMVare, а именно полноценный порт на Win платформу, с оптимизацие для NT ядра?

WF>Не знаю как с этим в GTK. В QT наверняка что-то есть (но если и есть, то, видимо, гораздо слабее, чем в Виндах), KDE-шные части неплохо друг с другом интегрируются.
QT, насколько я знаю свободен, только под Никсы, плюс к этому даже под никсами он свободен только для программ с открытым исходным кодом (Читай: QT не является лицензионно чистым продуктом). Что касается KDE, опять же, вопрос в его присутствии под Win32 в виде порта, и я не очень помню лицензионное соглашение по KDE.

WF>gobject — объекты на C. RTTI, наследование, и.т.д
gobject — что за зверь?

WF>Все это частично или полностью есть в GTK. Правда, он ограниченно кроссплатформенный. Под X-ы — стабильная версия, под Win32 — не очень.
GTK,KDE,GNOME,Motif, если чего забыл — не обижайтесь , каждая из них имеет свои плюсы, но почему их так много? И кроме этого, каждая из них расчитана на присутствие в памяти системы специальной программы, а иногда и программ, предоставляющих к графической подсистеме компьютера, что для Win несколько странно. Вот и получается что кроссплатформенность этих библиотек ограничивается Никс системами.

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

LVV>Ага! А в Ява интерфейс как раз стандартизирован — целые тонны интерфейсных классов реализованы.
В начале разговора речь шла именно о средствах получения родного кода, без привлечения виртуальных машин, и прочей лабуды, лежащей между вашим кодом и процессором.
LVV>А стандартизация давно уже существует — только на юниксовых системах. Поищите ссылки по слову MOTIF — это как раз либа интерфейса — платформенно-независимого. Или в Яве посмотрите классы — она как раз на основе идеологии мотифа делалась.
Мотиф и иже с ним, требуют присутствия как минимум сервиса иксов, менеджера окон, а частенько и сервиса шрифтов, что для винды чуждо, по этой причине, говорить о кросплатформенности этих библиотек, в самом широком понимании этого слова, НЕ УМЕСТНО.
Те порты, ссылки на которые мне удалось найти, либо тащат за собой всю никсовую гвардию, либо базируются на MFC.

Здравствуйте, Аноним, Вы писали:

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

В любом случае что-то будет лежать, более- или менеевысокоуровненове.

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

M>В любом случае что-то будет лежать, более- или менеевысокоуровненове.
Одно дело — коллекция виджетов, из которой ты дергаеш нужный и адаптировал его под свои нужды и пользуеш, и совсем другое, когда ты виджет дернул, нужным образом его от родителей унаследовал, а система потом к каждому байту твоего кода приглядывается, прежде чем исполнить — тормаза.

Здравствуйте, <Аноним>, Вы писали:

WF>>GDK
А>Как насчет полноценного порта под Win, не притягивания за уши через cygwin, или WMVare, а именно полноценный порт на Win платформу, с оптимизацие для NT ядра?

Не понял, причем тут ядро. Я знаю QT и GTK. Оба под Винды идут.

GDK — это (наколько я понимаю) платформенно-зависимая либа, на которой GTK построен (что-то типа GDI).

На данный момент поддерживаются три backend-а — X11, linux frame buffer и Win32 (наверное, через GDI).

WF>>gobject — объекты на C. RTTI, наследование, и.т.д
А>gobject — что за зверь?

GNOME-овская разработка. GTK на нем построен.

А>GTK,KDE,GNOME,Motif, если чего забыл — не обижайтесь , каждая из них имеет свои плюсы, но почему их так много?

GNOME и KDE — это вообще-то десктопы, построенные на GTK и QT соответственно.

А много их потому, что все они имеют свои плюсы и минусы.

А> И кроме этого, каждая из них расчитана на присутствие в памяти системы специальной программы, а иногда и программ, предоставляющих к графической подсистеме компьютера, что для Win несколько странно.

Не понял. Ты о чем? В Виндах всеми этими кнопочками управляют такие же библиотеки, как и в случае с GTK. Просто они в систему встроены (в смысле, поставляеются с Виндами). А GTK-шные в виде отдельных .dll-ек идут.

А>Вот и получается что кроссплатформенность этих библиотек ограничивается Никс системами.

GTK под Виндами безо всяких Cygwin-ов идет. Dia (UML-рисовалка), Gimp (рисовалка), Glade (рисовалка интерфейсов, что-то типа RAD-ости для GTK) — вот некоторый набор GTK приложений под, идущих под Винды. Другое дело, что это мало кому нужно, поэтому версия GTK под Винды не очень-то и стабильна.

А>Изначально рассуждалось о необходимости унификации GUI API в принципе, не привязываясь к конкретным ОС. Основная мысь была в том, что было бы неплохо иметь универсальный API для написания GUI приложений под любую ось, реализующей данный стандарт в числе своих API.

XAML подходит под это определение, ага? В любой операционке, поддерживающей XAML можно использовать XAML — и притом везде единообразно!

Причём, широта распространения операционок, поддерживающий XAML, конечно, будет тотальной. 95% клиентских компьютеров или что-то в этом роде.


А>Какой ценой эта красота будет достигнута? Ось прирастет еще на пару тройку сотен метров, принципиально не делая ничего нового.

Делая, делая. Посмотри, что там заложено.

А> К сожалению MS уже давно не утруждает себя зачисткой кода, с этим, я думаю, согласятся многие, кто копался в кишках графической подсистемы винды.

Зачистка ради зачистки — просто плохой способ потратить деньги.

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

А тут без вариантов, только так. Другое дело, что профи высшего класса могут друг с другом не соглашаться. Что бы не сделали профи, если они из Микрософта — их будут ругать. Это традиция.


А>MS, к стати, могла бы выступить инициатором создания лицензионно чистого API подобного рода, и обеспечить его поддержку не на уровне мидлваре а на уровне ядра в своих ОС, что имело бы и коммерческий смысл для них самих.

Что такое "лицензионно чистое API"? Это означает, что API можно будет использовать/реализовывать бесплатно?

Скорее всего XAML будет стандартизован примерно таким образом. Это было бы в духе Микрософтовского отношения к .NET Framework.


M>>Хотя Win32 будет работать, но окна "в стиле Win32" будут смотреться на фоне новых приложений как 16-битные окна в наше время, все зависит от того, какой ценой.
А>Народ уже сейчас наловчился делать свои окна похожими, хоть на XP, хоть на KDE, хоть на XFree, а если очень хочется, то и ни на кого не похожими.

Ну да, пожалуйста. Так можно будет делать, но какой смысл? Назло кондуктору куплю билет и пойду пешком?