Здравствуйте, VladD2, Вы писали:
...
VD>>>И каждый раз бегать по тексту рассчитывая строку? А смысл? Тормоза от этого конечно увеличатся, а вот бенефиты...
A>>Если юзать string[] для хранения текста, то да, смысла нет, не спорю.
VD>Я не понимаю о чем ты говоришь. Что еще можно "юзать"? Массивы символов? Ну, и какая разница?
VD>Объясни мне доходчиво.
У тебя сейчас, если я ничего не путаю, так:
class Document
{
string[] lines;
public:
string getLine(int idx) { return lines[idx]; }
};
Такое решние дает очень эффективную реализацию Document::getLine. В минусе то, что время выполнения вставки/удаления строки не const и растет с увеличением количества элементов в массиве lines[].
A>>Загрузили в редактор большой текст и стали его с головы редактировать.
...
VD>Ограничения string[]? Ты о чем? В редакторе вообще нет никаких string[]. Строки хранятся в специальном классе храняещем по одному string-гу на строку редактируемого файла.
Этот специальный класс (Document, если ничего не путаю) инкапсулирует string[], так? Я об этом писал.
...
VD>А какие проблемы? Стиль == класс. Создавай наследника и храни хоть черта лысого. Другое дело, что прийдется отрисовку менять. Над расширением процесса отрисовки я даже не думал, так как не нужно. Проект с открытым кодом. Всякие плагины для него не особо то актуальный. Хотя если понадобится, то прикрутить будет не долго.
Тебя в сцинтиле все устраивает? Видимо нет, раз взялся за свой редактор. А почему сцинтилу не стал "подкручивать"? IMHO потому что, разбираться в чужом коде радость та еще. Ты идешь по тому же пути — захотят расширения делать, пусть правят код, а не плагин пишут.
Плагины и открытый код вещи не взаимоисключающие.
VD>Тут же речь не о том. Речь о банальном удобстве. Человек решивший создать подсветку для некоторого формата не должен трахаться создвая стили для всех пересечений, или как ты предлагашь писать какой-то код вместо того, чтобы декларативно задать нужные ему свойства.
Уже были вроде посты про то, что писать свой стайлер для твоего редактора пока не очень удобно.
...
VD>И как это поможет тебе с рисованием той же рамки?
Так же как с фонтом.
VD>Да уж... Прямо как в ИЕ или Сцинтиле... почти! Так как динамическое пересоздание шрифта на каждый токен — это задница для производительности. На относительно старом железе это будет тормозить как АБС. 
Я код написал чтоб принцип был понятен. На самом деле на каждый токен фонт рожать не надо, заводим в FontChangeDecorator std::map<HFONT, HFONT>, где ключи — шрифты от существующего декоратора, а зчачения — новые, увеличенные и все дела.
VD>К тому же изменение размеров шрифта должно быть незаметно для пользователя контрола. Да, и вобще, прямая возня с GDI — это само по себе фигня какая-то. Даже Сцинтила от нее абстрагироуется. Хотя это конечно к делу не относится.
Ну привел бы я тебе код с использованием своих классов оберток над GDI, стал бы он поятней?
VD>Ага. И на каждое вычисление размера токена мы имеем пересоздание шрифата. Плюс его же на отрисовку. Ну, нафиг такие "грамотные решения". К тому же еще и влезание пользовательского кода в низкоуровневые.
Создавать или нет шрифт решает декоратор, он может вообще один и тот же фонт юзать созданный заранее (так мой дефолтовый декоратор и делает).
VD>Масштибировние шрифта — задача редактора. Это относительно низкоуровневая пробелма и я лично на сегодня вижу ее решение на уровне библиотеки вывода на физическое устройство (ну, нечто вроде замены Graphics из GDI+).
...
VD>Что касается прикладного оформления (тех самых стилей), то я считаю совершенно не верным делать какие-то потойные лазейки в данной области. Все форматирование должно определяться стилями. Если нужен новый вид форматировани, то просто добавляй новый стиль.
Дело хозяйское.
...
A>>Бенефиты такого подхода:
A>>1. декоратор дергается только для тех строк которые видны на экране — не надо мучать процессор лишней работой;
VD>А как на счет рассчета переноса строк? Забить на него? Лично я против. Мне нужен удобный в использовании редактор, а не набор компромисов.
Все считается и перенос строк и прокрутка. Не в лоб конечно, но и каши в коде нет. Кстати, у тебя можно иметь строки разной высоты? Например, если в одной строке шрифт высотой 10, а в другой 20, то они будут 10 и 20 или обе по 20 высотой? У меня можна
A>>2. легко сделать кэш строк обработанных декоратором, т.к. для этого достаточно просто написать еще одну реализацию IDecoratorListener;
VD>А зачем мне кэш строк? Я и без него отлично живу. Дотнет и так жрет слишком много памти, чтобы забиват ее совершенно не нужными кэшами.
Кэш затем, чтобы юзверьский код лишний раз не дергать. Дернул декоратор для строки и запомнил результаты в кэш.
A>>3. Визуализация текста не ограничена рисованием текста или рисованием картинки вместо текста, т.к. реализация IDecoratedSubstring ограничена только фантазией юзверя (в разумных пределах конечно ;
VD>Я не заметл, чтобы твой прмер что-то мог изменить в отрисовке. Да и ливно мне это не нужно. Любое расширение дожно быть продумано и ограничено, чтобы оно не мешала остальным частям приложения. Твое предложение убивает к чертям всю диею стилей. Ну, нафиг такие расширения.
Я не навязываю свое решение, просто озвучил свой взгляд на задачу раскраски текста. Чем плохо на проблему с разных сторон посмотреть?
...
VD>Мне нужна простота, ясность и скорость.
Сколько методов нужно реализовать юзеру чтобы написать свой стайлер? В IDecorator-е он всего один
Алексей
