Здравствуйте, kov_serg, Вы писали:
_>Но главными источниками засад идут C++ Qt6 и браузеры всякие flutter-ы
Разработчик linuxdeployqt придерживается политики, что должно работатать как минимум на самой старой Убунте с длительной поддержкой:
Please run on a system no newer than the oldest still-supported Ubuntu LTS release.
Здравствуйте, Skorodum, Вы писали:
_>>Но главными источниками засад идут C++ Qt6 и браузеры всякие flutter-ы S>Разработчик linuxdeployqt придерживается политики, что должно работатать как минимум на самой старой Убунте с длительной поддержкой: S>
S>Please run on a system no newer than the oldest still-supported Ubuntu LTS release.
А с какой вообще целью они вообще меняют номер версии Если раньше номер версии означал качественное изменение, то теперь просто знаменует годы выхода и дату устаревания.
Здравствуйте, kov_serg, Вы писали:
_>А с какой вообще целью они вообще меняют номер версии Если раньше номер версии означал качественное изменение, то теперь просто знаменует годы выхода и дату устаревания.
А что такое "качественное изменение"?
Здравствуйте, Евгений Музыченко, Вы писали:
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 было просто нельзя.
Ещё раз извиняюсь за то, что я не смогу эту тему поддерживать в будущем, писать долго приходится, у меня времени столько нет.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему именно с ReactOS, а не с XP или 2k?
Пожалуй вставлю сюда свои 5 копеек: если говорить про Visual Studio, то для полноценной компиляции под XP (независимо от сервиспаков) придется использовать очень древний тулсет "Visual Studio 2008 (v90)". Более свежий "Visual Studio 2015 — Windows XP (v140_xp)", совместим только с XP SP3.
Здравствуйте, Alekzander, Вы писали:
A>Ещё раз извиняюсь за то, что я не смогу эту тему поддерживать в будущем, писать долго приходится, у меня времени столько нет.
Впрочем, ладно. Есть время, нет время — как же не оседлать любимого конька. Готов, в общем, со своей стороны поддерживать эту тему сколько потребуется.
А пока добавлю ещё кое-что про контролы. С моей точки зрения, контролы всегда были очень плохим решением для UI. Легче всего показать это на следующем примере. Была такая библиотека — MFC. На ней писали приложения типа Блокнота или Ворда — создал документ, отредактировал документ, сохранил документ, открыл документ, снова отредактировал. (И ещё распечатал документ — тогда это было актуально). MFC предлагала удобную абстракцию — представление документа. Как в таких случаях поступал нуб, соблазнившись визивигом? Он выбирал представление на основе диалогового окна (дай бог памяти, CFormView это называлось). Это представление умело грузить форму из ресурсов, а в ресурсах её можно было редактировать визуально, набрасывая на неё контролы. Особенно часто этим грешили дельфишники, у которых идеология контролов была возведена в абсолют (вплоть до невизуальных контролов).
Я помню гениев, которые писали приложение для (условно) картографии с задачей коммивояжёра, и для того, чтобы сделать многоточечный маршрут, натурально создавали во всех возможных точках маршрута радиобаттоны. Кликая по которым, юзер описывал граф. И дополнительную информацию (поверх карты) они тоже выводили, сделав отдельный контрол. Кстати, ActiveX-контрол. Кто работал с ActiveX, тому, наверно, уже смешно, как всё это работало. Градиенты в альфа-канале особенно. Если кому-то не смешно, предлагаю подумать, какой комбинацией контролов можно реализовать представление вордовского документа. (Если самому писать, а не брать готовый у Майкрософта, как сделал я, приспособив для этого браузер).
В общем, контролы у представлений-монолитов просасывали со страшной силой. Если создать требовалось высококачественное приложение без компромиссов между "хочу" и "могу", требовалось взять базовый класс CView и пилить всё самому, от A до Я, утрясая порядок отрисовки разных данных в разных режимах. Но, к сожалению, монолит имеет и свои недостатки. Монолитное представление быстро превращалось в неконтролируемо разраставшийся файл от десятков тысяч строк, в котором трудно разобраться.
HTML же (как яркий представитель маркапной парадигмы) позволяет взять лучшее от обоих подходов. Можно обходиться без контролов, соответственно, не имея проблем с тем, как одни данные отображаются поверх других, или произвольно вкладывая разные части интерфейса друг в друга. И при этом — никакого многотонного файла-всемогутора. Это происходит в том числе за счёт стилей, например, определяющих порядок отрисовки. Разные режимы отображения могут просто опираться на разные наборы стилей. И так далее.
Не знаю, понятно ли получилось написать. Для понимания крайне желателен бэкграунд в виде работы над интерфейсами, когда ты не можешь отмахнуться от требований "сделать как у Майкрософт", просто налепив говноконтролов на форму.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, kov_serg, Вы писали:
_>>А с какой вообще целью они вообще меняют номер версии Если раньше номер версии означал качественное изменение, то теперь просто знаменует годы выхода и дату устаревания. S>А что такое "качественное изменение"?
Это означало что новое апи не совместимо со старым. Например было 16бит segmented, стало 32бит flat.
Здравствуйте, drVanо, Вы писали:
ЕМ>>Почему именно с ReactOS, а не с XP или 2k?
V>Пожалуй вставлю сюда свои 5 копеек: если говорить про Visual Studio, то для полноценной компиляции под XP (независимо от сервиспаков) придется использовать очень древний тулсет "Visual Studio 2008 (v90)". Более свежий "Visual Studio 2015 — Windows XP (v140_xp)", совместим только с XP SP3.
Здравствуйте, Marty, Вы писали:
M>Ну это да. А нет варианта канпелять нормальным свежим компилятором, а линковать старым линкером?
Насколько я помню более свежий тулсет (даже "Visual Studio 2010 (v100)") начинает пихать в прогу EncodePointer и DecodePointer из kernel32, которые появились только в SP2. Поэтому приходится сидеть на старье.
V>its official windows xp without any service packs.
V>for some reasons we can not update it.
Очень сильно подозреваю, что "some reasons" — что-то вроде религиозного убеждения. Ну, или у них какой-то критичный софт от разработчика с подобными убеждениями. Еще ни разу не слышал, чтоб кому-то приходилось использовать XP именно в голом виде. Наоборот, многие продукты явно требуют SP3, что ни разу не удивительно.
Здравствуйте, drVanо, Вы писали:
V>Насколько я помню более свежий тулсет (даже "Visual Studio 2010 (v100)") начинает пихать в прогу EncodePointer и DecodePointer из kernel32
Сам тулсет не пихает ссылок непосредственно на системые функции — только на собственные библиотечные. Соответственно, при желании их можно переписать без этих функций, или реализовать недостающие функции у себя.
Если раньше номер версии означал качественное изменение, то теперь просто знаменует годы выхода и дату устаревания.
