Список в конце поста написан Лавсаном 2 года назад. (2011-03-23 19:56:00) (источник)
Надеюсь, автор не подаст жалобу в Роспатент за перепечатку :-)
Кстати, sudo cast lovesan.

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

Временное резюме: С++ всё еще актуален по историческим причинам. Еще есть мобилки (sudo cast mono), гиперкластеры для шиндовс 3.11 (sudo cast vromanov) и базы данных. Т.к. он актуален, но не предназначен ни для чего (см. выводы в конце списка) новых специалистов по нему должно быть мало. Маленькая конкуренция на огромной области применения — огромное лавэ $$$. Вот это и есть истинная причина использовать кресты — возможность срубить €€€.

Честно говоря, «хитрый план» мне уже очень надоел, поэтому пора открыть карты.

Заодним, крестопоклонники смогут выйти на последний и решительный бой, т.к. сегодня пятница и вечером будет время пообщаться. Поклонникам мамкиного борща тоже наверняка есть что добавить, конструктивно и аргументированно.

Вот этот список:

1. Вырвиглазный синтаксис и контекстно-зависимая грамматика
   • медленная компиляция
   • частые «internal error» в компиляторах
   • код плохо читается и его сложно поддерживать
   • разбор кода различными инструментами, вроде IDE, и его генерация - сильно затруднены
2. ручное управление памятью
   • неудобства при работе с динамической памятью
   • утечки памяти
   • висячие ссылки
   • сегфолты
   • стандартные средства, как то malloc/new, работают медленно
   • фрагментация кучи
   • велосипедные аллокаторы на каждом шагу
     • которые далеко не факт что эффективнее malloc/new

   • велосипедные счетчики ссылок на каждом шагу, опять же
     • медленная работа
     • перерасход по памяти

   • отладка затруднена
   • написание GC, по факту, невозможно, отчасти из-за (5), (7) и (8)
3. Никакого ABI
4. Нестандартизированный и непредсказумый name mangling
5. Дублирование функционала Си
   • сами фичи из Си никуда не деваются при этом
     • отчасти из-за того, что по функционалу превосходят аналоги из C++

   • запутывает новичков
   • malloc - new/new[], free - delete/delete[]
   • препроцессор - шаблоны
   • указатели - ссылки
     • ссылка не может быть NULL, что способствует появлению висячих ссылок и сегфолтов

   • структуры - классы
   • stdio - iostream
6. Стандартная библиотека убога
   • Отсутствует даже такой функционал, как вменяемая работа со строками и многомерные массивы
     • Юникод?

7. Слабая типизация
   • способствует ошибкам
   • затрудняет отладку
   • const не дает абсолютно никаких гарантий
   • при этом система типов невероятно переусложенена
     • в основном из-за пунктов (2), (5) и (9)
     • медленная компиляция
     • частые внутренние ошибки в компиляторах

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

   • множественное наследование неудобно в использовании
     • проблема ромба по дефолту не разрешается никак

   • исключения в конструкторах гарантированно влекут утечку памяти
     • исключения в деструкторах тоже, и просто утечку - еще в лучшем случае
       • коды ошибок деструкторы и конструкторы возвращать не могут
         • ошибки в них не обработать никак
           • поэтому ими стараются не пользоваться
             • раздувание кода

   • деструктор можно вызывать до выхода из блока кода, или до delete
     • гарантированная утечка ресурсов/сегфлот
     • это не предотвратить никак, деструктор обязан быть public

   • одиночная диспетчеризация
     • виртуальные методы в конструкторах не работают
     • реализована убого
       • pure virtual function call
       • сложности в случае с множественным наследованием
       • деструкторы обязаны быть виртуальными
         • по дефолту - не виртуальные

       • никаких интерфейсов, только классы

   • порядок инициализации статических членов классов не определен
   • private, public и protected не дают никаких гарантий сокрытия данных
     • к инкапсуляции же не относятся совершенно никак

   • отсутствие «свойств»
     • вынуждает городить getter'ы и setter'ы
       • раздувание кода
       • размывание интерфейса класса

   • неявно генерирумые конструкторы, деструкторы и операторы присваивания
   • «friend» нарушают инкапсуляцию
