LINUX.ORG.RU

Релиз Qt 4.5 и Qt Creator 1.0

 , ,


0

0

Разработчики из QtSoftware (ранее Trolltech, а ныне подразделение компании Nokia) выпустили новую версию кросс-платформенного GUI (и не только) фреймворка Qt, а также первую стабильную версию Qt Creator IDE.

======== Qt ========

В Qt 4.5 было добавлено несколько новых возможностей, также значительно увеличилась скорость работы графической подсистемы и подсистемы обработки данных. Улучшена интеграция с WebKit, в том числе:

  • Поддержка API плагинов Netscape, позволяющая загружать флеш (и другие плагины) в программах на Qt.
  • Сложные эффекты пользовательского интерфейса, включая анимацию, трансформации и масштабирование.
  • Новый движок JavaScript для улучшения производительности.

Также Qt был портирован на фреймворк Cocoa от Apple. Предыдущие версии поддерживали только Carbon. Это означает, что разработчики теперь могут создавать приложения, которые поддерживают одновременно и 32, и 64 бита, и на Intel, и на PowerPC под Mac, и при этом остаются полностью кросс-платформенными.

И одно из важных новшеств — Qt теперь можно использовать по условиям лицензии LGPL (ранее только GPL и коммерческая).

======== Qt Creator ========

Qt Creator — это легковесная кросс-платформенная среда разработки, заточенная для разработки под C++ и Qt. Разработка Qt Creator велась с прицелом на две вещи: полностью кросс-платформенная разработка; и простота использования для тех, кто только начинает знакомиться с Qt.

Среда Qt Creator включает эффективный набор средств для создания и тестирования программ на Qt:

  • Продвинутый редактор кода на языке C++
  • Контекстная помощь
  • Визуальный отладчик
  • Управление исходным кодом
  • Средства управления проектом и сборкой

Qt Creator также распространяется под лицензией LGPL 2.1. На данный момент для разработки поддерживаются только десктопные операционные системы (Windows, Linux и Mac OS), но поддержка платформ для встраиваемых устройств возможно будет добавлена в следующие несколько месяцев.

Скачать исходники: Qt 4.5, Qt Creator 1.0.

>>> Подробности

Deleted

Проверено: maxcom ()

Ответ на: комментарий от frame

> несовместимости компиляторов нет, если есть исходники, т.е. все можно собрать одним компилятором

А как же знаменитая опенсорсная свобода выбора?

> Это ты почитай LSB, там все описано, вплоть до mangled имен функций из Qt


Как связан *L*SB с компиляторами? Разных компиляторов не две и даже не три штуки. И на линуксе свет клином не сошёлся и этого никогда не произойдёт.

> 4.2, ибо calling convention у DLL от BC и MSCV различаются, и для совместимости нужно в опциях указывать stdcall _явно_, учим матчасть вообщем


Я знаю матчасть и именно это и говорил. Можно спокойно вызвать функцию на Си, ты даже сам сказал как. Для C++ подобной магии не придумали. Calling convention - это не проблема.

> У линукса есть LSB, а все остальное никого не волнует


Для разработчиков компиляторов LSB - это не более чем филькина грамота.

> Мне, как разработчику на с++, к примеру, проблемы жабакодеров не волнуют - я лучше буду трарать время и думать над тем, как улучшить свою библиотеку


Да никто и не сомневался =).

Deleted
()
Ответ на: комментарий от Deleted

> Но с другой стороны, если символы не лезут в wchar_t, то с ними и сделать ничего нельзя (на экран не вывести стандартными средствами)

Как это нельзя? Если utf-8 локаль, то можно.

Reset ★★★★★
()
Ответ на: комментарий от Deleted

>А как же знаменитая опенсорсная свобода выбора?

У тебя есть выбор каким одним компилятором собирать.

krasnoglazeg
()
Ответ на: комментарий от frame

Буквально это означает следующее. Выделяем память с помощью new в одном модуле. Затем пытаемся удалить этот же кусок памяти в другом модуле. Какой делокатор будет использован? От первого модуля или от второго?

dave ★★★★★
()
Ответ на: комментарий от Reset

> Как это нельзя? Если utf-8 локаль, то можно.

В венде локаль utf8?! Если даже установить с помощью setlocale utf8, то всё равно строки будут преобразованы в "родное" для winapi представление - ucs-2.

Deleted
()
Ответ на: комментарий от dave

Хуже того. Есть два модуля. По какой-то причине их собрали разными версиями _одного_ компилятора. Но проблема в том, что в следующей версии поменяли внутреннее представление exception. Как тогда exception будет мигрировать между модулями, которые, напомню, собраны разными версиями компилятора?

