Подскажите наконец-то нормальную IDE

Может kate + ProjectManager(plugin) ?

> 1. Наличие дерева проекта.

(ProjectManager)

> 2. Запоминиие положения в файлах. Запоминиание сосотяния при выходе и восстановление его при повторном запуске.

Сессии

> 3. Возможность назначить кнопкам на тулбаре/хоткеям свои действия.

Кнопкам нет, а на хоткеи можно вешать т.н. Внешние инструменты - натравливание внешней проги на файл с кучей опций.

Например "Google Selection", "Compare Current Document to CVS", "make" и т.д.

> 4. Возможности отладки/интеграции с отладчиками не волнуют.

Интеграции с отладчиком там нету.

> 5. Поддержка юникода.

=)

> 6. Желательно, но не обязательно GTK.

kde

SlicEdit

Ты будешь смеятся, но это emacs + (ecb || cedet). Или монструозно? Тогда вышеупомянутый Kate. Или зайти на vim.org - там такого добра навалом.

Кстати, восстановление состояния не нужно - настоящие мужчины используют suspend :)

Я честно пытался осилить Emacs. Я не могу набирать сочетания типа Ctrl-A X. Они меня в миникоме добивают все время, но там их хоть немного и можно привыкнуть.

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

Вот нашел нечто под названием geany. Довольно удобно, но проектов нет. При попытке втянуть туда ее же исходники выдала, что максимум можно открыть 25 вкладок. Это здорово, когда есть дерево проекта. Думаю проще будет к ней прикрутить его, чем искать.

Он-же платный. Воровать чего-то не хочется, платить как ни странно тоже :)

Если emacs не катит, то взгляни всё же на Kate. На vim.org точно есть менеджер проектов, и примочки для просмотра тегов/intellisense. Да и на морду vim7 неплох.

Что бы там ни говорили не сделать из вима удобной IDE. Мышка не всегда зло. И хочется это использовать. Я думаю в любом случае медленне чем набираю, а запомнить тучту хоткеев я не могу, даже если я сам их настраивал.

Кстати... Как насчет anjuta, Code::Blocks? Щасс тебе набросают столько названий, что тебе было бы быстрее довести vim до юзабельного состояния :D

На kate я смотрел, но без плагина. Попробую еще раз с плагином.

> не сделать из вима удобной IDE.

<shrug> На vim.org есть плагины для всех перечисленных тобой требований + intellisense.

> Мышка не всегда зло

(недоверчиво) ты не слышал о gvim? Там и мышка, и тулбар...

Анюта падает при попытке ее запустить. Установлена версия из дистрибутива. Попрбую руками собрать попозже.

Code::Blocks это вообще песня - бинарные сборки только под винду, при попытке втянуть дерево исходников ядра виснет минут на 10 после чего падает.

Или ядро это настолько неподъемно?

> Или ядро это настолько неподъемно?

Оно же очень здоровое... Особенно со всеми архитектурами и драйверами. Я думаю, его вообще ни один project manager не всосет (хотя я читал, что Eclipse на это способен). Не говоря уже о том, чтобы проиндексировать - по-моему, на это способны только ctags и производные.

Другое дело - а зачем нужно всё ядро в виде проекта? ИМХО, максимум, что нужно - это конкретная (суб)архитектура. Если же пишешь драйвер или файловую систему - дерево исходников ядра в проекте просто не нужно.

Слышал конечно. От того что vim завернули внутрь окошка он графичнее не стал.

Я не видел 7 вима с его табами, но как-то это по спатрански все - выделывать что-то из по сути консольной проги.

Про стой пример. Можно сделать drop-down list? а фолдинг так, чтобы сворачивание-разворачивание происходило по клику мыши?

Я очень люблю вим и мне не хочется от него отказываться, но я чувствую что он становится для меня не удобным. :(

Ну мне это например понадобилось при портировании его для КПК. Когда что-то не работает причем на низком уровне припопытках что-то найти выстраивается такая цепочка, что забываешь откуда начал.

> От того что vim завернули внутрь окошка он графичнее не стал.

К нему еще прицепили тулбар (IIRC даже не один) и кучу меню. По-моему, вполне графично.

> Можно сделать drop-down list?

Сорри, не понял вопроса

> а фолдинг так, чтобы сворачивание-разворачивание происходило по клику мыши?

Не знаю, но буду сильно удивлен, если нет - делов-то, добавить кнопку на тулбар.

Кстати, вот тебе еще одно название: KScope (kscope.sf.net)

> понадобилось при портировании его для КПК.

Хоть я ничего сложнее драйверов и не писал, но мнение имею - всё равно конкретной архитектуры длжно было хватить 8)