9. шаблоны
   • очень сильно замедляют компиляцию
   • раздувание кода
   • обфускация кода
   • результат раскрытия плохо предсказуем
   • сложности в отладке
     • километровые и плохо читаемые сообщения об ошибках при компиляции

   • нарушают инкапсуляцию
     • обязаны содержать реализацию в заголовочных файлах

   • позволяют генерировать некорректный код
10. исключения
    • отсутствие finally/unwind-protect
      • заставляет городить классы ради одних деструкторов
        • раздувание кода
        • медленная компиляция
        • медленная работа

    • конфликтуют с другими возможностями языка
      • конструкторы/деструкторы
      • ручное управление памятью

    • работают медленно
    • малофункциональны (ср. CL condition system)

По причинам 3, 4, 5, 9 и 10 C++ совершенно неприменим для системного и низкоуровневого программирования. А по причинами 1, 2, 5, 6, 7, 8, и, опять же, 9 и 10 - и для прикладного.

У C++ нет области применения.

У меня Opensuse 11.4 LTS 64-bit, потому что обновления были до 2014 года, и потому что тут GNOME2. Но не менее заслуживает внимания KDE3, который здесь в отдельном репозитории (из которого уже удалили пакеты для этой версии системы). Сразу после загрузки занято ровно 200 Мб памяти. Включение/выключение системных служб меняет эту картину, но незначительно - гораздо значительнее меняет установка 12.1, 12.2 или 12.3. А 10.1 32-bit вообще влезала в 64 Мб!

Скрин 1

На скриншоте - в ОЗУ только Qt3 и kdelibs. Судя по выводу top при нажатии сочетания клавиш Shift-M, Ksensors ест 16 Мб памяти - что, согласитесь, дофига. Но судя по выполнению free -m в этот момент, на самом деле он ест всего лишь 3 Мб. Compton же ест 11 Мб - весьма и весьма неплохо! Я уверен что, с ростом количества текстур, потребление памяти возрастёт, но наверное всё-таки VRAM:

Скрин 2

Что касается замечательного GNOME2, ради которого эта версия Opensuse и остаётся на моей Workstation - с ней потребление ровно в 2 раза больше: 400 Мб после запуска. Чё-то дофига: Ubuntu 7.10 + GNOME 2.18 ел гораздо меньше! Впрочем, ничего нового:

представлены результаты сравнения производительности Ubuntu 7.04, 7.10, 8.04 и 8.10. В результате, наиболее производительным релизом оказался Ubuntu 7.04

Ну так вот...

1. При включении любой GTK-шной программы (например GXneur) 200 Мб превращаются в 235 Мб - что пережить можно. И тем не менее, какой Qt-шный браузер действительно можно использовать? Opera 10.12 - последний нормальный браузер на Qt, или есть другие? Как дела у проекта Trinity с переводом Konqueror на Webkit - есть ли прототипы?
2. Какой тулкит для GUI вы посоветуете для написания нового софта (или портирования с винды) с точки зрения потребления ОЗУ? Evas из состава E17 - может ли он конкурировать по фичам с GTK2, GTK3, Qt4 и Qt5?
   
   Просто смотрю я на потребление памяти Винампом 2.95 под Wine (32 Мб), и Excel 2003 с одним файлом в 30000 тыс. строк (90 Мб) - и мне становится грустно за наши нативные программы... Но не с помощью Winelib же портировать GUI!
   
   Например Utorrent 1.7 на винде занимает 900 Кб (!), а превосходит по возможностям любой тяжеловесный торрент-клиент! В версии для Linux он не имеет GUI. Что можно посоветовать авторам? Или для Photoshop - было бы странно портировать его с помощью GIMP ToolKit

Дисклеймер. Этот пост всесторонне вдохновлен каким-то древним видео в интернете, автора которого я благополучно забыл. Если автор сейчас читает это - респект тебе и увага, бро!

Итак.

Помойму программисты сильно перегибают палку.

Засрали всю джаву мусором.

Хотите вы бин, и что-то в нем хранить тупо, сделайте все поля public! Вместо лесов геттеров-сеттеров.

Боитесь, что такой класс (с пабликами) будет не thread-safe и хомяки не смогут писать с ним хороший многопоточный код? Да побойтесь б-га, хомяки вообще не напишут хорошего многопоточного кода, всё это миф. Дайте среднестатистическому человеку треды и локи, и он напишет код в миллион раз более медленный, чем аналогичный на готовом TransferQueue. Вот и пишите свой продюсер-консумер на TransferQueue, не выпендривайтесь.