dave ★★★★★
()
Ответ на: комментарий от Deleted

>А как же знаменитая опенсорсная свобода выбора?

выбирай: gcc или геморрой =)

>Как связан *L*SB с компиляторами? Разных компиляторов не две и даже не три штуки.

Я знаю только один свободный и самый распространенный, остальные пусть подстраиваются под него, зоопарк abi не нужен

>И на линуксе свет клином не сошёлся и этого никогда не произойдёт.

А что - кто-то надеется перенести свои бинарные библиотеки с винды/whatever на линукс и чтобы все cходу заработало? "Ня-ня-ня!" =)

>Можно спокойно вызвать функцию на Си, ты даже сам сказал как. Для C++ подобной магии не придумали. Calling convention - это не проблема.

Если calling convention (задается-то во время компиляции!) не проблема, то и name mangling тоже не проблема

frame ★★★
()
Ответ на: комментарий от dave

>Буквально это означает следующее. Выделяем память с помощью new в одном модуле. Затем пытаемся удалить этот же кусок памяти в другом модуле. Какой делокатор будет использован? От первого модуля или от второго?

Если ума не хватило собрать два модуля одним компилятором - то да, начинаем гадать на кофейной гуще

frame ★★★
()
Ответ на: комментарий от dave

> Какой делокатор будет использован? От первого модуля или от второго?

Тот, который в libstdc++?

> Есть два модуля. По какой-то причине их собрали разными версиями _одного_ компилятора. Но проблема в том, что в следующей версии поменяли внутреннее представление exception. Как тогда exception будет мигрировать между модулями, которые, напомню, собраны разными версиями компилятора?

А это разрабы специально нашли себе проблему, или не знали про свитчи, которые указывают версию ABI?

tailgunner ★★★★★
()
Ответ на: комментарий от frame

> Если calling convention (задается-то во время компиляции!) не проблема, то и name mangling тоже не проблема

Фокус в том, что если calling convention задаётся во время компиляции, то правила name mangling прибиты к компилятору и обычно не настраиваются вообще.

Deleted
()
Ответ на: комментарий от dave

>Хуже того. Есть два модуля. По какой-то причине их собрали разными версиями _одного_ компилятора. Но проблема в том, что в следующей версии поменяли внутреннее представление exception. Как тогда exception будет мигрировать между модулями, которые, напомню, собраны разными версиями компилятора?

Ядерные сишные модули, собранные разными версиями (4.2 и 4.3, к примеру) gcc тоже несовместимы между собой, и что? Хватить выдумывать всякую херню.

frame ★★★
()
Ответ на: комментарий от Deleted

>Фокус в том, что если calling convention задаётся во время компиляции, то правила name mangling прибиты к компилятору и обычно не настраиваются вообще.

ну так собери все одним компилятором, какие проблемы?

frame ★★★
()
Ответ на: комментарий от Deleted

> правила name mangling прибиты к компилятору и обычно не настраиваются вообще.

Они задаются ABI, а версия ABI указывается компилятору. Да и сам вариант mangling'а вроде можно было настраивать раньше (когда их было много).

tailgunner ★★★★★
()
Ответ на: комментарий от frame

Это прописные, т.е. прописанные в книгах, истины. Я их не выдумывал сам. Просто моя небольшая интерпретация.

Что касается тех же exception. Можно взять тот же самый g++, но задать разные опции компиляции: в одном случае включить поддержку exception; а во втором - нет. Вполне себе реальная ситуация. И тогда возникнет проблема между двумя модулями.

Мой посыл состоит в том, что много таких технических деталей, которые препятствуют тому, что бы API писался на C++.

dave ★★★★★
()
Ответ на: комментарий от dave

>Можно взять тот же самый g++, но задать разные опции компиляции: в одном случае включить поддержку exception; а во втором - нет. Вполне себе реальная ситуация. И тогда возникнет проблема между двумя модулями.

Я тоже могу для одной библиотеки задать fastcall (regparm), а для другой cdecl. Вполне себе реальная ситуация. И тогда возникнет проблема между двумя модулями.

>Мой посыл состоит в том, что много таких технических деталей, которые препятствуют тому, что бы API писался на C++.

Целиком и полностью надуманный посыл, основанный на предвзятом отношении к С++.

frame ★★★
()
Ответ на: комментарий от frame

> Я тоже могу для одной библиотеки задать fastcall (regparm), а для другой cdecl. Вполне себе реальная ситуация. И тогда возникнет проблема между двумя модулями.

