Реализация ColorDefault ломает бинарную совместимость с ANSI и xterm-256color about termbox-go

[nsf]

Извиняюсь, но причем тут совместимость? Я никогда не обещал никакой совместимости. Рекомендовал бы вообще не привязывать логику к конкретным цифрам. Главная причина сделать AttrDefault как 0 это то, что в Го все инициализируется в ноль по умолчанию и это просто дружественность к семантике языка.

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

Терминалы меня особо никогда сильно не интересовали и возвеличивать какие-то там устоявшиеся годами циферки нет желания. Терминал - просто реализация термбокса. Термбокс как API претендует на полную самостоятельность.

В виндоус вот вообще флаги для цветов используются: https://github.com/nsf/termbox-go/blob/master/termbox_windows.go#L427-L449

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

Так что вот. Уже один раз сломал совместимость с сишным termbox этим сдвигом на единицу, ломать обратно второй раз вряд-ли буду.

[kutuluk]

Термбокс как самостоятельное API - это по сути, массив структур типа Cell со своими методами. Все остальное жестко и хардкодно привязано к терминалу. Не могу себе представить ни одного кейса, когда термбокс мог бы использоваться без терминала.

Тут не в возвеличивании дело. К примеру, Cyan - он везде 6, в каждой библиотеке любого ЯП, в HTML. А тут он 7.

Просто добавить отнять воды единицу не получится, это убьет 255 цвет. Не страшно, в принципе, но получается костыль, который тоже толком не работает ))

Кстати, я так понял, ты собираешься портнуть ColorDefault и в сишную реализацию. Мне думается это поломает большое количество программ, его использующих, потому что далеко не все используют константы. 16 ANSI цветов - это нечто незыблемое, некий фундамент, который каждый может использовать без страха и опаски. Пока не столкнется с термбоксом...

[nsf]

ColorDefault уже в сишечках: https://github.com/nsf/termbox/blob/master/src/termbox.h#L110-L118

Поэтому я и не хочу ломать обратно все. Оно уже сломано один раз было. Я думаю пользователям хватит.

[nsf]

А да, насчет термбокса вне терминала. Почему бы и нет? Во-первых есть windows api реализация. Во-вторых я делал термбокс в полностью виртуальном и контролируемом пространстве, в опенгл движке: http://imgur.com/UnOnF34. Вполне можно сделать какую-нибудь GTK реализацию, как это делают емаксы и вимы для своих нужд. Почему бы и нет.

[kutuluk]

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

Но твою позицию я понял. В крайнем случае форкну, там всего-то надо пару строчек вроде удалить ))

[nsf]

Ну конечно терминалы как популярная реализация влияют на термбокс. Потому что я пытаюсь сделать API с одной стороны простым, с другой наиболее портабельным. И приходится учитывать "интересы" терминалов.

[kutuluk]

Я повнимательней посмотрел, на самом деле далеко не везде цвета совместимы, я переборщил, ни какой очень уж фундаментальной совместимости нет. ANSI цвета - это специфика unix-терминалов, не более того. Правда, unix-терминалы - это 99,9% всех терминалов ))

[kutuluk]

Есть мыслишка, как не сломать API и сохранить ANSI-совместимость.

Сделать ColorDefault не константой, а переменной, значение которой меняется в зависимости от режима.

При OutputNormal ColorDefault=8
При Output216=216
При OutputGrayscale=24
При Output256=231

В первых 3 режимах на единицу большего максимального значения, и, следовательно, не замещающая ни какого цвета.
А в полноцветном режиме 231 потому что это цвет FFFFFF, который в xterm-палитре продублирован - и 231, и 015 https://upload.wikimedia.org/wikipedia/en/1/15/Xterm_256color_chart.svg.

Потребуется изменить константы цветов, изменить write_sgr*, чтобы они не вычитали из цвета единицу и, соответственно, изменить логику send_attr. Ну и наверно еще в пару мест потребуются какие-то изменения, я глубоко в исходниках не лазил.

[nsf]

Ой, боже упаси. :D

[kutuluk]

Почему?
Хотя нет смысла в разных режимах разное значение, можно везде 231, туплю ))

[nsf]

Прекратите лохматить бабушку.

(Извиняюсь, что я так кидаюсь русскими фразеологизмами, просто не часто есть возможность обсудить что-то на гитхабе на великом и могучем)