ООП, и конкретно механизм наследования, очень плохо подходит для увеличения реюзабельности кода. Глупому заказчику можно втирать рекламу ООП=реюзабельность, но мы тут все грамотные люди, линуксоиды, как минимум с 8 классами образования, мы же все понимаем как оно на самом деле. Трейты/миксины и препроцессор и то с этим лучше справляются иногда.

Но сидят сумрачные гении, и ночами напролет пишут какие-то иерархии классов, чтобы одну строчку копипасты сэкономить. Всё это фигня! В такой надуманной иерархии классов еще сложней разобраться, чем отрефакторить копипасту. И уж точно ее сложнее модифицировать. Мой совет: копипастите смело и открыто! Если коллеги будут придираться, спокойным голосом, глядя на правое ухо поциента, говорите: «вот сам и поправь», 90% что коллега посинеет от страха и сдрыснет в ужасе, в остальные 10% можно утешаться тем, что эту лажу писать пришлось хотя бы не тебе.

Никто не заставляет писать Factory которые производят Factory, которые производят Factory! Хочешь посмотреть, откуда берется объект, а там целый стектрейс на 50 этажей, можно блуждать пока не умрешь от голоду. Хотите сделать объект - ставите new и поехали. Сразу понятно - вот тут делается объект. Фактори нужно изничтожать безбожно (только если это не Spring, Spring надо пожалеть).

И вообще, дизайн паттерны - сплошной хлам. Получается говно вместо результата - давайте нафигачим дизайн паттерн! На каждую проблему есть свой дизайн паттерн! И получается, одна строчка смысла, всё остальное мусор, костыли как они есть. Это стрёмно, господа. Почитаешь какой-нибудь код, и так вымажешься в дизайн-паттернах с ног до головы, что потом по улице стыдно идти, на людей смотреть.

Никаких фреймворков! Ехал фреймворк через фреймворк, и все - говно. Каждый день кто-то еще производит новый фреймворк. Потом набигают ПМы-хипстеры и такие, а что у нас популярно? Ахххаха, гороскоп показывает, что в эту фазу луны популярен Wicket, давайте нафигачим на нем гуй для Международной Космической Станции. Потом где-то там эта чушка не распарсила XML, свалилась в корку обосравшись стектрейсами, и все космонавты сварились. Отлично! Зато фреймворк!

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

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

Никаких лесов комментариев! Пишут, значит, целые поэмы там. А кто эти поэмы потом апдейтить будет? Потому что понапихали своих дизайн-паттернов и фреймворков, отформатировали в кривую архитектуру, ничего уже не понятно, что код делает! Надо пояснить суть поэмой! Резюме тут такое: в коде должно быть написано ровно то, что он делает. Если строчки кода расходятся со смыслом, этот код нужно переписать, а не подпирать комментариями.

Самая жуть, это всякие ынтерпрайзные сервера, портлеты, фигеты, шушпанчики. Вот притащил ты себе в проект WebLogic или еще какой-нибудь архитектурно-окаменевший кусок, и что изменилось? Кстати, вы видели чтобы на одном реальном хайлоадном сервере запускалось больше одного приложения? Обычно бывает как раз наоборот - на куче серверов запускается ОДНО приложение! А сколько бед от этой псевдофункциональности по огранизации шаред хостинга! Что ынтерпрайзные сервера лучше делают, чем Jetty запущенная прямо из функции main? Собственно в этом и совет, запускайте джетти откуда-нибудь руками, или из мавена, и не парьте мозг.

Надо писать так, чтобы код отражал СУТЬ. Чтобы деплой отражал СМЫСЛ. Посмотрел на код - и сразу понятно, что там написано. Запустил сервер - и сразу понятно, что и как он обслуживает, где скачать его исходники и пофиксить, если чо.

Если вы последовали перечисленным советам, но вас никто не понимает, скажите что stevejobs с лора разрешил.

В общем, идея понятна, теперь можно приступать к критике :)

Привет.

Подскажите, пожалуйста, в какой файл или каталог принято закидывать цветовые схемы для консоли? И в обще можно ли такое?