> Сорри, не понял вопроса

В смысле автокомплит сделать не последовательным перебором вариантов, а выбором из выпадающего списка.

> Не знаю, но буду сильно удивлен, если нет - делов-то, добавить кнопку на тулбар.

Вот в том-то и дело. Слишком много компромисов.

> Кстати, вот тебе еще одно название: KScope (kscope.sf.net)

Да, штучка полезная, но как у них на сайте замечено IDE это не заменит. Хотя посмотрю.

Да, после того как я эти финты проделал один раз, в другой естественно проще будет. Но тогда вплоть до main.c приходилось подниматься увешивая все отладочным выводом.

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

А, это.. да, можно. http://www.vim.org/scripts/script.php?script_id=1520 (правда, не знаю, работает ли на Линуксе - но можно поискать и другие похожие на vim.org по ключевому слову intellisense).

> штучка полезная, но как у них на сайте замечено IDE это не заменит

Опять же - твоим требованиям удовлетворяет.

Anjuta. имхо хорошая ИДЕ. сам юзаю. сейчас в убунте нестабильная 2-я ветка, но для работы пока что достаточно. дебаг конечно не очень, но оно и понятно, они в этой ветке нехилый рефакторинг затеяли.

> Оно же очень здоровое... Особенно со всеми архитектурами и драйверами. Я думаю, его вообще ни один project manager не всосет (хотя я читал, что Eclipse на это способен). Не говоря уже о том, чтобы проиндексировать - по-моему, на это способны только ctags и производные.

ну kdevelop да, ядро явно не всосёт. а MSVC или SlikEdit прекрасно всасывают ядро Linux даже не поморщившись. с тегами, перекрёстными ссылками и пр. мелкими радостями.

// wbr

> MSVC или SlikEdit прекрасно всасывают ядро Linux

MSVC? "Не верю" (С) Станиславский.

> MSVC? "Не верю" (С) Станиславский.

khm.. ну это уже ваши личные подробности.
ps: возьмите MSVC 2003 да попробуйте если актуально.

// wbr

> khm.. ну это уже ваши личные подробности.

> ps: возьмите MSVC 2003 да попробуйте если актуально.

Очень может быть, что так и сделаю. Вот только найду машину с Виндой :) А какова практическая цель импорта ядра в MSVC - он его может собрать?

> Очень может быть, что так и сделаю. Вот только найду машину с Виндой :) А какова практическая цель импорта ядра в MSVC - он его может собрать?

наверное, цель такая же, как и в случае со SlikEdit-ом? aka обычный IDE для тех, кто без него не может. собирать ядро MSVC в штатном режиме конечно же не будет, но это в общем то и не актуально.

// wbr

>В смысле автокомплит сделать не последовательным перебором вариантов, а выбором из выпадающего списка.

В седьмом vime это работает из коробки.

>Я не могу набирать сочетания типа Ctrl-A X.

а интересно с кого слизали 3х кнопочные сочетания в MSVS ? Только там вместо комбинаций C-C кнопка используется C-K кнопка :)

jedit

> Про стой пример. Можно сделать drop-down list?

Да.

> а фолдинг так, чтобы сворачивание-разворачивание происходило по клику мыши?

Опять да. Правда не нужно оно. Комбинациями кнопок правильными все равно удобнее.

