Сообщение Re[9]: До упора буду сидеть на семерке от 17.10.2023 12:46
Изменено 17.10.2023 13:32 Alekzander
Re[9]: До упора буду сидеть на семерке
Здравствуйте, Евгений Музыченко, Вы писали:
A>GUI-элементы от IE
Вот эта фраза меня смущает. Если это о контроле, который умел отображать HTML (WebControl), он был в единственном числе. У него даже был глобально уникальный идентификатор
А если это про HTML-разметку, то почему она "от IE"?
ЕМ>По-хорошему, MS следовало реализовать эти компоненты GUI на уровне того же COM/OLE просто в системе
Видимо, речь выше шла всё-таки про HTML-разметку. Тут я сразу оговорюсь, что спорить не буду, а просто объясню своё вИдение (кто-то согласится, кто-то нет, личное дело каждого).
Дело в том, что это две очень разные концепции — контролы и маркап.
Не было такого, что IE поддерживал крутые контролы, а WinAPI — нет. И HTML (как стандарт), и IE (как браузер) принципиально поддерживали очень маленький и очень бедненький набор контролов. Майкрософту нечего было реализовать "на уровне того же COM/OLE просто в системе". Кнопка, поле ввода, выпадающий список, обычный список — всё это в виндах и так было. А других контролов в HTML нет.
Маркап (HTML) позволяет создавать интерфейсы не в терминах контролов (у каждого из которых ограниченный набор свойств), а в терминах строительных кубиков и универсальных стилей, которые в принципе ничем не ограничены. Программист берёт те же самые div'ы, что и любой другой (и ещё он берёт текст, который тоже на всех один, но текст в HTML вообще явно не представлен, в частности каким-то тегом). И делает из них каждый своё. И если и берёт button, то только для семантики, технической необходимости в этом нет. На WinAPI аналогом такого подхода будет создать окно с пустым оконным классом, и делать всё руками. Разница в том, что в WinAPI тебе придётся весь внешний вид программировать кодом, а в разметке, как говорилось выше, есть универсальные стили, благодаря им интерфейс будет изолирован от кода. Например, сможешь подписаться на эвент нажатия, а как оно там будет отрисовываться, переливаться всеми цветами радуги, и даже грузить дополнительные материалы с сайта — это тебе в принципе не надо знать. С контролами так не сделать. Тем более, с тухлыми COM-контролами (COM-контролы это херово спроектированная сериализация плюс неотсоединяемые диалоги настроек, уезжающие в конечное приложении).
В IE очень рано сделали очень хорошую поддержку CSS, введя свойство filter, его функционал W3C-комитет потом годами, нет, десятилетиями, не мог догнать. С помощью этого filter (и блюренных масок) можно было, например, уже позже, во времена XP, реализовать поддержку всех тем, в частности трёх стандартных (blue, olive, silver), вообще ничего не меняя в приложении (IE имел проброску системных цветов в CSS).
Теперь про то, что мог и чего не мог Microsoft. Начнём с того, что поддержка маркапного (разметочного) подхода у них тоже появилась очень рано. Я говорю про язык разметки .rc, который компилировался в бинарную версию .res. Это был, конечно, амёбный уровень развития для разметок. Microsoft мог делать одно из трёх: либо до упора игнорировать подход с разметкой, оставаясь на контролах и давая программисту писать только .rc. Либо перевести интерфейс виндов на HTML. Либо сделать свой HTML. Все три подхода ничего хорошего Майкрософту не сулили. Если сидеть на контролах, писать будет неудобно. Если перейти на HTML, то зачем тогда клиентам вообще винды. А если сделать свой HTML, то как конкурировать со стандартом, который делает весь остальной мир?
В итоге, они пошли сразу по всем путям. Оставили контроло-ориентированный API как основной. Начали проталкивать диалоги на DHTML и приложения UPX (или как оно там называется, я эту херню принципиально проигнорил). А также сделали свой HTML под названием XAML. Собрали всё худшее отовсюду и в результате обосрались. Но я думаю, в этом нет большой их вины — если конкурировать честно (без EEE, за которое их вздрючили), выиграть у HTML было просто нельзя.
Ещё раз извиняюсь за то, что я не смогу эту тему поддерживать в будущем, писать долго приходится, у меня времени столько нет.
A>GUI-элементы от IE
Вот эта фраза меня смущает. Если это о контроле, который умел отображать HTML (WebControl), он был в единственном числе. У него даже был глобально уникальный идентификатор
А если это про HTML-разметку, то почему она "от IE"?
ЕМ>По-хорошему, MS следовало реализовать эти компоненты GUI на уровне того же COM/OLE просто в системе
Видимо, речь выше шла всё-таки про HTML-разметку. Тут я сразу оговорюсь, что спорить не буду, а просто объясню своё вИдение (кто-то согласится, кто-то нет, личное дело каждого).
Дело в том, что это две очень разные концепции — контролы и маркап.
Не было такого, что IE поддерживал крутые контролы, а WinAPI — нет. И HTML (как стандарт), и IE (как браузер) принципиально поддерживали очень маленький и очень бедненький набор контролов. Майкрософту нечего было реализовать "на уровне того же COM/OLE просто в системе". Кнопка, поле ввода, выпадающий список, обычный список — всё это в виндах и так было. А других контролов в HTML нет.
Маркап (HTML) позволяет создавать интерфейсы не в терминах контролов (у каждого из которых ограниченный набор свойств), а в терминах строительных кубиков и универсальных стилей, которые в принципе ничем не ограничены. Программист берёт те же самые div'ы, что и любой другой (и ещё он берёт текст, который тоже на всех один, но текст в HTML вообще явно не представлен, в частности каким-то тегом). И делает из них каждый своё. И если и берёт button, то только для семантики, технической необходимости в этом нет. На WinAPI аналогом такого подхода будет создать окно с пустым оконным классом, и делать всё руками. Разница в том, что в WinAPI тебе придётся весь внешний вид программировать кодом, а в разметке, как говорилось выше, есть универсальные стили, благодаря им интерфейс будет изолирован от кода. Например, сможешь подписаться на эвент нажатия, а как оно там будет отрисовываться, переливаться всеми цветами радуги, и даже грузить дополнительные материалы с сайта — это тебе в принципе не надо знать. С контролами так не сделать. Тем более, с тухлыми COM-контролами (COM-контролы это херово спроектированная сериализация плюс неотсоединяемые диалоги настроек, уезжающие в конечное приложении).
В IE очень рано сделали очень хорошую поддержку CSS, введя свойство filter, его функционал W3C-комитет потом годами, нет, десятилетиями, не мог догнать. С помощью этого filter (и блюренных масок) можно было, например, уже позже, во времена XP, реализовать поддержку всех тем, в частности трёх стандартных (blue, olive, silver), вообще ничего не меняя в приложении (IE имел проброску системных цветов в CSS).
Теперь про то, что мог и чего не мог Microsoft. Начнём с того, что поддержка маркапного (разметочного) подхода у них тоже появилась очень рано. Я говорю про язык разметки .rc, который компилировался в бинарную версию .res. Это был, конечно, амёбный уровень развития для разметок. Microsoft мог делать одно из трёх: либо до упора игнорировать подход с разметкой, оставаясь на контролах и давая программисту писать только .rc. Либо перевести интерфейс виндов на HTML. Либо сделать свой HTML. Все три подхода ничего хорошего Майкрософту не сулили. Если сидеть на контролах, писать будет неудобно. Если перейти на HTML, то зачем тогда клиентам вообще винды. А если сделать свой HTML, то как конкурировать со стандартом, который делает весь остальной мир?
В итоге, они пошли сразу по всем путям. Оставили контроло-ориентированный API как основной. Начали проталкивать диалоги на DHTML и приложения UPX (или как оно там называется, я эту херню принципиально проигнорил). А также сделали свой HTML под названием XAML. Собрали всё худшее отовсюду и в результате обосрались. Но я думаю, в этом нет большой их вины — если конкурировать честно (без EEE, за которое их вздрючили), выиграть у HTML было просто нельзя.
Ещё раз извиняюсь за то, что я не смогу эту тему поддерживать в будущем, писать долго приходится, у меня времени столько нет.
Re[9]: До упора буду сидеть на семерке
Здравствуйте, Евгений Музыченко, Вы писали:
A>GUI-элементы от IE
Вот эта фраза меня смущает. Если это о контроле, который умел отображать HTML (WebControl), он был в единственном числе. У него даже был глобально уникальный идентификатор
А если это про HTML-разметку, то почему она "от IE"?
ЕМ>По-хорошему, MS следовало реализовать эти компоненты GUI на уровне того же COM/OLE просто в системе
Видимо, речь выше шла всё-таки про HTML-разметку. Тут я сразу оговорюсь, что спорить не буду, а просто объясню своё вИдение (кто-то согласится, кто-то нет, личное дело каждого).
Дело в том, что это две очень разные концепции — контролы и маркап.
Не было такого, что IE поддерживал крутые контролы, а WinAPI — нет. И HTML (как стандарт), и IE (как браузер) принципиально поддерживали очень маленький и очень бедненький набор контролов. Майкрософту нечего было реализовать "на уровне того же COM/OLE просто в системе". Кнопка, поле ввода, выпадающий список, обычный список — всё это в виндах и так было. А других контролов в HTML нет.
Маркап (HTML) позволяет создавать интерфейсы не в терминах контролов (у каждого из которых ограниченный набор свойств), а в терминах строительных кубиков и универсальных стилей, которые в принципе ничем не ограничены. Программист берёт те же самые div'ы, что и любой другой (и ещё он берёт текст, который тоже на всех один, но текст в HTML вообще явно не представлен, в частности каким-то тегом). И делает из них каждый своё. И если и берёт button, то только для семантики, технической необходимости в этом нет. На WinAPI аналогом такого подхода будет создать окно с пустым оконным классом, и делать всё руками. Разница в том, что в WinAPI тебе придётся весь внешний вид программировать кодом, а в разметке, как говорилось выше, есть универсальные стили, благодаря им интерфейс будет изолирован от кода. Например, сможешь подписаться на эвент нажатия, а как оно там будет отрисовываться, переливаться всеми цветами радуги, и даже грузить дополнительные материалы с сайта — это тебе в принципе не надо знать. С контролами так не сделать. Тем более, с тухлыми COM-контролами (COM-контролы это херово спроектированная сериализация плюс неотсоединяемые диалоги настроек, уезжающие в конечное приложении). На всякий случай напишу: можно, конечно, упихать в контрол весь нужный функционал, включая переливание всеми цветами радуги и загрузку дополнительных материалов с сайта, но он от этого перестанет быть универсальным контролом, который можно поставлять с операционной системой.
В IE очень рано сделали очень хорошую поддержку CSS, введя свойство filter, его функционал W3C-комитет потом годами, нет, десятилетиями, не мог догнать. С помощью этого filter (и блюренных масок) можно было, например, уже позже, во времена XP, реализовать поддержку всех тем, в частности трёх стандартных (blue, olive, silver), вообще ничего не меняя в приложении (IE имел проброску системных цветов в CSS).
Теперь про то, что мог и чего не мог Microsoft. Начнём с того, что поддержка маркапного (разметочного) подхода у них тоже появилась очень рано. Я говорю про язык разметки .rc, который компилировался в бинарную версию .res. Это был, конечно, амёбный уровень развития для разметок. Microsoft мог делать одно из трёх: либо до упора игнорировать подход с разметкой, оставаясь на контролах и давая программисту писать только .rc. Либо перевести интерфейс виндов на HTML. Либо сделать свой HTML. Все три подхода ничего хорошего Майкрософту не сулили. Если сидеть на контролах, писать будет неудобно. Если перейти на HTML, то зачем тогда клиентам вообще винды. А если сделать свой HTML, то как конкурировать со стандартом, который делает весь остальной мир?
В итоге, они пошли сразу по всем путям. Оставили контроло-ориентированный API как основной. Начали проталкивать диалоги на DHTML и приложения UPX (или как оно там называется, я эту херню принципиально проигнорил). А также сделали свой HTML под названием XAML. Собрали всё худшее отовсюду и в результате обосрались. Но я думаю, в этом нет большой их вины — если конкурировать честно (без EEE, за которое их вздрючили), выиграть у HTML было просто нельзя.
Ещё раз извиняюсь за то, что я не смогу эту тему поддерживать в будущем, писать долго приходится, у меня времени столько нет.
A>GUI-элементы от IE
Вот эта фраза меня смущает. Если это о контроле, который умел отображать HTML (WebControl), он был в единственном числе. У него даже был глобально уникальный идентификатор
А если это про HTML-разметку, то почему она "от IE"?
ЕМ>По-хорошему, MS следовало реализовать эти компоненты GUI на уровне того же COM/OLE просто в системе
Видимо, речь выше шла всё-таки про HTML-разметку. Тут я сразу оговорюсь, что спорить не буду, а просто объясню своё вИдение (кто-то согласится, кто-то нет, личное дело каждого).
Дело в том, что это две очень разные концепции — контролы и маркап.
Не было такого, что IE поддерживал крутые контролы, а WinAPI — нет. И HTML (как стандарт), и IE (как браузер) принципиально поддерживали очень маленький и очень бедненький набор контролов. Майкрософту нечего было реализовать "на уровне того же COM/OLE просто в системе". Кнопка, поле ввода, выпадающий список, обычный список — всё это в виндах и так было. А других контролов в HTML нет.
Маркап (HTML) позволяет создавать интерфейсы не в терминах контролов (у каждого из которых ограниченный набор свойств), а в терминах строительных кубиков и универсальных стилей, которые в принципе ничем не ограничены. Программист берёт те же самые div'ы, что и любой другой (и ещё он берёт текст, который тоже на всех один, но текст в HTML вообще явно не представлен, в частности каким-то тегом). И делает из них каждый своё. И если и берёт button, то только для семантики, технической необходимости в этом нет. На WinAPI аналогом такого подхода будет создать окно с пустым оконным классом, и делать всё руками. Разница в том, что в WinAPI тебе придётся весь внешний вид программировать кодом, а в разметке, как говорилось выше, есть универсальные стили, благодаря им интерфейс будет изолирован от кода. Например, сможешь подписаться на эвент нажатия, а как оно там будет отрисовываться, переливаться всеми цветами радуги, и даже грузить дополнительные материалы с сайта — это тебе в принципе не надо знать. С контролами так не сделать. Тем более, с тухлыми COM-контролами (COM-контролы это херово спроектированная сериализация плюс неотсоединяемые диалоги настроек, уезжающие в конечное приложении). На всякий случай напишу: можно, конечно, упихать в контрол весь нужный функционал, включая переливание всеми цветами радуги и загрузку дополнительных материалов с сайта, но он от этого перестанет быть универсальным контролом, который можно поставлять с операционной системой.
В IE очень рано сделали очень хорошую поддержку CSS, введя свойство filter, его функционал W3C-комитет потом годами, нет, десятилетиями, не мог догнать. С помощью этого filter (и блюренных масок) можно было, например, уже позже, во времена XP, реализовать поддержку всех тем, в частности трёх стандартных (blue, olive, silver), вообще ничего не меняя в приложении (IE имел проброску системных цветов в CSS).
Теперь про то, что мог и чего не мог Microsoft. Начнём с того, что поддержка маркапного (разметочного) подхода у них тоже появилась очень рано. Я говорю про язык разметки .rc, который компилировался в бинарную версию .res. Это был, конечно, амёбный уровень развития для разметок. Microsoft мог делать одно из трёх: либо до упора игнорировать подход с разметкой, оставаясь на контролах и давая программисту писать только .rc. Либо перевести интерфейс виндов на HTML. Либо сделать свой HTML. Все три подхода ничего хорошего Майкрософту не сулили. Если сидеть на контролах, писать будет неудобно. Если перейти на HTML, то зачем тогда клиентам вообще винды. А если сделать свой HTML, то как конкурировать со стандартом, который делает весь остальной мир?
В итоге, они пошли сразу по всем путям. Оставили контроло-ориентированный API как основной. Начали проталкивать диалоги на DHTML и приложения UPX (или как оно там называется, я эту херню принципиально проигнорил). А также сделали свой HTML под названием XAML. Собрали всё худшее отовсюду и в результате обосрались. Но я думаю, в этом нет большой их вины — если конкурировать честно (без EEE, за которое их вздрючили), выиграть у HTML было просто нельзя.
Ещё раз извиняюсь за то, что я не смогу эту тему поддерживать в будущем, писать долго приходится, у меня времени столько нет.