(Читать комментарии) - (Добавить комментарий)

	tiphareth 2007-11-29 02:29 (ссылка)
	Ну а чего, нормально, в принципе, я считаю. В Линуксе много чего сделать нельзя. Игрушки к примеру только старые, а полиграфии вовсе нет У нас в департменте у IT именно такой сетап. Нужно какой-нибудь ворд гнойный посмотреть, запускают вымыварь, а так спокойно работают. Такие дела Миша (Ответить) (Уровень выше) (Ветвь дискуссии)

	russkiy 2007-11-29 05:31 (ссылка)
	Есть полиграфия. Корела нету, правда. А полиграфия есть. Ворд гнойный смотрится ОО.о.2.3 без каких-либо проблем. Так что пиздов давайте айти своему чаще. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-11-29 05:35 (ссылка)
	Полиграфия либо без CMYK (Gimp), либо дохлая (Killustrator). OO тормозит и сосет и несовмещается. И вызывает какую-то чертову идиотскую прорву гномосексуальных утилит, которые потом приходится отдельно вручную убивать. Я у себя поставил abiword+catdoc, а OO вообще нахер снес. Такие дела Миша (Ответить) (Уровень выше) (Ветвь дискуссии)

	siraenuhlaalu.livejournal.com 2007-11-29 06:02 (ссылка)
	Полиграфия? Тогда наверно scribus или нечто навроде. (Ответить) (Уровень выше) (Ветвь дискуссии)

	yushi 2007-11-29 06:24 (ссылка)
	Scribus пока неработоспособен (нет спуска полос и ещё ряда столь же востребованных фич), хотя, говорят, скоро будет. LaTeX — сверстайте-ка в LaTeX обложку (или буклет) для диска, Мише, насколько я понимаю, именно для этих целей. А лезть в потроха TeX/MetaPost — всё же развлечение не для слабонервных… (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-11-29 06:27 (ссылка)
	Я, кстати, верстал. Но там некоторых вещей нет довольно фатально, и потроха не помогут. Ну, и с цветом такие напряги, что лучше и не пробовать Такие дела Миша (Ответить) (Уровень выше)

	siraenuhlaalu.livejournal.com 2007-11-29 06:02 (ссылка)
	опять же, LaTeX никто не отменял (Ответить) (Уровень выше) (Ветвь дискуссии)

	kaledin 2007-11-29 06:38 (ссылка)
	LaTeX ochen' khorosho rabotaet dlya verstki teksta -- dlya chego sobstvenno i -- i sovershenno neprigoden dlya verstki chego-nibud' s bol'shim kolichestvom kartinok. (Ответить) (Уровень выше) (Ветвь дискуссии)

	yushi 2007-11-29 06:45 (ссылка)
	Ну, вообще говоря, тот же "Добросвет" издал недавно книжку по истории архитектуры с сотнями картинок, свёрстанную в LaTeX'е, и ничего, очень прилично всё. Но глянцевый журнал в *TeX было бы верстать мучительно, да. (Ответить) (Уровень выше) (Ветвь дискуссии)

tiphareth 2007-11-29 06:58 (ссылка)

Я Антикопирайт под LaTeX верстал, там картинок штук 60. Ничего так. Но ни одно издательство его, естественно не возьмет, они с постскриптом и PDF обращаться не умеют вовсе. Покойная Ультра-Культура пересобирала текст вручную (и добавила там зачем-то опечаток по 10 штук на странице). Моими молитвами, она сдохла до того, как это безобразие там появилось Такие дела Миша (Ответить) (Уровень выше) (Ветвь дискуссии)

	spqr 2007-11-29 09:24 (ссылка)
	А можно где-нибудь его выложить в исходниках? (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-12-01 00:45 (ссылка)
	Он там лежит с самого начала (на афиширую, ибо не хочу отвечать на вопросы о TeXе) http://imperium.lenin.ru/LENIN/32/C/VERSTKA/ Такие дела Миша (Ответить) (Уровень выше) (Ветвь дискуссии)

	spqr 2007-12-03 10:44 (ссылка)
	Спасибо. (Ответить) (Уровень выше)

yushi 2007-11-29 14:45 (ссылка)

Но ни одно издательство его, естественно не возьмет, они с постскриптом и PDF обращаться не умеют вовсе. Ну, строго говоря, они в своём праве; PostScript и PDF — это, в меру моего понимания, способ общения с типографией, а не издательством. А в издательство надо отдавать LaTeX'овский исходник, для редактуры, корректуры и вёрстки. Другой вопрос, что таких издательств, в которых хотя бы слышали слово "LaTeX", в России два или три. (Ответить) (Уровень выше)

	tiphareth 2007-11-29 07:00 (ссылка)
	Ну, отчасти пригоден, но только при условии, что все картинки - врезки. Если картинок больше 1-2 на страницу, он закономерно падает с копыт, ибо floats тут бессилен (Ответить) (Уровень выше)

	tristes_tigres 2007-11-29 22:56 (ссылка)
	Поисследуйте как-нибудь на досуге ситуацию со шрифтами под TeXом (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-11-29 23:06 (ссылка)
	Да нормальная в общем ситуация. Пакета 2-3 есть, а для верстания статей больше и не нужно. Плохие, правда, но это никому не видно, кроме профи. А кому нужно еще шрифты, есть же метафонт. Обложки на ТеXе рисовать никак нельзя конечно, но это и со шрифтами. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tristes_tigres 2007-11-29 23:19 (ссылка)
	Не нужно быть профи, чтобы заметить, что "Computer Modern" выглядит не особо. Lucida Bright же только за деньги. > А кому нужно еще шрифты, есть же метафонт. А кому захотелось кушать, может сам посеять хлебушек, собрать урожай, размолоь и напечь лепёшек. Разработка шрифтов это полноценная нетривиальная профессия. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-12-01 01:05 (ссылка)
	Шрифт, которым я пользуюсь, написан Шенем a_shen@lj (Ответить) (Уровень выше)

yushi 2007-11-29 06:36 (ссылка)

Killustrator Миша, не пинай труп. Вектор в Линуксе — это Inkscape и sk1 (если кто-то подхватит Xara Xtreme, то будет ещё и она, но пока это такой памятник деревянного зодчества, годный только на то, чтобы напоминать, как выглядит действительно приличный интерфейс), а растр — Krita, конечно, а вовсе не GIMP. Ты давно на вышеперечисленные продукты смотрел? Они, в отличие от KIllustrator (который, кстати, давно переименован в Karbon — возможно, это ответ на вопрос об актуальности твоего впечатления) и GIMP, развиваются, причём очень быстро (билды полугодовой давности разительно отличаются от свежих версий из SVN). Информация о свободном софте, к счастью, имеет свойство быстро устаревать. (Ответить) (Уровень выше) (Ветвь дискуссии)

	gregory_777 2007-11-29 12:39 (ссылка)
	Ну так Inkspace очень Xara напоминает. Да и сама Xara говорят ще не вмерла, они там что-то пишут потихоньку. Глядишь и эти разродятся. Крита - унылое говно. До фотошопа там ещё как до луны раком. (Ответить) (Уровень выше) (Ветвь дискуссии)

yushi 2007-11-29 15:21 (ссылка)

Да и сама Xara говорят ще не вмерла, На официальном сайте последние новости датируются августом прошлого года. По слухам же (степень достоверности которых мне лень проверять) ситуация такая: авторы ей больше заниматься не будут, т.к. их купили какие-то буржуи; авторская версия к тому же завязана на закрытую библиотеку рендеринга, есть форк с использованием Cairo, но дорабатывать его всем влом. Ну так Inkspace очень Xara напоминает. По эргономике Inkscape отстаёт чудовищно. Впрочем, продравшись через невменяемый интерфейс, понимаешь, что сделать в нём можно даже больше. Крита - унылое говно. Угу, зато GIMP — угарное повидло, должно быть: без CMYK (есть в Krita), без L*a*b (есть в Krita), без слоёв эффектов (есть в Krita), без тридцатидвухбитного цвета (есть в Krita)… А ещё рекомендую посмотреть исходники GIMP'а, хотя бы по диагонали. Мне кажется, человек, не видевший этого и притом употребляющий словосочетание "унылое говно", просто не подозревает, что такое по-настоящему унылое говно. До фотошопа там ещё как до луны раком. Послушайте, давайте не забывать, о чём вообще тред, да? Исходное утверждение выглядело как "если нужен растровый редактор под Linux, следует использовать Krita". Когда фотошоп портируют под *nix'ы и выпустят под свободной лицензией, можно будет вернуться к этому треду и сравнить его возможности с возможностями Krita на тот момент. А до этого сравнения Krita с фотошопом и, скажем, мотоциклом имеют примерно равную осмысленность. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tzirechnoy.livejournal.com 2007-12-01 16:05 (ссылка)
	В GIMP можно работать с CMYK и Lab. Разобрать — затем собрать. Хреновато, будь это моей повседневной работой плюнул бы и купил photoshop. Но можно. (Ответить) (Уровень выше)

	dna21m 2007-11-30 10:39 (ссылка)
	Крита - нестабильное унылое говно. (Ответить) (Уровень выше)

	spqr 2007-11-29 06:37 (ссылка)
	Вроде как CMYK прикрутили к Gimp'у, а OOo сам пользую ещё со времён StarOffice'а, и сейчас всю администрацию Владимирской области на него перевели, нормально, отдельные жалобы пользователей на отсутствие ползунков привычных только. (Ответить) (Уровень выше) (Ветвь дискуссии)

	yushi 2007-11-29 06:41 (ссылка)
	GIMP — нежизнеспособный крабомонстр (а изобретали GEGL и прочих средств его гальванизации — натуральные диверсанты, занятые объективно вредными вещами). На самом деле, лучшее, что может сделать сообщество — добавить в Krita поддержку GIMP'овских плагинов и забыть про GIMP, как про страшный сон. (Ответить) (Уровень выше) (Ветвь дискуссии)

	spqr 2007-11-29 09:26 (ссылка)
	А что в нём такого страшного? Или хотя бы где обсуждают его недостатки? (Ответить) (Уровень выше) (Ветвь дискуссии)

yushi 2007-11-29 15:54 (ссылка)

А что в нём такого страшного? Да страшного, в принципе, ничего, это просто очень плохо написанная и практически прекратившая развитие программа. Недостатки же у GIMP следующие: Он написан на чистом C. Проекты такого размера и назначения просто нельзя писать на этом языке, C для этого предназначен. Собственно, именно авторы GIMP ответственны за появление двух самых чудовищных библиотек в истории свободного софта — Gtk и GLib. В оправдание гимпописателей можно сказать только то, что они вряд ли предполагали, насколько вырастет их дипломный проект. Он (что отчасти, видимо, следует из п.1), судя по всему, больше не интересен своим разработчикам. Дело житейское, но, что хуже, они при этом играют в собаку на сене — доступ к телу имеют только избранные. В результате появляются многочисленные форки (самый удачный из которых — Cinepaint — даже, пожалуй, превосходит оригинал по большинству параметров). Но авторы форков тоже сталкиваются с проблемой, изложенной в п.1: GIMP — это много сложного кода не самого лучшего качества, в их случае ещё и чужого. По мере интимного знакомства с кодом GIMP желание переписать его с нуля, как правило, ширится и крепнет. Он, к сожалению, очень популярен. Поэтому, в частности, многие, поглядев на монструозный, не развивающийся, глюкавый, неэргономичный и бедный по возможностям GIMP, делают вывод: "если это самый известный свободный пакет для работы с графикой, все свободные пакеты для работы с графикой — говно". А это не так. GIMP — это, вопреки распространённому заблуждению, НЕ клон Photoshop; более того, авторы утверждают, что впервые увидели последний через несколько лет после начала работы над GIMP. При этом (см. пункт 3) он имеет большую базу пользователей, которые просто не поймут "прогиба" под принятые в мире проприетарного софта способы, например, организации интерфейса. В то время как создатели той же Krita идут именно по пути "фотошопообразности", пользуясь, по сути, услугами профессиональных дизайнеров интерфейса и заодно облегчая жизнь мигранта. Или хотя бы где обсуждают его недостатки? В стиле "ваш гимп ацтой как мне запустить мой пиратский фотошоп под вайн" — везде (забавно, что типовые потребности выступающей в подобном духе пионэрии как раз обычно гимпом полностью перекрываются). А вменяемо — ну, на русском есть чудесный ресурс http://linuxgraphics.ru/ Там очень грамотные статьи по всем свободным программам обработки изображений, включая GIMP, и чрезвычайное приятное сообщество, которое действительно отвечает на вопросы и помогает решать проблемы, а не самоутверждается. (Ответить) (Уровень выше) (Ветвь дискуссии)

	yushi 2007-11-29 15:54 (ссылка)
	C для этого предназначен Тьфу. Не предназначен, естественно. (Ответить) (Уровень выше)

(Комментарий удалён)

	yushi 2007-11-29 17:13 (ссылка)
	Ага! На самом деле, всё ещё страшнее. Там средствами чистого C реализован некий квазиобъектный тулкит, и уже на нём написано всё остальное. Что грустно, дурной пример оказался заразителен: это нашло себе массу применений далеко за пределами собственно гимпа. (Ответить) (Уровень выше)

	На чистейшем ttnl 2007-11-29 18:16 (ссылка)
	А если включить мозги и немного подумать. GTK означает Gimp ToolKit и написан на C. На чем написан Gimp ??? (Ответить) (Уровень выше)

ttnl 2007-11-29 17:37 (ссылка)

А что чудовищного в библиотеке GLib? Наоборот. Множество функций, которые так или иначе приходится реализовывать в программе: списки, потоки, функции для работы с памятью, строками. Код выдержан в едином стиле, названия функций логичны. Единственный недостаток в том, что в результате этого некоторые названия функций длинные, но это не такая серьёзная проблема, чтобы называть библиотеку чудовищной. (Ответить) (Уровень выше) (Ветвь дискуссии)

ttnl 2007-11-29 17:43 (ссылка)

Он написан на чистом C. Проекты такого размера и назначения просто нельзя писать на этом языке, C для этого предназначен. Собственно, именно авторы GIMP ответственны за появление двух самых чудовищных библиотек в истории свободного софта — Gtk и GLib. В оправдание гимпописателей можно сказать только то, что они вряд ли предполагали, насколько вырастет их дипломный проект. К GTK+ существуют множество bindings, разработку можно вести на разных языках от java до питона. На каком языке вы предлагаете писать графические библиотеки, если не на c? Можно представить SDL, переписанную на питоне. Скорость работы будет потрясающей. (Ответить) (Уровень выше) (Ветвь дискуссии)

yushi 2007-11-29 18:19 (ссылка)

SDL не является библиотекой для создания GUI, вообще-то. Это как раз способ "быстро и грязно" вывести графику на экран в ситуации, когда дорог каждый такт процессора — в играх, эмуляторах и т.д. Там и используется. За применение SDL для написания, скажем, морды к БД надо лишать доступа к компьютеру в судебном порядке. Человеческое решение проблемы, которую решали авторы Gtk и GLib, называется Objective C. Чуть менее человеческое решение той же проблемы называется C++. И даже они применимы только там, где уже нужен очень сложный код, а нормальные языки, с автоматической сборкой мусора, интроспекцией и прочими минимально необходимыми для разработки программ с правильной архитектурой свойствами по соображениям эффективности использовать ещё нельзя. Позиционирование же Gtk и GLib как средства для создания приложений общего назначения, типа "альтернативы Qt" это вообще преступление. Мы, собственно, можем наблюдать "злонравия достойные плоды". Код GIMP занимает больше ста мегабайт; контроль над ним безвозвратно потерян, на feature request'ы команда не реагирует (потому что не может), при каждой попытке исправить баг добавляется четыре новых. А всё почему? А потому, что, как известно, производительность программиста, измеряемая в значимых строках кода, не зависит от языка. Поэтому выбравшие в качестве языка разработки для огромного приложения слегка разбавленный синтаксическим сахаром портабельный ассемблер сами себе злобные бакланы. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-11-29 18:38 (ссылка)
	На вкус и цвет товарищей нет. Со своей стороны, хочу посоветовать INTERCAL (Ответить) (Уровень выше) (Ветвь дискуссии)

	yushi 2007-11-29 21:24 (ссылка)
	Прикольно, действительно. На Brainfuck местами похоже (не сочти за наезд, язык действительно интересный). (Ответить) (Уровень выше) (Ветвь дискуссии)

tiphareth 2007-11-29 21:51 (ссылка)

Язык баснословный, в принципе. Особенно 4 арифметические операции, Брайнфак это уже эпигонство практически. Я к чему его вспомнил - к тому, что у разных людей есть привычка пропагандировать экзотические языки программирования. Как мы недавно еще раз убедились (с куздриной убивалкой комментов на окамле) - все, что написано на языке, который не шлифовали лет 10 как минимум, нежизнеспособно и требует постоянного внимания человека с напильником. То есть для реализации практических задач (как минимум, совместимости между дистрибутивами и беспроблемной компилируемости из сорса) - годится только перл, питон и си. Ну там, флекс, тк/тцл, руби, паскаль, если нужно экзотичного. А окамлы строятся в колонну и идут нахуй вместе с ос/2, би-осом и планом-найн. Ибо экзотика, применимая только для хобби-проектов. Си-плюс-плюс отметаю за ужасающим быдлячеством концепта, тем более .NET и все, где успело порыться свиное рыло микрософта. Такие дела Миша (Ответить) (Уровень выше) (Ветвь дискуссии)

yushi 2007-11-29 22:19 (ссылка)

Вот, и опять нельзя не вспомнить Эрланг. К моему удивлению (я с детства интересуюсь экзотическими ЯП, и думал, что более или менее в них ориентируюсь), оказалось, что это практически мейнстрим (просто в далёкой от десктопов области — роботы, телеком; кстати, по той же причине — бешеная популярность вдали от десктопов — к списку беспроблемных языков стоило бы-таки добавить Аду), и всё, что нужно допиливать напильником, было допилено где-то к началу двухтысячных. На Эрланге написан ejabberd, который без звука ставится в любом популярном Linux-дистрибутиве, много всякой забавной мелочи, и такое ощущение, что "провинциальности" Схемы или Оберона он начисто лишён. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-11-29 22:22 (ссылка)
	Ага. Я никогда с ним не работал, но допускаю вполне (Ответить) (Уровень выше)

	joppux 2007-11-30 02:13 (ссылка)
	> годится только перл, питон и си Фи, какой узколобый прагматизм! (Ответить) (Уровень выше)

ttnl 2007-11-29 19:34 (ссылка)

Человеческое решение проблемы, которую решали авторы Gtk и GLib, называется Objective C. GLib-то тут при чем? Человеческое решение проблемы, которую решали авторы Gtk и GLib, называется Objective C. Чуть менее человеческое решение той же проблемы называется C++. И даже они применимы только там, где уже нужен очень сложный код, а нормальные языки, с автоматической сборкой мусора, интроспекцией и прочими минимально необходимыми для разработки программ с правильной архитектурой свойствами по соображениям эффективности использовать ещё нельзя. Позиционирование же Gtk и GLib как средства для создания приложений общего назначения, типа "альтернативы Qt" это вообще преступление. Есть такая штука, как gtkmm. Используйте её вместе с языком C++. Используйте любой язык, поддерживаемый GTK+. Какой язык не используй, суть графической программы не изменится: главный цикл, обработчики событий, т.д. И на чем эти обработчики написаны, зависит от личных пристрастий каждого. Тем, что она упрощает решение ряда задач неподходящими для этих задач средствами - из другого коммента. Что имеется ввиду? (Ответить) (Уровень выше) (Ветвь дискуссии)

yushi 2007-11-29 21:21 (ссылка)

Имеется в виду, что работать со столь сложными структурами данных и столь высокоуровневыми абстракциями, как в GLib, с помощью настолько низкоуровневого языка, как plain С, мягко выражаясь, непродуктивно. На программиста ложится тупая и неблагодарная работа по ручному освобождению памяти, явному вызову sizeof(), бесконечным приведениям типов и т.д. При написании пользовательских приложений надо думать не об этом! Так можно писать ядра операционных систем и реализации языков. А при написании пользовательского приложения об всей этой байде должен заботиться интерпретатор/компилятор. Есть такая штука, как gtkmm Она накрылась. К тому же — см. ниже. Используйте любой язык, поддерживаемый GTK+. Я пробовал, вместе со Scheme и Python. Спасибо, больше не хочу. Врождённые уродства Gtk пролезают даже в Схему, противоестественное устройство самой библиотеки не лечится выбором языка. Какой язык не используй, суть графической программы не изменится: главный цикл, обработчики событий, т.д. И на чем эти обработчики написаны, зависит от личных пристрастий каждого. Это распространённое заблуждение. Напомню, исследования показывают, что количество операторов, которое программист создаёт в единицу времени, постоянно и не зависит от языка программирования. Вот только в двести операторов на Лиспе влезает неслабая библиотека для работы с русской морфологией, а в двести операторов на plain C или ассемблере мало что сложнее "Hello, world!". Язык определяет мышление. Разные языки обеспечивают разные уровни абстракции. Есть задачи, в рамках которых полезно думать о регистрах процессора и размере выделяемой памяти в байтах. Есть задачи, в рамках которых об этом думать вредно. Gtk и Glib предлагают средства для решения вторых в рамках языка, предназначенного исключительно для первых; поэтому Gtk и Glib следует отправить в топку. (Ответить) (Уровень выше) (Ветвь дискуссии)

ttnl 2007-11-30 14:31 (ссылка)

Использование ООП языков для написания библиотек ещё отвратительней. Любая C++ библиотека тянет за собой кучу ненужного мусора, который тормозит приложение и ухудшает восприятие кода. Невозможно разобраться, откуда происходит наследование, все эти виртуальные функции, перегрузки, нагромождение шаблонов и прочих конструкций превращает программу в ребус, и большая часть разработки превращается в его разгадывание. Ещё больший дебилизм разносить заголовочные и СPP-файлы в разные директории, и следующий из этого мартышкин труд по поиску выполняющейся функции среди прочих перегруженных: она описана в заголовочном файле или нет? Аргумент типа char * или он приводится к const char *? А про наследующиеся конструкторы и говорить не хочется. Даже сам дедушка Страусруп смеётся над ООП программистами. Наглядный пример - kdelibs и qt. В ближайшее время выйдет новая версия KDE4. Все KDE программы к этому выпуску должны быть переписаны(!), потому что у библиотеки отсутствует обратная совместимость. А всё потому что наследуемость и прочие инкапсуляции. Нынешних возможностей Gimp'а хватит ещё лет на 20, Gimp или фотошоп, на бумаге это будет выглядеть примерно одинаково. От графического интерфейса многого не надо, не нужны эти перделки и свистелки, избыток красочности. А нужна простота, удобство, функциональность и производительность. Для нормальных вещей, которые пишутся для простоты, удобства, функциональности и производительности (для людей, а не блондинков) используется язык C и библиотека GTK+. А все остальные перделки идут в топку. (Ответить) (Уровень выше) (Ветвь дискуссии)

yushi 2007-12-02 22:17 (ссылка)

Невозможно разобраться, откуда происходит наследование, все эти виртуальные функции, перегрузки, нагромождение шаблонов и прочих конструкций превращает программу в ребус, и большая часть разработки превращается в его разгадывание. То, что вы не видели хорошего кода на C++ — это повод вам посочувствовать, но не повод считать, что его не бывает. Аргумент типа char * или он приводится к const char *? Мелочь, но характерная, да. Ни один человек в здравом уме не будет использовать char* внутри кода на C++ иначе как для общения с операционной системой (разбор команднострочных аргументов и пр.). Функция на C++, принимающая аргумент типа char* (если это не функция конвертации null-terminated "строки" в какую-нибудь человеческую) по определению написана криворуким пионером. Все KDE программы к этому выпуску должны быть переписаны(!), потому что у библиотеки отсутствует обратная совместимость. Не вижу в этом ничего ужасного. В жизненном цикле программы (если это не студенческая поделка, забытая всеми, включая автора, сразу после создания) собственно "написание" требует ничтожной доли суммарных усилий программиста. После бурного и романтического, но короткого этапа создания кода начинается сопровождение программы — ликвидация багов, реализация feature request'ов, правка документации и т.д. Если переписывание с нуля (которое по готовой иерархии классов — мы ведь договорились, что речь не о пионерах, не способных, скажем, нарисовать UML-диаграмму, да? — занимает считанные недели, если не дни) способно резко упростить сопровождение (а при переходе с Qt3 на Qt4 это так — чего стоит один фреймворк Interview; в потроха KDE не залезал, но подозреваю, что там благотворных изменений не меньше), любой разумный разработчик перепишет код, не делая из этого трагедии. "Планируйте выбросить первую версию - вам все равно придется это сделать"©Брукс. Нынешних возможностей Gimp'а хватит ещё лет на 20, Gimp или фотошоп, на бумаге это будет выглядеть примерно одинаково. "Рыдалъ"©. Слова, скажем, "CMYK", "L*a*b", или (для разнообразия) "HDR", или "слои эффектов" вам о чём-нибудь говорят? Для нормальных вещей… используется язык C и библиотека GTK+. Забавно видеть это утверждение в треде, начавшимся с обсуждения GIMP'а. Оный GIMP, напомню, практически прекратил развиваться именно из-за того, что в коде такого объёма, написанном на языке, по убожеству сопоставимом с ассемблером, никто не способен разобраться, просто физически (человек не может удержать в голове столько разноранговых сущностей). Никто, собственно, и не разбирается. (Ответить) (Уровень выше)

yushi 2007-11-29 17:57 (ссылка)

А что чудовищного в библиотеке GLib Тем, что она упрощает решение ряда задач неподходящими для этих задач средствами. На языке, который не поддерживает хотя бы наследования и шаблонов (или их аналога), нельзя писать приложения, которые трогает руками пользователь (подробнее сейчас отвечу в другом комменте) и которые по этому поводу хотят юникода, сложных структур данных и пр. фич, обеспечиваемых GLib. (Ответить) (Уровень выше) (Ветвь дискуссии)

tiphareth 2007-11-29 18:26 (ссылка)

Нет, понятно, конечно, что C это не дело. Но альтернатив для подобных ситуаций ему нет: C++ - гнутый компилятор сосет, сам язык концептуально еще хуже C. Реально - я не видел кода Гимпа, но с кодом Мозиллы возился довольно долго, и твердо уверен, что хуже, чем это, просто не бывает. Python - медленно. Нет совместимости между версиями. Perl - синтаксическое болото, особенно в части модулей и наследования Haskell, Java - падают от щелчка, совместимость нулевая. Паскаль - язык, составленный по принципу "шаг вправо, шаг влево - расстрел", и никакого наследования, естественно Я забыл чего-то? Схема? Лисп? Руби? Интеркальк? Такие дела Миша (Ответить) (Уровень выше) (Ветвь дискуссии)

(Комментарий удалён)

tiphareth 2007-11-29 19:22 (ссылка)

В том смысле, что у меня есть штук 8 линукс-боксов с разными дистрибьютивами, и на каждом JVM либо падает сразу, либо не падает, но работает криво, и в обоих случаях имеет большие проблемы с версиями и установкой. На theunderdogs.info есть десятка два жабных игр, которые в теории должны работать, на практике ж падают через 2 минуты максимум. На виндах, впрочем, вполне работают, только дико тормозят. Хуже JVM среды под Линукс просто нет. Такие дела Миша (Ответить) (Уровень выше) (Ветвь дискуссии)

(Комментарий удалён)

	yushi 2007-11-29 22:01 (ссылка)
	А чего там есть, в новом стандарте C++? Boost как часть языка, или ещё что-то придумали? (Ответить) (Уровень выше)

	yushi 2007-11-29 21:53 (ссылка)
	А JVM какая? В большинстве дистрибутивов по умолчанию шёл Blackdown, который типа не вполне родной (никогда не писал ничего большого на Жабе и не пользовался жаба-приложениями, кроме разве что Azureus, так что не помню деталей)… (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-11-29 21:58 (ссылка)
	Брал, которая ставилась. Много разных. Они обрушивали весь линукс в половине случаев. (Ответить) (Уровень выше)

	joppux 2007-11-29 19:21 (ссылка)
	> Haskell, Java - падают от щелчка, совместимость нулевая Эээ, это как? > Я забыл чего-то? C#! :D Ну и OCaml. (Ответить) (Уровень выше) (Ветвь дискуссии)

tiphareth 2007-11-29 19:30 (ссылка)

Про JVM тут по соседству ответил. "В том смысле, что у меня есть штук 8 линукс-боксов, и на каждом JVM либо падает сразу, либо не падает, но работает криво, и в обоих случаях имеет большие проблемы с установкой. На theunderdogs.info есть десятка два жабных игр, которые в теории должны работать, на практике ж падают через 2 минуты максимум. На виндах, впрочем, вполне работают." Насчет Окамла - известна эпическая история с попыткой установить куздрину приблуду для прибивания спама в LJ. Ставил ее в 3 разных места (Mandrake, Gentoo, SuSe). Бинарий не работал нигде. Откомпилировалась она только в одном из них (Gentoo), из-за несовместимостей между версиями, и после кадринальной докрутки мэйкфайла. Но после компиляции работать все равно не стала, а разнообразно глючила и падала. Ни одного человека, который смог бы ее запустить, я не знаю. При этом - Куздра совершенно не криворук, а наоборот, просто машинка несовместима ни с чем, ни на уровне бинариев, ни на уровне сорса. Мораль проста: окамл в практической жизни непригоден совершенно. С таким же успехом можно на сендмэйле программы писать, работать лучше будет. Такие дела Миша (Ответить) (Уровень выше) (Ветвь дискуссии)

	joppux 2007-11-29 19:38 (ссылка)
	(сейчас я буду послан) Вообще-то это скорее говорит о кривизне Linux, под виндами проблем почему-то намного меньше :) (Ответить) (Уровень выше) (Ветвь дискуссии)

	tiphareth 2007-11-29 19:39 (ссылка)
	Потому что винды - это один дистрибутив, а Линукс - 30 разных. (Ответить) (Уровень выше)

yushi 2007-11-29 20:38 (ссылка)

C++ - гнутый компилятор сосет, сам язык концептуально еще хуже C. Реально - я не видел кода Гимпа, но с кодом Мозиллы возился довольно долго, и твердо уверен, что хуже, чем это, просто не бывает. Ну, Мозилла, ИМХО — не лучший пример кода на C++. Один из худших даже, я бы сказал. C++ действительно огромный, бардачный и по большому счёту дурацкий язык, но если уж писать много кода на чём-то близком к ассемблеру, то лучше на нём, чем на plain C. Ещё лучше Objective C, но под него почти нет библиотек. Haskell, Java - падают от щелчка, совместимость нулевая. А что бывает на Haskell общеупотребительного (если не считать общеупотребительным Perl6)? Я как-то с софтом на Haskell не сталкивался. А вообще опытные товарищи его как раз хвалят. Паскаль - язык, составленный по принципу "шаг вправо, шаг влево - расстрел", и никакого наследования, естественно Ну, в этом семействе есть Ада и Оберон. Ада, правда, совсем уже параноидальна, а у Оберона я не знаю хороших свободных реализаций. Ну и библиотек тоже нет, соответственно. А так был бы вполне себе выбор. Я забыл чего-то? Схема? Лисп? Руби? Интеркальк? У Схемы, увы, нет во всём хороших реализаций, а стандарт пока описывает слишком малую часть языка для обеспечения переносимости между ними. А так был бы идеальный вариант. А забыл ты как минимум Smalltalk, C# (и вообще .Net в инкарнации Mono как платформу) — ну, это, положим, на любителя, хотя в любом случае про C# можно сказать, что это Жаба as it shall be; и OCaml (кстати, есть .Net-реализация ML — F#). И Erlang. Вот тот же Erlang — чем плох? Функциональный (но при этом не такой параноидально-функциональный, как Haskell — императивные фичи есть, но они хорошо инкапсулированы, и их можно легко использовать без нарушения надёжности функциональной части), офигенная работа с многозадачностью (свои, независимые от ОС, лёгкие потоки, каждый из которых по умолчанию занимает всего 300 байт; message-based IPC, делающая невозможными deadlock'и и race conditions; при соблюдении нескольких нехитрых правил написания кода — линейное масштабирование производительности при увеличении количества узлов, на которых запущена система); в отличие от большинства функциональных языков, почти двадцать лет успешного использования в индустрии; свой, достаточно приличный, GUI-toolkit и вообще изрядная куча библиотек, компиляция в переносимый байт-код; зверская надёжность; изящный синтаксис… в общем, сплошные достоинства. Да, свободная реализация от авторов языка. А из недостатков разве что динамическая типизация; но, во-первых, это обещают отчасти поправить, не портя при этом ядро интерпретатора и не нарушая backward compatibility, а во-вторых, ещё не факт, что это недостаток. (Ответить) (Уровень выше) (Ветвь дискуссии)

	tristes_tigres 2007-11-29 23:28 (ссылка)
	> но при этом не такой параноидально-функциональный, как Haskell — > императивные фичи есть, Они и в хаскеле есть, называются монады и стрелки. последние пока не осили, но первые - вполне работают. (Ответить) (Уровень выше)

	yushi 2007-11-29 16:02 (ссылка)
	Или хотя бы где обсуждают его недостатки? Конкретнее — гляньте, например, вот этот тред на http://linuxgraphics.ru Прямо удивительно — обычно в тредах с такой темой разворачивается holy war, бессмысленный и беспощадный; а там взрослые люди спокойно обсуждают реальные проблемы. Не устаю рекламировать этот ресурс, да. (Ответить) (Уровень выше)

russkiy 2007-11-29 09:04 (ссылка)

У тебя устаревшие сведения. Я выгоняю из гимпа через Separate+, совершенно нормально. (И кстати Krita конвертирует и работает с CMYK). Вектор делается в Inkscape с нашим удовольствием, далее можно либо обратно же через гимп и отдавать печатать тиффом, либо через Scribus - в PDF или EPS. Кроме того, вскоре sK1 доделают, там обещают полное управление цветом. Главная проблема в ленивых пидорах в типографиях, которые требуют непременно в кореле, еще и версию определенную им подавай. И с ними либо плюнуть, сунуть тупо типо тиф в корел и отдать, либо доебать, чтоб брали валидные форматы, а не что им угодно, поскольку требовать корел - это свинство необоснованное. Что до ОО, то я ничего такого не замечал, ексель, ворд - открываются спокойно. Может мало пользуюсь, конечно. (Ответить) (Уровень выше) (Ветвь дискуссии)

	bugware.livejournal.com 2007-12-02 16:48 (ссылка)
	В sK1 управление цветом осуществляется через pylcms. Так что вопрос в том, что сам sK1 пока не очень доделан. CDR-ы в кривых читает, вставленные битмапы и текст (если не в кривых) пока игнорирует. Сохранять в CDR скорее всего не будет, во всяком случае финансово-поддержанного спроса не было. (Ответить) (Уровень выше)

	tritopora 2007-11-29 12:23 (ссылка)
	К Гимпу есть расширение, которое CMYK нормально делает. А ОО после 2.2 уже вовсе не тормозит (а 2.3 у меня летает на 512 мб памяти и Семпроне 2,2+). А газеты в Scribus'е делать можно ничуть не хуже, чем в Кварке. Журналы не пробовал, не скажу. (Ответить) (Уровень выше)

	pzz 2007-11-29 12:03 (ссылка)
	А чего опеноффисом не смотрят? (Ответить) (Уровень выше)

(Читать комментарии) -