> Я очень люблю вим и мне не хочется от него отказываться, но я чувствую что он становится для меня не удобным. :(

Был на емаксе, пробовал jEdit. Но сейчас снова на виме, правда уже гВиме. Нормальные табы и красивая подсветка синтаксиса. Потом куча возможностей работы с текстом. Чем больше с ним работаю, тем больше вижу таких фишек, что в других редакторах к ним даже никто не додумался.

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

>>А какова практическая цель импорта ядра в MSVC - он его может собрать?

>наверное, цель такая же, как и в случае со SlikEdit-ом? aka обычный IDE для тех, кто без него не может

Ну со SlickEdit я бы еще понял - он наверняка умеет запускать стандартный make и парсить GNU extensions. Но MSVC? Он же этого не умеет (или умеет всё же)? То есть цель - чисто академическая: доказать, что MSVC это умеет. Так?

> Ну со SlickEdit я бы еще понял - он наверняка умеет запускать стандартный make и парсить GNU extensions. Но MSVC? Он же этого не умеет (или умеет всё же)? То есть цель - чисто академическая: доказать, что MSVC это умеет. Так?

никто не мешает забиндить на желаемую комбинацию клавиш запуск чего-то извне - gmake - и получить желаемое. впрочем, с практической точки зрения применительно к сборки ядра Linux из-под MSVC ценность решения весьма сомнительна. для указанной связки проще собирать проект на честном сервере под Linux и разделять его через SMB или NFS или же использовать тот-же SlikEdit или что-то другое.

// wbr

> никто не мешает забиндить на желаемую комбинацию клавиш запуск чего-то извне - gmake - и получить желаемое. впрочем, с практической точки зрения применительно к сборки ядра Linux из-под MSVC ценность решения весьма сомнительна. для указанной связки проще собирать проект на честном сервере под Linux и разделять его через SMB или NFS или же использовать тот-же SlikEdit или что-то другое.

ps: ядро Linux приводилось лишь как пример более-менее толстого проекта. и если для ядра ведение проекта в MSVC выглядит несколько странным, то для ACE/TAO - которые по объёму ни чуть не меньше - это уже вполне оправдано.

// wbr

> никто не мешает забиндить на желаемую комбинацию клавиш запуск чего-то извне - gmake - и получить желаемое.

Думаю, что так просто не получится - для начала нужно, чтобы MSVC умел разбирать формат вывода ПТГ make и MinGW. Впрочем, как мне кажется, вы не собирали ядро под MSVC. Да пойнт и не в этом, а в том, чтобы получить редактор с поддержкой Си.

Как насчет GNU extensions, которыми набито ядро - MSVC ими не давится?

> Думаю, что так просто не получится - для начала нужно, чтобы MSVC умел разбирать формат вывода ПТГ make и MinGW. Впрочем, как мне кажется, вы не собирали ядро под MSVC. Да пойнт и не в этом, а в том, чтобы получить редактор с поддержкой Си.

нет, я конечно же не собирал Linux из-под MSVC и навряд ли буду этим заниматься в обозримом будущем :) и цель действительно не в том, чтобы собрать ядро а в том, чтобы получить нормальный IDE. впрочем, кому-то и emacs - это то-же нормальный IDE и спорить или переубеждать кого-то в обратном я не намерен. в конце-концов, это дело субъективного вкуса.

> Как насчет GNU extensions, которыми набито ядро - MSVC ими не давится?

мне почему то казалось очевидным, что гипотетическая сборка ядра Linux из-под (sic!) MSVC по всей видимости должна происходить внешним gcc & K а MSVC используется лишь как оболочка.. если это не очевидно и я зря это опустил, прошу прощения.

// wbr

>> Как насчет GNU extensions, которыми набито ядро - MSVC ими не давится?

>мне почему то казалось очевидным, что гипотетическая сборка ядра Linux из-под (sic!) MSVC по всей видимости должна происходить внешним gcc & K

Да это я уже понял :) Я спрашиваю про _парсинг_ - для того, чтобы построить таблицу тегов/функций/итд, для intellisense и прочих вкусностей MSVC должен как-то распарсить исходники. Но в этих исходниках куча GNU extensions - он с ними справляется?

> Да это я уже понял :) Я спрашиваю про _парсинг_ - для того, чтобы построить таблицу тегов/функций/итд, для intellisense и прочих вкусностей MSVC должен как-то распарсить исходники. Но в этих исходниках куча GNU extensions - он с ними справляется?

да вроде справлялся без особых проблем. впрочем, как дойду до работы не сложно проверить ещё раз. SlikEdit то-же справляется. а вот последний Doxygen с большим трудом понимает "извраты" gcc и часто обламывается. даже на банальных обёртках типа fastcall(foo). что конечно несколько удручает и пропускание кода ядра через doxygen на выходе выглядит далеко не столь радужно и полезно, как можно было бы предположить :-/ ну да в сущности и хрен с ним.

