"New Qt IDE Called Greenhouse (http://www.linuxpromagazine.com/online/news/qt_developer_day...)" - компания Qt Software планирует через несколько недель выпустить первую тестовую версию новой среды разработки Greenhouse (http://trolltech.com/developer/greenhouse), являющейся воплощением грез об идеальной IDE для Qt-разработчиков. Интерфейс системы будет максимально простым и лишенным излишеств, но позволяющим проконтролировать процесс сборки на любом уровне.
Об этом было объявлено на конференции Qt Developer Days. Исходные тексты Greenhouse будут доступны под лицензией GPL.URL: http://www.linuxpromagazine.com/online/news/qt_developer_day...
Новость: https://www.opennet.ru/opennews/art.shtml?num=18451
А чем KDevelop плох? том что не они писали?
Ну мне например табовый интерфейс невдугу :)
>Ну мне например табовый интерфейс невдугу :)там табы отключить мона
Тем, что это только под линукс подразумевается. А у них может кросс-платформенное само ИДЕ будет.
да сделать KDevelop кроссплатформенным? например: QDevelop
> А чем KDevelop плох? том что не они писали?Ну например автозавершение никакое. Вообще не знает про существование мемберов у классов, а это очень сильно снижает продуктивность.
>> А чем KDevelop плох? том что не они писали?
>
>Ну например автозавершение никакое. Вообще не знает про существование мемберов у классов,
>а это очень сильно снижает продуктивность.Автозавершение там в порядке (для C++ и QT все отлично). И про мемберы он отлично знает.
PS: В параметрах проекта в настройках поддержки C++ на вкладке Code Completion ковырялись?
>> А чем KDevelop плох? том что не они писали?
>
>Ну например автозавершение никакое. Вообще не знает про существование мемберов у классов,
>а это очень сильно снижает продуктивность.закаленные программисты автозаполнение не пользуют :)
А как же кросс-платформенный QT?
А что с ним?
*А как же кросс-платформенный QDevelop?
простите, а Вы его пробовали? насколько я помню там версия 0.25 уже полгода...
постоянно пользуюсь. отличная вещь!
будем надеятся, что у них всё получится...
А как же плагины к Eclipse и Visual Studio? Чем они плохи?
А чем KDevelop плох?
- не кроссплатформенно.
- не очень умный интелессенс
QDevelop
- автоподставновка практически не работает
eclipse
то что надо, правда памяти жрет.
Code blocks
душа не легла, а так неплохая вещьбуду ждать когда выйдет среда от Троллей ...
перепробовав всё выше остановился на NetBeans
память кушает, зато всё есть, подстановки, проверки, контроль версий и полегче эклипса
С плюсами нормально работает?зы. новость клёвая, выйдет среда - потестю обязательно, хотелось бы иметь привычного/приличного вида IDE =)
уже не тролли ;)
Серега, давай КБ доработаем? ;)
Дима, проще QDevelop довести, он хотя бы на QT написан :)
>eclipse
>то что надо, правда памяти жрет.Автодополнение кода не далеко ушло от KDevelop и уж никак даже не рядом с VS в этом плане.
>Автодополнение кода не далеко ушло от KDevelop и уж никак даже не
>рядом с VS в этом плане.Ага, зато VS ни разу не кроссплатформенный и компилить без извращений умеет только виндовые проги.При том если не попрыгать с бубном как следует - эти проги еще и хотят туеву хучу левых ДЛЛ рантайма, которые у программера конечно есть а у остальных - фигу там.Так что если такую прогу раздать юзерам - на выбор или вынесут весь мозг или придется делать невъ...нный сетапер с кучей длл.Отличнее просто некуда, бэть.Особенно в состоянии по дефолту.
Я последний год в emacs пишу - под Red Hat, Windows и FreeBSD. Раньше сидел в Visual Studio, Kdevelop и пр. По моему мнению, IDE отлично автоматизирую рутинную работу. Однако, я считаю, что лучше не писать похожий код, не создавая тем самым никакой рутинной работы. Это упрощает разработку, делает приложения проще, понятнее и надёжнее и стирает границы между IDE и текстовыми редакторами.
>Я последний год в emacs пишу - под Red Hat, Windows и
>FreeBSD. Раньше сидел в Visual Studio, Kdevelop и пр. По моему
>мнению, IDE отлично автоматизирую рутинную работу. Однако, я считаю, что лучше
>не писать похожий код, не создавая тем самым никакой рутинной работы.
>Это упрощает разработку, делает приложения проще, понятнее и надёжнее и стирает
>границы между IDE и текстовыми редакторами.ну копипаст до добра еще никого не доводил
А чем JEdit плох, конечно, формочек аля VS, Delphi и прочее не придусмотренно...
QT изнутри может быть прямой и удобный, снаружи же - это тормозное унылое говно, немерянно поедающее ресурсы.
>QT изнутри может быть прямой и удобный, снаружи же - это тормозное
>унылое говно, немерянно поедающее ресурсы.Ты с gtk перепутал
:)
Посмотрим что это будет. Хотя меня сейчас полностью KDevelop устраивает.
То что он не кроссплатформенный не напрягает, ибо достаточно написать проект под линуксом, а потом в винде просто собрать его.
Как по мне, так лучше vi + make может быть разве только ed + mk :)
Поддерживаю. Ушел в сторону Vim + cmake. А *.ui наклепать можно и в Designer-е.
>Поддерживаю. Ушел в сторону Vim + cmake. А *.ui наклепать можно и в Designer-е.Qt, Gtk и пр. - это устаревший подход к HI, особенно непроизводительны графические редакторы интерфейсов, которые так популярны среди новичков.
Лучше всего использовать Qt, Gtk и пр. в качестве "ассемблера HI", а для приложения разрабатывать HI более высокоуровнево. Тогда больше чем vim или emacs не понадобится, а стоимость разработки сократится.
Одна из идей в эту тему:
http://stlab.adobe.com/group__asl__overview.html#asl_overvie...
>Qt, Gtk и пр. - это устаревший подход к HI, особенно непроизводительны
>графические редакторы интерфейсов, которые так популярны среди новичков.По-моему QT-Designer ничего себе так штука. В чем его непроизводительность?
>Лучше всего использовать Qt, Gtk и пр. в качестве "ассемблера HI", а
>для приложения разрабатывать HI более высокоуровнево. Тогда больше чем vim или
>emacs не понадобится, а стоимость разработки сократится.
>Одна из идей в эту тему:
>http://stlab.adobe.com/group__asl__overview.html#asl_overvie...Сейчас нет времени и сил в это вчитываться. Можно суть?
Да и с чего уменьшится стоимость разработки?
>>Одна из идей в эту тему:
>>http://stlab.adobe.com/group__asl__overview.html#asl_overvie...
>Сейчас нет времени и сил в это вчитываться. Можно суть?
>Да и с чего уменьшится стоимость разработки?Адам берёт на себя часть функций контроллера и всю модель из MVC, а Ева - отображение (view). То есть надо написать adam sheet и eve layout, а также те функции контроллера, что берут данные из предметной области и пишут туда. Всё.
То, что в Qt делается при помощи signal & slots, берёт на себя Адам, причём выражает это в виде данных и зависимостей между ними. Адам сам решает задачу определения вклада каджого виджета в результат. То есть не надо писать код или тыкать мышью в дизайнере, чтобы пояснить, что при выборе такого-то значения из dropdown box нужно некий edit сделать disabled. Он сам всё рассчитает.
Стоимость разработки уменьшаетсяза счёт:
1) Более быстрого создания интерфейсов.
Не надо тыкать мышью или писать код, чтобы выразить примитивные зависимости между данными.2) Уменьшения объёма тестирования.
В тестах есть секция expect, где описывается, что должно получиться при таких-то условиях. Adam sheets и так содержат в себе эти зависимости по отдельности в явном и понятном виде. Тесты на HI не нужны.3) Сокращения числа HI-багов.
За счёт высокоуровневого и понятного представления зависимостей между виджетами.Всё это не означает, что надо выбросить Qt - Ева сама по себе ничего на экран выдать не может. А вот использовать Qt в качестве back-end - идея вполне хорошая.
Насколько мне извествно, ни Qt ни Gtk в качестве back-ends ещё не поддерживаются.
Вообще достаточно спорно, что это упростит создание интерфейсов. Но спорить не буду, потому что чтобы сказать точно надо попробовать.
>Вообще достаточно спорно, что это упростит создание интерфейсов. Но спорить не буду,
>потому что чтобы сказать точно надо попробовать.Да, точно. А главное, совершенно непонятно как это может усложнить их создание :-)
> Интерфейс системы будет максимально быстрым, простым и лишенным излишества еще он будет работать в консоли :)))