Вышел KDevelop 1.4 for KDE2

Прикольно! Мне кдевелоп очень нравится Он точно только для КДЕ 2, а то мне больше гном импонирует

Нифига он не вышел... Смотреть надо внимательнее, прежде чем новости постить. Я вообще KDevelop давно не смотрел, помню я от него отказался (вернулся к (X)Emacs) из-за того, что он свою структуру директорий навязывает (все файлы проекта в одну кучу сваливает, проще говоря), да и модуль kwrite, который он в качестве редактора юзает, до емакса не дотягивает (indent'ить так хорошо не умеет). Если кто юзал KDevelop, скажите, может что в этой области исправилось? Или всё такой же отстой? Ещё есть KDE Studio, но меня в нём поразили до глубины души несколько, я бы сказал, offensive bugs и некотрые методы, используемые его авторами - например, там есть Code Completion "plugin" (на самом деле часть другого plugin'а), основанный на неизвестно у кого спёртом parser'е для C++ (все ссылки на авторов удалены, написан на C, код хороший, по-видимому - подозреваю, что TheKompany такое родить не в силах ;) - казалось бы, замечательная вещь, но при каждом обращении (посмотреть, какие аргуметны у функции etc.) эта дрянь в качестве препроцессора вместо gcc -E ... вызывает gcc ... -save-temps -S -o /dev/null, который над кучей C++-ных header'ов думает по полминуты. Я фигею, дорогая редакция. Ни за что бы не догодался, что Сизифов труд может быть так полезен ;)

2ivan4th: такие вещи сделаны не для того чтобы в них работать (хотя может делаются именно для этого - но нифига не катит), а чтобы привлечь внимание сторонников масдая и всякой там мнимой красоты... рано или поздно многие с подобных тулузин переходят или на Vi* или на *Emacs... возможно я не прав... тада киньте в меня камень в виде справедливой критики :)

2 ivan4th:
А какую версию Вы пробовали? Насколько я помню, в kdevelop испокон
веков можно было добавлять в проект файлы из новой папки и в ней
автоматически появлялся Makefile. Так что никто Вас не заставлет
хранить файлы в одной большой куче :-) Плюс к этому можно создавать
новые классы в разных "виртуальных" папках, только вот перемещать
уже созданные классы через GUI нельзя :-( (думаю, можно ручками в
файле проекта).

2 hoopoe:
Я не знаю какого рода "справедливую критику" Вы хотите услышать
в свой адрес, поскольку Вы не привели ни одного аргумента в пользу
Vi и (X)Emacs против kdevelop ;-)))) IMHO, каким инструментом
пользоваться -- это дело вкуса, все они по-своему хороши. Я, например,
решил также изучить XEmacs, ибо штука ОЧЕНЬ симпатичная на мой
взгляд.

Дмитрий

Сам организовал писал с кучей дирей и поддирей на Kdevelope очень даже все работает. Только все ето надо ручками прописывать. Файлики править. Но вам то как человеку привыкшему к emacs должно быть не впервой такое делоть. Хотя согласен что при всей возможности сделать что угодно несколько нестройно все получается.

Прошу прошения за язык. Накатывает безграмотность периодами. :)

Сначала у меня был мастдай, потом Linux, потом kdevelop, потом emacs. Что будет дальше, не знаю ;)..

Сначала у меня был мастдай, потом стал Linux + kdevelop, потом Linux + emacs. Что будет дальше, не знаю ;).. Но назад не к kdevelop не вернусь, пока emacs не будет вместо kwirte. Вроде как QtEZ поддерживает внешние emacs, как редактор.. Все лень поставить посмотреть.

Повторяю:

Товарищи! Не надо песен! Чтобы были подкаталоги ничего ручками
править не надо! Хватит лить воду, никто так ещё и не сказал чем
плох kdevelop!

Как всегда, пустые слова, сопли пузырями... :-(

Дмитрий

потом будет vi, потом cat, потом echo, затем dd... :))

2anonymous: "Товарищи! Не надо песен! Чтобы были подкаталоги ничего ручками править не надо! Хватит лить воду, никто так ещё и не сказал чем плох kdevelop!" - а вот в этом и недостаток, что "ничего ручками править не надо". :) Понимаешь... со времением ручки атрофируются, :) и ты начинаешь глядеть на Makefile.am с абсолютным непониманием, другими словами kdevelop лишает Вас абсолютного контроля того, что Вы делаете, а это не есть гуд. Dmitry Yusupov <dmy7@yahoo.com>

Все недостатки Linux проистекают из-за отсутствия толковых средств разработки, каковые в изобилии есть для Windows. Посему и разработка идет очень медленно, и ошибок крайне много. Непадучее у Linux наверное только ядро да glibc. Ну еще демоны, портированные с других *nix типа Apache, Sendmail и т.д., которые вылизывались годами. А остальное все в той или иной мере падает. Программисты, что пишут под Linux, больше заняты юзанием крутейшего vi или emacs, чем действительно ловлей багов и расширением возможностей. Вот и получается, что Linux постоянно в позиции догоняющего Win32.

2 Dmitry Yusupov:

"...kdevelop лишает Вас абсолютного контроля того, что Вы делаете..."

