docs/kdevelop/kdevelop/unixdev.docbook

   1 <appendix id="unixdev">
   2
   3 <appendixinfo>
   4   <authorgroup>
   5     <author
   6 ><firstname
   7 >Bernd</firstname
   8 ><surname
   9 >Pol</surname
  10 ></author>
  11     <!-- ROLES_OF_TRANSLATORS -->
  12   </authorgroup>
  13 </appendixinfo>
  14
  15 <title
  16 >Разработка ПО в &UNIX;</title>
  17
  18 <indexterm zone="unixdev"
  19 ><primary
  20 >разработка</primary
  21 ></indexterm>
  22 <indexterm zone="unixdev">
  23   <primary
  24 >&UNIX;</primary>
  25   <secondary
  26 >программирование</secondary
  27 ></indexterm>
  28
  29 <sect1 id="history">
  30 <title
  31 >Исторические замечания</title>
  32
  33 <indexterm zone="history"
  34 ><primary
  35 >история</primary
  36 ></indexterm>
  37 <indexterm zone="history"
  38 ><primary
  39 >языки сценариев</primary
  40 ></indexterm>
  41 <indexterm zone="history">
  42   <primary
  43 >&UNIX;</primary>
  44   <secondary
  45 >история</secondary
  46 ></indexterm>
  47 <indexterm zone="history">
  48   <primary
  49 >&UNIX;</primary>
  50   <secondary
  51 >конфейер</secondary
  52 ></indexterm>
  53 <indexterm zone="history">
  54   <primary
  55 >&UNIX;</primary>
  56   <secondary
  57 >оболочка</secondary
  58 ></indexterm>
  59 <indexterm zone="history">
  60   <primary
  61 >shell</primary>
  62   <secondary
  63 >&UNIX;</secondary
  64 ></indexterm>
  65
  66 <para
  67 >С самого начала, программы в &UNIX; разделились на два разных типа. Один тип &mdash; это мир <emphasis
  68 >языков программирования системы и приложений</emphasis
  69 >, где некоторый исходный код транслируется в машинный транслирующей программой, <emphasis
  70 >компилятором</emphasis
  71 > или <emphasis
  72 >интерпретатором</emphasis
  73 >. Примером является язык программирования C. &UNIX; была первой ОС, написанной на таком языке высокого уровня (относительно), вместо ассемблера, ориентированного на конкретную машину (на самом деле одним из изначальных назначений языка C было написание ядра &UNIX; и вспомогательных программ на машинах DEC PDP-11). </para>
  74 <para
  75 >Второй тип &mdash; это мир <emphasis
  76 >сценариев</emphasis
  77 > (скриптов). Он развился с приходом оболочки &UNIX; (shell), которая являлась интерфейсом пользователя к ОС &mdash; и в то же время языком программирования очень высокого уровня. Сценарии используют набор маленьких утилит, таких как <command
  78 >grep</command
  79 >, <command
  80 >sed</command
  81 > и <command
  82 >find</command
  83 >, каждая из которых создана для конкретной задачи. Хитрость заключается в том, что любая такая программа может быть соединена с другой посредством простого транспортного механизма, который называется <emphasis
  84 >конвейером</emphasis
  85 >, суть его заключается в том, что он перенаправляет вывод одной программы на ввод другой. Это есть основа многофункциональности и гибкости инструмента. </para>
  86 <para
  87 >С течением времени, оба мира бурно развивались. Язык C до сих пор используется преимущественно в качестве системного язык программирования, тогда как C++ &mdash; дальнейшее развитие C, воплощающее объектно-ориентированную модель программирования, &mdash; с начала 90-ых используется при программировании сложных структурированных систем. Кроме того, осталась поддержка многих других языков программирования, даже таких, как FORTRAN77 и Ada, которые всё ещё используются в некоторых областях. </para>
  88 </sect1
  89 > <!-- history -->
  90
  91 <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
  92
  93 <sect1 id="unixdev-scripting-languages">
  94 <title
  95 >Современные языки сценариев</title>
  96 <para
  97 >Ну, а в мире сценариев произошла перестановка, от оболочки, недостатком которой было отсутствие полной переносимости, до языков, которые унифицируют всю общую необходимую функциональность в своих стандартных библиотеках, оставляя возможность прибегать к конвейерному механизму. </para>
  98 <para
  99 >Общее всех этих сценарных языков &mdash; их переносимость между клонами &UNIX;, Microsoft &Windows;, &MacOS;, или даже VMS. Также, для всех их доступны свободно распространяемые реализации. </para>
 100
 101 <sect2 id="unixdev-SL-Perl">
 102 <title
 103 >&perl;</title>
 104
 105 <indexterm zone="unixdev-SL-Perl"
 106 ><primary
 107 >Perl</primary
 108 ></indexterm>
 109 <indexterm zone="unixdev-SL-Perl">
 110   <primary
 111 >языки сценариев</primary>
 112   <secondary
 113 >Perl</secondary
 114 ></indexterm>
 115
 116 <para
 117 ><ulink url="http://www.perl.com"
 118 >&perl;</ulink
 119 > популярен как язык обработки текста и, следовательно, системного администрирования. На заре World Wide Web, CGI-скрипты на &perl; использовались для генерирования динамических web-страниц на основе базы данных. Сегодня такой метод реализован в виде модуля <command
 120 >mod_perl</command
 121 > web-сервера &apache;. Среди сильных сторон &perl;'а &mdash; его встроенная поддержка расширенных регулярных выражений и богатый архив свободных модулей к нему, для подробностей см.: <ulink url="http://cpan.org"
 122 >Comprehensive Perl Archive Network (CPAN)</ulink
 123 >. </para>
 124
 125 </sect2
 126 > <!-- unixdev-SL-Perl -->
 127
 128 <sect2 id="unixdev-SL-Python">
 129 <title
 130 >Python</title>
 131
 132 <indexterm zone="unixdev-SL-Python"
 133 ><primary
 134 >Python</primary
 135 ></indexterm>
 136 <indexterm zone="unixdev-SL-Python">
 137   <primary
 138 >языки сценариев</primary>
 139   <secondary
 140 >Python</secondary
 141 ></indexterm>
 142
 143 <para
 144 ><ulink url="http://www.python.org"
 145 >&python;</ulink
 146 > отличается элегантностью классовой системы, лёгкостью и гибкостью, с которой можно внешние библиотеки могут быть подключены &mdash; к ним можно обращаться как к стандартным классам и функциям &python;. В отличие от &perl;, &python; имеет прозрачный и сконцентрированный встроенный &API;, что делает его прекрасным средством поддержки сценариев для программ, написанных на C и C++, . </para>
 147 </sect2
 148 > <!-- unixdev-SL-Python -->
 149
 150 <sect2 id="unixdev-SL-PHP">
 151 <title
 152 >PHP</title>
 153
 154 <indexterm zone="unixdev-SL-PHP"
 155 ><primary
 156 >PHP</primary
 157 ></indexterm>
 158 <indexterm zone="unixdev-SL-PHP">
 159   <primary
 160 >языки сценариев</primary>
 161   <secondary
 162 >PHP</secondary
 163 ></indexterm>
 164
 165 <para
 166 ><ulink url="http://www.php.net"
 167 >&php;</ulink
 168 > встраивается прямо в &HTML;-страницы, и, следовательно, применяется для генерирования динамических web-страниц. </para>
 169 </sect2
 170 > <!-- unixdev-SL-PHP -->
 171 </sect1
 172 > <!-- unixdev-scripting-languages -->
 173
 174 <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
 175 <sect1 id="unixdev-hl-script">
 176 <title
 177 >Высокоуровневые сценарии</title>
 178
 179 <para
 180 >Высокоуровневые приложения обычно более медлительные и не так гибки в применении. Это проявляется в мире программ с графическим пользовательским интерфейсом (GUI), таких как &kde;. </para>
 181 <para
 182 >Потребность в некоем подобии конвейеров низкоуровневых консольных программ для высокоуровневых приложений привела к появлению <link linkend="unixdev-corba"
 183 >CORBA</link
 184 > и, позже в среде &kde;, <link linkend="unixdev-dcop"
 185 >&DCOP;</link
 186 >. </para>
 187
 188 <sect2 id="unixdev-corba">
 189 <title
 190 >Протокол CORBA</title>
 191
 192 <indexterm zone="unixdev-corba"
 193 ><primary
 194 >CORBA</primary
 195 ></indexterm>
 196 <indexterm zone="unixdev-corba">
 197   <primary
 198 >языки сценариев</primary>
 199   <secondary
 200 >CORBA</secondary
 201 ></indexterm>
 202 <indexterm zone="unixdev-corba">
 203   <primary
 204 >связь</primary>
 205   <secondary
 206 >CORBA</secondary
 207 ></indexterm>
 208
 209 <para
 210 ><ulink url="http://www.omg.org/gettingstarted/corbafaq.htm"
 211 >CORBA</ulink
 212 > (<emphasis
 213 >Common Object Request Broker Architecture</emphasis
 214 >) - это механизм, позволяющий разным программам работать совместно через сеть. Он разработан комитетом стандартов <ulink url="http://www.omg.org"
 215 >OMG</ulink
 216 > (Object Management Group). </para>
 217 <para
 218 >Программы, поддерживающие CORBA, используют протокол IIOP для связи. Реализации, основанные на IIOP, есть для многих операционных систем, языков программирования, и сетей, что делает его хорошо переносимым. </para>
 219 <para
 220 >Основной недостаток CORBA - это его очень низкая скорость. Возможно это не так существенно. в сетях с мощными серверами, но на обычных компьютерах, для которых предназначен &kde;, это является главным. </para>
 221
 222 </sect2
 223 > <!-- unixdev-corba -->
 224
 225 <sect2 id="unixdev-dcop">
 226 <title
 227 >Интерфейс &DCOP;</title>
 228
 229 <indexterm zone="unixdev-dcop"
 230 ><primary
 231 >DCOP</primary
 232 ></indexterm>
 233 <indexterm zone="unixdev-dcop">
 234   <primary
 235 >языки сценариев</primary>
 236   <secondary
 237 >DCOP</secondary
 238 ></indexterm>
 239 <indexterm zone="unixdev-dcop">
 240   <primary
 241 >связь</primary>
 242   <secondary
 243 >DCOP</secondary
 244 ></indexterm>
 245
 246 <para
 247 >Протокол <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
 248 ><emphasis
 249 >DCOP</emphasis
 250 ></ulink
 251 > разработан для связи и более тесной интеграции между приложениями &kde;, т.к. использование медленного CORBA, имеющего ряд ограничений, привело бы к всеобщей "неподъёмности" &kde; на обычных компьютерах. </para>
 252 <para
 253 >&DCOP; расшифровывается как <emphasis
 254 >Desktop COmmuniсation Protocol</emphasis
 255 > (протокол связи рабочих станций). Он реализован как простой механизм IPC/RPC, построенный для оперирования сокетами. Словом, он обеспечивает удобства схожие с традиционным конвейерным механизмом &UNIX;. </para>
 256 <para
 257 >Традиционные сценарии основываются на очень маленьких программах, которые были созданы для работы на строго текстовой основе. &DCOP; позволяет графическим программам связываться между собой схожим путём. Т.е. одна &kde;-программа может посылать сообщения другой (возможно своей копии), и сама получать и обрабатывать данные от неё. </para>
 258 <para
 259 >Однако у такого метода всё же есть и недостатки &mdash; для использования &DCOP; в программу нужно встроить специальный код интерфейса &DCOP;. Кроме того, связь происходит несколько медленно (но значительно быстрее CORBA), хотя, в свою очередь, она даёт мощь и гибкость сценариев &UNIX; высокоуровневым программам с графическим пользовательским интерфейсом. </para>
 260 <para
 261 >Для подробностей см. <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html"
 262 >DCOP: Desktop COmmunications Protocol</ulink
 263 > или <ulink url="developer.kde.org/documentation/library/cvs-api/dcop/html/index.html"
 264 > &API;-справочник библиотеки &DCOP;</ulink
 265 >. </para>
 266 </sect2
 267 > <!--  unixdev-dcop -->
 268
 269 </sect1
 270 > <!--  unixdev-hl-script -->
 271
 272 <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
 273
 274 <sect1 id="unixdev-buildsystems">
 275 <title
 276 >Системы сборки</title>
 277
 278 <para
 279 >Кроме самых простых случаев, ваш проект будет состоять из множества блоков исходного кода, разделённых по нескольким файлам для удобства сопровождения. Для преобразования исходного кода в машинный, нужно транслировать всё это в несколько машинных модулей в удобном для чтения операционной системой формате. </para>
 280 <para
 281 >Для этого как минимум требуется <itemizedlist>
 282   <listitem
 283 ><para
 284 ><emphasis
 285 >текстовый редактор</emphasis
 286 > &mdash; для написания исходного кода, </para
 287 ></listitem>
 288   <listitem
 289 ><para
 290 >транслирующая программа, обычно это <emphasis
 291 >компилятор</emphasis
 292 >, &mdash; для преобразования исходного кода в объектные файлы, </para
 293 ></listitem>
 294   <listitem
 295 ><para
 296 ><emphasis
 297 >библиотекарь</emphasis
 298 > &mdash; для сборки объектных файлов в библиотеки для последующего их использования без необходимости перекомпилирования, </para
 299 ></listitem>
 300   <listitem
 301 ><para
 302 ><emphasis
 303 >компоновщик</emphasis
 304 > &mdash; связки нескольких объектных файлов и библиотек в один исполнимый файл, </para
 305 ></listitem>
 306   <listitem
 307 ><para
 308 ><emphasis
 309 >система сборки</emphasis
 310 >, претендующая на управление всем этим "добром", и </para
 311 ></listitem>
 312   <listitem
 313 ><para
 314 ><emphasis
 315 >отладчик</emphasis
 316 > &mdash; чтобы найти (надеемся) все ошибки в исходных кодах, и, возможно, другие диагностические утилиты для последующей оптимизации кода. </para
 317 ></listitem>
 318 </itemizedlist>
 319 </para>
 320
 321 <para
 322 >Когда у вас имеется большой проект, состоящий из возможно сотен исходных файлов, процесс компиляции может быть медлительным. Не нужно компилировать заново все файлы когда был изменён только один, вместо этого следует компилировать файлы, которые были затронуты изменениями. На самом деле это не так очевидно, как кажется на первый взгляд. </para>
 323 <para
 324 >Например, если вы изменили прототип функции  в заголовке, нужно перекомпилировать каждый файл, включающий этот заголовок. И если в проекте таких файлов много, легко пропустить один делая это вручную. Сборочная система обеспечивает автоматизацию такой работы. </para>
 325
 326 <sect2 id="unixdev-buildsystems-make">
 327 <title
 328 >Процесс сборки</title>
 329
 330 <indexterm zone="unixdev-buildsystems-make">
 331   <primary
 332 >make</primary
 333 ></indexterm>
 334 <indexterm zone="unixdev-buildsystems-make">
 335   <primary
 336 >Makefile</primary
 337 ></indexterm>
 338 <indexterm zone="unixdev-buildsystems-make">
 339   <primary
 340 >правило</primary
 341 ></indexterm>
 342 <indexterm zone="unixdev-buildsystems-make">
 343   <primary
 344 >перекомпиляция</primary
 345 ></indexterm>
 346 <indexterm zone="unixdev-buildsystems-make">
 347   <primary
 348 >target (целевой)</primary
 349 ></indexterm>
 350 <indexterm zone="unixdev-buildsystems-make">
 351   <primary
 352 >зависимости</primary
 353 ></indexterm>
 354 <indexterm zone="unixdev-buildsystems-make">
 355   <primary
 356 >команды</primary
 357 ></indexterm>
 358
 359 <para
 360 >Инструмент, выполняющий перекомпиляцию называется <command
 361 >make</command
 362 >. Его работа управляется специальными <emphasis
 363 >правилами</emphasis
 364 >, которые описывают необходимые действия в случае изменения определённой информации (обычно объектного файла или файла исходного кода). Все правила, принадлежащие определённому проекту записываются в т.н. <filename
 365 >Makefile</filename
 366 >, который обрабатывается  командой <command
 367 >make</command
 368 > в любое время когда вы хотите обновить вашу работу. </para>
 369 <para
 370 >Каждое правило состоит из нескольких сборочных блоков, а именно <itemizedlist>
 371   <listitem
 372 ><para
 373 ><emphasis
 374 >целевого</emphasis
 375 >(<emphasis
 376 >target</emphasis
 377 >), т.е. файла, который нужно собрать </para
 378 ></listitem>
 379   <listitem
 380 ><para
 381 >набора <emphasis
 382 >зависимостей</emphasis
 383 >, обычно это имена файлов, от которых зависит целевой (target), например это может быть имя исходного файла, где целевой будет упомянут как объектный, </para
 384 ></listitem>
 385   <listitem
 386 ><para
 387 ><emphasis
 388 >команд</emphasis
 389 >, которые выполняются для <quote
 390 >сборки</quote
 391 > целевого файла (например его компиляции или компоновки нескольких объектных файлов). </para
 392 ></listitem>
 393 </itemizedlist>
 394 </para>
 395 <para
 396 >Обычно команда <command
 397 >make</command
 398 > читает правила, одно за другим, проверяет каждый файл из списка зависимостей конечного файла и собирает его заново если хотя бы один файл из списка зависимостей был изменён. </para>
 399 <para
 400 >В больших проектах <filename
 401 >Makefile</filename
 402 > может стать очень большим и сложным. Мы не можем здесь углубляться в подробности, однако рекомендуем вам изучить хотя бы основы синтаксиса <command
 403 >make</command
 404 >. Даже если вы не используете его напрямую, понимание принципов системы сборки вам должно пригодиться. Для подробностей см. <ulink url="info://make/Top"
 405 > <quote
 406 >GNU Make Manual</quote
 407 ></ulink
 408 >. </para>
 409 <para
 410 >Для подробностей, касающихся &kdevelop;, см. главу <link linkend="project-management"
 411 >Сборка и управление проектом</link
 412 >. </para>
 413 <para
 414 >Доступно несколько руководств, см. в главе <link linkend="automake-references"
 415 >Сборка и управление проектом</link
 416 >. </para>
 417 </sect2
 418 > <!-- unixdev-buildsystems-make -->
 419
 420 </sect1
 421 > <!-- unixdev-buildsystems -->
 422
 423 <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
 424
 425 <sect1 id="unixdev-guidevelopment">
 426 <title
 427 >Объектно-ориентированное программирование</title>
 428
 429 <indexterm zone="unixdev-guidevelopment">
 430   <primary
 431 >GUI</primary
 432 ></indexterm>
 433 <indexterm zone="unixdev-guidevelopment">
 434   <primary
 435 >графический пользовательский интерфейс</primary
 436 ></indexterm>
 437 <indexterm zone="unixdev-guidevelopment">
 438   <primary
 439 >пользовательский интерфейс</primary>
 440   <secondary
 441 >GUI</secondary
 442 ></indexterm>
 443
 444 <para
 445 >Разработчики программного обеспечения вынуждены создавать не только библиотеки и алгоритмы, но и удобный пользовательский интерфейс, гибкий и интуитивный. Однако большинство программистов не удаляют этому большого внимания, и, как результат, хорошие программы имеют <ulink url="http://www.rha.com/ui_hall_of_shame.htm"
 446 >бедный дизайн</ulink
 447 >. </para>
 448 <para
 449 >На протяжении годов, были выработаны некоторые общие принципы реализации интерфейса. Настоятельно рекомендуется придерживаться их. Таким образом ваши пользовательские интерфейсы будут сохранять общий вид и интуитивность, что непременно будет оценено пользователями. </para>
 450 <para
 451 >Визуальная разработка &kde; также имеет свои принципы. Их можно найти на <ulink url="http://developer.kde.org/documentation/standards/kde/style/basics/index.html"
 452 >странице принципов дизайна пользовательского интерфейса</ulink
 453 > в уголке разработчика &kde;. </para>
 454 <para
 455 >Краткое введение в дизайн графического пользовательского интерфейса можно найти <ulink url="http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm"
 456 >здесь</ulink
 457 >, либо <ulink url="http://russian.joelonsoftware.com/"
 458 >здесь</ulink
 459 > (больший уклон в сторону умирающей ОС). </para>
 460
 461 </sect1
 462 > <!-- unixdev-guidevelopment -->
 463
 464 <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
 465
 466 <sect1 id="unixdev-ide">
 467 <title
 468 >Концепции и средства интегрирования: IDE</title>
 469
 470 <indexterm zone="unixdev-ide">
 471   <primary
 472 >IDE</primary
 473 ></indexterm>
 474 <indexterm zone="unixdev-ide">
 475   <primary
 476 >интегрированная среда разработки</primary
 477 ></indexterm>
 478 <indexterm zone="unixdev-ide">
 479   <primary
 480 >разработка</primary>
 481   <secondary
 482 >IDE</secondary
 483 ></indexterm>
 484 <indexterm zone="unixdev-ide">
 485   <primary
 486 >окружение</primary>
 487   <secondary
 488 >IDE</secondary
 489 ></indexterm>
 490
 491 <para
 492 >Для каждого этапа процесса программирования существует множество отдельных инструментов &mdash; планирование, редактирование, управление файлами и компилирование (сборка), отладка, документирование и т.д. Однако по мере роста проекта, он (почти всегда) становится громоздким, и процесс его дальнейшего программирования становится затруднительным. </para>
 493 <para
 494 >Наиболее повторяющаяся работа проделывается при проектировании, компилировании и отладке программы. Большую часть такой работы можно автоматизировать используя шаблоны и сценарии. Другую большую часть &mdash; наличием инструментов. способных связываться один с другим через общий визуальный интерфейс (GUI). </para>
 495 <para
 496 >К примеру, действительно удобно, когда отладчик может открыть исходный код в редакторе и расположить курсор в месте, где произошла ошибка. </para>
 497 <para
 498 >Такую схему совершенствуют <emphasis
 499 >интегрированные среды разработки</emphasis
 500 > (&IDE;). Они собирают воедино все шаблоны, инструменты и сценарии, необходимые для продуктивного процесса разработки. </para>
 501 <para
 502 >Для всевозрастающей платформы &kde; таким &IDE; является &kdevelop;. Эта среда разработки содержит широкий набор инструментов, обеспечивая простое окружение разработки и сопровождения ПО, использующего разные языки программирования и платформы. </para>
 503
 504 <sect2 id="unixdev-ide-kdevelop">
 505 <title
 506 >Основные возможности &kdevelop; &kdevrelease;</title>
 507
 508 <indexterm zone="unixdev-ide-kdevelop">
 509   <primary
 510 >&kdevelop;</primary>
 511   <secondary
 512 >возможности</secondary
 513 ></indexterm>
 514 <indexterm zone="unixdev-ide-kdevelop">
 515   <primary
 516 >возможности</primary
 517 ></indexterm>
 518
 519 <!-- ### copied from web page, needs to be updated -->
 520
 521 <itemizedlist>
 522   <listitem>
 523   <para
 524 >Управление всеми <emphasis
 525 >средствами разработки</emphasis
 526 > на языке C++, такими как компилятор, компоновщик, отладчик и система сборки</para>
 527   </listitem>
 528   <listitem>
 529   <para
 530 ><emphasis
 531 >Мастер приложений</emphasis
 532 >, упрощающий создание новых программ</para>
 533   </listitem>
 534   <listitem>
 535   <para
 536 ><emphasis
 537 >Интегрированный редактор</emphasis
 538 >, основанный на редакторе &kwrite;, <application
 539 >QEditor</application
 540 > от Trolltec или другой.</para>
 541   </listitem>
 542   <listitem>
 543   <para
 544 ><emphasis
 545 >Генератор классов</emphasis
 546 >, для создания новых классов и интегрирования их в проект</para>
 547   </listitem>
 548   <listitem>
 549   <para
 550 ><emphasis
 551 >Управление</emphasis
 552 > исходными, заголовочными <emphasis
 553 >файлами</emphasis
 554 >, документацией и т.д.</para>
 555   </listitem>
 556   <listitem>
 557   <para
 558 >Помощь при <emphasis
 559 >написании руководства приложения</emphasis
 560 > средствами &kde;</para>
 561   </listitem>
 562   <listitem>
 563   <para
 564 >Автоматическое генерирование <emphasis
 565 >&API;-документации</emphasis
 566 > в формате &HTML;, включающей описания классов проекта и перечня используемых библиотек</para>
 567   </listitem>
 568   <listitem>
 569   <para
 570 ><emphasis
 571 >Поддержка интернационализации</emphasis
 572 >, &kbabel;</para>
 573   </listitem>
 574   <listitem>
 575   <para
 576 >Поддержка управления проектом через <emphasis
 577 >систему управления версиями</emphasis
 578 > (например, &CVS;)</para>
 579   </listitem>
 580   <listitem>
 581   <para
 582 >Встроенный интерфейс к <emphasis
 583 >отладчику</emphasis
 584 >.</para>
 585   </listitem>
 586   <listitem>
 587   <para
 588 >Встроенный эмулятор <emphasis
 589 >консоли</emphasis
 590 >.</para>
 591   </listitem>
 592   <listitem>
 593   <para
 594 ><emphasis
 595 >Синтаксическая подсветка</emphasis
 596 > в файлах исходного кода.</para>
 597   </listitem>
 598   <listitem>
 599   <para
 600 ><emphasis
 601 >Автодополнение кода</emphasis
 602 > для переменных класса, его методов, аргументов функций и т.п.</para>
 603   </listitem>
 604   <listitem>
 605   <para
 606 ><emphasis
 607 >Шаблоны для конкретных задач</emphasis
 608 > (написание модулей &kcontrol;, &konqueror;, апплетов &kicker;, KIO, а также стилей рабочего стола)</para>
 609   </listitem>
 610   <listitem>
 611   <para
 612 >Четыре <emphasis
 613 >дерева информации</emphasis
 614 >, для наглядного разделения исходных, заголовочных файлов, классов и документации, что позволяет отказаться от внешнего проводника</para>
 615   </listitem>
 616   <listitem>
 617   <para
 618 ><emphasis
 619 >Кросс-компилирование</emphasis
 620 >, с возможностью указания разных компиляторов, их ключей, архитектуры процессора и т.п.</para>
 621   </listitem>
 622   <listitem>
 623   <para
 624 >Поддержка проектов <emphasis
 625 >Qt/Embedded</emphasis
 626 > (таких как Zaurus и iPAQ).</para>
 627   </listitem>
 628   <listitem>
 629   <para
 630 >Простота использования <emphasis
 631 >внешних программ</emphasis
 632 >, в виде добавления их в меню <guimenuitem
 633 >Сервис</guimenuitem
 634 >.</para>
 635   </listitem>
 636 </itemizedlist>
 637
 638 </sect2
 639 > <!-- unixdev-ide-kdevelop -->
 640
 641 </sect1
 642 > <!-- unixdev-ide -->
 643
 644 </appendix
 645 > <!-- unixdev -->
 646