Глобальная переменная - плохая идея, потому что кто-нибудь да зачем-нибудь начнет ее выставлять в нужные себе значения. Про 231, ну вы забываете, что я хочу именно 0 оставить за ColorDefault, т.к. это еще и значение по умолчанию для всех Го элементов (дружественность к семантике языка). Поэтому тут вряд-ли есть красивое решение, остается только понять и простить.

А какой смысл-то в этом рвении все исправить? Вряд-ли существующие цветовые параметры кто-то будет портировать на термбокс. А если и заниматься этим, то можно сразу вообще цвет конвертнуть в 32 бита и далее просто подбирать ближайшее значение для каждого конкретного случая (будь то термбокс или кто-то может захочет HTML5, сейчас модно).

Не вижу особых преимуществ в данных изменениях.

[kutuluk]

Моя логика в данном случае такая: ColorDefault введен исключительно для терминалов, но именно в терминалах он смещает стандартную палитру терминалов и исключает из палитры один цвет. И если есть возможность от этого избавиться, то почему бы и нет? Но, конечно, 231 плохое число, внутри диапазона, а не на крае, но это единственный дублированный цвет в палитре, так почему бы не этим воспользоваться?

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

[nsf]

Ну как, в Го сплошь и рядом в коде расчет на семантику обнуления. Тот же var buf bytes.Buffer. Здесь логика такая же, особенно удобно для тех кто работает с буферами, чтобы termbox.Cell структуры по умолчанию инициализировались в ColorDefault.

[kutuluk]

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

[kutuluk]

Черные символы на черном фоне, то бишь пустота при инициализации по-моему даже более симантична, чем инициализация цветами по умолчанию. Сама идея термбокса в том, что он используется в случаях, когда обычное поведение stdout'а не удовлетворяет нуждам. Даже при инициализации термбокса уже сразу теряется прошлый вывод в консоль и экран очищается. Почему он должен обязательно очищаться системными цветами? Нули в их естественном виде более симантичны - это черный экран. Если вдруг нужно выводить что-то системными цветами - ради бога, для этого и сделан ColorDefault.

Если же нужно весь экран заполнить системными цветами, то можно и ручками написать в 3 строчки, но это уже первый звоночек к тому, что термбокс вообще в данной задаче не требуется и можно обойтисть стандартными принтелнами.

[nsf]

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

[kutuluk]

Ну так я же и не настаиваю, я просто рассуждаю, делюсь своим видением, так сказать. При использовании констант вообще ни каких проблем ни у кого не возникнет, кстати говоря. Константы проще всего скорректировать ))

Я в целом прекрасно понимаю нежелание как-либо менять API. Хотел найти способ пофиксить проблему смещения без потерь, но, по всей видимости, это не возможно - в любом случае где-то логика работы библиотеки изменится.

[kutuluk]

Открыл глаза и увидел, что

AttrBold Attribute = 1 << (iota + 9)

и

case Output256:
fgcol = fg & 0x1FF
bgcol = bg & 0x1FF

То есть один битик во втором байте специально зарезервирован для 255 нативного цвета и цвет задается в диапазоне [0..256]

А потом увидел даже вот это:

Output256 => [1..256]

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

Закрыто =)

[nsf]

Хм, а я думал что написано в документации. Надо обновить документацию значит.

[kutuluk]

Да, не помешало бы =)

Вот это:

1. Output256 => [1..256]

In this mode you can leverage the 256 terminal mode:
0x00 - 0x07: the 8 colors as in OutputNormal
0x08 - 0x0f: Color* | AttrBold
0x10 - 0xe7: 216 different colors
0xe8 - 0xff: 24 different shades of grey

Example usage:
SetCell(x, y, '@', 184, 240);
SetCell(x, y, '@', 0xb8, 0xf0);

Надо поменять на:

1. Output256 => [1..256]

In this mode you can leverage the 256 terminal mode:
0x01 - 0x08: the 8 colors as in OutputNormal
0x09 - 0x10: Color* | AttrBold
0x11 - 0xe8: 216 different colors
0xe9 - 0x1ff: 24 different shades of grey

Example usage:
SetCell(x, y, '@', 184, 240);
SetCell(x, y, '@', 0xb8, 0xf0);

[kutuluk]

И, кстати, по поводу режима OutputGrayscale

В этом режиме невозможно вывести чистый черный и чистый белый цвет и это совсем не правильно.

Можно создать внутренний слайс

var grayscale = []Attribute{
0, 17, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244,
245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 232,
}

и в режиме OutputGrayscale писать на выход индексом из этого слайса

Тогда получится полноценный 26-цветный монохромный режим.