Я просто смотрю вот в xfce4-terminal там не одна предлагается на выбор, в konsole было примерно так же. В свое время для xterm и urxvt я когда-то задавал конкретно по цветам и хотелось бы что бы все-все были на выбор цветовые схемы.

Инновационный интерфейс, новая корневая идея, всплывающие окна, тонущие двери, убегающие стенки, конкурирующие звёзды, толкающие шары

Приглашаю в творческю мастерскую идей интерфейса

Есть обширное рабочее пространство. Одни окна лежат поверх других. Есть обычные координаты xгоризонталь и yвертикаль. Также есть zглубина. Слишком глубокие окна тонут и сворачиваются в иконку нижнего моря панели. Слишком близкие окна конкурируют с другими близкими окнами, конкуренты представляются как звёзды в верхней панели небе.

Например я пишу в чате, рисую картину, и играю в сапёра. Все эти окна топовые, они в самом вершу, поэтому это звёзды, звёзды конкурируют, это разные задачи как разные рабочие столы.

Передо мной круглая дверь около изображения, на ней надпись размытие. Я постучал в дверь. Из неё вышли две двери, размыть гаусово, размыть пиксельно, дверь из которой они вышли вывернулась на изнанку и утонула.

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

Я листаю каталоги информация загружается и стенки убегают. Ограниченность оперативки не позволяет мне разогнать все стенки, я какбы в пузыре стенок.

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

Я трогаю шар под определённым вектором и вызываю причину его качения, ура я сделал необративное действие, это шаротрон.

Но я до этого ясно видел последствия трогания шара в этом векторе, потому что я представлял дальнейшие касания. Это как всё равно как нажать на кнопку.

Прошу не придираться к фантастичности и другому. А приглашаю в мастерскую перлов во имя новых идей !!

Перемещено tazhate из development

• Debian
• dwm
• Xfce terminal
• Terminus со стрелками
• кусочек конфига, mc, moc, mcabber

Патчи:

$ find . -maxdepth 1 | grep diff
./movestack-5.8.2.diff
./dwm-6.0-bstack.diff
./dwm-6.0-systray.diff
./dwm-ansistatuscolors-6.0.diff
./dwm-6.0-fancybar.diff
./dwm-6.0-pertag.diff
./dwm-r1437-gaplessgrid.diff

В трее gxkb + pnmixer.

Ругайте.

>>> Просмотр (1366x768, 112 Kb)

Написал такой код:

#define SML_COL_B(COLOR) (unsigned char)(((uint32_t)(COLOR) & 0x000000FF) >> 0)
#define SML_COL_G(COLOR) (unsigned char)(((uint32_t)(COLOR) & 0x0000FF00) >> 8)
#define SML_COL_R(COLOR) (unsigned char)(((uint32_t)(COLOR) & 0x00FF0000) >> 16)
#define SML_COL_A(COLOR) (unsigned char)(((uint32_t)(COLOR) & 0xFF000000) >> 24)
#define SML_COL_RGB(R, G, B)     (uint32_t)(((unsigned char)(R) << 16) |\
                                            ((unsigned char)(G) << 8 ) |\
                                            ((unsigned char)(B)))
#define SML_COL_RGBA(A, R, G, B) (uint32_t)(((unsigned char)(A) << 24) |\
                                            ((unsigned char)(R) << 16) |\
                                            ((unsigned char)(G) << 8 ) |\
                                            ((unsigned char)(B)))
/// @todo get rid of floats
#define SML_COL_MIX(START, TARGET, INTENSITY)                                      \
    SML_COL_RGBA(                                                                  \
    SML_COL_A(START) + (SML_COL_A(TARGET) - SML_COL_A(START)) / 255.0 * INTENSITY, \
    SML_COL_R(START) + (SML_COL_R(TARGET) - SML_COL_R(START)) / 255.0 * INTENSITY, \
    SML_COL_G(START) + (SML_COL_G(TARGET) - SML_COL_G(START)) / 255.0 * INTENSITY, \
    SML_COL_B(START) + (SML_COL_B(TARGET) - SML_COL_B(START)) / 255.0 * INTENSITY)

Теперь хочу оптимизировать SML_COL_MIX, ибо разворачивается оно в бешеную простыню:

(uint32_t)(((unsigned char)((unsigned char)(((uint32_t)(startcolor) & 0xFF000000) >> 24) + ((unsigned char)(((uint32_t)(color) & 0xFF000000) >> 24) - (unsigned char)(((uint32_t)(startcolor) & 0xFF000000) >> 24)) / 255.0 * value) << 24) | ((unsigned char)((unsigned char)(((uint32_t)(startcolor) & 0x00FF0000) >> 16) + ((unsigned char)(((uint32_t)(color) & 0x00FF0000) >> 16) - (unsigned char)(((uint32_t)(startcolor) & 0x00FF0000) >> 16)) / 255.0 * value) << 16) | ((unsigned char)((unsigned char)(((uint32_t)(startcolor) & 0x0000FF00) >> 8) + ((unsigned char)(((uint32_t)(color) & 0x0000FF00) >> 8) - (unsigned char)(((uint32_t)(startcolor) & 0x0000FF00) >> 8)) / 255.0 * value) << 8 ) | ((unsigned char)((unsigned char)(((uint32_t)(startcolor) & 0x000000FF) >> 0) + ((unsigned char)(((uint32_t)(color) & 0x000000FF) >> 0) - (unsigned char)(((uint32_t)(startcolor) & 0x000000FF) >> 0)) / 255.0 * value))),

Хочу оптимизировать по скорости.

Что эта фиговина делает: смешивает два цвета, используя START как начальный цвет, TARGET - цвет, который накладывается сверху, INTENSITY - степень прозрачности наложения TARGET цвета в рамках от 0 (нет наложения) до 255 (полная закраска).
По какому принципу работает:

FFFFFF           FFFFFF
....  ---------- TARGET
....             ....
START ---------- ....
....             ....
....             ....
000000           000000

Берется разница между каждым каналом цветов, делится на 255, умножается на INTENSITY, плюсуется к START.

Debian 7, как сделать java(jdk, jre) use jemalloc?

Выход Elementary OS Luna породил некоторый шум на ЛОРе и серию скриншотов, мол, какая это замечательная сборка, как в ней все продумано и т.д. Я честно попытался ее попробовать, но видимо отношения с Ubuntu у меня испортились окончательно — я понял, что потребуется много, очень много работы напильником. Развернул из образа обратно Debian с KDE, однако эстетические впечатления от Elementary сподвигли меня оставить прежнюю черноту в оформлении.

Debian Stable + Testing, из Testing сейчас стоят только KDE 4.10.5, Vim 7.4, Qupzilla 1.4.4; ШГ — OpenSans + Droid Sans Mono.

Также хочу спросить совета. У, например, QupZilla имеется своя иконка приложения. Когда ни одного окна не открыто, то отображается иконка из Faenza, а когда окно есть — то родная иконка QupZilla. Нет ли способа заставить панель задач всегда отображать «фаянсовую» версию?

UPD: проблема с иконками решилась очень качественно. Доделанная тема на домашнем ноутбуке.

>>> Просмотр (1920x1080, 1068 Kb)

Спустя некоторое время, сделал окружение более темное и приятное глазу, т.к. сижу по ночами из-за сбитого режима.
Лор не пропустил png из-за большого размера, потому на качественный скриншот ссылка вот - http://rghost.ru/49113945/image.png

Итак:
ArchLinux ядро - 3.11.2
Иконки - KFaenza
Plasma - produkt
KWin - qtcurve
Тема Qt - qtcurve
GTK 2 - qtcurve
Шрифт в терминале - FiraMono
Обоина - http://rghost.ru/49113935/image.png

Игры таки на Linux уже есть. И не мало http://rghost.ru/49113932/image.png

>>> Просмотр (1920x1080, 1461 Kb)

root@hp:~# aptitude install lxde-core 
Следующие НОВЫЕ пакеты будут установлены:        
  gksu libgksu2-0{a} libgtop2-7{a} libgtop2-common{a} lxde-common lxde-core lxpanel lxsession{a} openbox 
  openbox-themes{a} sudo{a} 
0 пакетов обновлено, 11 установлено новых, 0 пакетов отмечено для удаления, и 0 пакетов не обновлено.
Необходимо получить 2 551 kB/3 123 kB архивов. После распаковки 14,8 MB будет занято.
Хотите продолжить? [Y/n/?]

