Релиз Qt Creator 2.3

> http://ifolder.ru/25541579 (знаю-знаю, говнофайлообменник и всё такое, но своего сервера нет, а по мылу из-за размеров не пролезет)

За полноценность по названным ранее причинам не ручаюсь, но вряд ли такой вариант хуже почти неюзабельного оригинала. :)

успешно загружено. дзенкую.

> А как у него отношения с Андроидом? Игнорирует?

Есть неофициальный порт Qt на Андроид — Necessitas. Лично пока не проверял, но говорят, что вполне рабочий.

А почему не использовать Eclipse + плагин для клепания формочек? Есть же интерграция дизайнера в Eclipse?

Ей бы еще возможность подключить KDE'шный highlighter для cpp файлов, но это уже из разряда необязательных плюшек.

Уже есть же. Просто надо скачать файлы - определения!

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

> ПОМОГИТЕ!

Пошел в жопу.

>> ПОМОГИТЕ!

Пошел в жопу.

добрый милый ЛОР

можно, но не нужно

А пока сидим на Qt4, в QtCore собираются сделать обязательную зависимость от v8.

http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-September/001003.html

I am also considering having a dependency of QtCore onto a JS engine. Now before you all cry out loud, let me first explain this (I'll write a separate mail).

Это не очень-то удивляет — в обсуждениях планов на Qt5 уже не раз замечали, что Qt хотят превратить из плюсового тулкита в стопицотпервый жабаскриптный фреймворк, разве что способный работать вне браузера. Из всех тредов (заглядываю, в основном, в статьи на Qt Labs) про Qt5 ещё ни один меня не разубедил в том, что нокия не хочет превратить Qt в говно. Скорее, наоборот — чем дальше, тем хуже...

Как минимум не так - это то, что в компоновщик запаришься запихивать контролы. Особенно, когда уже установлен компоновщик для главного окна. Когда есть компоновщики в другом компоновщике (вложенные) вообще невозможно запихать контрол в нужный компоновщик. Приходится создавать ещё один виджет, бросать на него контролы, формировать отдельные блоки компоновщиков, везде напихивать спэйсеров (без них очень трудно запихать контролы в нужные места), потом с такой-то матерью всё это объединять и переносить в главную форму и устанавливать главный компоновщик в самом конце. Это конечно «очень удобно», тут естественно дорабатывать ничего не нужно. :)

+1. Однако удобнее перетаскивать контрол не на сам компоновщик, а на имя компоновщика в дереве объектов.

А причем тут PySide/PyQt?

А, да, в эклипсе есть. Собственно я и планировал использовать эклипс. Но у меня проект уже есть (я продолжаю чужой), а эклипс, зараза, на нём падает. Первый раз такое: грохается в анализаторе кода где-то. Где именно и почему не понятно.

А ты прочитай пост, на который он отвечал.

К сожалению, бывает. Сам видел такое, и тоже было не ясно, что ему не нравится. Обычно такие моменты в новых версиях исправляют, но когда это будет... А проект ждать не будет. Жалко.

в qt creator есть же фича форматирования кода, что за 4.2?

4.2 - это твой пост.
А с обоими продуктами ты очевидно знаком только по описаниям. Потому что после порядка 100 настроек форматтера в эклипсе, 5 настроек креатора смотрятся крайне уныло и неполноценно. Даже теперь, в версии 2.3, где возможности форматирования чуть-чуть расширили.
В частности, в эклипсе я мог написать код как угодно, хоть в одну строку, и получить не выходе форматирования текст чётко соответствующий code-style. И если я потом перепишу его ещё изменив абсолютно все отступы, пробелы, переносы строк и т.п., то после форматирования код будет один в один повторять предыдущий.
Креатор так не умеет. Всё что он может - это поправить отступы кое-где, да убрать пробелы в конце строк.

Вкладка C++ / Code Style не подходит под определение форматирования кода?

В эклипсе конечно гораздо больше, но не в отношении 100:5, 100:20 может быть.

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

> Вкладка C++ / Code Style не подходит под определение форматирования кода?
Ну ексли форматирование кода сводить только к расстановке отступов... То да. А я вот хочу, чтобы оно умело переносить строки, когда они слишком длинные становятся, разбивать параметры функций по строкам, if-ы и т.п. Где это всё? Где возможность убрать лишние пробелы в середине строки, а не в начале или конце? И в итоге - где именно _форматирование_ кода, а не интеллектуальная расстановка отступов

В эклипсе конечно гораздо больше, но не в отношении 100:5, 100:20 может быть.

Даже если принять 100 к 20 (хотя там максимум к 10, ибо см. выше), то это всё равно в 5 раз больше!
Я приведу наглядный пример: за 1000 тыс рублей можно взять BMW первой серии. А за 200 тыс. рублей - максимум жигули 2107.
Вот и разница между форматированием в эклипсе и креаторе. BMW против жигулей...

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

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

я всё понял:-)

то-то же :P