По-моему ты путаешь разные вещи. Одно дело явно прописать интерфейс в коде (в твоем случае), а другое дело - использовать разные ключи компилятора на том же самом коде.

> Целиком и полностью надуманный посыл, основанный на предвзятом отношении к С++.

Нет предвзятости. Напротив, даже озабочен прочтением книги Герба Саттера "Решение сложных задач" (в оригинале Exceptional C++ and More Exceptional C++). Пытаюсь лучше понять материал, с которым непосредственно приходится иметь дело по работе.

dave ★★★★★
()
Ответ на: комментарий от dave

> Одно дело явно прописать интерфейс в коде (в твоем случае),

regparam можно задать ключом. То же, что и в Си++, короче говоря. Правда, в Си++ больше возможностей ошибиться (потому что язык сложнее и больше настраиваемых параметров).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Да, в C++ много таких параметров. Например, я еще не говорил об RTTI, который тоже может быть разным в пределах разных модулей. Более того, его тоже можно отключить.

Склоняюсь к мысли svu: для общесистемного API либо бинарная совместимость на уровне чего-то вроде Си, либо единая виртуальная машина и стандрартизированный байт-код. Похоже, что третьего еще не придумали :)

Хотя если бы си-пи-пишные бинарники были бы стандартизированы и не было такого разброда в опциях... но это трудно себе представить.

dave ★★★★★
()
Ответ на: комментарий от dave

Ошибся. Третьим можно назвать COM/Corba, но это как-то не очень смотрится по сравнению с managed кодом

dave ★★★★★
()
Ответ на: комментарий от dave

> Склоняюсь к мысли svu: для общесистемного API либо бинарная совместимость на уровне чего-то вроде Си

Тебе же показали, что ABI можно сломать и в Си, причем теми же методами, что и в Си++.

> либо единая виртуальная машина и стандрартизированный байт-код.

Виртуальная машина не нужна. Да и байт-код, в общем, не нужен. Нужен... ABI :D

> Похоже, что третьего еще не придумали :)

Общесистемные стандарты на соглашения о вызовах успешно реализованы еще лет 30 назад.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Общесистемные стандарты на соглашения о вызовах успешно реализованы еще лет 30 назад.

А где соглашения по обработке exception?

> Тебе же показали, что ABI можно сломать и в Си, причем теми же методами, что и в Си++.

Это был высосанный из пальца пример, переходящий грань разумного. А вот, сломать бинарную совместимость в Си-пи-пи при сохранении неприкосновенным исходного кода - проще простого.

dave ★★★★★
()
Ответ на: комментарий от dave

Вот, пример из жизни.

Есть библиотека OCCI для Оракула под Солярис. Эта штука скомпилирована с libCstd, т.е. со старой сановской версией STL. Чтобы использовать новую версию STL нужно задать ключик -library=stlport4. Одно условие: нельзя линковать между собой объектники, если они используют разные версии сановской STL... И если ты используешь OCCI, то ты не можешь использовать новую сановскую STL. Ну, что за хрень!

Как можно мечтать о системном API на плюсах, если возникают такие проблемы при использовании библиотек?! Пусть проприетарщина. Без нее никуда.

dave ★★★★★
()
Ответ на: комментарий от dave

>По-моему ты путаешь разные вещи. Одно дело явно прописать интерфейс в коде (в твоем случае), а другое дело - использовать разные ключи компилятора на том же самом коде.

Ну уж извините, что про защиту от дураков в этом месте не подумали =)

>Нет предвзятости. Напротив, даже озабочен прочтением книги Герба Саттера "Решение сложных задач" (в оригинале Exceptional C++ and More Exceptional C++). Пытаюсь лучше понять материал, с которым непосредственно приходится иметь дело по работе.

И все еще не понятно, что все компоненты программы нужно собирать одной версией одного компилятора? Тогда продолжай тратить время на песполезную читанину.

frame ★★★
()
Ответ на: комментарий от dave

>> Общесистемные стандарты на соглашения о вызовах успешно реализованы еще лет 30 назад.

> А где соглашения по обработке exception?

ВотЪ. В этом корень проблемы - стандарт ABI описывает нечто, существовашее в прошлом. А прогресс идет, и кто-то придумывает вещь, не учтенную стандартом. И это неизбежно, никакая виртуальная машина и байт-код здесь не помогут - только изменение стандарта.

>> Тебе же показали, что ABI можно сломать и в Си, причем теми же методами, что и в Си++.

> Это был высосанный из пальца пример, переходящий грань разумного.

