Qt 6 замаячил на горизонте

плазма больше не будет падать? а если серьезно, то перепишут на qt6, в остальном будет как с 5.x.

плазма больше не будет падать?

Речь всё ещё идёт о кедах?

Рабов чего?

Ты знаешь ответ.

Я знаю, что ты поехавший.

Блин, пятые кеды только только стали юзабельными =)

UPD. Грёбанные некропостеры.

А вот и злой раб возмутился.

И всё же на вяленном он у меня перестал падать относительно недавно.

Раб охвесов? Это ты намекаешь, что в кедах нет вменяемого охвесного пакета и поэтому они нужны?

Грёбанные некропостеры

На себя пОсмОтри.

15 несовместимых стандартов?
или шутка не к месту?

Выше, по линии обсуждения, обсуждалась нужность кутей в чём-то кроме кед.

тут не к месту. Qt это не GTK. С выходом новой версии старую закапывают и не используют.

И при чём тут твоя картинка и рабы?

4.2, я с год-два назад откопал полезную софтину на Qt3, а hobbit портировал её на Qt4.

а hobbit портировал её на Qt4.

но зачем на Qt4???

Видимо, через специальную либу для этого.

но зачем на Qt4???

Затем, что так проще. У них был специальный конвертер, позволяющий переносить на Qt4 малой кровью с добавлением модуля Qt3Support. После того, как программа заработала, классы из этого модуля можно потихоньку переделывать на родные из Qt4 - и после того, как от Qt3Support ничего не останется, полученный исходник с довольно большой вероятностью будет универсальным как для Qt4, так и для Qt5 (исключения - QtWebkit и Phonon). Qt4 и Qt5 с точки зрения торчащих наружу классов достаточно близки, там нет антагонизма.

Я уже говорил, что у меня в DoubleContact ровно две условные компиляции на весь проект, чтобы оно работало в 4 и 5 (это другой проект, не тот, про который bodqhrohro_promo написал).

Qt 6, детали о котором будут объявлены в этом году.

Что-то маловато у них времени осталось до конца года :)

А нафига нам кутя в отрыве от окошечек и кед?

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

P.S. Да-да, я знаю, что ты паскаль любишь. Базовые библиотеки для него и впрямь хорошо переносимы, но для того, чтобы написать на паскале что-то большое и переносимое, таки придётся велосипедить. Т.е. если мне понадобится библиотека доступа к большому количеству медиаформатов, скорее всего, потребуется наворачивать биндинги к ffmpeg. А в кресты ffmpeg и без биндингов отлично линкуется. А уж если мне OpenCV понадобится... у...

Так что по универсальности кресты рулят, при всех своих недостатках. А для них лучше Qt я ничего не видел, пока ещё.

P.P.S. Вот тут недавно очередная версия Hedgewars вышла. Программе 13 лет, автор паскаль явно знает, ядро программы на нём всю жизнь писалось и пишется. Так зачем ему при этом понадобился фронт-енд на Qt? (Я ответа не знаю, если что, можешь поинтересоваться у автора, но явно причины были.)

Читай текст выше.

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

Так и напиши что для винды, потому что в линуксе с кутей боль - для запуска/сборки таких «кроссплатформенных» приложений постоянно требуют не ту версию что есть в наличии.

Т.е. если мне понадобится библиотека доступа к большому количеству медиаформатов, скорее всего, потребуется наворачивать биндинги к ffmpeg. А в кресты ffmpeg и без биндингов отлично линкуется.

Те биндинги в среднем получатся круче чем «отлично линкуется на цпп», т.к. они пишутся раз и надолго, а потом заменяют собой заголовки файлов. В результате ты не подцепишь не слишком нужные второстепенные изменения в интерфейсе фэфэмпега, и программа будет совместима с большим количеством его версий. Это хорошо иллюстрировать на примере glibc - хоть в системе с GLIBC_2.17, хоть с GLIBC_2.15 программу собирай, если очень не постараться, то она потом запустится в системе с <GLIBC_2.15

Так что по универсальности кресты рулят, при всех своих недостатках. А для них лучше Qt я ничего не видел, пока ещё.

И потом приходится для запуска новой бледной луны на федоре искать в тырнете сборку совместимую с GLIBC_2.15. И поиски приводят на какой-то частный мини-репозиторий для седьмого дебиана на сайте зюзи. Кто-то сделал для дебиана репак свободной программы на цпп и теперь ей можно пользоваться - в винде так стимовские игрушки рипают и выкладывают на торренты с файлообменниками, а в линуксе - свободные плюсовые программы. Вот только там мало готовых рипаков, на все случаи не запасёшься.

P.P.S. Вот тут недавно очередная версия Hedgewars вышла. Программе 13 лет, автор паскаль явно знает, ядро программы на нём всю жизнь писалось и пишется. Так зачем ему при этом понадобился фронт-енд на Qt?

