Компания Qt Company опубликовала релиз фреймворка Qt 6.5, в котором продолжена работа по стабилизации и наращиванию функциональности ветки Qt 6. В Qt 6.5 обеспечена поддержка платформ Windows 10+, macOS 11+, Linux (Ubuntu 20.04, openSUSE 15.4, SUSE 15 SP4, RHEL 8.4/9.0), iOS 14+, Android 8+ (API 23+), webOS, WebAssembly, INTEGRITY и QNX. Исходные тексты компонентов Qt поставляются под лицензиями LGPLv3 и GPLv2...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58911
После такого подлого и необоснованного бросания Win7, я больше не фанат qt. "Мы не работаем на M$", говорили они, одновременно проталкивая политику M$.
Для Win7 никто не мешает использовать Qt5. Qt6 вот только недавно по возможностям достиг паритета с Qt5. На Qt6 еще даже не переехали дистрибутивы линукс.
Типа ты думаешь кто-то специально будет делать версию своего продукт на Qt5 лишь бы удовлетворить их желаниям? Или ты думаешь Qt5 в окнах ставится глобально и все используют одни и те же либы? Нет так не будет.
Это я всё к чему пишу? Да к тому что обновляться надо чаще, а все десктоп приложения делать исключительно на электроне. Никакого другого пути нет, пора всем это уже давно понять.
Причем здесь желания? Многие еще не перешли на Qt6, т.к. линуксы не перешли, а Qt используют в первую очередь как раз для кроссплатформенности. Да и Qt6 вот только недавно достиг возможностей Qt5. Например QtTextToSpeech появился только в Qt 6.4.
При том что когда придет время они не будут у тебя спрашивать, а просто возьмут и перейдет на Qt6 тебя спрашивать не будут.
OBS. qBittorrent.
Transmission тоже, но они выпустили релиз специально на QT5
телеграм переехал, хотя им только в постсовке пользуются
Ага, особенно в постсоветской Индии, Латинской Америки и Германии)
>Для Win7 никто не заставляет (кроме жизни, рыночек порешал, хе-хе) использовать софт, перешедший на Qt6Как-то так.
а их должны парить проблемы форточников?особенно копролитной системы которая уже не поддерживается ни платно, ни бесплатно.
я уже молчу сколько процентов юзеров остались сидеть на семерке.
А сколько процентов юзеров остались сидеть на Убунту 10.04?
Илон Муск сидит и тойота тоже чай сидит, денюжку вносят исправно и воняют как пигмеи из «неправильных» юрисдикций на ворованной семерке.
https://www.reddit.com/r/teslamotors/comments/a1fln4/rooted_.../
И что кроме того что в тесле xfce ничего не понятно.
на семерочке сидит больше людей, чем на всех линуксах вместе взятых.Можно даже маки и бзд приплюсовать.
Готов согласиться. Только вчера мне рассказывали совершенно далёкие от IT люди что не будут ради свистоперделок ставить Диабло Ремастеред и ради него 10ю винду.
Для подкрепления твоих слов, анон: https://arstechnica.com/gadgets/2023/03/steam-will-end-suppo.../
Windows 7 still runs on more Steam PCs than every version of Linux combined.
>The main culprit, according to Valve, is the built-in Chromium-based browser that Steam actually uses to render the Steam store and other bits of the UI.злой_босс_выкидывает_из_окна_предложившего_выпилить_хром.jpg
стим сам отказывается от поддержки семерки со следующего года, так что в топку стим
>на семерочке сидит больше людей, чем на всех линуксах вместе взятых.А это удар ниже пояса. Но ответа аффтара не будет, ибо это ломает уютный маня-мирок мамкиного линаксойда.
> на семерочке сидит больше людей, чем на всех линуксах вместе взятых.Это пока. Как только последние браузеры прекратят её поддержку, она сразу уйдёт в забвение со своими 0.1% луддистов - побратимов тех кто до сих пор сидит на XP.
Зачем поддерживать ось, которую не поддерживает даже ее разработчик?
/me Наверно потому что её поддерживают клиенты.
Как клиент может поддерживать ОС?
Писать прикладной софт который будет запускаться и без проблем работать на этой ОС. Я лично в своих проектах поддерживаю даже Win95\98\Me.
Я тоже, но vcrt проблем доставляет.
Это не поддержка ОС. Ваш софт поддерживает ОС, но вы не занимаетесь поддержкой этой ОС.
По данным statcounter'а у win7 3.72% пользователей. Ради них стараться смысла нет. Вы еще о 0.4% пользователей winXP вспомните
Уже упоминалось: доля линуха ещё меньше. Зачем тогда его вообще поддерживают?
> доля линуха ещё меньшеДоля Линукса намного больше. Обычно на нем предустанавливают Firefox, у которого один встроенный переключатель превращает юзер-агент в виндовый.
> Зачем тогда его вообще поддерживают?
Чтобы у тебя подгорало, разумеется.
Обычно им пользуется 100 человек в природе и все они записаны где надо, потому эти же переключатели их выдали. Тем более есть линуксовые параметры, которые браузер не может поменять например он всегда сообщит что у пользователя иксы и этот параметр нельзя изменить без перекомпиляции браузера.
Ответ типичного линаксойда. Где пруфы Билли?
Совершенно не зачем. Кто программист - у того есть деньги на новейшее железо и новейшую ОС. Кто не программист - тот на милость программистов сдался, прикажут программисты купить новый комп - купит как миленький. Или придётся ему самомоу себе софт разрабатывать и компилять. Опенорсный, как бомжи на помойке. За разработку чужого проприетарного - без машины, квартиры, зарплаты и штанов останется.
Сам то понял что написал?
Пиши софт на TQt Trinity TDE.
> Win7На семёрке кто-то разве ещё сидит? Серьезно? Она же давно протухла и даже в интернет не позволяет ходить из-за того что не обновляются сертификаты.
Сертификаты спокойно скачиваются и кладутся в хранилище.
Вот и я удивляюсь что народ это как-то беспокоит. Не, у меня была проблема когда я кому-то XP ставил лет 10 назад и надо было дату переводить чтобы сертификаты дали винде установиться, но дальше уже проще.ЗЫ: в этот тред явно набегают какие-то щкольники и минусуют все адекватные посты. Рука-лицо...
Cемерка просто удобнее и эстетичнее выглядит, чем десятка и все последующее. На работе десятка - постоянно плююсь от совершенно дурацкого интерфейса, гораздо более тяжелого для визуального восприятия чем в семерке и XP.
К сожалению и линукс пошел тем же путем, систем со старым олдскульным GUI уже крайне мало осталось.
Исходный код полностью открыт. Никто, кроме твоей собственной лени, не мешает тебе самому пересобрать под любую платформу, хоть под Win95
> Никто, кроме твоей собственной лениТакие проекты это тысячи человекочасов. Сейчас не 95 год, энтузиасты, хакеры и прочие программисты-одиночки давно остались в прошлом.
Так и не нужно переписывать все тысячи человеко-часов. Достаточно изменить лишь некоторые специфические для windows8+ вызовы и поменять/удалить их, чтобы всё работало, как в предыдущей версии.
Дядя Вася, ты дурак? Выпускать ПО для ОС, которую официально дропнул производитель?
win7 помер, ура!
Что мешает собрать Qt6 для Windows 7? На сколько я помню MSVS2013 фреймфорк все еще собирается.
Тем более никто не мешает собрать Qt6 с помощью MinGW. И тем более сборки такие уже есть.
руко*опство им мешаета вот поныть - пожалуйста, им же все должны...
Не тупи, в Qt 6.x используются куски WinAPI от Windows 10. И это разбросано по разным модулям, например QtNetwork и прочее. Поэтому при попытке использовать на Windows 7 эти модули (или определенные методы из этих модулей) получишь шляпу.
Qt 6.x используются куски GLibC API, по твоей логике в Windows 10 эта версия Qt6 не будет работать. Да?Qt 4.5 использовались куски WinAPI от Windows 7. Но в Windows XP софт на QT4.5, в которых не использовались WinAPI6.2 (Win7) работал. И в Linux работал, и в MacOS X.
Что мешает софту сейчас работать?
> Qt 4.5 использовались куски WinAPI от Windows 7Не было такого. WinAPI от Windows 7 начали использовать в Qt 5.7 (или 5.6) и выше (ЕМНИП), поэтому Windows XP можно полноценно использовать с Qt <= 5.7 (или 5.6, не помню).
> Qt 6.x используются куски GLibC API,
Причем тут GLibC и Windows, болезный? Ты не путай теплое с мягким.
> Что мешает софту сейчас работать?
Я объяснил уже выше что мешает - новые функции из WinAPI, которых не было в старом WinAPI, не тупи.
> Причем тут GLibC и Windows, болезный? Ты не путай теплое с мягким.Болезный, это ты тут заявляешь, что из-за WinAPI от Win10 нельзя использовать в Qt6 в Win7. Так как же Qt6 в Linux работает (или у тебя не работает?) и как же Qt6 работает в винде, если в Qt6 есть GlibCAPI (или Qt6 в твоей реальности вообще нигде не работает)?
> Не было такого. WinAPI от Windows 7 начали использовать в Qt 5.7 (или 5.6) и выше (ЕМНИП)
Поддержка WSD появилась в Qt в версии где-то 4.5. WSD появилась в Vista. В ХPени этой xpени не было.
> новые функции из WinAPI, которых не было в старом WinAPI, не тупи.
Ну расскажи же тогда, где а Linux, MacOS, iOS и Android можно найти в принципе WinAPI? Qt6 в этих ОС работает. И надо же без WinAPI. А знаешь как это достигается? Макросами при сборке определяются части исходного кода, которые компилируются для каждой из ОС и их версий. На этапе конфигурации сборки определяешь макросы для каждой ОС:
На примере Windows.
#if defined(COMPILE_OS_WIN10)
<SOME_CODE_ONE>
#elif defined(COMPILE_OS_WIN6.3) or defined(COMPILE_OS_WIN6.2)
<SOME_CODE_TWO>
#if defined(COMPILE_OS_WIN6.1)
<SOME_CODE_THREE>
#else
<SOME_CODE_FOUR>
#endifСобственно говоря, так оно и делается при сборке Qt, когда из одних исходников собирают код по каждую ОС, которые между собой несовместимы.
Смотри офффорум Qt по теме "Qt Creator 6.0.1 and Qt 6.2.2 running on Windows 7"
>> Причем тут GLibC и Windows, болезный? Ты не путай теплое с мягким.
> Болезный, это ты тут заявляешь, что из-за WinAPI от Win10 нельзя использовать
> в Qt6 в Win7. Так как же Qt6 в Linux работает
> (или у тебя не работает?)Посмотрите сами, изучите вопрос, прежде чем обобщать частности.
В Linux Qt рисует на экране через XCB или Wayland (пока поддерживается оба варианта, но первый выкинут).
В Windows должно быть через GDI32/User32, эти части Win32 API менялись (добавлялось новое), о чём Вам и пишут.> и как же Qt6 работает в
> винде, если в Qt6 есть GlibCAPI (или Qt6 в твоей реальности
> вообще нигде не работает)?GLibC - это GNU C library? Оно вообще при чём?
Реализации стандартной библиотеки Си и Си++ в Windows свои.
> Посмотрите сами, изучите вопрос, прежде чем обобщать частности.Попробуйте прочитать написанное. Мне упорно доказывают, что из-за Win10Api Qt6 нельзя собрать для Win7. Я пишу, что МОЖНО СОБРАТЬ Qt6 без WinAPI.
> Реализации стандартной библиотеки Си и Си++ в Windows свои.
Еще и в Amdroid другая реализация. И в других ОС.
Еще раз попробуйте прочитать написанное! МНЕ ПИШУТ: "Нельзя собрать Qt6 для Win7 из-за Win10API". Я ПИШУ: "прекрасно собирают Qt6 для ОС, где нет WinAPI совсем, где полностью свои API, которых нет в Windows."
>> Посмотрите сами, изучите вопрос, прежде чем обобщать частности.
> Попробуйте прочитать написанное. Мне упорно доказывают, что из-за Win10Api Qt6 нельзя собрать
> для Win7. Я пишу, что МОЖНО СОБРАТЬ Qt6 без WinAPI.Приложения пользователя под операционными системами семейства Windows NT (в частности, бесяточка) работают через Win32 API *).
Собрать Qt6 без WinAPI можно, конечно, но в Windows оно не запустится.*) есть ещё NativeAPI, но здесь нет смысла это обсуждать.
> Приложения пользователя под операционными системами семейства Windows NT (в частности,
> бесяточка) работают через Win32 API *).
> Собрать Qt6 без WinAPI можно, конечно, но в Windows оно не запустится.Вопрос изначально был не о API в системах. Выше по ветке упорно доказывают, что собрать Qt6 без Win10API совсем нельзя. Однако, Qt6 собирают без WinAPI вообще для других ОС из одних и тех же исходниках.
Опции MinGW-GCC
--enable-threads=posix
--enable-threads=win32
по разному работают с потоками.
>> Приложения пользователя под операционными системами семейства Windows NT (в частности,
>> бесяточка) работают через Win32 API *).
>> Собрать Qt6 без WinAPI можно, конечно, но в Windows оно не запустится.
> Вопрос изначально был не о API в системах. Выше по ветке упорно
> доказывают, что собрать Qt6 без Win10API совсем нельзя. Однако, Qt6 собирают
> без WinAPI вообще для других ОС из одних и тех же
> исходниках.Изначальное сообщение ветки №2 -- "После такого подлого и необоснованного бросания Win7, я больше не фанат qt".
Далее начинают доказывать, что у кого-то руки растут не оттуда, потому не могут собрать.
Естественно, что все эти господа теоретики не смогли показать готовые примеры, как они это сделали. Потому что никто из них сам не пробовал.В сообщениях №147 и №170 появляется практик -- он или читал changelog, или смотрел код, как минимум -- и указывает причину несовместимости с Win7.
> Опции MinGW-GCC
> --enable-threads=posix
> --enable-threads=win32
> по разному работают с потоками.Не вижу связи с Qt под Win32 API. Заявлена поддержка MSVC.
> Далее начинают доказывать, что у кого-то руки растут не оттуда, потому не
> могут собрать.
> Естественно, что все эти господа теоретики не смогли показать готовые примеры, как
> они это сделали. Потому что никто из них сам не пробовал.Пример есть на офффоруме. Название темы я привел. Давать прямую ссылку на чужой форум в новостной теме - моветон.
> В сообщениях №147 и №170 появляется практик -- он или читал changelog,
> или смотрел код, как минимум -- и указывает причину несовместимости с
> Win7.Только показать ченджлоге или коде место, где сборка под Win7 невозможна, никто не может. А после соответствующей темы на форуме Qt, где это опровергают, еще и не будет.
> Не вижу связи с Qt под Win32 API. Заявлена поддержка MSVC.
Очень плохо, что вы связи не видите.
Обычно MinGW собирается только с включенным --enable-threads=posix, --enable-threads=win32 не включают. В makefile она по умолчанию в disable. Поддержку threads=win32, а так же Win32API осуществляет либа w32api. Данная либа до сих пор собирается под Windows7.
>> Не вижу связи с Qt под Win32 API. Заявлена поддержка MSVC.
> Очень плохо, что вы связи не видите.
> Обычно MinGW собирается только с включенным --enable-threads=posix, --enable-threads=win32Программисты для Windows обычно используют MSVC.
> не включают. В makefile она по умолчанию в disable. Поддержку threads=win32,
> а так же Win32API осуществляет либа w32api. Данная либа до сих
> пор собирается под Windows7.В Win32 API потоки создаются функцией CreateTread().
Qt именно её и использует.
Странно, что исходники Qt приходится смотреть мне, а не специалисту по её сборке.
/*
NOTE: we create the thread in the suspended state, set the
priority and then resume the thread.since threads are created with normal priority by default, we
could get into a case where a thread (with priority less than
NormalPriority) tries to create a new thread (also with priority
less than NormalPriority), but the newly created thread preempts
its 'parent' and runs at normal priority.
*/
#if defined(Q_CC_MSVC) && !defined(_DLL) // && !defined(Q_OS_WINRT)
# ifdef Q_OS_WINRT
// If you wish to accept the memory leaks, uncomment the part above.
// See:
// https://support.microsoft.com/en-us/kb/104641
// https://msdn.microsoft.com/en-us/library/kdzttdcb.aspx
# error "Microsoft documentation says this combination leaks memory every time a thread is started. " \
"Please change your build back to -MD/-MDd or, if you understand this issue and want to continue, " \
"edit this source file."
# endif
// MSVC -MT or -MTd build
d->handle = (Qt::HANDLE) _beginthreadex(NULL, d->stackSize, QThreadPrivate::start,
this, CREATE_SUSPENDED, &(d->id));
#else
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,
reinterpret_cast<LPTHREAD_START_ROUTINE>(QThreadPrivate::start),
this, CREATE_SUSPENDED, reinterpret_cast<LPDWORD>(&d->id));
#endif // Q_OS_WINRT
> Программисты для Windows обычно используют MSVC.Программисты для Windows много что используют. В том числе и MinGW, ICC, Dev-C++...
Или вы для Qt на оффсайте никогда не видели сборок на MinGW?> Qt именно её и использует.
А сборка для MinGW это знает? А сам MinGW это знает?
И почему же в MinGW прокатывает вызов sem_init() и pthread_mutexattr_settype() и не позволяет вызывать CreateSemaphore()?
>> Программисты для Windows обычно используют MSVC.
> Программисты для Windows много что используют. В том числе и MinGW, ICC,
> Dev-C++...У ICC заявлена совместимость с MSVC, т.е. он мало что меняет. А Dev-C++ это компилятор? Считаете это смешной шуткой?
> Или вы для Qt на оффсайте никогда не видели сборок на MinGW?
Не видел сборок для Win7.
>> Qt именно её и использует.
> А сборка для MinGW это знает? А сам MinGW это знает?
> И почему же в MinGW прокатывает вызов sem_init() и pthread_mutexattr_settype() и не
> позволяет вызывать CreateSemaphore()?Потому что Вы не смогли собрать под Win7 и занялись демагогией.
> А Dev-C++ это компилятор?Нет. Это IDE, в которой можно подключить Borland/Turbo C++.
Макрос Qt Q_CC_BOR о чем знаете?> Считаете это смешной шуткой?
Считаю. Реально смешно, что вы не можете найти макросы Q_CC_BOR.
Макроса для LCC (компилятора МЦСТ) нет.> У ICC заявлена совместимость с MSVC, т.е. он мало что меняет.
Так у него и совместимость с GCC заявлена. Для Linux есть сборки.
> Потому что Вы не смогли собрать под Win7 и занялись демагогией.
Я собрал Qt 6.0 RC для Windows7 вместе со сборкой poppler-qt6 и libmariadb-connector в статике. Из-за Poppler, пришлось собирать в MinGW. В целом сборка оказалась не нужной - в Qt6 есть нативная работа с PDF.
Сборки 6.2 собранная MSVC2013 (студия, появившаяся за два года минимум до выхода Win10) выложена одним из участников stackoverflow на его GDrive. Это информация доступна любому, кто способен гуглить.
>> А Dev-C++ это компилятор?
> Нет. Это IDE, в которой можно подключить Borland/Turbo C++.
> Макрос Qt Q_CC_BOR о чем знаете?Не имеет отношения к вопросу. Упорство в таких делах воспринимаю как демагогию.
>> Считаете это смешной шуткой?
> Считаю. Реально смешно, что вы не можете найти макросы Q_CC_BOR.
> Макроса для LCC (компилятора МЦСТ) нет.Печально, что Вы считаете подобную манипуляцию действенной.
>> У ICC заявлена совместимость с MSVC, т.е. он мало что меняет.
> Так у него и совместимость с GCC заявлена. Для Linux есть сборки.Вам необходимо и достаточно собрать для Windows.
>> Потому что Вы не смогли собрать под Win7 и занялись демагогией.
> Я собрал Qt 6.0 RC для Windows7 вместе со сборкой poppler-qt6 и
> libmariadb-connector в статике. Из-за Poppler, пришлось собирать в MinGW. В целом
> сборка оказалась не нужной - в Qt6 есть нативная работа с
> PDF.Подмена предмета обсуждения, версия 6.5 на 6.0.
> Сборки 6.2 собранная MSVC2013 (студия, появившаяся за два года минимум до выхода
> Win10) выложена одним из участников stackoverflow на его GDrive.Подмена предмета обсуждения, версия 6.5 на 6.2.
> Это информация доступна любому, кто способен гуглить.
Вы уже приводили ссылку, оставив фиаско без внимания.
Вместо подобных передёргиваний Вам стоило бы посмотреть в код, при чтении которого Вы ошиблись. №187 и №193. В ошибках нет ничего страшного. В отличии от выпадов с Q_CC_BOR.
> Печально, что Вы считаете подобную манипуляцию действенной.Печально, что вы не знаете для чего используются макросы.
> Подмена предмета обсуждения, версия 6.5 на 6.0.
Нет подмены. Официально не поддерживается сборка всей ветки Qt6 для Win7. Версия Qt6.5 кардинально не отличается от Qt6.0 RC в плане сборки.
> Подмена предмета обсуждения, версия 6.5 на 6.2.
С Вашей стороны подмена обсуждения Qt в целом на Qt6.5. Где в тексте для Qt6.5 сказано, что не поддерживается Windows 7? Где начале ветки упоминается Qt6.?
"Сами придумали, сами обиделись!" - Не в первый раз у вас. И чуть что не по вам, то вместо ответов - слив от от вас. Не надоело еще с темы на тему в одном обсуждении скакать?
>> Печально, что Вы считаете подобную манипуляцию действенной.
> Печально, что вы не знаете для чего используются макросы.Что бы показать их в коде сообщения №187 и EULA при прочтении сел в лужу? Вообще, конечно, это не было целью, нечаянно получилось.
>> Подмена предмета обсуждения, версия 6.5 на 6.0.
> Нет подмены. Официально не поддерживается сборка всей ветки Qt6 для Win7. Версия
> Qt6.5 кардинально не отличается от Qt6.0 RC в плане сборки.6.0 собрана, а 6.5 не собрана. И задача не просто собрать, а что бы оно запускалось, что бы импортируемые функции присутствовали в системе.
>> Подмена предмета обсуждения, версия 6.5 на 6.2.
> С Вашей стороны подмена обсуждения Qt в целом на Qt6.5. Где в
> тексте для Qt6.5 сказано, что не поддерживается Windows 7? Где начале
> ветки упоминается Qt6.?В шапке новости -- 6.5.
> "Сами придумали, сами обиделись!" - Не в первый раз у вас. И
> чуть что не по вам, то вместо ответов - слив от
> от вас. Не надоело еще с темы на тему в одном
> обсуждении скакать?Да всё по мне -- я показал фрагмент кода, Вы его прочесть не смогли, а теперь просто проецируете.
> Вообще, конечно, это не было целью, нечаянно получилось.Нечаянно в очередной раз сели в лужу.
Если бы вы знали понимали, что копипастите, то в лужу бы не сели.> Что бы показать их в коде сообщения №187 и EULA при прочтении сел в лужу?
Вы не знаете, для чего использую макросы, чтобы другой сел в лужу?
"Я ему гадил, но нечаянно свои штаны забыл снять!" - это эпично.> В шапке новости -- 6.5.
Ни в шапке, ни в самой новости нет ничего про отсутствие поддержки Windows7.
Получается, что это вообще только вы выдумали.> я показал фрагмент кода,
Который для WindowsRT и не собирается для Windows10 x86 32 и 64 bit.
С таким же успехом можно было привести код от GTK4.
"Нуачётакова! Код же есть." - звучит эпично.
>> Вообще, конечно, это не было целью, нечаянно получилось.
> Нечаянно в очередной раз сели в лужу.
> Если бы вы знали понимали, что копипастите, то в лужу бы не
> сели.
>> Что бы показать их в коде сообщения №187 и EULA при прочтении сел в лужу?
> Вы не знаете, для чего использую макросы, чтобы другой сел в лужу?
> "Я ему гадил, но нечаянно свои штаны забыл снять!" - это эпично.Есть гипотеза кроме луж, почему Вы упорно не видите моё сообщение №193? А №205?
Подозреваю, Вы их видите, но ответить не можете.>> В шапке новости -- 6.5.
> Ни в шапке, ни в самой новости нет ничего про отсутствие поддержки
> Windows7.
> Получается, что это вообще только вы выдумали.
>> я показал фрагмент кода,
> Который для WindowsRT и не собирается для Windows10 x86 32 и 64
> bit.
> С таким же успехом можно было привести код от GTK4.Ваше бы упорство, да направить на понимание кода.
Попробуйте ещё раз.
Вот фрагмент для WINRT:# ifdef Q_OS_WINRT
// If you wish to accept the memory leaks, uncomment the part above.
// See:
// https://support.microsoft.com/en-us/kb/104641
// https://msdn.microsoft.com/en-us/library/kdzttdcb.aspx
# error "Microsoft documentation says this combination leaks memory every time a thread is started. " \
"Please change your build back to -MD/-MDd or, if you understand this issue and want to continue, " \
"edit this source file."
# endifВот ещё кое-что:
#if defined(Q_CC_MSVC) && !defined(_DLL) // && !defined(Q_OS_WINRT)
...
#else
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,
reinterpret_cast<LPTHREAD_START_ROUTINE>(QThreadPrivate::start),
this, CREATE_SUSPENDED, reinterpret_cast<LPDWORD>(&d->id));
#endif // Q_OS_WINRT// - видите это в условии #if? Это называется комментарий, текст после него препроцессор пропускает. При автогенерации комментария к последнему #endif Qt Creator не учёл это и занёс туда Q_OS_WINRT.
> "Нуачётакова! Код же есть." - звучит эпично.
Эпично, что собранной Qt 6.5 до сих пор нет, а умелец собирать не смог прочитать пару #if-ов и не знает CreateThread().
> Вы упорно не видите моё сообщение №193? А №205?А что там надо увидеть?
Что вы не знаете, что код в остальной части этого же файла компилируется MinGW. Кроме этого больше там ничего нет.> а умелец собирать не смог прочитать пару #if-ов и не знает CreateThread().
В другой части года этого же файла есть pthread_mutexattr_settype() и что? Наверное, Windows - это Posix теперь, если компилируется MinGW.
Nooby, вы разве не видели, что копированный вами код внезапно есть и в Qt5?
qtbase/src/corelib/thread/qthread_win.cpp
В ревизии 558fc903acc610769279da2737ad679aa9fd728d от 28 января 2020 года.
https://github.com/qt/qtbase/commit/58c69df4d38324644bc49ec5...
Строка 133.
Но это версия Qt5.Я еще раз задаю вопрос, как же тогда MinGW вызывает потоки Windows, если в коде на C++ вызываются Posx- методы потоков? Ответ прост либа - w32api, которая является транслятором вызовов.
> Не видел сборок для Win7.
Опять вы сменили тему. Где в сборках для MinGW выполняется код с CreateThread()? ЭТО ЗАЯВИЛИ ВЫ! Так где он выполняется?
>> Вы упорно не видите моё сообщение №193? А №205?
> А что там надо увидеть?Там всё прекрасно написано, что надо увидеть. В предыдущем сообщении я повторял. Могу ещё раз скопировать, в надежде, что до Вас дойдёт его смысл:
# ifdef Q_OS_WINRT
// If you wish to accept the memory leaks, uncomment the part above.
// See:
// https://support.microsoft.com/en-us/kb/104641
// https://msdn.microsoft.com/en-us/library/kdzttdcb.aspx
# error "Microsoft documentation says this combination leaks memory every time a thread is started. " \
"Please change your build back to -MD/-MDd or, if you understand this issue and want to continue, " \
"edit this source file."
# endif...
#else
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,
reinterpret_cast<LPTHREAD_START_ROUTINE>(QThreadPrivate::start),
this, CREATE_SUSPENDED, reinterpret_cast<LPDWORD>(&d->id));> Что вы не знаете, что код в остальной части этого же файла
> компилируется MinGW. Кроме этого больше там ничего нет.В контексте Ваших гипотез по поводу --enable-threads=win32 интересны исключительно реализации QThread::start()
>> а умелец собирать не смог прочитать пару #if-ов и не знает CreateThread().
> В другой части года этого же файла есть pthread_mutexattr_settype() и что?Вышеприведённый код скопирован из src/corelib/thread/qthread_win.cpp
Вот ссылка на версию 6.5 https://github.com/qt/qtbase/blob/6.5/src/corelib/thread/qth...
там отсутствует pthread_mutexattr_settype()
Получается, Вы что-то путаете.
Хотя теперь я начинаю рассматривать версию, что намеренно лжёте.> Наверное, Windows - это Posix теперь, если компилируется MinGW.
Совершенно точно - в №147 шла речь о WinAPI. Qt с какой-то версии использует появившиеся в Windows 10 функции, и потому не работает в 7-ке.
> Nooby, вы разве не видели, что копированный вами код внезапно есть и
> в Qt5?
> qtbase/src/corelib/thread/qthread_win.cpp
> В ревизии 558fc903acc610769279da2737ad679aa9fd728d от 28 января 2020 года.
> https://github.com/qt/qtbase/commit/58c69df4d38324644bc49ec5...
> Строка 133.
> Но это версия Qt5.Конечно видел, я и копировал из 5й версии. И рядом написал, что в части создания потоков оно будет точно так же работать и в будущих Qt. Потому порекомендовал не отвлекаться на создание тредов, а наконец порадовать собранной Qt 6.5, работающей в Windows 7.
Если бы я копировал из версии 6.5, Вы бы увидели нижеследующий код и не генерировали удивительную гипотезу про WinRT.
#if defined(Q_CC_MSVC) && !defined(_DLL)
// MSVC -MT or -MTd build
d->handle = (Qt::HANDLE) _beginthreadex(NULL, d->stackSize, QThreadPrivate::start,
this, CREATE_SUSPENDED, &(d->id));
#else
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,
reinterpret_cast<LPTHREAD_START_ROUTINE>(QThreadPrivate::start),
this, CREATE_SUSPENDED, reinterpret_cast<LPDWORD>(&d->id));
#endif> Я еще раз задаю вопрос, как же тогда MinGW вызывает потоки Windows,
> если в коде на C++ вызываются Posx- методы потоков? Ответ прост
> либа - w32api, которая является транслятором вызовов.А если бы Вы посмотрели код и смогли бы его понять, Вы бы увидели. Попробуйте наконец. Видите там MinGW?
>> Не видел сборок для Win7.
> Опять вы сменили тему. Где в сборках для MinGW выполняется код с
> CreateThread()? ЭТО ЗАЯВИЛИ ВЫ! Так где он выполняется?Я уже подустал это копировать, но на всякий случай еще раз:
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,А так то тема "После такого подлого и необоснованного бросания Win7, я больше не фанат qt" (№2)
На что Вы ответили в №123 "Что мешает собрать Qt6 для Windows 7? ... тем более сборки такие уже есть."
Так что Вам надо показать такую сборку, а не отвлекаться на треды (тем более не понимая, как они создаются в Windows).
> Вот ссылка на версию 6.5Я вам ссылку привел туда же. Только для версии 5.13.
И кусок кода там был.Я вам задал вопрос. Перефразирую его: почему этот кусок кода не компилируется в MinGW, но все это прекрасно же работает в WinRT?
Но, почитав вас, ответа все равно не будет - чсв вам не позволит ответь правду.> Так что Вам надо показать такую сборку, а не отвлекаться на треды (тем более не понимая, как они создаются в Windows).
Я сборку с куском вашего кода показал - Qt 5.15.
Можете взять эту сборку: https://packages.msys2.org/base/mingw-w64-qt5-baseВот этот код
#if defined(Q_CC_MSVC) && !defined(_DLL) // && !defined(Q_OS_WINRT)
# ifdef Q_OS_WINRT
// If you wish to accept the memory leaks, uncomment the part above.
// See:
// https://support.microsoft.com/en-us/kb/104641
// https://msdn.microsoft.com/en-us/library/kdzttdcb.aspx
# error "Microsoft documentation says this combination leaks memory every time a thread is started. " \
"Please change your build back to -MD/-MDd or, if you understand this issue and want to continue, " \
"edit this source file."
# endif
// MSVC -MT or -MTd build
d->handle = (Qt::HANDLE) _beginthreadex(NULL, d->stackSize, QThreadPrivate::start,
this, CREATE_SUSPENDED, &(d->id));
#else
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,
reinterpret_cast<LPTHREAD_START_ROUTINE>(QThreadPrivate::start),
this, CREATE_SUSPENDED, reinterpret_cast<LPDWORD>(&d->id));
#endif // Q_OS_WINRT
из ревизии If61c206ee43ad1d97f5b07f58ac93c4583ce5620
Merge remote-tracking branch 'origin/5.15' into dev
Conflicts:
src/corelib/tools/qhash.h
src/gui/kernel/qevent.h
src/widgets/kernel/qshortcut.cpp
src/widgets/kernel/qshortcut.hChange-Id: If61c206ee43ad1d97f5b07f58ac93c4583ce5620
Qt Forward Merge Bot authored and Allan Sandfeld Jensen committed on Nov 25, 2019
Это даже не 5.15. Это Qt5.13https://github.com/qt/qtbase/blob/58c69df4d38324644bc49ec5f4...,endif%20//%20Q_OS_WINRT
Готовы заявить, что Qt5.13 на Windows 7 не работает?
Но вы так и заявите: "не важно, что было в 5.13. Важно, что в 6.5 он есть, а значит не работает. я доказывать ничего не буду, смотреть тоже ничего не буду. мне плевать на ваша слова, правду говорю только я. все остальные не достойны говорить правду"> Видите там MinGW?
Я в коде этого же файла вижу:
#include "qthread_p.h"> Попробуйте наконец. Видите там MinGW?
Попробуйте ответить на вопрос, почему работают в MinGW потоки в любой версии Window, если они вызываются только, если компиляция происходит MSVC, на что вы тут раз 10 указали?
Ответа не будет. В вашем мире сборки Qt6 для MinGW нет ни для какой версии Windows. И доказываете вы это кодом для Qt5.Все как обычно.
Осталось услышать от вас, что Поттеринг придумал Linux, так как в Linux есть SystemD.
>> Вот ссылка на версию 6.5
> Я вам ссылку привел туда же. Только для версии 5.13.
> И кусок кода там был.Вы привели ссылку на коммит, а не на файл. Там масса файлов, в том числе не имеющих отношения к созданию треда в Windows NT.
> Я вам задал вопрос. Перефразирую его: почему этот кусок кода не компилируется
> в MinGW, но все это прекрасно же работает в WinRT?Потому что Вы лжете. Директива препроцессора #error прерывает сборку.
# ifdef Q_OS_WINRT
...
# error "Microsoft documentation says this combination leaks memory every time a thread is started. " \
"Please change your build back to -MD/-MDd or, if you understand this issue and want to continue, " \
"edit this source file."
# endif> Но, почитав вас, ответа все равно не будет - чсв вам не
> позволит ответь правду.Я показал кусок, который компилируется MinGW:
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,Почему у Вас там не компилируется какие-то левые куски - это мне не очень интересно.
>> Так что Вам надо показать такую сборку, а не отвлекаться на треды (тем более не понимая, как они создаются в Windows).
> Я сборку с куском вашего кода показал - Qt 5.15.
> Можете взять эту сборку: https://packages.msys2.org/base/mingw-w64-qt5-baseВам надо показать сборку версии 6.5. И без Вас понятно, что старые версии собирались.
>> Попробуйте наконец. Видите там MinGW?
> Попробуйте ответить на вопрос, почему работают в MinGW потоки в любой версии
> Window, если они вызываются только, если компиляция происходит MSVC, на что
> вы тут раз 10 указали?
> Ответа не будет.Вопрос тут один: почему Вы так и не показали собранную 6.5. Вам он очень неудобен, потому Вы пытаетесь его заболтать.
А чем отличается макрос Q_CC_MSVC от _MSC_VER -- разбирайтесь сами, я не брался учить всех подряд.
> В вашем мире сборки Qt6 для MinGW нет ни
> для какой версии Windows.То есть Вы соврали в #123, заявив по поводу Qt6.5 из заголовка новости, цитирую: "И тем более сборки такие уже есть."
Наконец-то признали сами, полагаю, можно закончить.
> Вы привели ссылку на коммит, а не на файл. Там масса файлов,
> в том числе не имеющих отношения к созданию треда в Windows
> NT.То есть, если в коммите для Qt5.13 нужный кусок кода есть, то это не значит, что в самой версии 5.13 этот код есть?
В моем сообщении 208 я специально указал файл.
qtbase/src/corelib/thread/qthread_win.cpp
Специально для вас еще раз эту строку повторю.
qtbase/src/corelib/thread/qthread_win.cpp>> Я вам задал вопрос. Перефразирую его: почему этот кусок кода не компилируется
>> в MinGW, но все это прекрасно же работает в WinRT?
> Потому что Вы лжете. Директива препроцессора #error прерывает сборку.Почему вы лжете, когда говорите, что сборок MinGW для Winows10 нет?
> Я показал кусок, который компилируется MinGW:
Вы соврали! Вы лжец! Вы привели кусок
Вы привели ЭТОТ кусок кода:
#if defined(Q_CC_MSVC) && !defined(_DLL) // && !defined(Q_OS_WINRT)
...
#else
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,
reinterpret_cast<LPTHREAD_START_ROUTINE>(QThreadPrivate::start),
this, CREATE_SUSPENDED, reinterpret_cast<LPDWORD>(&d->id));
#endif // Q_OS_WINRT
Ваше сообщение 207? Или все должны сделать вид, что нужно забыть, что вы писали раньше?
В приведенном вами коде есть макрос
#if defined(Q_CC_MSVC)
Который говорит, что сборка идет в MSVC> Почему у Вас там не компилируется какие-то левые куски - это мне
> не очень интересно.О как! В официальных источниках, у вас левые куски кода?
Или для Вас макрос
#if defined(Q_CC_MSVC)
левый и на него смотреть не надо?Стоит ждать заявите, что # - это символ комментария.
> Вам надо показать сборку версии 6.5. И без Вас понятно, что старые
> версии собирались.Вы мне доказывали, что данный кусок кода есть только в Qt6. А теперь вы заявляете, что это были не вы!
> Вопрос тут один: почему Вы так и не показали собранную 6.5. Вам
> он очень неудобен, потому Вы пытаетесь его заболтать.Потому, что вы подменили вопрос по Qt6 на Qt5. Ни топикстартер ветки, ни автор новости не говорил про Qt6.5 в Windows7.
Топик стартер ветки говорил про Qt6. Ответ был про Qt6.> А чем отличается макрос Q_CC_MSVC от _MSC_VER -- разбирайтесь сами, я не
> брался учить всех подряд.Где вы нашли _MSC_VER? Его не было в кодах, которые вы приводили! Опять подменяете тему вопроса, чтобы не отвечать про то, что не знаете.
> То есть Вы соврали в #123, заявив по поводу Qt6.5 из заголовка
> новости, цитирую: "И тем более сборки такие уже есть."Цитату приведите, где я говорил про Qt6.5, не про Qt6, как писал топикстартер?
> Наконец-то признали сами, полагаю, можно закончить.Я рад, что вы признали, что вы врете, подменяете понятия, и ни в чем не разбираетесь.
Из-за этого вас из редось выперли?
Проигнорирую "содержательную" часть сообщения, на которое отвечаю, как его автор систематически поступал с моими.EULA в сообщении #123 заявил о возможности собрать обсуждаемую версию 6.5, цитирую:
> Что мешает собрать Qt6 для Windows 7?
> На сколько я помню MSVS2013 фреймфорк все еще собирается.
> Тем более никто не мешает собрать Qt6 с помощью MinGW.
> И тем более сборки такие уже есть.Работающих в Windows 7 cборок Qt 6.5 он показать не смог, неделю упражняясь в демагогии.
В сообщении №186 предоставил ссылку https://forum.qt.io/topic/133002/qt-creator-6-0-1-and-qt-6-2...
где удалось запустить Qt 6.2.2 в Windows 7.
Со слов автора, для этого потребовалось "топорно выдрать куски из старой версии" (Some hacking/backporting) [1].
То есть о сборке и речи нет.Хочу выразить благодарность EULA.
Теперь, помимо технических нюансов с Qt, у меня есть наглядный пример эксперта по Qt.[1] Today I spent some time debugging how much trouble it would be to make Qt 6.2.2 run on Windows 7. Turns on there are 3 showstoppers: qt6core.dll, qt6gui.dll and the platforms plugin qwindows.dll. Some hacking/backporting later I had new versions of them.
> Проигнорирую "содержательную" часть сообщения, на которое отвечаю, как его автор систематически поступал с моими.У вас привычка пенять на зеркало.
> EULA в сообщении #123 заявил о возможности собрать обсуждаемую версию 6.5, цитирую:
Любой политик нервно курит в сторонке от вашего умения врать. В вставленной вами цитате нет подстроки "6.5". Но вы в наглую заявляете обратное.
> для этого потребовалось "топорно выдрать куски из старой версии" (Some hacking/backporting) [1].
Бэккпорт переводится "обратное портирование". Почему-то в контексте ядра Linux эту фразу применяют когда хотят в более старой версии получить фишки из более новой. Но у вас с точностью наоборот.
Уже всем понятно, что врать вам не просто не стыдно, но весьма привычно.> Хочу выразить благодарность EULA.
> Теперь, помимо технических нюансов с Qt, у меня есть наглядный пример эксперта по Qt.Жаль, что у вас не появились знания по макросам компилятора.
Уймитесь уже со ссылкой ссылкой на устаревшую версию (Qt Creator 6.0.1 and Qt 6.2.2 running on Windows 7)
Я уже понял, что содержимое слишком сложно для Вас, потому приводит перевод в #213, повторю ещё раз:"топорно выдрать куски из старой версии" (Some hacking/backporting) [1].
То есть о сборке и речи нет.Ну и да. Жмякать жалобы, когда не можешь подтвердить своё заявление - так себе идея.
[1] Today I spent some time debugging how much trouble it would be to make Qt 6.2.2 run on Windows 7. Turns on there are 3 showstoppers: qt6core.dll, qt6gui.dll and the platforms plugin qwindows.dll. Some hacking/backporting later I had new versions of them.
Вы когда код цитируете, вы его читаете?#if defined(Q_CC_MSVC) && !defined(_DLL) // && !defined(Q_OS_WINRT)
# ifdef Q_OS_WINRTВам эти дефайны ничего не говорят?
Помимо Q_CC_MSVC там еще есть код, который компилируется Q_CC_GNU (GCC и MinGW), Q_CC_CLANG (CLANG, что собственно и говорит из названия). И даже макрос поддержки кода для Borland C++ есть Q_CC_BOR.Q_OS_WINRT А этот макрос вообще для Windows RT. Приведенный вами фрагмент вообще не собирается для Windows x86.
> Вы когда код цитируете, вы его читаете?
> #if defined(Q_CC_MSVC) && !defined(_DLL) // && !defined(Q_OS_WINRT)
> # ifdef Q_OS_WINRT
> Вам эти дефайны ничего не говорят?Говорят, что дальше Вы не смогли прочитать. Попробуйте ещё раз, для начала:
# ifdef Q_OS_WINRT
// If you wish to accept the memory leaks, uncomment the part above.
// See:
// https://support.microsoft.com/en-us/kb/104641
// https://msdn.microsoft.com/en-us/library/kdzttdcb.aspx
# error "Microsoft documentation says this combination leaks memory every time a thread is started. " \
"Please change your build back to -MD/-MDd or, if you understand this issue and want to continue, " \
"edit this source file."
# endif> Помимо Q_CC_MSVC там еще есть код, который компилируется Q_CC_GNU (GCC и MinGW),
> Q_CC_CLANG (CLANG, что собственно и говорит из названия). И даже макрос
> поддержки кода для Borland C++ есть Q_CC_BOR.Что-то Вы забыли привести этот код. Наверное, потому что он плохо вписывается в Вашу гипотезу про --enable-threads=win32
#else
// MSVC -MD or -MDd or MinGW build
d->handle = CreateThread(nullptr, d->stackSize,
reinterpret_cast<LPTHREAD_START_ROUTINE>(QThreadPrivate::start),
this, CREATE_SUSPENDED, reinterpret_cast<LPDWORD>(&d->id));> Q_OS_WINRT А этот макрос вообще для Windows RT. Приведенный вами фрагмент вообще
> не собирается для Windows x86.Ещё раз. В Win32 API нет другого способа создать тред, кроме как CreateThread (точнее, NtCreateThread, если не считать пула потоков, о котором MinGW знает вряд ли больше здешних экспертов). И всё это не имеет отношения к вопросу. Эта часть Qt должна собираться и работать и в будущих версиях. Проблемы с теми частями Qt, что завязаны на новые возможности Win32 API.
Надеюсь, ссылка пройдет модерацию.
https://forum.qt.io/topic/133002/qt-creator-6-0-1-and-qt-6-2...Не желаете признать свою неправоту?
> Надеюсь, ссылка пройдет модерацию.
> https://forum.qt.io/topic/133002/qt-creator-6-0-1-and-qt-6-2...И что же он там собрал? Выложил 3 dll в архиве для замены.
Some hacking/backporting later I had new versions of them.
When I replaced both Qt Creator's dlls in C:\Qt\Tools\QtCreator\bin and the qwindows.dll in C:\Qt\Tools\QtCreator\bin\plugins.\platforms, voila!
> Не желаете признать свою неправоту?
Пока лень вникать в тему.
hskoglund
8 февр. 2023 г., 06:37@dmginc Still on my beloved Win7, couldn't get Qt Creator 9 to run.
crystalidea
2 дня назадany update on Qt 6.5?
> any update on Qt 6.5?Сборку под Windows 7 официально для всей Qt6 не поддерживают.
>> any update on Qt 6.5?
> Сборку под Windows 7 официально для всей Qt6 не поддерживают.Напомню: Вы пытаетесь доказать, что собрать можно.
> Напомню: Вы пытаетесь доказать, что собрать можно.Именно так.
Собрать можно. Официальная техническая поддержка разработчиком не оказывается, и разработчик собирать не будет. Противоречия нет.
Вы же не будете отрицать, что Qt3 можно собрать для современных дистрибутивов Linux?
>> Напомню: Вы пытаетесь доказать, что собрать можно.
> Именно так.
> Собрать можно. Официальная техническая поддержка разработчиком не оказывается, и разработчик
> собирать не будет. Противоречия нет.
> Вы же не будете отрицать, что Qt3 можно собрать для современных дистрибутивов
> Linux?Вы сейчас пытаетесь переложить бремя доказательства на оппонента.
Доказывайте сами.
Пока не видно подтверждений гипотезе из №123, цитирую: "тем более сборки такие уже есть".
> Доказывайте сами.Что доказывать?
Что в приведенном вами примере есть только часть кода под макросом Q_CC_MSVC, а остальная часть собирается любым другим компилятором, а не только MSVC?Я вам задал вопрос: "Макрос Qt Q_CC_BOR о чем знаете?" Что вы ответили? Что ничего не знаете. Если бы вы знали, то не ответили бы "не имеет отношения". Ведь макросQ_CC_BOR означает "Defined if the application is compiled using Borland/Turbo C++." Точно так же макрос Q_CC_MSVC означает
"Defined if the application is compiled using Microsoft Visual C/C++, Intel C++ for Windows."
Если имя макроса определено ранее в операторе #define, то последовательность операторов, стоящих между #ifdef и #endif, будет компилироваться.Еще и макрос для WinRT ВЫ привели для WIN32. Ваше сообщение 187? Ничего, что API WINRT отличается от Win10? Или вам и тут все равно? И лишь бы попытаться с умничать?
>> Доказывайте сами.
> Что доказывать?
> Что в приведенном вами примере есть только часть кода под макросом Q_CC_MSVC,
> а остальная часть собирается любым другим компилятором, а не только MSVC?Что собирается и работает.
> Я вам задал вопрос: "Макрос Qt Q_CC_BOR о чем знаете?" Что вы
> ответили? Что ничего не знаете.Мне не требуется вообще отвечать. Не я доказываю, что оно собирается и работает.
> Если бы вы знали, то не
> ответили бы "не имеет отношения". Ведь макросQ_CC_BOR означает "Defined if the
> application is compiled using Borland/Turbo C++." Точно так же макрос Q_CC_MSVC
> означает
> "Defined if the application is compiled using Microsoft Visual C/C++, Intel C++
> for Windows."
> Если имя макроса определено ранее в операторе #define, то последовательность операторов,
> стоящих между #ifdef и #endif, будет компилироваться.Для доказательства Вы можете собрать любым удобным компилятором. По моему опыту, Борлданд использовать вообще не стоит, разве что хотите усложнить задачу.
> Еще и макрос для WinRT ВЫ привели для WIN32. Ваше сообщение 187?
> Ничего, что API WINRT отличается от Win10? Или вам и тут
> все равно? И лишь бы попытаться с умничать?Вы код из №187 не поняли, поскольку не дочитали, либо последнее
#endif // Q_OS_WINRT
ввело в заблуждение по проводу ветки #else.
О чём я уже сообщал в №193.
Если не понятно, то под Q_OS_WINRT оно вообще не соберётся, если не отредактировать - и про это явно указано в комментариях.
Хорошо допустим собрать ты сможешь, но работать то оно не будет.
В MSys2 работает в сборке MinGW64 и MinGW32 на Windows 7. (Там есть еще сборка UCRT64, которая не должна работать.)
Если у одних работает, а у других не работает, значит проблема у тех, у кого не работает. Не?
Всё мешает. Винда это не прыщи - там каждый софт свой Qt6 тащит. В т.ч. и проприетарный.
Ну, что там тащит другой софт - это зависит от разработчика этого конкретного софта. И тогда он решает какие ОС поддерживать. Можно и на Qt5 можно и на Qt5 написать софт и заявить, что поддерживается только Windows 11.
> После такого подлого и необоснованного бросания Win7Это не Qt бросил, а MinGW (ну и msys уже должен подтянуться)! Cygwin в ближайшее время тоже бросит win7.
Т.е. перед Qt возник выбор - старый gcc (а вообще-то нужны новые стандарты c++) или win10.
А на Расте можно делать приложухи на Qt? Есть рабочие примеры? Я не троллю, правда интересно.
Есть биндинги к культям, легко гуглятся.
видел биндинг на Go -- традиционно последний коммит n years ago
Нет, на расте можно писать только на переписанных либах, так что жди пока rustQt допишут. Там уже немного осталось, думаю к 2077 допишут как раз.
Аккурат к полной готовности Wayland.
Slint как раз сегодня в 1.0 вышел.
Поехавший да? Надо сначала Qt переписать на раст чтобы было точно безопасТно.
Там же все небезопасно на дырявом С++. Сначала ПЕРЕПИШИ на расте этот тулкит, потом делай приложухи на нем и расте.
Rust-Qt или rust-ui-qmetaobject (тут уж кому что больше нравится).Но, нужно ли? Есть же и другие тулкиты. См. https://www.areweguiyet.com/ и https://dev.to/davidedelpapa/rust-gui-introduction-a-k-a-the... там есть и вполне самобытные GUI-фреймворки, для простых приложений с основными контроллами их может быть более чем достаточно.
Спасибо
> Я не троллюДа.
Я не знаю что там qt6 но KDE с каждой версией нормальной так деградирует в плане интерфейса.
> Я не знаю что там qt6 но KDE с каждой версией нормальной
> так деградирует в плане интерфейса.Только из-за qml, в остальном лучше. Что хуже, так это пакеты типа plasma-welcome и завязки на гном.
только из-за кривых рук разрабов KDE, которые умудряются на qml такое вырвиглазие делать. хотя они qml пользовались ещё до qt5, когда он в принципе неюзабелен был
> только из-за кривых рук разрабов KDE, которые умудряются на qml такое вырвиглазие
> делать. хотя они qml пользовались ещё до qt5, когда он в
> принципе неюзабелен былНа примере настроек оконного менеджера версия до qml была очень норм.
kde всегда был и всегда будет вырвиглазным, смирись, qt здесь ни при чём
Ну так поставь KDE 0.0.0.1 версии, самую развитию версию, где нет ни капли деградации и радуйся.
У тебя шутки, такие же как и твое имя, хреновые. Хотя да, первые версии КДЕ, тогда ещё просто k-deektop повторяя один в один windows 95, действительно удобнее современной плазмы.
И это было правильно.
Где тебе тут шутка померещилась, если ты сам пишешь
>>первые версии КДЕ, ... действительно удобнее
Вот и поставь себе первую версию и пользуйся, кто тебе мешает?
Монстр для Enterprise. Для моих поделок хватает imgui.
Будешь смеяться, но энтерпрайз сидит либо в браузерах\электронах\reactnative или что ещё чаще на Tcl/Tk
Не, самый настоящий энтерпрайз сидит на Java.
На C++ и NDK в отдельной, особо-засекреченной репе. А Java - лишь обёрткой
Тоже ImGui использую. Для всего хватает, и оно для моих систем намного лучше, чем Qt.
Видовое разнообразие — хорошо. На этом хорошее в Qt заканчивается: толстый, неповоротливый, раздутый. В общем, красивый.
Обьясните раку, почему кинули Win7? не просто с голослосными заявлениями, а с реальными фактами.
А зачем тебе устаревшая Ось от корпорации Зла? Купи новый компьютер и использую Линукс.
а есть кто готов оплатить поддержкку 7ки? не 200 евро заслать, а реально все оплатить? Видимо нет.
Ёптель, потому что в Windows 8,10, появилось новое WinAPI, которого нет в Windows 7. Например для работы с Bluetooth LE, сетью и другими шнягами. Поэтому Windows7 в утиль, кому не нравится, сами пачте сорцы и пересобирайте, это опен сурс.
Потому что семёрку не поддерживает производитель и она официально объявлена устаревшей и не актуальной. Сейчас её доля около 3%, через год-два будет едва ли 1%. Семёрка вышла почти 15 лет назад, блин, я за это время 3 раза женился, 2 раза развёлся, родил 3 детей и переехал в ЕС... а сколько раз апгрейдил железо и не счесть.
А я застал те времена когда народ с windows 98 никуда не собирался переходить и cpались с мажорами с хр. До сих пор, кстати, некоторые на форумах пытаются выжить на 98 в 2023 году.
Ну на Win9x вполне можно работать, а не просто выживать. С одним "но" - если не требуются браузеры, свежие игры и работа с видео. Осенью бывал на студии звукозаписи где до сих пор сидят на Windows 2000, а знакомый фрилансер ради интереса целый месяц работал в Adobe Illustrator 9.0 + Windows 98 и делал арты не хуже чем в современных версиях.
Работает лучше современного гимпа? Я тут пару типичных psd попробовал открыть, зрелище весьма печальное. Одно "но", типичные psd это разрешение порядка 15k и тысяча слоёв. Не хуже… Это говорит только о привычном уровне. Всё-таки, технологии шагнули вперёд весьма ощутимо, так что ты весьма приукрасил.
ил это вектор
Я примерно в курсе, да и разрешение там было 16 на 16 пикселей. Просто такая казалось бы примитивная задача как нарисовать и обработать картинку на деле не такая примитивная. И да, можно наглядно видить, как качество цифровых артов шагнуло семимильными шагами в будущее за какие-то 10 лет.
оно просто стало массовымтот компьютер по производительности, который в компании могли 10-15 лет назад предоставить проф-дизайнеру, сейчас у каждой домохозяйки и школьника. Куча туториалов в ютубе и курсов для "мамкиных-дизайнеров" в онлайн/оффлайн. Ну позволяют современные программы наинающим дизайнерам получить по техническому уровню картинки заметно выше чем программы старых версий и в ресурсах сейчас ограничений старых нет. Но технический уровень это только часть дела, художественный то уровень программа тебе не подтянет...
> семимильными шагами в будущее за какие-то 10 летвот научат AI рисовать руки не с 6ю пальцами и третью ногу когда перестанет дорисовывать и оставит половину графических дизайнеров без работы... :)
> оставит половину графических дизайнеров без работыНе оставит. Просто будут другие ценности, такие как ручная работа, ведь дизайнер вкладывает душу в свое творение. Хотя будут и те кому нужен будет тупо результат без разницы как достигнутый - это и будут основные клиенты AI.
> это и будут основные клиенты AI.и их будет много
в итоге если в конторе было 3 дизайнера, то останется один, что может в творчество для этой ручной работы, а остальные на мороз
>Работает лучше современного гимпа?Объективно, все эти гимпы, криты и инкскейпы - мусор. Из профессионалов никто их не использует и даже не знают о существовании таковых. P.S. Профессионал - от слова профессия, т.е. люди которые зарабатывают на этом деньги.
Ну так исторически сложилось, что что Эпл и Аддобе идут в связке. А потом Аддобе стал индустриальным стандартом. Это не значит что перечисленные тобою прям хуже что невозможно работать. Многие знают про альтернативы.
это на территории эксСССР не знают.я помню как подгорело у местных виндузятников когда статистику со стима выложили по тем программам которые установлены у обычных домашников. Дак либраофис оказалось популярнее мелкоофиса, а гимп популярнее фотошопа...
Это у нас [s]привыкли тырить мелочь по карманам[/s] на рутрекере винду ультимейт качать и обязательно распоследний фотошоп чтоб пдыщик для вконтакика подмазать на фоточке
Ну, не то, чтобы мусор, но попросили тут срочно накидать лого - сделал в ФШ 7 векторами. Пришёл с PSD, а там линукс - ну, ок - открыли критой. И ничего. Редактировать нельзя. Оказывается, в ней хоть и есть свои векторы, но чужие отредактировать нельзя. Вот и всё, приехали.
Так что, да. Не для прода.
> сделал в ФШ 7 векторами. Пришёл с PSD, а там линукспросто гениально!
но виноват, конечно, крита/гимп...
> Всё-таки, технологии шагнули вперёд весьма ощутимо, так что ты весьма приукрасил.Ага, раньше не писали музыку на ПК и не делали иллюстрации, не обрабатывали фото. Таблетки прими чтоль.
То, что раньше считалось ок, сегодня просто уровень гаража с бомжами. Да и старые продукты той же адобы это багованное нечто. Такие баги так долго висели, что диву даёшься, как они умудрялись это впаривать.
Adobe всегда была, есть и будет багованным нечто. Она м сецчас такая же, как во времена Вин95, ничего не поменялось. Фирма так работант, ничего не поделаешь...
У гимп и нет полной поддержки psd например помню нет градиентов у слоёв, который ФШ нормально работают. У гимпа свой формат.
> Сейчас её доля около 3%В абсолютных цифрах это прорва народу.
Никто не кинул, просто сборку официальную не сделали. Запрета сделать свою на MSVC15 или MinGW никто вносил.
> на MSVC15Не думаю, что мне нужен компилятор (да и ввобще любые средства разработки от его поставщика), который полагает, что переменная цикла после выхода из последнего не определена, а тип double не может быть счетчиком цикла ... ну и т.д.
Тогда Вам пригодиться компилятор GCC от MinGW.
Да, именно им и пользуюсь. Спасибо.
> Да, именно им и пользуюсь. Спасибо.Тогда у Вас вообще проблем особых нет.
Кстати, MinGW for Windows поставляется в составе комплекта Qt.
С одним уточнением. Даже с двумя.
1. Это только один из вариантов поставки. Так же есть варианты поставки для MSVS разных более-менее актуальных версий.
2. MinGW там слегка ущербный. Некоторые кроссплатформенные проекты на нем не собираются. Например connector-mariadb.
Уважаемые коллеги, не обессудьте за вопрос. Как так получается, что гном на ужастном GTK4, который сломал все что только можно и под который надо переписывать все с нуля, давным давно вышел, а KDE под великолепный Qt6, почти полностью совместимый с Qt5, для перехода с которого достаточно поправить пару строчек в манифесте, все еще нет? Ведь GTK4 релизнулся даже позже Qt6.
> поправить пару строчек в манифестеЭто не так. Объектную модель придется пересмотреть и заменить deprecated функции. Даже в рамках минорных версий несовместимость может случаться. Работы много.
Ответ тривиальный, ты бы и сам легко догадался. У гномеров как? Тяп-ляп и GNOME 4 готов. Половину функций выкинули, другой половины там никогда и не было. А KDEшники - люди серьёзные. Они сперва Plasma 5 допиливают, чтобы потом проще портировать было. А когда уже основная масса кода готова, они переходят на Qt6. Осталось ещё чуток подождать.
КДЕшники такие серьезные что фирменная фишка КДЕ это падение плазмы.
У кого падает плазмы, интересно какой дистрибутив используют?, либо kwin путают с плазмой, кwin бывает падает когда кучу левых плагинов наставить, но подгружается за пару секунд, так что бы совсем упала в окно входа в систему, такого не было ни разу.
Кому нужна пятая плазма на шестых кутях?
Проблема непонятна. Если о прикладных решениях - включаешь в сборку все используемые файлы фреймворка (как под Linux, так и под Windows), скажем, Qt 5.12, и поставляешь в комплекте. Если функциональность устраивает, нет необходимости переписывать приложение, и работать под любой версий ОС будет долго еще. Решения для автоматического равертывания доступны.
Одна среда рабочего стола, один фреймворк. Чтобы не было что харды. Вышла новая версия фреймворка, все обновились, у все все работает. Никаких проблем.