Как я понимаю за счет мета-пакета устанавливается не один пакет и простое удаление этого -core мне не даст удаление всего установленного

Вопрос, в debian есть что-то типа отката на предыдущее состояние по установленным пакетам?

Предположим, есть некий пароль (не обязательно пароль, просто любой кусок текста), который я хочу месяца на два-три спрятать подальше, в том числе, и от самого себя. Есть какой-нибудь способ, так сказать, доверить его кому-то на хранение, чтобы с абсолютной уверенностью получить обратно через указанный срок? Некий сервис? Почтовая услуга? Может это можно как-то реализовать прямо на собственном компьютере? Тред создал, потому что даже не знаю, как это гуглить.

Операционная система GNU Emacs получила новые возможности! Собрал волю в кулак и написал библиотеку, которая практически полностью реализует протокол X11. Библиотека незамысловато называется x11 и написана на чистом Emacs Lisp, но пока имеет статус technical preview, хотя в принципе уже можно писать что-то реальное. За основу пока взяты описания протокола на XML из проекта XCB, которые разворачиваются в реализацию. В результате имеем практически все расширения. Работа с протоколом осуществляется в асинхронном стиле подобно XCB. Чего пока нет:

• MIT-SHM. Запросы реализованы, но работать через разделяемую память из операционной системы Emacs мы пока не можем, поэтому Будем через сокет закидывать. Тем более, что разница в скорости, говорят (видел где-то в инете замеры), не такая сумасшедшая.
• XKB. Просто забыл реализовать пару конструкций XML, используемых для описания этого расширения. Это я скоро реализую, поэтому расширение будет работать в полном объеме.
• Big-requests. Тоже будет реализовано. Расширение содержит всего один запрос. Он реализован. Но именно для этого расширения надо несколько перелопатить процедуры формирования запросов к серверу X, так как подсчет размеров запросов изменяется с этим расширением.
• GLX. Огромнейший пласт. За него возьмусь сильно позже. Тут же еще надо полностью сгенерировать протокол GL, а он очень обширный.

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

(размер экрана уменьшил до 1024x768, чтобы скриншот поменьше был)

На скриншоте сверху робкая демонстрашка в стиле LSD основного протокола X11 (Core protocol). Ну с arcs, rectangles и core fonts все и так понятно. А вот как выведены фотографии? Я пока не настолько крут, чтобы писать растеризацию jpg и png на Emacs Lisp. Пораскинув мозгами, пошел смотреть, чем может помочь ImageMagick. Оказалось, есть там возможность получить дамп картинки в нужном формате. Так и сделал: надо отобразить картинку - дергаем stream, она нам отдает дамп в буфер, мы его отсылаем в сервер X. «Привет, Isden» написана мышкой. Демка отслеживает событие motion-notify и рисует маленький квадратик под указателем. По кнопке «q» - выход (отслеживается событие key-press)

На скриншоте снизу робкая и неумелая демонстрашка расширения XRender. Тоже в стиле LSD. На ней мы видим linear gradient, radial gradient, треугольник и отрисовку сглаженных окружностей. Окружности состоят из трапезоидов. Алгоритм рассечения (tessellation) я применил первый, какой мне пришел в голову - горизонтальными трапециями. Какая есть проблема? Сглаженный текст! Что-то мне писать растеризацию TrueType или Type1 на Emacs Lisp не улыбается. Есть идея написать программку на Си с помощью Xft, которую я буду что-то просить растеризовать, а она результат будет отдавать в Emacs. То есть примерно как и с ImageMagick поступить.

Надо хорошенько переобдумать API библиотеки, чтобы его заморозить. При этом надо учесть потенциальные и вероятные будущие новшества в Emacs и в библиотеке, чтобы людям не пришлось переписывать то, что написано ранее. Есть недостатки в Emacs, которые реально мешают и раздражают. Преодолимы, конечно, но это будут костыли. Если интересно, то потом поясню, а то уже и так много воды налил.

Так что есть потенциальная возможность воплотить мечту atoku в жизнь. :)

Традиционная ссылка на обоину: #888888. Старую удалил, так как она надоела, а новую еще не искал. Этот серый цвет реально бесит. :)

>>> Просмотр (1024x1536, 254 Kb)