Модно-стильно-молодёжно. К третьему гытыка переходник для морды находится в состоянии альфы - народу наверно лень с ним возиться пока вторые гытыка рулят и педалят. У вторых мало недостатков, я два знаю: не знает про мониторы со щетиной, но они есть у малого количества буржуев, ради них мало кто захочет напрягаться, и второй недостаток - если сделать форму не системного цвета и воспользоваться полосой автопрокрутки, то при прокручивании форма не будет перекрашиваться, а при растягивании - будет.

Чёртовы некропостеры. Я уже подумал, что Qt6 вот-вот релизнется.

Затем, что так проще. У них был специальный конвертер, позволяющий переносить на Qt4 малой кровью с добавлением модуля Qt3Support. После того, как программа заработала, классы из этого модуля можно потихоньку переделывать на родные из Qt4 - и после того, как от Qt3Support ничего не останется, полученный исходник с довольно большой вероятностью будет универсальным как для Qt4, так и для Qt5 (исключения - QtWebkit и Phonon). Qt4 и Qt5 с точки зрения торчащих наружу классов достаточно близки, там нет антагонизма.

ок, спс за объясенение

Ты про тот понос про рхель? Опять не пойму, при чём тут рабы. Ты намекаешь, что в рхеле ничего, кроме кед, на культях нету?

Как раба кутей распоносило, любо-дорого посмотреть!

Чойта тебе везде рабы кутей мерещатся? Ты ещё скажи, что я раб LWUIT или раб XUL.

Мне не нравится, что развернуть несколько версий тех же пятых Qt, не проблема. Но при этом пакет будет все равно зависеть от пакетов с какой-то определенной версий Qt и в итоге все равно надо пересобирать пакет (debian проблемы да). К счастью не так много разработчиков которые привязываются к самым свежим Qt.

в линуксе с кутей боль - для запуска/сборки таких «кроссплатформенных» приложений постоянно требуют не ту версию что есть в наличии.

Да ладно. Большая часть софта ставится из реп, на крайняк можно либо собрать из исходников. Ну и программу на Qt всегда можно сделать статической сборкой. Точно так же, как и в паскале, только в паскале это основной метод, а здесь - дополнительный.

Да ладно. Большая часть софта ставится из реп

С репами хреново. Если дистр не красношапка/центос, то срок жизни реп маленький, а когда он кончится, то пакеты не добавляют, а из онлайн поисковиков - выбрасывают.

либо собрать из исходников

Не та версия кутей - ошибка конфигурации/сборки.

Ну и программу на Qt всегда можно сделать статической сборкой.

На линуксе так не делают, потому здесь кути и есть боль. И не надо забывать про свинью, которую для статической сборки подложил проект ГНУ. Если их продукцию вкомпилить статически, то программа заразится лицензией, для коммерческого ПО это недопустимо, а значит технологию не нужно развивать и для свободного ПО.

Точно так же, как и в паскале, только в паскале это основной метод,

В паскале гуйнню на Qt подключают через внешние либы-переходники, а для другого он вроде как и не нужен, потому ГТК менее проблемен, а результат выглядит почти также.

Не та версия кутей - ошибка конфигурации/сборки.

Кривых проектов проблемы.

Если их продукцию вкомпилить статически, то программа заразится лицензией

Во-первых, это 4.2. Достаточно обеспечить возможность сборки под другой версией Qt, например, предоставив объектные модули - никакого заражения не будет.

для коммерческого ПО это недопустимо, а значит технологию не нужно развивать и для свободного ПО.

Вот ещё. Когда коммерческое ПО диктует свои правила свободному, это типа нормально, а когда наоборот - недопустимо?

В паскале гуйнню на Qt подключают через внешние либы-переходники, а для другого он вроде как и не нужен, потому ГТК менее проблемен, а результат выглядит почти также.

Кстати, могли ведь и свой собственный бэк-енд поверх X11 сделать. Не смогли или не захотели?

Кривых проектов проблемы.

Проектам как-то пофиг на кривость.

Вот ещё. Когда коммерческое ПО диктует свои правила свободному, это типа нормально, а когда наоборот - недопустимо?

В итоге приходится пользоваться треснутыми корытами - это хорошо? На одном «дай донат, дай донат» много погромистов прокормить проблемно, а значит для системного кода бывает нужна свободная лицензия с исключением для статической сборки.

Кстати, могли ведь и свой собственный бэк-енд поверх X11 сделать. Не смогли или не захотели?

Есть целых 2: fpgui и customdrawn. Находятся в состоянии «допилено авторами до состояния „хватает для моих проектов для всяких мобилок“».

И что нового будет в KDE 6?

Больше не будет никаких кделиб и прочих прослоек, т.к. весь это функционал переехали в Qt.

я считаю, что...гтк2 хватит каждому.