Здравствуйте, Vladek, Вы писали:
V>Две познавательных ветки, рассказывающих нам про новые дотнетовские и нативные API в Window 8
Агония. Они просрали WPF (его до сих пор никто почти не использует + он НЕРЕАЛЬНО сложный и тормозной), просрали Сильвер (до сих пор используется практически только на МС-овских сайтах), XAML же оказался куда как менее удобен, чем HTML5+CSS3.
Сейчас DirectUI, WinRT...
Всё это фейл, это уже очевидно.
Микрософту нужно было полировать Win32 и ВСЁ, от них больше ничего не требуется. Win32 простудится на похоронах и WPF, и Сильвера, и нового барахла.
Две познавательных ветки, рассказывающих нам про новые дотнетовские и нативные API в Window 8: Win8 M3 (7955), Win8 (7989). А здесь статья с кучей других ссылок для дальнейшего изучения вопроса в ожидании конференции BUILD.
Вкратце, в Windows есть нативный движок/библиотека DirectUI (XP/7/8, dui*.dll или DirectUI*.dll в папке system32), который используется внутри Микрософта и по архитектуре очень похож на WPF — он так же поддерживает декларативное описание интерфейса. Судя по всему, именно он в облагороженном виде придёт на замену старого доброго лампового WinApi, кроме того он же будет использоваться и для дотнетовских приложений через управляемые обёртки. Возможно, совместимость на уровне исходников сохранится с чистыми WPF/Silverlight/XAML.
И помните, всё это пока на 99% гадание на кофейной гуще.
27.06.11 20:01: Перенесено модератором из '.NET GUI' — TK
Здравствуйте, dmitry_npi, Вы писали:
_>Здравствуйте, Vladek, Вы писали:
V>>Вкратце, в Windows есть нативный движок/библиотека DirectUI (XP/7/8, dui*.dll или DirectUI*.dll в папке system32), который используется внутри Микрософта и по архитектуре очень похож на WPF — он так же поддерживает декларативное описание интерфейса. Судя по всему, именно он в облагороженном виде придёт на замену старого доброго лампового WinApi, кроме того он же будет использоваться и для дотнетовских приложений через управляемые обёртки. Возможно, совместимость на уровне исходников сохранится с чистыми WPF/Silverlight/XAML.
_>Но зачем это нужно?(ну для native еще понятно) Но зачем .net приложениям использовать этот движок?
Вот статья, раскрывающая некоторые исторические детали о взаимоотношениях WinAPI и .NET.
Здравствуйте, Vladek, Вы писали:
_>>Но зачем это нужно?(ну для native еще понятно) Но зачем .net приложениям использовать этот движок?
V>Вот статья, раскрывающая некоторые исторические детали о взаимоотношениях WinAPI и .NET.
Это уже действительно новый API, не тот поверх которого WPF работает — milcore(или его псевдонимы).
There will be a new native user interface library, DirectUI, that builds on top of the native Direct2D and DirectWrite APIs that were introduced with Windows 7.
Это уже интересно если поверх D2D, DW.
В идеале еще бы DX12 выпустили в Win8, и следующую версию Direct2D сделали уже DX12. И хорошую .NET обертку вокруг DirectUI,Direct2D которую бы включили в состав NET 4.5 . Тогда бы в винде наступил графический рай, по сравнению с сегодняшним бардаком.
Здравствуйте, Mamut, Вы писали:
M> HL>Во-во. Одни теоретики там. Ничего даже отдалённо приближающегося по качеству к Cocoa (by Apple) там сделать не могут.
M> Как оказалось, в Cocoa нет даже layout'ов. Так что я бы сравнивал качество оооочень аккуратно.
И каким образом отсутствие лайаутов указывает на качество? Вот что точно указывает на качество, так это догфудинг, которого у МС в отношении WPF тю-тю. Впрочем, VS2010 использует, почему-то в перемешку с нативными контролами (шиза такая шиза) Даже Windows Media Center, для которого эта технология просто просится быть задействованной, ее не использует (хотя ранее, нам тут говорили обратное). В общем, все понятно и без слов Осиляторы, возрадуйтесь, скоро МС придумает для вас еще что нибудь новенькое
Здравствуйте, Klatu, Вы писали:
K>Не надо искать заговор там, где всё прекрасно объясняется глупостью. Ну и хорошая порция подковерной грызни, естественно.
Здравствуйте, x64, Вы писали:
x64>Нет. x64>Всё продумано. x64>Это стратегия такая. x64>Все подробности здесь.
Господи, да сколько можно Каждый второй считает своим священным долгом давать ссылку на Fire And Motion. Поднимает ЧСВ что-ли? А вообще — Б-А-Я-Н.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Новый WinAPI — WinRT (не только GUI, а похоже весь WinAPI собрались так переписывать), хоть написан на C++ но есть файлы метаданных *.WinMD . И эти файлы можно подключать к .NET проектам, типа автоматической генерации Interop кода.
Соответствено вопрос. Это что еще один способ взаимодействия Managed и Unmanaged кода придумали, в дополнение к Com,DllImport[] ?
Это только в Win8 , или я что-то пропустил и *.WinMD есть в Win7?
Здравствуйте, dmitry_npi, Вы писали:
_>Здравствуйте, Vladek, Вы писали:
V>>Вкратце, в Windows есть нативный движок/библиотека DirectUI (XP/7/8, dui*.dll или DirectUI*.dll в папке system32), который используется внутри Микрософта и по архитектуре очень похож на WPF — он так же поддерживает декларативное описание интерфейса. Судя по всему, именно он в облагороженном виде придёт на замену старого доброго лампового WinApi, кроме того он же будет использоваться и для дотнетовских приложений через управляемые обёртки. Возможно, совместимость на уровне исходников сохранится с чистыми WPF/Silverlight/XAML.
_>Но зачем это нужно?(ну для native еще понятно) Но зачем .net приложениям использовать этот движок?
ну так в дот-нете как раз с гуем проблема:
— winforms уже на момент создания был устаревшим, просто по быстрому слепили обертку вокруг win-api, соответственно любой шаг вправо-влево только через win-api, никакого декларативного гуи, все через код — ни нормальных биндингов, ни шаблонов\стилей — ничего, никакой переносимости на другие платформы итд.
— wpf, вроде бы концептуально все хорошо, но:
— тормозной и прожорливый до невозможности
— тулзовины для визуального редактирования гуя, скажем так, есть куда улучшать
— оказался сложноватым для простых разработчиков
— сильверлайт — фактически упрощенный WPF, все замечательно, но:
— работает только в песочнице, что не для всех приложений приемлемо
— кое-где слишком доупрощались, нет многих совершенно необходимых вещей — ручной отрисовки графики, нормального рич-текста, мульти-биндингов итд. И главное сэмулировать эти вещи с нормальной производительностью нельзя
— практически не используется хардверное ускорение графики, многие вещи которые на wpf летают, на сильверлайте практически не реализуемы
— опять же недоделанные тулзовины
HL>Во-во. Одни теоретики там. Ничего даже отдалённо приближающегося по качеству к Cocoa (by Apple) там сделать не могут. Что касается авалона, то первая мысль, когда я вижу корявое приложение с кривыми шрифтами и галимыми кнопками — тут пахнет авалоном.
Приглядываюсь к Apple, Cocoa. Смущает пока одно — отсутствие промышленной системы управления реляционными базами данных, наподобие SQL Server.
Ну и синтаксис Objective-C не очень воодушевляет.
Здравствуйте, iHateLogins, Вы писали:
HL>Здравствуйте, Vladek, Вы писали:
V>>Две познавательных ветки, рассказывающих нам про новые дотнетовские и нативные API в Window 8
HL>Агония. Они просрали WPF (его до сих пор никто почти не использует + он НЕРЕАЛЬНО сложный и тормозной), просрали Сильвер (до сих пор используется практически только на МС-овских сайтах), XAML же оказался куда как менее удобен, чем HTML5+CSS3.
о майн гат, хуже html+css ничего нет, а wpf сложный только на первый взгляд
Здравствуйте, iHateLogins, Вы писали:
HL>Во-во. Одни теоретики там. Ничего даже отдалённо приближающегося по качеству к Cocoa (by Apple) там сделать не могут.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Vladek, Вы писали:
V>>Рантайм новый — зачем?
НС>Это ты у себя спроси. НС>
НС>Новые управляемые интерфейсы Windows 8 завязаны на возможности C# 5.0 — вряд ли, это дело выпустят в виде сервис-пака.
Я ничего не утверждал про новый рантайм, я лишь спекулировал на тему смены версии компилятора. А смена версии не всегда означает развитие рантайма. Я не уверен, что новый компилятор выпустят в составе .NET 4.0 SP1, я предполагаю, что это будет .NET 5.0.
Здравствуйте, Vladek, Вы писали:
V>Вкратце, в Windows есть нативный движок/библиотека DirectUI (XP/7/8, dui*.dll или DirectUI*.dll в папке system32), который используется внутри Микрософта и по архитектуре очень похож на WPF — он так же поддерживает декларативное описание интерфейса. Судя по всему, именно он в облагороженном виде придёт на замену старого доброго лампового WinApi, кроме того он же будет использоваться и для дотнетовских приложений через управляемые обёртки. Возможно, совместимость на уровне исходников сохранится с чистыми WPF/Silverlight/XAML.
Но зачем это нужно?(ну для native еще понятно) Но зачем .net приложениям использовать этот движок?
Здравствуйте, dmitry_npi, Вы писали:
_>Но зачем это нужно?(ну для native еще понятно) Но зачем .net приложениям использовать этот движок?
А что .net приложениям использовать? WPF по какой-то шкале лежит ближе к HTML, как и IE+HTML не могут заменить WinAPI+GDI, так и WPF пока не может. А WinForms уже устарел, и продолжает стремительно устаревать.
Только вот будет ли новый API, или как сейчас — какие-то недокументированные dll'ки лежат для внутренего использования.
Хотелось бы чтобы он был тесно интегрирован с Direct2D/3D , т.е. чтобы можно было их использовать и напрямую.
WPF сам Direct использует (хотя и не очень эффективно), а программам не дает.
Вобщем как называют условно: WPF — Retained графикой, D2D — Immediate графикой.
Нужны и Immediate возможности для UI API.
Здравствуйте, dmitry_npi, Вы писали:
_>Здравствуйте, Vladek, Вы писали:
V>>Вкратце, в Windows есть нативный движок/библиотека DirectUI (XP/7/8, dui*.dll или DirectUI*.dll в папке system32), который используется внутри Микрософта и по архитектуре очень похож на WPF — он так же поддерживает декларативное описание интерфейса. Судя по всему, именно он в облагороженном виде придёт на замену старого доброго лампового WinApi, кроме того он же будет использоваться и для дотнетовских приложений через управляемые обёртки. Возможно, совместимость на уровне исходников сохранится с чистыми WPF/Silverlight/XAML.
_>Но зачем это нужно?(ну для native еще понятно) Но зачем .net приложениям использовать этот движок?
Сам не понимаю, если поглядеть эти сборки с описаниями типов из пространства имён Windows.UI.* (лежат в %WINDIR%\System32\WinMetadata в утекщих сборка ОС) — они по сути снова копируют API от WPF/Silverlight. Может быть, этот движок будет использоваться под капотом WPF, заменив собой прежнюю реализацию.
Здравствуйте, Silver_S, Вы писали:
S_S>Здравствуйте, Vladek, Вы писали:
S_S>Еще вот интересная информация: здесь
S_S>Новый WinAPI — WinRT (не только GUI, а похоже весь WinAPI собрались так переписывать), хоть написан на C++ но есть файлы метаданных *.WinMD . И эти файлы можно подключать к .NET проектам, типа автоматической генерации Interop кода. S_S> Соответствено вопрос. Это что еще один способ взаимодействия Managed и Unmanaged кода придумали, в дополнение к Com,DllImport[] ? S_S>Это только в Win8 , или я что-то пропустил и *.WinMD есть в Win7?
Здравствуйте, Silver_S, Вы писали:
S_S>>Еще вот интересная информация: здесь
S_S>Там хоть и написано: "ALL SPECULATION", но у него куча каких-то скриншотов с кодом.
Здравствуйте, Silver_S, Вы писали:
S_S>>Еще вот интересная информация: здесь S_S>Там хоть и написано: "ALL SPECULATION", но у него куча каких-то скриншотов с кодом.
Что-то смущает меня огромное наличие extern-ов. А как делать свои контролы? В них будут DependencyProperty из .Net? Не окажутся ли они в проигрышной ситуации по отношению к extern свойствам? Не окажется ли в итоге так, что контролы выгоднее писать в unmanaged, а для managed только обертками ограничиваться.
Здравствуйте, Vladek, Вы писали:
V>Это и есть COM, формат этих файлов стандартный.
Очень хорошо что они в Винде предустановлены по умолчанию. Значит и так дизайнить будут, чтобы косяков не было с .Net совместимостью (хоть и WinMD скорее всего автоматом генерятся). Если бы лежали всякие *.tlb , то это бы еще ни чего не гарантировало.
А то для Win7 уже 2 года пишут руками обертку "WindowsAPI CodePack", и до сих пор еще не все обернули и не все баги исправили, а в нем всего лишь DirectX и некоторые фичи Win7.
Они бы так могли бы и новый DirectX задизайнить, тогда бы все эти самоделки SharpDX,SlimDX,WinAPICodepack стали бы не нужны.
Здравствуйте, Silver_S, Вы писали:
S_S>Здравствуйте, Vladek, Вы писали:
S_S> А то для Win7 уже 2 года пишут руками обертку "WindowsAPI CodePack", и до сих пор еще не все обернули и не все баги исправили, а в нем всего лишь DirectX и некоторые фичи Win7.
Эта штука уже потихоньку перекочёвывает в WPF vNext — в Windows 8, например, класс WindowChrome уже встроен в WPF из .NET 4.5.
Здравствуйте, Vladek, Вы писали:
V>Эта штука уже потихоньку перекочёвывает в WPF vNext — в Windows 8, например, класс WindowChrome уже встроен в WPF из .NET 4.5.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, Vladek, Вы писали:
V>>Эта штука уже потихоньку перекочёвывает в WPF vNext — в Windows 8, например, класс WindowChrome уже встроен в WPF из .NET 4.5.
T>.NET 4.5
Ну пока там номинально всё та же версия 4.0, но вот номер ревизии вырос: 4.0.30319.225 -> 4.0.30319.16749.
Здравствуйте, iHateLogins, Вы писали: HL>Агония. Они просрали WPF (его до сих пор никто почти не использует + он НЕРЕАЛЬНО сложный и тормозной), просрали Сильвер (до сих пор используется практически только на МС-овских сайтах), XAML же оказался куда как менее удобен, чем HTML5+CSS3.
Да ладно
silverlight
Найдено 139 вакансий за месяц здесь
WPF
Найдено 192 вакансии за месяц здесь
HTML5
Найдено 94 вакансии за месяц здесь
HL>Микрософту нужно было полировать Win32 и ВСЁ, от них больше ничего не требуется. Win32 простудится на похоронах и WPF, и Сильвера, и нового барахла.
Я об этом говорил как только появились первые сведения о WPF, когда все были так оптимистично настроены, у некоторых аж дыхание захватывало: авалон, авалон, ах, авалон, технология будущего. А я прямо на их конференциях вопрошал: зачем мне авалон?!!! Сделайте нормальным WinForms и ADO.NET, а дальше страдайте фигнёй, какой пожелаете. Теперь я не верю больше MS, ничего стабильно и нормально работающего они сделать не могут. Ими там руководят Астронавты Архитекторы, по-видимому, не создавшие в своей жизни ни одного реального приложения.
Здравствуйте, khimiki, Вы писали:
HL>>Микрософту нужно было полировать Win32 и ВСЁ, от них больше ничего не требуется. Win32 простудится на похоронах и WPF, и Сильвера, и нового барахла.
K>Я об этом говорил как только появились первые сведения о WPF, когда все были так оптимистично настроены, у некоторых аж дыхание захватывало: авалон, авалон, ах, авалон, технология будущего. А я прямо на их конференциях вопрошал: зачем мне авалон?!!! Сделайте нормальным WinForms и ADO.NET, а дальше страдайте фигнёй, какой пожелаете. Теперь я не верю больше MS, ничего стабильно и нормально работающего они сделать не могут. Ими там руководят Астронавты Архитекторы, по-видимому, не создавшие в своей жизни ни одного реального приложения.
Во-во. Одни теоретики там. Ничего даже отдалённо приближающегося по качеству к Cocoa (by Apple) там сделать не могут. Что касается авалона, то первая мысль, когда я вижу корявое приложение с кривыми шрифтами и галимыми кнопками — тут пахнет авалоном.
HL>Во-во. Одни теоретики там. Ничего даже отдалённо приближающегося по качеству к Cocoa (by Apple) там сделать не могут. Что касается авалона, то первая мысль, когда я вижу корявое приложение с кривыми шрифтами и галимыми кнопками — тут пахнет авалоном.
Знаешь, когда они зарелизили свой WPF и я решил всё — таки взглянуть на него, то в начале даже не поверил, что это оно. Потом был шок и ощущение того, что они там посходили с ума. Подсунуть такое гов...ще и объявить ЭТО новой революционной технологией для создания пользовательских интерфейсов могли только постоянные пациенты американского жёлтого дома.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Vladek, Вы писали:
V>>Ну пока там номинально всё та же версия 4.0, но вот номер ревизии вырос: 4.0.30319.225 -> 4.0.30319.16749.
НС>Это просто будущий сервис-пак.
Новые управляемые интерфейсы Windows 8 завязаны на возможности C# 5.0 — вряд ли, это дело выпустят в виде сервис-пака.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Vladek, Вы писали:
V>>Новые управляемые интерфейсы Windows 8 завязаны на возможности C# 5.0
НС>В C# 5.0 будет только Async, который особо на управляемые интерфейсы не влияет, так как, по большому счету, просто синтаксический сахар.
Там как раз используются типы, которые за этой синтаксической глазурью скрываются.
Здравствуйте, Vladek, Вы писали:
V>Там как раз используются типы, которые за этой синтаксической глазурью скрываются.
Не понимаю. Что за типы и как они за асинком скрываются? Все влияние асинка на публичные контракты состоит в пометке асинк-методов специальным атрибутом. Все остальное — внутри методов. Ты считаешь, что добавление нового атрибута требует обязательной смены версии фреймворка?
Здравствуйте, iHateLogins, Вы писали:
HL>Во-во. Одни теоретики там. Ничего даже отдалённо приближающегося по качеству к Cocoa (by Apple) там сделать не могут. Что касается авалона, то первая мысль, когда я вижу корявое приложение с кривыми шрифтами и галимыми кнопками — тут пахнет авалоном.
Cocoa — это бледное подобие QT, если что.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Vladek, Вы писали:
V>>Там как раз используются типы, которые за этой синтаксической глазурью скрываются.
НС>Не понимаю. Что за типы и как они за асинком скрываются? Все влияние асинка на публичные контракты состоит в пометке асинк-методов специальным атрибутом. Все остальное — внутри методов. Ты считаешь, что добавление нового атрибута требует обязательной смены версии фреймворка?
Разве одного атрибута достаточно? Чтобы вся глазурь async/await работала, от типов требуется реализовывать метод GetAwaiter, который возвращает объект типа TaskAwaiter. Как для возможности использования foreach с типом нужно поддерживать IEnumerbale и GetEnumerator. Подробнее тут. Вот новые API этим соглашениям и соответствуют.
Здравствуйте, alexsoff, Вы писали:
A>Да ладно A>silverlight A>Найдено 139 вакансий за месяц A>здесь A>WPF A>Найдено 192 вакансии за месяц A>здесь A>HTML5 A>Найдено 94 вакансии за месяц A>здесь
Здравствуйте, Vladek, Вы писали:
V>Разве одного атрибута достаточно?
Для рантайма — достаточно.
V> Чтобы вся глазурь async/await работала, от типов требуется реализовывать метод GetAwaiter, который возвращает объект типа TaskAwaiter.
Не обязательно от типов, можно внешним классом.
V> Как для возможности использования foreach с типом нужно поддерживать IEnumerbale и GetEnumerator.
Здравствуйте, x64, Вы писали:
MM>>А вообще — Б-А-Я-Н. x64>Однако почему-то в этой теме люди об этом не знают.
Да знают. Но придерживаются иной точки зрения.
Здравствуйте, Vladek, Вы писали:
НС>>Для рантайма — достаточно.
V>О каком атрибуте вообще речь? Название его типа (из VS Async CTP SP1, а не из твоей головы) в студию. Рекомендую для чтения этот документ.
Я так понимаю, вопросов о необходимости нового рантайма для C# 5 больше нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Vladek, Вы писали:
НС>>>Для рантайма — достаточно.
V>>О каком атрибуте вообще речь? Название его типа (из VS Async CTP SP1, а не из твоей головы) в студию. Рекомендую для чтения этот документ.
НС>Я так понимаю, вопросов о необходимости нового рантайма для C# 5 больше нет?
Если он существует, расскажи и о нём. Итак, атрибут — какой? Рантайм новый — зачем?
Здравствуйте, Vladek, Вы писали:
НС>>Это ты у себя спроси. НС>>
НС>>Новые управляемые интерфейсы Windows 8 завязаны на возможности C# 5.0 — вряд ли, это дело выпустят в виде сервис-пака.
V>Я ничего не утверждал про новый рантайм, я лишь спекулировал на тему смены версии компилятора. А смена версии не всегда означает развитие рантайма. Я не уверен, что новый компилятор выпустят в составе .NET 4.0 SP1, я предполагаю, что это будет .NET 5.0.
Не не не. Ты утверждал, что новый API требует этого обновления. API, напоминаю, это не C#, это бинарный вещь. И захотят ли включить в W8 новый компилятор шарпа — большой вопрос. Во-первых с таймфреймами по обоим продуктам не все ясно, особенно касаемо дотнета — девдив характерен конкретными прощелками и по срокам и по фичам. Во-вторых, зная Синовского, можно с большой уверенностью утверждать, что при малейших сомнениях в готовности свежей версии фреймворка его выметут из винды поганой метлой в мгновение ока.
А то что наблюдается сейчас в подпольных альфах — это просто сервиспак, который сейчас фактически уже тестируется.
Ого веточка!
Т.е., если я правильно понял, Microsof наконец-то решило пожалеть юзеров нативного кода и открыть им доступ к Direct UI + XAML ?
Интересно, а MFC они реанимируют или похоронят окончательно?
Здравствуйте, 23W, Вы писали:
23W>Т.е., если я правильно понял, Microsof наконец-то решило пожалеть юзеров нативного кода и открыть им доступ к Direct UI + XAML ?
Пока что — только на уровне слухов. Часть, возможно, подтвердится на сентябрьской конференции — BUILD.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, 23W, Вы писали:
23W>>Т.е., если я правильно понял, Microsof наконец-то решило пожалеть юзеров нативного кода и открыть им доступ к Direct UI + XAML ? S>Пока что — только на уровне слухов. Часть, возможно, подтвердится на сентябрьской конференции — BUILD.
Спасибо, жду конференции...
Даже Windows Media Center, для которого эта технология просто просится быть задействованной, ее не использует (хотя ранее, нам тут говорили обратное). В общем, все понятно и без слов 
Осиляторы, возрадуйтесь, скоро МС придумает для вас еще что нибудь новенькое 
Каждый второй считает своим священным долгом давать ссылку на Fire And Motion. Поднимает ЧСВ что-ли? А вообще — Б-А-Я-Н.