// wbr

>> Но в этих исходниках куча GNU extensions - он с ними справляется?

> да вроде справлялся без особых проблем. впрочем, как дойду до работы не сложно проверить ещё раз.

Блин, пока сам не попробую - не поверю.

> пропускание кода ядра через doxygen на выходе выглядит далеко не столь радужно и полезно, как можно было бы предположить :-/ ну да в сущности и хрен с ним.

Яволь! Для нас, угрюмых драйверопейсателей, LDD3 - это наше фсё :)

> Яволь! Для нас, угрюмых драйверопейсателей, LDD3 - это наше фсё :)

LDD конечно книга хорошая и написана доступно и качественно, но драйвера - это далеко не всё ядро. такие ключевые вещи как виртуальная файловая система, управления памятью и пр. и пр. в ней практически отсутствуют бо для написания драйвера, очевидно, нет необходимости разбираться во всех тонкостях работы смежных подсистем. но драйвера - это ещё далеко не всё. да, есть конечно пара книг "про ядро" отличных от LDD. "Understanding the Linux Kernel" например. но написана она на порядок небрежнее чем LDD за счёт чего практической пользы от неё раз два и обчёлся.

ps: за один только fs/namespace.c и struct vfsmount можно расстреливать, а они имеют четкую тенденцию пухнуть и пухнуть..

pps: только не говорите, что в Documentation всё есть - хрена там с Гулькин нос а не документация :-/

// wbr

> драйвера - это далеко не всё ядро

Знаю. Поэтому и рад, что сейчас у нас есть LDD - до нее было гораздо труднее.

> такие ключевые вещи как виртуальная файловая система, управления памятью и пр. и пр. в ней практически отсутствуют

Управление памятью всё-таки есть в LDD3. Кроме того, в Linux оно достаточно "традиционное". Насчет VFS - если вас интересуют _внутренности_ VFS, то ой... Но в какой ОС эти внутренности описаны? IIRC, у вас просто _очень_ необычная, хм, "область приложения" - там просто требуется очень высокая квалификация. Или в других (каких?) ОС с этим легче?

Для написания виртуальных ФС есть libfs, для реальных - достаточно примеров простых ФС в коде ядра.

> ps: за один только fs/namespace.c и struct vfsmount можно расстреливать

Это наезд на Эла Виро? :)

> pps: только не говорите, что в Documentation всё есть

Даже и не собирался.

> Управление памятью всё-таки есть в LDD3. Кроме того, в Linux оно достаточно "традиционное". Насчет VFS - если вас интересуют _внутренности_ VFS, то ой... Но в какой ОС эти внутренности описаны? IIRC, у вас просто _очень_ необычная, хм, "область приложения" - там просто требуется очень высокая квалификация. Или в других (каких?) ОС с этим легче?

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

> Для написания виртуальных ФС есть libfs, для реальных - достаточно примеров простых ФС в коде ядра.

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

> Это наезд на Эла Виро? :)

ни малейшего представления, на кого именно. да и указание конкретной личности сути дела не меняет бо код уже есть и используется заказчиками. о том, что кому-то вдруг может понадобится фильтровать события файловой системы и надстраивать или добавлять свой уровень VFS, разработчики VFS в Linux практически не подумали. а жаль :-/ в некоторых "других" операционных системах это весьма распространённая практика и ею активно пользуются.

ps: впрочем, к выбору IDE это уже не имеет никакого отношения.

// wbr

> о том, что кому-то вдруг может понадобится фильтровать события файловой системы и надстраивать или добавлять свой уровень VFS, разработчики VFS в Linux практически не подумали. а жаль :-/

Я помню минимум 2 проекта stacked fs в Линукс. Ни один не был принят в ядро, но подозреваю, любой из них помог бы вам не меньше IFS DDK из оффтопика.

> ps: впрочем, к выбору IDE это уже не имеет никакого отношения.

Это LOR, здесь к таким вещам подходят неформально :)

> Я помню минимум 2 проекта stacked fs в Линукс. Ни один не был принят в ядро, но подозреваю, любой из них помог бы вам не меньше IFS DDK из оффтопика.

название проектов?

ps: будет жаль, если один из них - это студенческое поделие FiST..

