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

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

Десятки мегабайт. Я редко видел тексты более 1мб. Соответственно, в 10 раз больше это уже "много больше".
Что бы редактировать простыни в гигабайт, это представить не могу, зачем такое надо.
Атом справляется где то с сотней мб.

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

А зачем мне блокнот? Там же никаких фич нету.

P>>Т.е. нативность сама по себе не даёт автоматических бенефитов
CC> А жабаскриптность получается сама по себе даёт автоматических бенефиты?

Именно что даёт. Ты избавлен от низкоуровневого кодинга.
Во всех областях разработки, хоть игры, хоть сапр, хоть офис, хоть машин-лёрнинг, идет разделение на низкоуровневый-высокоуровневый слои.
Соответственно юзер-фичи легче, проще, надежнее и быстрее писать на высокоуровневом ЯП.
Пример — никто в своём уме не пишет GUI игрушки на плюсах. Только рендеринг. Морда рисуется скриптованием.
Эта же вещь появилась и в Nginx — скриптовать можно на Lua и Жээсе, что используется в полный рост повсюду.
ML — питон прёт ото всюду.

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

P>> зато в обязательном порядке требует много бОльшей квалификации, что влечет за собой экономические последствия — разработчиков раз два и обчелся.
CC>Зато вебовских говношлёпов каждый второй, хоть печку ими топи! И эти мастера говна и костыля сделают всем щасте! Никто не уйдёт безнаказанным!

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

> А то помнится как в том же расхваливаемом VS Code моргание курсора было тяжеловесной операцией.

5 лет назад. Уже пофикшено. А вот дыры ОС, браузера, бд, итд не могут и по сей день пофиксить, хотя коду 20-30 и более лет.

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

Ога. Сколько у тебя лет опыта было, когда ты свой фремворк пилил? Довел до прода?

P>>UI фремворк это уровень студенческой курсовой. Раньше такое чуть не в каждой книге по программированию было.
CC>Ну да, конечно!

Именно.

CC>Вон поди расскажи авторам например того же sciter что у них на самом деле студенческая курсовая.

Логическая ошибка. Скитера не было "в каждой книге по программированию".

P>>Написать редактор с нуля мягко говоря затея на много бОльшее количество работы.
CC>Как уже написавший — не согласен.

Сколько времени ты потратил, довел ли до продакшна, и сколько опыта у тебя было на момент старта проекта?

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

А, ну ясно, раз баги, то криворучки. Твой фремворк кроме тебя кто нибудь тестировал? Кто, кроме тебя использовал, сколько команд?

P>>Скажем, нативные редакторы в норме то валятся от access violation, то морозятся, то еще чего.
CC>Ещё раз, тебя спрашивают про названия аппов, а не про твои сказки как оно у тебя валится. Мы сами в состоянии проверить как оно на самом деле вместо того чтоб верить твоим сказкам.

Ты странный — когда я попросил привести парочку примеров где жээс глючит, ты мне сходу нахамил, а теперь просишь аналогичную встречную услугу? Жду корректных извинений, после того приведу пример. Идёт?

P>>Наоборот. Рендеринг в консоли ничтожный по сложности, на уровне копирования строк.
CC>А там шрифты сами появляются и рендерить их не надо что ли? Это ж самая тяжёлая операция, все остальные вспомогательные расчёты и близко не валялись.
Насколько я помню, фар рисует через что нибудь навроде ReadConsoleOutput и WriteConsoleOutput. Раньше я юзал его в терминале, т.е. UI в этом случае тупо нет.
Даже если там есть вариант рендеринга через GDI, там моноширинный рендеринг. Что ты там считать собрался, если количество знаков в ширину-высоту известно заранее, размер шрифта задан заранее? Консольное приложение не управляет шрифтами, это делает винда. Размер окна она тебе сама выставит.

P>> Это следует из того, что ты редактор фара привел как пример.
CC>Опять гадание по фотографии?
CC>Я FAR пользую каждый день, постоянно, что на винде что на маке. Это мой основной тул для очень многих задач, который прекрасно

И отличия в рендеринге ты не видишь, да?

CC>В простейшем текстовом редакторе нет вообще никакого GUI, тупо текст на всё окно, курсор, один или два скроллбара. Кнопками или мышой двигаешь курсор, делаешь выделение, copy/cut/paste на шорткатах, ну или если ну очень хочется — меню по right click.
CC>Все интересности как раз под капотом, поддержка большого объёма текста в том числе. Если такие навороты в этом зоопарке не нужны то там вообще всё становится примитивно до безобразия.

Простейший как раз никого не интересует, он есть на всех платформах в виде компонента. Его не надо писать, если ты не студент.

Объем работы для редактора моно глянуть в сцинтилле — минимум 500кб внятного кода только под сам редактор и рендеринг с юзеринпутом под винду. Сравни со своими 800кб на весь фремворк.

CC>Позвать системную функцию которая рисует строку — не низкоуровневый рендеринг.

Это все еще низкоуровневый рендеринг, тк мы оперируем примитивами — строка, координаты, хендл, итд. Высокоуровневые примитивы — текст+ стили.
Сравни "нарисуй строку по координатам с цветом в такой то хендл"
И "вот тебе текст, вот тебе стили".

P>>Что именно готовое? Уровень этого "готового" много ниже того, что умеет браузерный движок.
CC>Чо, правда что ли?
CC>https://stackoverflow.com/questions/38766737/why-skia-on-windows-has-bad-efficiency

Читаем вместе:

in debug mode that skia with raster backend is 20 times slower than gdi. however in release mode skia with raster backend is 4-5 times slower than gdi.

i had another test that skia uses opengl as backend. the result shows skia and gdi spend almost the same time. skia is about 15% slower than gdi.

Что тебе не нравится?

CC>Я ж просто пошёл и посмотрел на iPad. Если там в спотлайте натайпать iBook то оно показывает статью в вики про какую то древнюю железяку. Ближайшее что есть с похожим названием из аппов называется Books, без каких либо i.

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

P>>Ты в курсе, что внятных компонентов для пдф раз-два и обчелся, вне зависимости от технологии?
P>>Те, что предлагают и полноценный функционал и быстро работают, стоят чудовищных денег.
CC>Этот плач тут к чему?
CC>Я писал свой PDF парсер, там прилично работы но вся она довольно таки рутинная. Если у тебя уже есть готовый рендерер которому можно скормить распаршеное (шрифты в том числе) то всё сильно упрощается.

Парсер это малая часть работы! Нужен внятный рендеринг, что бы выглядело красиво, глаза не уставали. Большинство рендереров этого не умеют. Не в курсе, что там, шрифты надо правильные или сглаживание, или сабпиксельный рендеринг, не могу сказать. Но у адоба круто, а у большинства компонентов резь в глазах или муть. Еще нужны ватермарки.
Далее, нужны вещи типа точный поиск, приблизительный, поиск по выражению и тд, выделение, правильное копирование, навигация, перелистывание, аннотации, комментарии, хайлайты.
Далее, нужна частичная подгрузка, чтобы не всасывать все 20000 страниц (не знаю, зачем верстают такие книги)
Кроме того, к этому всему нужно прикрутить внятное АПИ, на что большинство компонентов не способны.
Ну и перформанс — здесь снова большинство товарищей садятся в лужу.

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

P>>Пока что никто не смог обогнать акробат адобовский, ни на чем.
CC>Foxit, не?

Проект длился много лет и закончился в 17м после n версий на 4х платформах. Что там было на тот момент с фокситом, я не помню.