Здравствуйте, Igor Trofimov, Вы писали:
iT>Проект действительно может оказаться очень нужным.
iT>Подкину участникам проекта ссылочку, которая может оказаться полезной:
iT>Dissecting a C# Application iT>Inside SharpDevelop
iT>Christian Holm iT>Mike Krüger iT>Bernhard Spuida
iT>Там есть несколько разделов по теме. iT>Без труда находится в google, ну вот например тут.
Большое спасибо за ссылочку, действительно очень полезно
Здравствуйте, Spaider, Вы писали:
S>Не сочтите за труд, выложите куда-нибудь слепок SVN репозитория. S>Сижу за проксей, достучаться Черепугой нет возможности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Rsdn.Editor
От:
Аноним
Дата:
17.01.06 16:42
Оценка:
У меня парочка мыслей появилась после прочтения статьи и беглово знакомства с исходниками:
1. Зачем делать word wrap для строк которые не видны на экране? Лишняя работа.
2. Для адресации позиции в тексте достаточно знать смещение символа от начала текста, а уж строку которой принадлежит символ и смещение в строке можно расчитать. Тогда можно было бы обойтись без Position<View> и Position<Document>. Понятно, что если использовать, грубо говоря, string[] в качестве хранилища текста, то вариант с адресацией символов по номеру строки и смещению выглядит естественно. IMHO простота string[] обманчива. Упретесь рано или поздно в масштабируемость.
3. IMHO не получилось полностью отделить документ от вида. Зачем в Document-е ссылки на IView и Formatter? IMHO разумно в классе Document держать только код для доступа к тексту, его изменеию (insert/erase) и undo/redo. Модификация документа IMHO никак не связана с тем как он отформатирован.
Здравствуйте, <Аноним>, Вы писали:
А>У меня парочка мыслей появилась после прочтения статьи и беглово знакомства с исходниками: А>1. Зачем делать word wrap для строк которые не видны на экране? Лишняя работа.
Чтобы сделать точный скролинг и точное отображение позиции в документе.
А>2. Для адресации позиции в тексте достаточно знать смещение символа от начала текста, а уж строку которой принадлежит символ и смещение в строке можно расчитать.
И каждый раз бегать по тексту рассчитывая строку? А смысл? Тормоза от этого конечно увеличатся, а вот бенефиты...
А> Тогда можно было бы обойтись без Position<View> и Position<Document>. Понятно, что если использовать, грубо говоря, string[] в качестве хранилища текста, то вариант с адресацией символов по номеру строки и смещению выглядит естественно. IMHO простота string[] обманчива. Упретесь рано или поздно в масштабируемость.
Как-то проблем с масштабируемостью я пока не видел. Как и ее необходимости. Поясни, плиз, о чем речь.
А>3. IMHO не получилось полностью отделить документ от вида. Зачем в Document-е ссылки на IView и Formatter? IMHO разумно в классе Document держать только код для доступа к тексту, его изменеию (insert/erase) и undo/redo. Модификация документа IMHO никак не связана с тем как он отформатирован.
Возможно. Надо будет подумать на этот счет.
ЗЫ
Чесно говоря сейчас волнуют несколько другие вещи. Есть несклько просчетов и несколько недоделок.
1. Так плохой идеей было использовать дотнетный Font. Это не позволяет менять в стилях отдельные атрибуты шрифта. Например, чтобы сделать жирным ключевые слова. Это же не дает реализовать простое масштабирование шрифтов. Мне очень нравится как в Сцинтиле или ИЕ можно менять размер ширфтов просто покрутив колесико мыши удерживая при этом Ctrl.
2. Надо сделать сменяемый парсер для языков. Для этого нужно как-то создать генератор лексеров по удобной граматике.
3. Для реализации п. 2 не плохо было бы реарганизовать Formatter. Выделить из него парсер и т.п. Возможно твой п. 3 можно как раз объеденить с этим пунктом.
В любом случае, спасибо за конструктивные комментарии.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, <Аноним>, Вы писали:
А>>У меня парочка мыслей появилась после прочтения статьи и беглово знакомства с исходниками: А>>1. Зачем делать word wrap для строк которые не видны на экране? Лишняя работа.
VD>Чтобы сделать точный скролинг и точное отображение позиции в документе.
Вернее чтобы упростить реализацию этих функций
А>>2. Для адресации позиции в тексте достаточно знать смещение символа от начала текста, а уж строку которой принадлежит символ и смещение в строке можно расчитать.
VD>И каждый раз бегать по тексту рассчитывая строку? А смысл? Тормоза от этого конечно увеличатся, а вот бенефиты...
Если юзать string[] для хранения текста, то да, смысла нет, не спорю.
... VD>Как-то проблем с масштабируемостью я пока не видел. Как и ее необходимости. Поясни, плиз, о чем речь.
Загрузили в редактор большой текст и стали его с головы редактировать. Ограничения стурктуры данных (в данном случае string[]) не будут видны пока мощности железа хватает, но рано или поздно они вылезут. Вообще IMHO использование Position<Document> для адресации сомволов очень напоминает старничную память с кошмариками в виде long и short pointer-ов.
... VD>1. Так плохой идеей было использовать дотнетный Font. Это не позволяет менять в стилях отдельные атрибуты шрифта. Например, чтобы сделать жирным ключевые слова. Это же не дает реализовать простое масштабирование шрифтов. Мне очень нравится как в Сцинтиле или ИЕ можно менять размер ширфтов просто покрутив колесико мыши удерживая при этом Ctrl.
Думаю это не проблема шрифта, а не совсем удачный дизайн класса Style. Если пользователи захотят что-то большее кроме как рисовать вместо текста картинки? Например обводить подстроку в рамку. Что делать будете? Добавлять поле _drawRectAroundText в Style? IMHO коряво.
Я сам счас редактор делаю. Вот как раскраска у меня задизайнена:
Вот, например, как можно сделать изменение размера шрифта "как в Сцинтиле или ИЕ":
class FontChangeDecorator : public IDecorator, IDecoratorListener
{
IDecorator* decorator_;
IDecoratorListener* listener_;
public:
FontChangeDecorator(IDecorator* decorator): decorator_(decorator) {}
public:
virtual void
decorate(
unsigned line,
const char_type* str,
unsigned len,
IDecoratorListener& dl) const
{
// запомнить текущее значение listener_, чтобы восстановить его в случае рекурсивного
// вызова FontChangeDecorator::decorate
IDecoratorListener* l = listener_;
// подменить листенер
listener_ = dl;
decorator_->decorate(line, str, len, *this);
// восстановить листенер
listener_ = l;
}
private:
virtual bool
onSubstringDecorated(
unsigned line,
const char_type* str,
unsigned strLen,
const char_type* substr,
unsigned substrLen,
const TextStyle& ts)
{
HDC dc = getTempDC(); // каким-то образом получить HDC
::SelectFont(dc, ts.font);
TEXTMETRICS tm;
::GetTextMetrics(dc, &tm);
LOGFONT lf = textMetrics2LogFont(tm); // как-то сконвертировали
lf.height += (lf.height * 10) / 100; // увеличить шрифт на 10%
TextStyle newTs(ts);
newTs.font = ::CreateFontIndirect(lf);
// передать в листенер измененный шрифт
listener_.onSubstringDecorated(line, str, strLen, substr, substrLen, newTs);
}
};
Использование FontChangeDecorator:
void
setFontChangeDecorator(HWND hwnd /* хендл на окно моего редактора */)
{
IDecorator* d = ::SendMessage(hwnd, MYEDITOR_MSG_GETDECORATOR, 0, 0);
IDecorator* d2 = new FontChangeDecorator(d);
::SendMessage(hwnd, MYEDITOR_MSG_SETDECORATOR, d2, 0)
}
Редактор дергает IDecorator::decorate каждый раз когда надо отрисовать строку текста передавая свои реализации интерфейса IDecoratorListener. Есть реализации IDecoratorListener-а которые высчитывают ширину подстроки/целой строки, высоту ну и т.д. Word wrap так же сделан через IDecoratorListener.
Бенефиты такого подхода:
1. декоратор дергается только для тех строк которые видны на экране — не надо мучать процессор лишней работой;
2. легко сделать кэш строк обработанных декоратором, т.к. для этого достаточно просто написать еще одну реализацию IDecoratorListener;
3. Визуализация текста не ограничена рисованием текста или рисованием картинки вместо текста, т.к. реализация IDecoratedSubstring ограничена только фантазией юзверя (в разумных пределах конечно ;
4. декораторы можно комбинировать. Пример — FontChangeDecorator который изменяет результаты разбора уже существующего декоратора.
Здравствуйте, alsemm, Вы писали:
VD>>Чтобы сделать точный скролинг и точное отображение позиции в документе. A>Вернее чтобы упростить реализацию этих функций
Я в последнее время вообще стараюсь не делать вещи сложенее чем нужно. Но тут это не причем.
При редактировании текстов с большими абзацами (вроде текста этого сообщения) скролинг должен быть не менее удобным чем при редактировании файла с кодом, где стоки почти не переносятся. Отсюда надо заранее рассчитывать переносы строк. Темболее, что это относительно недолго.
VD>>И каждый раз бегать по тексту рассчитывая строку? А смысл? Тормоза от этого конечно увеличатся, а вот бенефиты... A>Если юзать string[] для хранения текста, то да, смысла нет, не спорю.
Я не понимаю о чем ты говоришь. Что еще можно "юзать"? Массивы символов? Ну, и какая разница?
Объясни мне доходчиво.
A>Загрузили в редактор большой текст и стали его с головы редактировать.
И? Размер файла будет влиять только на время загрузки, ну, и на время изменения размера окна если включен перенос по его границе. А на редактирование это никак не скажется. Стой ты хоть в начале текста, хоть в конце.
A> Ограничения стурктуры данных (в данном случае string[]) не будут видны пока мощности железа хватает, но рано или поздно они вылезут. Вообще IMHO использование Position<Document> для адресации сомволов очень напоминает старничную память с кошмариками в виде long и short pointer-ов.
Ограничения string[]? Ты о чем? В редакторе вообще нет никаких string[]. Строки хранятся в специальном классе храняещем по одному string-гу на строку редактируемого файла.
A>... VD>>1. Так плохой идеей было использовать дотнетный Font. Это не позволяет менять в стилях отдельные атрибуты шрифта. Например, чтобы сделать жирным ключевые слова. Это же не дает реализовать простое масштабирование шрифтов. Мне очень нравится как в Сцинтиле или ИЕ можно менять размер ширфтов просто покрутив колесико мыши удерживая при этом Ctrl. A>Думаю это не проблема шрифта, а не совсем удачный дизайн класса Style. Если пользователи захотят что-то большее кроме как рисовать вместо текста картинки? Например обводить подстроку в рамку. Что делать будете? Добавлять поле _drawRectAroundText в Style?
А какие проблемы? Стиль == класс. Создавай наследника и храни хоть черта лысого. Другое дело, что прийдется отрисовку менять. Над расширением процесса отрисовки я даже не думал, так как не нужно. Проект с открытым кодом. Всякие плагины для него не особо то актуальный. Хотя если понадобится, то прикрутить будет не долго.
Тут же речь не о том. Речь о банальном удобстве. Человек решивший создать подсветку для некоторого формата не должен трахаться создвая стили для всех пересечений, или как ты предлагашь писать какой-то код вместо того, чтобы декларативно задать нужные ему свойства.
A>IMHO коряво.
Каждый имеет право на лево. Я считаю корявы знаниматься программированием там где можно без него обойтись.
A>class IDecoratorListener
A>{
A>public:
A> virtual ~IDecoratorListener() {}
A>public:
A> virtual bool
A> onSubstringDecorated(
A> unsigned line,
A> const char_type* str,
A> unsigned strLen,
A> const char_type* substr,
A> unsigned substrLen,
A> const TextStyle& ts) = 0;
A> virtual bool
A> onSubstringDecorated(
A> unsigned line,
A> const char_type* str,
A> unsigned strLen,
A> const char_type* substr,
A> unsigned substrLen,
A> const IDecoratedSubstring& ds) = 0;
A>};
И как это поможет тебе с рисованием той же рамки?
A>Вот, например, как можно сделать изменение размера шрифта "как в Сцинтиле или ИЕ": A>
A>...
A> virtual bool
A> onSubstringDecorated(
A> unsigned line,
A> const char_type* str,
A> unsigned strLen,
A> const char_type* substr,
A> unsigned substrLen,
A> const TextStyle& ts)
A> {
A> HDC dc = getTempDC(); // каким-то образом получить HDC
A> ::SelectFont(dc, ts.font);
A> TEXTMETRICS tm;
A> ::GetTextMetrics(dc, &tm);
A> LOGFONT lf = textMetrics2LogFont(tm); // как-то сконвертировали
A> lf.height += (lf.height * 10) / 100; // увеличить шрифт на 10%
A> TextStyle newTs(ts);
A> newTs.font = ::CreateFontIndirect(lf);
A> // передать в листенер измененный шрифт
A> listener_.onSubstringDecorated(line, str, strLen, substr, substrLen, newTs);
A> }
A>};
A>
Да уж... Прямо как в ИЕ или Сцинтиле... почти! Так как динамическое пересоздание шрифта на каждый токен — это задница для производительности. На относительно старом железе это будет тормозить как АБС.
К тому же изменение размеров шрифта должно быть незаметно для пользователя контрола. Да, и вобще, прямая возня с GDI — это само по себе фигня какая-то. Даже Сцинтила от нее абстрагироуется. Хотя это конечно к делу не относится.
A>Редактор дергает IDecorator::decorate каждый раз когда надо отрисовать строку текста передавая свои реализации интерфейса IDecoratorListener. Есть реализации IDecoratorListener-а которые высчитывают ширину подстроки/целой строки, высоту ну и т.д. Word wrap так же сделан через IDecoratorListener.
Ага. И на каждое вычисление размера токена мы имеем пересоздание шрифата. Плюс его же на отрисовку. Ну, нафиг такие "грамотные решения". К тому же еще и влезание пользовательского кода в низкоуровневые.
Масштибировние шрифта — задача редактора. Это относительно низкоуровневая пробелма и я лично на сегодня вижу ее решение на уровне библиотеки вывода на физическое устройство (ну, нечто вроде замены Graphics из GDI+).
В приложении будет использоваться объект-пустышка который только хранить описание шрифта (что-то вроде высокоуровневого объектно ориентированного LOGFONT). Функции вывода будут получать его и на его основании получать из кэша шрифт. Это будет и быстро, и добноно, и прозрачно для основного кода. Представлние, перед отрисовкой или рассчетом высот строк, будет выставлять свой масштаб, а библиотека отображения будет его отрабатывать.
Что касается прикладного оформления (тех самых стилей), то я считаю совершенно не верным делать какие-то потойные лазейки в данной области. Все форматирование должно определяться стилями. Если нужен новый вид форматировани, то просто добавляй новый стиль.
Я же говорил вообще о том что уже реализовано. Сейчас чтобы создать стилевой набор в котором используется один шрифт у котрого могут меняться характиристики вроде "жирный", "курсив" и т.п. я должен создать новые объекты Font. А ведь некоторые стили могут пересекаться. Если пересекаются стили с разными шрифтами, то возникает проблема. Ведь я не могу логически объеденить описание шрифтов или задать его частично (как это делаетс с цветами). Один шрифт переоределить другой. Вот я и говорю, что это просчет который нужно устранить. Должна быть возможность задавать шрифт частично. Чтобы наложение стилей не перекрывало один шрифт другим, а объеденяло их описания.
A>Бенефиты такого подхода: A>1. декоратор дергается только для тех строк которые видны на экране — не надо мучать процессор лишней работой;
А как на счет рассчета переноса строк? Забить на него? Лично я против. Мне нужен удобный в использовании редактор, а не набор компромисов.
A>2. легко сделать кэш строк обработанных декоратором, т.к. для этого достаточно просто написать еще одну реализацию IDecoratorListener;
А зачем мне кэш строк? Я и без него отлично живу. Дотнет и так жрет слишком много памти, чтобы забиват ее совершенно не нужными кэшами.
A>3. Визуализация текста не ограничена рисованием текста или рисованием картинки вместо текста, т.к. реализация IDecoratedSubstring ограничена только фантазией юзверя (в разумных пределах конечно ;
Я не заметл, чтобы твой прмер что-то мог изменить в отрисовке. Да и ливно мне это не нужно. Любое расширение дожно быть продумано и ограничено, чтобы оно не мешала остальным частям приложения. Твое предложение убивает к чертям всю диею стилей. Ну, нафиг такие расширения.
A>4. декораторы можно комбинировать. Пример — FontChangeDecorator который изменяет результаты разбора уже существующего декоратора.
А зачем мне вообще заниматься импиратившиной зависящей от последовательности выполнения и приводящей к мутному коду, когда я могу все что нужно вырзить в виде стилей?
На то я их и проектировал, чтобы потом не трахаться с кодированием и не офигивать от побочных эффектов от наложения таких вот расширений.
Мне нужна простота, ясность и скорость.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
...
VD>>>И каждый раз бегать по тексту рассчитывая строку? А смысл? Тормоза от этого конечно увеличатся, а вот бенефиты... A>>Если юзать string[] для хранения текста, то да, смысла нет, не спорю.
VD>Я не понимаю о чем ты говоришь. Что еще можно "юзать"? Массивы символов? Ну, и какая разница? VD>Объясни мне доходчиво.
У тебя сейчас, если я ничего не путаю, так:
Такое решние дает очень эффективную реализацию 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-е он всего один
Здравствуйте, alsemm, Вы писали:
A>У тебя сейчас, если я ничего не путаю, так: A>
A>class Document
A>{
A> string[] lines;
A>public:
A> string getLine(int idx) { return lines[idx]; }
A>};
A>
A>Такое решние дает очень эффективную реализацию Document::getLine. В минусе то, что время выполнения вставки/удаления строки не const и растет с увеличением количества элементов в массиве lines[].
Нет. Строки это наследники класса DocumentRow. В документе они хранятся в коллекции DocumentRowCollection. DocumentRowCollection внутри себя хранит динамический массив DocumentRow (List<DocumentRow>).
A>Этот специальный класс (Document, если ничего не путаю) инкапсулирует string[], так? Я об этом писал.
Не так, как видишь. И об этом рассказано в стаье.
Что касается скорости, то дабавление или удаление даже в огромных текствых файлах (3 метра и больше) занимает меньше 1% времени вставки. И вообще вставка небольшого кличества строк в любую точку документа для пользователя незаметна (выглядит как ралтаймная операция).
В свое время я задумался не будет ли тормозить List<T> в качестве основы для коллекции строк. Думал, а не использовать ли BigList<T> из PowerCollections. Но тесты показали, что в самом большом текстовом файле который я смог найти на своей машине (около 3 метров) List<T> вел себя даже лучше чем BigList<T>.
A>Тебя в сцинтиле все устраивает? Видимо нет, раз взялся за свой редактор. А почему сцинтилу не стал "подкручивать"?
Потому что в Сцинтиле был ряд проблем устранение которых практически невозможно. Вот они:
1. Сцинтила написана на С++ причем в такой манере, что ее практически невозможно переписать на МС++. А редактор нужно использовать в управляемых приложениях. Неуправляемый С++-код в таких условиях приводит к ряду проблем (от плохой интерграции и траты ресурсов, до невозможности запуска прилоежния в 64-битном окружении).
2. Стили в Сцинтиле наначаются битами. Это очень неудобно для моих потребностей.
3. Сцинтила трудно поддается рефакторингу. Опять же С++-ный код для которого нет человеческих средств автоматизированного рефакторинга. Плюс написана она кривовато.
4. Сцинтила не юникодная. Возня с UTF-8 и т.п. сильно задалбывает.
Плюс было интересно написать аналог Сцинтилы на управляемом языке чтобы было можно сравнивать результат.
Результат оказался интересным. По скорости проблем практически нет. По памяти управляемый вариант выглядит значительно хуже, но приемлемо. По объему и простоте кода управляемый вариант намного обходит Сцинтилу.
A> IMHO потому что, разбираться в чужом коде радость та еще. Ты идешь по тому же пути — захотят расширения делать, пусть правят код, а не плагин пишут. A>Плагины и открытый код вещи не взаимоисключающие.
Мы, в свое время, пытались делать плагины-интерфейсы к Хоуму. Потом отказались, так как смысла это не имело. Намного проще и эффектинвее просто развивать проект.
A>Уже были вроде посты про то, что писать свой стайлер для твоего редактора пока не очень удобно.
Да, это так. Но проблема тут в том, что именно вопрос со стайлером и вообще форматером банально плохо проработан. Когда доведем его до ума, то и вопросов не возникнет. Нет же вопросов по работе с клавиатурой?
A>... VD>>И как это поможет тебе с рисованием той же рамки? A>Так же как с фонтом.
То есть ручками рисовать конкурируя с основным кодом? Мне это не нравится.
A>Я код написал чтоб принцип был понятен. На самом деле на каждый токен фонт рожать не надо, заводим в FontChangeDecorator std::map<HFONT, HFONT>, где ключи — шрифты от A> существующего декоратора, а зчачения — новые, увеличенные и все дела.
ОК, согласен. Производительность можно поднять. Но иделогических проблем это не снимает.
VD>>А как на счет рассчета переноса строк? Забить на него? Лично я против. Мне нужен удобный в использовании редактор, а не набор компромисов. A>Все считается и перенос строк и прокрутка. Не в лоб конечно, но и каши в коде нет. Кстати, у тебя можно иметь строки разной высоты? Например, если в одной строке шрифт высотой 10, а в другой 20, то они будут 10 и 20 или обе по 20 высотой? У меня можна
В редакторе каждый стилевой диапазон может иметь отдельную высоку. Более того так как диапазоны можно менять на лету, то и высота отдельных строк может меняться динамически. Когда у меня был глюк и стиль выделения менял характеристики шрифта, то было вообще кртуто. Изменение выделения приводило к динамическому перетеканию текста и изменению высоты строк. Выглядело просто фиерично.
Так что разная высота строк это самое простое.
A>Кэш затем, чтобы юзверьский код лишний раз не дергать. Дернул декоратор для строки и запомнил результаты в кэш.
Вот по этому я и считаю, что зеру можно давать лезть только куда нужно. Тогда и кэширование не потребуется.
A>Я не навязываю свое решение, просто озвучил свой взгляд на задачу раскраски текста. Чем плохо на проблему с разных сторон посмотреть?
Разные мнения и решения всегда полезны. Просто так же как ты имешь право высказать свое мнение, я имею право с ним не согласиться.
Полезны же здесь аргументы. Ведь они наталкивают на мысли. Да и несогласие при некотором количестве качественных аргументов может превратиться в согласие.
VD>>Мне нужна простота, ясность и скорость. A>Сколько методов нужно реализовать юзеру чтобы написать свой стайлер? В IDecorator-е он всего один
Когда все будет доделоно, то вообще ничего писать не прийдется. А пока что просто есть некоторая реализация которая позволила написать основной код.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
...
VD>Не так, как видишь. И об этом рассказано в стаье.
Видимо проглядел
VD>Что касается скорости, то дабавление или удаление даже в огромных текствых файлах (3 метра и больше) занимает меньше 1% времени вставки. И вообще вставка небольшого кличества строк в любую точку документа для пользователя незаметна (выглядит как ралтаймная операция).
Интересно, надо бы у себя посмотреть как время распределяется.
VD>В свое время я задумался не будет ли тормозить List<T> в качестве основы для коллекции строк. Думал, а не использовать ли BigList<T> из PowerCollections. Но тесты показали, что в самом большом текстовом файле который я смог найти на своей машине (около 3 метров) List<T> вел себя даже лучше чем BigList<T>.
Открой в редакторе любой из его же исходников приличного размера (10-20К) и повтори последовательность {ctr+a, ctr+c, ctr+v} раз 10.
... VD>То есть ручками рисовать конкурируя с основным кодом? Мне это не нравится.
Именно так. Проблем не вижу.
... VD>ОК, согласен. Производительность можно поднять. Но иделогических проблем это не снимает.
Просто другой подход.
... VD>Когда все будет доделоно, то вообще ничего писать не прийдется. А пока что просто есть некоторая реализация которая позволила написать основной код.
Дык подстроку в рамку обвести можно будет или нет?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Fahrain, Вы писали:
F>> — Распростанение, т.е. на каких условиях я могу использовать этот контрол?
VD>Чесно говоря и у самого это вопрос открытый. Пока что остановился на следующем: VD>http://rsdn.ru/projects/Rsdn.Editor/Article/Info.xml
Может, уберете пункт про GNU? В конце концов некрасиво бороться с врагом его же методами. Да и лишние грабли это для разработчиков — не грех в общем-то выпустить что-нибудь под GNU, если уж очень нужно использовать какой-нибудь GNUтый код.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Может, уберете пункт про GNU? В конце концов некрасиво бороться с врагом его же методами. Да и лишние грабли это для разработчиков — не грех в общем-то выпустить что-нибудь под GNU, если уж очень нужно использовать какой-нибудь GNUтый код.
Пункт про GNU запрещает ГНУть код этого контрола. Но он не запрещает использовать этот код в GNUтых проектах. Просто в лицензии нужно указать, что код редактора подчиняется не лицензии GNU GPL, а той что описана по этой ссылке. Только и всего. Так что в любом открытом или закрытом проекте можно использовать этото код.
Просто если в рамках GPLного проекта кто-то сделает модификацию кода этого контрола, то ее тоже можно будет использовать в коммерческих проектах. Вот какова цель этого ограничения.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alsemm, Вы писали:
A>Открой в редакторе любой из его же исходников приличного размера (10-20К) и повтори последовательность {ctr+a, ctr+c, ctr+v} раз 10.
И? Взял исходинк BreakLine.cs (~50 кил). Вставил 40 раз его же в его же начало. Особых проблем не обнаружил.
Ты сам то пробовал?
VD>>То есть ручками рисовать конкурируя с основным кодом? Мне это не нравится. A>Именно так. Проблем не вижу.
А я вижу.
Я предпочитаю чистые решения. Даже сказал бы декларативные. Это же решение никак нельзя называть чистым. Это скорее какой-то хак во славу гибкости.
VD>>ОК, согласен. Производительность можно поднять. Но иделогических проблем это не снимает. A>Просто другой подход.
Естественно другой. И его минусы я описал.
A>Дык подстроку в рамку обвести можно будет или нет?
Если кому-то понадобится, то сделает нужный стиль и обведет. Это не проблема.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alsemm, Вы писали:
A>>Открой в редакторе любой из его же исходников приличного размера (10-20К) и повтори последовательность {ctr+a, ctr+c, ctr+v} раз 10.
VD>И? Взял исходинк BreakLine.cs (~50 кил). Вставил 40 раз его же в его же начало. Особых проблем не обнаружил. VD>Ты сам то пробовал?
Нет не пробовал.
Если бы ты внимательно прочитал мой комментарий, то 40 раз забить 50Кб файл вряд-ли получилось. Так попробуй:
1. вставить через клипборд 50К текста в начало
2. вставить через клипборд 50К текста в начало
3. выделить весь текст в редакторе и скопировать в клипборд
4. вставить через клипборд уже 100К текста в начало
5. выделить весь текст в редакторе и скопировать в клипборд (в клипборде уже 200К)
6. вставить...
Подозреваю что 40 итераций сделать не получится
... VD>>>ОК, согласен. Производительность можно поднять. Но иделогических проблем это не снимает. A>>Просто другой подход.
VD>Естественно другой. И его минусы я описал.
Спорить не буду.
Здравствуйте, alsemm, Вы писали:
A>Нет не пробовал.
Так попробовал бы и все вопросы потпали бы.
A>Если бы ты внимательно прочитал мой комментарий, то 40 раз забить 50Кб файл вряд-ли получилось. Так попробуй: A>1. вставить через клипборд 50К текста в начало A>2. вставить через клипборд 50К текста в начало A>3. выделить весь текст в редакторе и скопировать в клипборд A>4. вставить через клипборд уже 100К текста в начало A>5. выделить весь текст в редакторе и скопировать в клипборд (в клипборде уже 200К) A>6. вставить... A>Подозреваю что 40 итераций сделать не получится
Да, так не получится. Правда не потому, что структуры данных не те, а потому что алгоритм квардаричный. Уже на 10 разах получается 15 метров чистого текса в Win1251. В оперативке же это получается уже ~200 метров. Ведь там и анду-буфер, и юникод, и ОО-оверхэд и куча всего другого.
Но 10 вставок делаются довольно не напряжно. Правда в Rsdn.Editor очень халявно реализована работа с выделением. На любой чих просто перепарсивается вся область выделения, но вставка новой строки, после 10 вставок проходит молниеносно. Так что с динамическим массивом проблем нет никаких.
С другой стороны эксперемент совершенно бессмысленный. Ведь текстов такого размера попросту не бывает. 5 метров текста — это нехилая книжка.
... << RSDN@Home 1.2.0 alpha rev. 631>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alsemm, Вы писали:
A>>Нет не пробовал.
VD>Так попробовал бы и все вопросы потпали бы.
Я в NET не силен, возиться не охота было со сборкой. Теперь попробую раз все так шустро работает.
... VD>Но 10 вставок делаются довольно не напряжно. Правда в Rsdn.Editor очень халявно реализована работа с выделением. На любой чих просто перепарсивается вся область выделения, но вставка новой строки, после 10 вставок проходит молниеносно. Так что с динамическим массивом проблем нет никаких.
Стало быть я ошибался насчет тормозов. Бывает
VD>С другой стороны эксперемент совершенно бессмысленный. Ведь текстов такого размера попросту не бывает. 5 метров текста — это нехилая книжка.
Логи бывают и побольше.
Собрал и погонял редактор. Вполне шустро. Правда P4 3.2G с 1G памяти замучать непросто
Подтормаживает если удалять большие куски текста( >10000 строк), когда ресайзится окно если включен вордврап и в контроле > 20000 строк текста.
Но это все вообщем-то близкие к параноидальным значения, так что можно внимание не заострять.
Табы imho неправильно расставляет если в строке несколько шрифтов используется. Если используется немоноширинный шрифт или несколько шрифтов, то расчет ширины таба должен не от его позиции в строке зависеть, а делаться как в wordpad-е (там задаются позиции для табов в пикселях). Для этого даже спец. функция GDI есть — TabbedTextOut.