// wbr

>название проектов?

>ps: будет жаль, если один из них - это студенческое поделие FiST..

wrapfs и unionfs. (шарится в гугле) Да, похоже wrapfs как-то относится к FiST. Правда, "студенческими поделиями" можно назвать и Mach, и Linux, да и не их одних, наверное. Что не так с FiST - она не работала, или была не тем, что надо?

Судя по тому, что я нагуглил, к stacked fs относится и eCryptfs (вроде написана в IBM).

> "Understanding the Linux Kernel" например. но написана она на порядок небрежнее чем LDD за счёт чего практической пользы от неё раз два и обчёлся.

Я и LDD-то с трудом воспринимаю (насколько я помню там даже одним куском не приведен исходник ни одного драйвера, только отрывки).

Зато "Разработка ядра linux" Р. Лав. читается легко и описывает структуру ядра весьда хорошо.

> Я и LDD-то с трудом воспринимаю (насколько я помню там даже одним куском не приведен исходник ни одного драйвера, только отрывки).

Насколько я знаю, к книге прилагается архив с исходниками всех учебных драйверов (есть где-то на сайте О'Рейли).

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

PS: Кстати, этим драйвером оказался драйвер биореактора (ищется на ЛОРе). :)))

> wrapfs и unionfs. (шарится в гугле) Да, похоже wrapfs как-то относится к FiST. Правда, "студенческими поделиями" можно назвать и Mach, и Linux, да и не их одних, наверное. Что не так с FiST - она не работала, или была не тем, что надо?

понятно. обе идут в FiST как попытка продемонстрировать его возможности. слава Богу, что разработчики ядра не включили Это.

http://www.am-utils.org/project-fist.html

а что такое FiST... это попытка впихнуть невпихуемое, написать под это дело десяток статей, распиарить их по юзенету в виде себя любимого & K, добрать до кучи бабла на грантах и в результате не сделать ровным счётом ничего, что можно было бы хоть как-то использовать даже по частям и в лучшем случае организовать площадку для защиты своим студентам :-/

> Судя по тому, что я нагуглил, к stacked fs относится и eCryptfs (вроде написана в IBM).

этого я не смотрел, ничего не могу сказать.

// wbr

>> wrapfs и unionfs.

>понятно. обе идут в FiST как попытка продемонстрировать его возможности. слава Богу, что разработчики ядра не включили

Судя по тому, что я читал, unionfs интенсивно развивается, используется (как минимум) в Кноппиксе и недавно представлена для включения в ядро.

> а что такое FiST... это попытка впихнуть невпихуемое ... в результате не сделать ровным счётом ничего

Проект явно вас разочаровал :) (хотя и непонятно, почему). Но unionfs реально используется, так что она хоть как-то, но работает.

> Судя по тому, что я читал, unionfs интенсивно развивается, используется (как минимум) в Кноппиксе и недавно представлена для включения в ядро.

кхм... ну-ну :)

в любом случае, FiST & K равно как и самой идеи организовать уровень расширения за счёт наращивания очередной файловой системы поверх текущего дизайна VFS ничего не светит. бо любое подобное решение ломает семантику низлежащей файловой системы с точки зрения конечного пользователя и, как следствие, далеко не всегда применимо. и уж до сравнительно универсального IFS DDK ему как пешком до Китая :-/

> Проект явно вас разочаровал :) (хотя и непонятно, почему).

посмотрите их код и что это из себя реально представляет, а не статьи комрадо кормчего о том, как всё чудесно и замечательно в проекте FiST.. :-/ код темплейтов Linux 2.4/2.6 - это просто праздник какой-то и больше чем на защиту нерадивого студента "типа отстрелялся" он не тянет. а что генерит fistgen.. мнда. с учётом того, что студентов видать было много и письмо дяди Фёдора разрослось до неприличных по царящему в нём бардаку размеров..

> Но unionfs реально используется, так что она хоть как-то, но работает.

а толку то. union fs и в *BSD есть причём уже родной и существенно Более продвинутый и вылизанный. но это не решение в случае, когда вам нужно расширить или модифицировать функциональность уже существующего уровня VFS. причём сделать это полностью прозрачно для конечного пользователя. наслоение дополнительных точек монтирования здесь просто не прокатывает.

// wbr