Нет, не лишает. Он лишь помогает думать о программе, а не о Makefile.am,
ибо Makefile -- это не самоцель, а средство. С другой стороны, хороший
программист обязан разбираться в autoconf/automake и никакой kdevelop ему
не помешает ;-)

2 Eugeny Balahonov:

"Программисты, что пишут под Linux, больше заняты юзанием крутейшего vi
или emacs, чем действительно ловлей багов и расширением возможностей."

Те, кто пишут в vi/emacs, делаюь это, извините, не для "понта", а потому,
что им это действительно удобно и привычно. На вкус и цвет... :-)

На самом деле можете сами выбирать как вы будете юзать kdevelop. Для всех простых случаев в том числе и для подкаталогов можно ничего не править, а сделать на автомате, и это действительно хорошо для начинающих. Но можете и в ручную делать Makefile.am и все другие, никто вам этого не запрещает, и если вы начнете уже как-то особо затачивать свой проект, то вам просто придется это делать. На автомате такие вещи уже не прокатят. Придется поразмять свои "атрофированные ручки" :-). На счет indent действительно не слишком хорошо работает, мне даже в старом dos-ом Dos Navigatore больше нравилось. :-( Но жить с этим можно. Ну и если develop-ить под KDE, то KDev пожалуй все-же самое лучшее что есть. А недостатки они ведь везде бывают...

Кстати нынче kdevelop предлагает выбирать стиль редактора kwrite и emacs style. И в 1.4(из ЦВС) имеется тип проекта когда он вообще не заботится об мэйкфайлах и прочей лабуде. Все на откуп девелоперу.

2 Дмитрий: многие переходят по трем причинам (про последнюю версию не знаю - уже не ставил): первое - KDevelop не дает в полной мере управлять Makefile.am... только не говорите мне что я могу их доделать руками и все будет ok, типа там есть комментарии, между которыми он правит а все остальное не трогает - таки это не так... я как-то недавно клюнул на это, добавил библиотек и своих ключей в компилляцию а потом несколько часов про...лся искав ошибку в сырцах, пока не заглянул в мейкфайл... второе его неоправданная тяжесть по отношению к возможностям... вы можете указать на разные вкусности, типа встроенная дока, всякие класс-бровзеры, встроенные дебуггеры и т.д. но это все не всех устраивает. и третье - он слишком сильно завязан на свой проект, т.е. он без проекта почти все вкусности отваливаются и он превращается в весьма посредственный редактор (а работа без проекта возможна если приходится подхватывать другой проект, не из кдевелопа)

Eugeny Balahonov утвержает что наличие кучи средств разработки делает Windows супер стабильной? Чушь полнейшая!
Дык вот давить надо Microsoft и расстреливать ту 3-х миллионную армию полупрограммеров которую породил их VisualВасёк!!!

2 hoopoe:

"KDevelop не дает в полной мере управлять Makefile.am... только не
говорите мне что я могу их доделать руками и все будет ok, типа там
есть комментарии, между которыми он правит а все остальное не трогает..."

Тут Вы правы :-( Для меня эта проблема проявилась при создании shared
library. В kdevelop пока нет такого типа проекта, поэтому приходится
править Makefile.am вручную. БОльшая часть изменений остаётся
нетронутой, но после добавления в проект нового файла стрОки

libname_la_SOURCES = file1.cpp file2.cpp file3.cpp
libname_la_LIBADD = -lname1 -lname2

упорно заменяются на

bin_PROGRAMS = name
name_SOURCES = file1.cpp file2.cpp file3.cpp
name_LDADD = -lname1 -lname2

что, в принципе, понятно (ну не знает он, что я делаю библиотеку), но
очень достаёт :-((

"...вы можете указать на разные вкусности, типа встроенная дока,
всякие класс-бровзеры, встроенные дебуггеры и т.д. но это все не
всех устраивает."

Кого не устраивает, тот и не пользуется kdevelop ;-)

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

В версии 1.3 появилась функция Generate Project File, которая создаёт
проект по Вашим Makefiles.

Дмитрий

2 Дмитрий: >> В версии 1.3 появилась функция Generate Project File, которая создаёт проект по Вашим Makefiles. че, серьезно ? не знал... надо будет попробовать..., спасибо что просветил... а тип таргета понимает ? а если несколько целей то как поведет себя ? может в двух словах перескажешь, а то у нас канал дохлый... качать несколько дней будет...

Лично для меня вполне хватает gcj (GNU Compiler for Java) and CodeGuide (www.omicore.de)<p> Он сейчас достаточно стабильный, вместо AWT юзаю GTK (KDE/QT 1.x - полный отстой)<p>

2 hoopoe:
"а тип таргета понимает ? а если несколько целей то как поведет себя ?
может в двух словах перескажешь, а то у нас канал дохлый... качать
несколько дней будет..."

Лично я этой feature не пользовался пока -- случая не представилось :-)
Знаю лишь, что делается это при помощи программы kimport, которая
работает из командной строки, а в kdevelop подвешена на пункт меню.
man/info, к сожалению, отсутствуют, так что больше ничего сказать не
могу. А kdevelop-1.3 достаточно небольшой, несколько дней скачивать
не придётся ;-))

Дмитрий