Не более высосанный, чем пример с Си++.

> Есть библиотека OCCI для Оракула под Солярис. Эта штука скомпилирована с libCstd, т.е. со старой сановской версией STL. Чтобы использовать новую версию STL нужно задать ключик -library=stlport4. Одно условие: нельзя линковать между собой объектники, если они используют разные версии сановской STL...

Это критика Сановской STL или Оракула?

tailgunner ★★★★★
()
Ответ на: комментарий от dave

>А где соглашения по обработке exception?

А кому оно нужно, кроме проприетарщиков, распространяющих бинарные блобы?

>Это был высосанный из пальца пример, переходящий грань разумного.

Будто бы компилирование модулей с разными флагами эту грань не переходит.

>А вот, сломать бинарную совместимость в Си-пи-пи при сохранении неприкосновенным исходного кода - проще простого.

Это как бы не проблема языка/API.

frame ★★★
()
Ответ на: комментарий от frame

> И все еще не понятно, что все компоненты программы нужно собирать одной версией одного компилятора? Тогда продолжай тратить время на песполезную читанину.

Не надо заниматься телепатией и думать за других. Выбор компилятора остается за разработчиками. Ведь мы говорим не только обо мне.

А про книгу зря так. Весьма достойная книга по плюсам. Может быть, одна из лучших.

dave ★★★★★
()
Ответ на: комментарий от tailgunner

> ВотЪ. В этом корень проблемы - стандарт ABI описывает нечто, существовашее в прошлом. А прогресс идет, и кто-то придумывает вещь, не учтенную стандартом. И это неизбежно, никакая виртуальная машина и байт-код здесь не помогут - только изменение стандарта.

И тут приходим к важной мысли, что трудно стандартизировать бинарник низко-уровневого языка. С виртуальной машиной проще. По сути нужно стандартизировать только байт-код, что намного легче - ведь виртуальная машина может быть всего одна...

dave ★★★★★
()
Ответ на: комментарий от frame

>>А где соглашения по обработке exception?

>А кому оно нужно, кроме проприетарщиков, распространяющих бинарные блобы?

Это относится ко всем.

Представим себе такой случай. Программа написана так, что многие вещи в ней deprecated. Тут вышла новая версия g++, которая превращает deprecated в error. Выход один - использовать старый компилятор.

> Будто бы компилирование модулей с разными флагами эту грань не переходит.

Нет. Реальный use case.

>>А вот, сломать бинарную совместимость в Си-пи-пи при сохранении неприкосновенным исходного кода - проще простого.

> Это как бы не проблема языка/API.

Многие беды от этой позиции. Впрочем, о сложности стандартизации бинарника низко-уровневого языка я уже написал выше.

dave ★★★★★
()
Ответ на: комментарий от dave

> С виртуальной машиной проще. По сути нужно стандартизировать только байт-код,

Это настолько далеко не так, что даже спорить не стану :)

tailgunner ★★★★★
()
Ответ на: комментарий от dave

>Представим себе такой случай. Программа написана так, что многие вещи в ней deprecated. Тут вышла новая версия g++, которая превращает deprecated в error. Выход один - использовать старый компилятор.

На новых версиях gcc тоже не всё компилируется.

>Нет. Реальный use case.

Скорее реальный abuse case.

frame ★★★
()
Ответ на: комментарий от tailgunner

>> wireshark, всё xfce (thunar), medit, emacs, gmpd, fbreader, xchat, midori, stardict, sylpheed, claws, xournal, и ещё дохрена...

>Научился шарить по репозиторию? Молодец. Теперь представь, что я не использую все эти достойные программы.

Ну и как, IE, Winamp и KDE удобнее?

Minoru ★★★
()
Ответ на: комментарий от Minoru

>> Теперь представь, что я не использую все эти достойные программы.

> Ну и как, IE, Winamp и KDE удобнее?

Утипути. Иди под^помолись на труп CDE, пока его не кремировали.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Это настолько далеко не так, что даже спорить не стану :)

Ради бога.

dave ★★★★★
()

> это сильное утверждение и оно требует не менее сильного подтверждения... с чего Вы это взяли?

хорошо. как без классов коротко сделать древовидный список чего угодно

чёнить аля //далее идёт скорее всего неправильный код, но это только иллюстация мысли

class Test { public: map<int, * Test> Tests; };

ferro
()
Ответ на: комментарий от tailgunner

Этот Minoru весьма интересный экземпляр. Такое ощущение что перечитался Виталковского толстого тролления про "программиста-сверхчеловека" образца 2001ого, и про мифологическое мега-удобство древних юниксов, и крутость тогдашних юниксойдов. Практически живое ископаемое.

