Здравствуйте, CreatorCray, Вы писали:

P>>судя по твоим примерам типа FAR итд ты не в курсе, что это значит, т.к. ни разу не пилил такое самостоятельно.
CC>Гадание по фотографии?

Ты сам про это пишешь.

P>>тупо суют готовый компонент, иначе на плюсах это будет самоубийство в большинстве случаев.
CC>И какой же есть "готовый компонент" редактора гигабайтных файлов для плюсов?

Я не говорил про гигабайтные. Я сказал — большие. Большие, это значит нетипичные для обычных сценариев. атом справляется с большими файлами, на которых большинство нативных уже тупо ложатся.
Т.е. нативность сама по себе не даёт автоматических бенефитов, зато в обязательном порядке требует много бОльшей квалификации, что влечет за собой экономические последствия — разработчиков раз два и обчелся.

CC>Самое геморное в редакторе, который может пережевать много текста, это совсем не рендеринг.

Не надо текст пережевывать — нужен виртуальный скроллинг и частичная подгрузка. А самое сложное будет рендеринг и юзер-инпут.

CC>Я как то под один свой проект собственный UI framework написал, где всё кастомное, всё рисует сам, причём на минимальном сабсете GDI.
CC>Так что все эти сказки про "сложности" "приседаний со шрифтами" и "вычисления координат" у меня вызывают смех.

UI фремворк это уровень студенческой курсовой. Раньше такое чуть не в каждой книге по программированию было.
Написать редактор с нуля мягко говоря затея на много бОльшее количество работы.

Тут можно вспомнить обилие косяков в редакторах в т.ч. однострочных на том же КДЕ — фиксовали баги десятки лет.

P>>То есть, в фаре изначально вообще нет ничего того, с чем придется столкнуться при написании текстового редактора или вьюера.
CC>Ну да, конечно, в готовом и работающем текстовом редакторе и просмотрщике нет ничего такого, "с чем придется столкнуться при написании текстового редактора или вьюера"

Ты ожидаемо решил поиграть в слова.

P>>Я привел свой пример, если ты не заметил.
CC>Нет, не привёл. Нет даже названия той самой "жээсной поделки", чтоб можно было проверить твоё утверждение о том, что она осилит всосать большой файл и показать его.

По дефолту — атом == электрон. Скажем, нативные редакторы в норме то валятся от access violation, то морозятся, то еще чего.
Т.е. нативных, что могут работать с большими файлам вобщем немного. Вот Ultraedit хорошо справляется, вроде как он нативный.
Атом по крайней мере не дохнет непойми от чего на ровном месте.

P>>Ну разумеется. Он пытается вгрузить всё, а нужна частичная подгрузка и виртульный скроллинг.
CC>Редактор в FAR, которому надо файл таки менять а не просто показывать, тем не менее справляется.

Ты адекватен? Для фара это ключевой кейс, его для того и используют. А для хрома это ничтожный, второстепенный. На кой ляд писать, отлаживать и тестировать ничтожный кейс, который никакого бенефита не добавит?

P>> Ты похоже не в курсе, чем отличается UI от консоли.
CC>В обсуждаемом контексте, а именно просмотр гигабайтного txt файла — ничем существенным.

Наоборот. Рендеринг в консоли ничтожный по сложности, на уровне копирования строк.

P>> Ты хоть раз пробовал вьюер или редактор теста писать, алё?
CC>Разумеется.

Вероятнее всего блеф Это следует из того, что ты редактор фара привел как пример.

P>>Нету ничего сложного в реализации виртуального скролинга и частичной подгрузки.
CC>Ты уж определись: нету ничего сложного или "могут не только лишь все" (С)

На мой взгляд это намного проще написания gui редактора с нуля и поддержки внятного юзер ипута.

P>> Сам алгоритм примитивный. Но вот приседания с памятью, апи отрисовки и прочими подобными вещами усложняют решение просто чудовищно.
CC>И опять ты приводишь утверждение в пользу С++ и не в пользу JS

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

P>>В жээсе ты избавлен от низкоуровнего рендеринга
CC>LOL! От чего?

От низкоуровнего рендеринга. Снова прочесть не можешь?

CC>Оно то конечно можно и так, если очень хочется, но нафига, если в системе уже есть всё это готовое?

Что именно готовое? Уровень этого "готового" много ниже того, что умеет браузерный движок. Частная загрузка и виртуальный скроллинг делается элементарно — кинул пару блоков, выставил css нужный и забыл. А на плюсах ты будешь пилить свои TextOut, колупаться с битмапами и тд. А еще надо селекшн и весь юзер-инпут. И сильно вряд ли первая версия выйдет лучше, чем у товарищей из КДЕ.

P>> а вот в плюсах у тебя должен быть значительный опыт в этой части.
CC>Ну просто капец как много опыта надо чтобы догадаться почитать документацию и позвать CreateFontW, GetTextMetrics, GetTextExtentPoint32W/GetTextExtentExPoint, SetTextColor, TextOutW

Вот-вот — низкоуровневая механика, которая, вдобавок, не гарантирует перформанс. Упс. А до кучи надо еще и селекшн запилить, и вообще весь юзер-инпут, типа курсов, клавиши и тд.
Эта же механика дает тебе возможность прострелить себе ногу, что в норме и случается.

Вот скажем однострочный редактор — вроде бы простая вещь, но вот товарищи в KDE в нулевых долго мучились, пока родили нормальный. У них вечно то зависал UI, то курсор при удалении выходил за границы, то процесс снимался, если понажимать удалить-вставить.

CC>Ты начал про "целая куча именно нативных редакторов/читалок не могут открыть большой файл"
CC>Ну и сравниваешь какую то древнюю читалку, которой похоже уже давно не существует судя по результатам гугления ("iBook is a line of laptop computers..."), с вообще не названной JS читалкой.

Да ты я вижу Мистер Осведомленность. Эта читалка по дефолту в ios искаропки идет, её на сколько знаю, и инсталировать не надо, Эпплом сделана для Эпловского магазина книжек.

P>>С редактированием простого txt файла граблей будет гораздо бОльше.
CC>Не может быть! Неужто я не писал "что гораздо проще редактирования оного" в прошлом сообщении?

Если проблемы уже в простом приложении, то в более сложном их будет тупо больше. Потому я и привел тебе пример вьюера.

CC>Ты поди не в курсе как устроен сам формат PDF, где даже парсить весь этот текст не надо а объект каждой страницы и её размеры можно найти в заботливо подготовленной метадате в PDF файле.

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

P>>Acrobat Reader не обогнали, но вот епубы работали лучше, чем нативном iBook
CC>Я тебе щас страшную тайну открою: акробат он как раз и есть тот самый "нативный" просмотрщик.

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