Могу поспорить что он ещё emacs считает идеальной IDE...

krasnoglazeg
()
Ответ на: комментарий от ferro

>хорошо. как без классов коротко сделать древовидный список чего угодно

data Tree a = Tree { branches :: [Tree a], values :: [a] }

ы? Хотя да, я совсем забыл, что ФП - это для позёров и свихнувшихся теоретиков.

Minoru ★★★
()
Ответ на: комментарий от tailgunner

>Практически живое ископаемое.

Я в том смысле, что он ископаемый тролль. Времена мифов о юниксах, и постулирующих абстракции сверхчеловеках - давно прошли.

krasnoglazeg
()
Ответ на: комментарий от ferro

>я конечно извиняюсь, но я не понимаю Вашего диалекта. Что есть ФП?

Функциональное программирование.

Minoru ★★★
()

> Функциональное программирование

это всё равно не панацея

ferro
()
Ответ на: комментарий от VladimirP

Re^2: Релиз Qt 4.5 и Qt Creator 1.0

Хм, сделать хреново_лишь_бы_не_так_как_в_де-факто_промышленном_стандарте - даа, великое достижение. Вот уж точно показывает всю глубину велосипедизма OSS - не просто велосипед сделаем, а с квадратными колесами! Фигня, что ездить неудобно, зато не как у презренных коммерсов, с их великами с круглыми колесами

//Был бы у меня год абсолютно свободного времени - потратил бы на портирование gimp на Qt4. С прикручиванием нормального интерфейса, которым пользоваться можно, а не матом со всех сторон обкладывать. Только вот нет этого времени, нету...

MadCAD ★★
()
Ответ на: Re^2: Релиз Qt 4.5 и Qt Creator 1.0 от MadCAD

> Хм, сделать хреново_лишь_бы_не_так_как_в_де-факто_промышленном_стандарте

Интерфейс GIMPа непривычен не из-за стремления сделать не так, как у всех. Для этой задачи интерфейс GIMP'а не менее удобен, если привыкнуть. То же касается и Blender'а.

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

VladimirP ★★★★
()
Ответ на: комментарий от VladimirP

Тред сдох

А был бы эпиктред... ЛОР уже не торт

pashazz ★★★★
()
Ответ на: комментарий от Liosha_Syrnikov

>Кто-нибудь может понятно объяснить, зачем GTK использует чистый C без плюсов?

Потому что чистый С является родным языком для linux...

>Зачем изобретать свое решение, если есть уже проверенное?

Чистый С - является ещё более проверенным решением. :)

>Но QT, STL, MFC используют синтаксис один (плюсовый)

Это Вам так кажется. :) Модели разные.

>Итак, кто-нибудь знает, зачем создатели GTK воспользовались чистым C вместо C++ и какие они из этого получили выгоды?

Когда пишешь на том что хорошо знаешь - это лучшая выгода. Имхо так. :)

shty ★★★★★
()
Ответ на: комментарий от dave

>Есть проблемы по-сложнее. Свой внутренний формат для exception, формат для низко-уровневого представления объектов, для управления памятью с помощью new/delete в пределах нескольких модулей и др.

А зачем Вам создавать объект в одном объекте, а удалять в другом? Скорее всего если у Вас встречается такая ситуация - Ваша программа неправильно спроектирована. :)

>Поскольку Си гораздо проще, и его библиотеки стандартизированы, то там таких проблем не возникает.

Ваша правда. Однако там есть свои проблемы. :)

Прочитайте например про setjump/sigsetjump и longjump/siglongjump... и про то в чём различие между ними. :)

>Другими словами, у Си++ нет стандарта на реализацию базовых вещей.

Из Ваших слов это никак не следует :)

А вообще для развития - читайте Мейерса, Александреску и пр. У Вас, уверен, сложится более полное впечатление о языке.

shty ★★★★★
()
Ответ на: комментарий от dave

>для того, чтобы new/delete работал в пределах нескольких модулей

Ещё раз - это ошибка проектирования!

shty ★★★★★
()
Ответ на: комментарий от dave

>Выделяем память с помощью new в одном модуле. Затем пытаемся удалить этот же кусок памяти в другом модуле.

Я конечно не оригинален - но это ошибка проектирования. :)

shty ★★★★★
()
Ответ на: комментарий от dave

>Как тогда exception будет мигрировать между модулями, которые, напомню, собраны разными версиями компилятора?

Читайте стандарты - это снова ошибка проектирования...

shty ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.