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

НС>>Даже с одним шрифтом у символов разная ширина, разное межстрочное расстояние, разный масштаб.
CC>И? Всё что тебе тут надо — GetTextExtentPoint32W и GetTextExtentExPointW
CC>Системный рендерер всё расчёты сделает за тебя.

Все рассчеты он за меня не сделает. И алгоритмы при этом заметно усложняется. Я уж не говорю о том, что GetTextExtent тормозной аж пипец, так что его результаты надо активно кешировать иначе будут те самые тормоза, с которыми ты сражаешься.

НС>> Кроме этого нужно учитывать попиксельный клиппинг
CC>Поскольку всё равно рисуешь в Bitmap по размеру viewport то достаточно посимвольного через GetTextExtentExPointW, всё остальное за тебя обрежет GDI renderer при вызове TextOutW.

Он, конечно, обрежет. Но будут те самые тормоза, с которыми ты сражаешься.

НС>> подавление фликеринга при скроллинге
CC>Это ж вообще азбука!

Это не азбука, а конкретне, в 2022 году довольно специфические навыки, требующие соответствующего спеца. С чего, собственно, разговор и начался.

CC>BitBlt буфера, куда отрисован viewport уже очень давно не фликерит.

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

НС>> отсутствие аппаратного курсора
CC>А в чём проблема нарисовать свой через банальный BitBlt?

В том что это надо делать.

НС>> поддержку мыши с пиксельными координатами и т.д.
CC>Да не проблема жеж вообще!

Да оно все не проблема, только в итоге набирается большая куча весьма специфического кода, который надо написать.

CC>Потом выясняешь внутри строки символьное положение через GetTextExtentExPointW

... который тормозит ... Ну ты понял.

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

CC>Электрон это ж хром + жабаскрипт. Так что браузер неизбежно присутствует.

Именно. Так что отсылка к С++ в браузере нерелевантна разговору.

Здравствуйте, 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 этот можно и обогнать с большим отрывом на том же жээсе.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Все рассчеты он за меня не сделает. И алгоритмы при этом заметно усложняется.
За меня делает

НС>Я уж не говорю о том, что GetTextExtent тормозной аж пипец
Ты про который из них вообще?

НС> так что его результаты надо активно кешировать иначе будут те самые тормоза, с которыми ты сражаешься.
Ты что, его посимвольно используешь что ли а потом из этих кусочков собираешь строку обратно?
Не удивительно что у тебя "всё тормозит".

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

НС>>> подавление фликеринга при скроллинге
CC>>Это ж вообще азбука!
НС>Это не азбука, а конкретне, в 2022 году довольно специфические навыки, требующие соответствующего спеца. С чего, собственно, разговор и начался.
Ващета double buffering это та элементарщина, без которой к графике и вовсе подходить не стоит, а не "специфические навыки"

CC>>BitBlt буфера, куда отрисован viewport уже очень давно не фликерит.
НС>А теперь вспоминаем про клиппинг. На который, конечно, можно забить, но будут те самые тормоза, с которыми ты сражаешься.

Какой нафиг клиппинг применительно к BitBlt для которого ты сам говоришь какой RECT откуда и куда сблитить?

НС>>> отсутствие аппаратного курсора
CC>>А в чём проблема нарисовать свой через банальный BitBlt?
НС>В том что это надо делать.
Ну капец какая проблема!!!
Странно что ты не сказал что это тоже "тормозит"

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

CC>>Потом выясняешь внутри строки символьное положение через GetTextExtentExPointW
НС>... который тормозит ... Ну ты понял.
Схренали он у тебя тормозит то?

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

P>>>Из твоего списка, наприме, IDE уже пишутся на веб-технологиях, хотя и не все.
CC>>Да на здоровье! Вот только получается хуже чем уже готовые native IDE. Так что толку с того?
P>Покажи как твоя native ide сможет отлажить node+react приложение
Это ж скриптота вебовская а не приложение

P>С такого, что сейчас стриминг это основная доля слушателей.
Да на здоровье! Вот только электрон для этого нафига?

P>Это можно заметить по куцым ssd в стоковых ноутбуках — не хватит ни на музыку, ни, тем более, на видео.
Интересно, а по шестиконечности снежинок ты тоже такие же далеко идущие выводы делаешь?

P>Тидал и Спотифай встроены в каждый утюг нативно.
Ни в одном из моих утюгов их нету
Ни на винде, ни на маке, ни на ведре, ни на iOS.
Где они?

P>>> а вот git UI уже на веб технологиях.
P>Раньше писали на плюсах тех же, потом на джаве-дотнете, сейчас — на электроне.
Ну вот у меня установлены два UI клиента: Source tree и Fork, оба судя по всему на Swift, у обоих нативный бинарь.
Нет там ни жавы, ни дотнета, ни электрона.

CC>>Загрузи туда PSD от верстальщиков с кучей слоёв — посмеёмся.
P>Пару лет назад и этого не было. Еще через пару лет это станет нормой.
Не станет.

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

P>А вот доля тех, кому хватает онлайн версии выросла чудовищно, настолько, что даже LibreOffice раскошелились на онлайн версию.
Эта та же аудитория которым хватает телефона на всё что им надо. Это не для работы, это так — потыкать одним пальцем.

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

P>>Покажи как твоя native ide сможет отлажить node+react приложение
CC>Это ж скриптота вебовская а не приложение

На этой скриптоте пишутся приложения, например, у микрософта это Скайп, Тимс, и кучка тулов.
Итого — твоя распрекрасная ИДЕ ничем не поможет.

P>>С такого, что сейчас стриминг это основная доля слушателей.
CC>Да на здоровье! Вот только электрон для этого нафига?

Десктопный клиент на нем.

P>>Это можно заметить по куцым ssd в стоковых ноутбуках — не хватит ни на музыку, ни, тем более, на видео.
CC> Интересно, а по шестиконечности снежинок ты тоже такие же далеко идущие выводы делаешь?

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

P>>Тидал и Спотифай встроены в каждый утюг нативно.
CC>Ни в одном из моих утюгов их нету

А что у тебя есть из рендереров музыки?

CC>Ну вот у меня установлены два UI клиента: Source tree и Fork, оба судя по всему на Swift, у обоих нативный бинарь.
CC>Нет там ни жавы, ни дотнета, ни электрона.

Ну и логика — у меня два нативных, значит на жээсе ничо нет

P>>Пару лет назад и этого не было. Еще через пару лет это станет нормой.
CC>Не станет.

Всего пару лет назад не было и того, что сейчас есть.

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

И ничего страшно в этом нет. Далеко не все фичи ворда нужны в повседневной жизни.

P>>А вот доля тех, кому хватает онлайн версии выросла чудовищно, настолько, что даже LibreOffice раскошелились на онлайн версию.
CC>Эта та же аудитория которым хватает телефона на всё что им надо. Это не для работы, это так — потыкать одним пальцем.

Именно. А раньше все эти юзеры вынуждены были десктопный офис юзать. Больше он им не нужен.

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

НС>>Это не азбука, а конкретне, в 2022 году довольно специфические навыки, требующие соответствующего спеца. С чего, собственно, разговор и начался.
CC>Ващета double buffering это та элементарщина, без которой к графике и вовсе подходить не стоит, а не "специфические навыки"

Вместо того, что бы кидать понты, глянул бы опенсорсный редактор типа сцинтиллы. Реализация чисто редактора + оконные приседения, юзеринпут и рендеринг занимает "всего" >500кб кода.

И это только cxx файлы. Собственно, для фара минимум 50% из всего этого не нужно.

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Зачем что-то представлять, воображение напрягать? Blazor именно так и работает, вполне себе уже в продакшине используется.

Кстати ты как то говорил, что в скором скайп и тимс собираются переводить на Blazor Hybrid

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

S>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>Зачем что-то представлять, воображение напрягать? Blazor именно так и работает, вполне себе уже в продакшине используется.

S>Кстати ты как то говорил, что в скором скайп и тимс собираются переводить на Blazor Hybrid

Не, я такого точно не говорил.
Меня как раз с блазором больше всего напрягает, что сам Микрософт не спешит что-то серьезное на нем делать.

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

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

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

P> Большие, это значит нетипичные для обычных сценариев.
Ты похоже в принципе не в состоянии выражаться внятно. Ну или просто ты не хочешь назвать какие либо проверяемые цифры потому как внезапно окажется что на самом деле всё не так как ты рассказываешь.
Ну да ладно, возьмём "нетипичные для обычных сценариев" размеры человекоредактируемых исходников, раз уж мы про IDE говорили.
В случае сурсов какие то жалкие 10К строк уже считается много (чаще даже меньшее колво строк, 3-4К, ну да ладно) и надо дробить на отдельные файлы ибо это банально неудобно что редактировать что ревьюить. В байтиках это ну килобайт 200. Но с таким объёмом текста справляется даже виндошный блокнот.
Ну давай проверим:
Пошарился в каталоге вижуалки, нашёл там самый большой файл сурсов — \VC\atlmfc\include\atldb.h — 383474 байта, 12230 строк. Блокнот его открыл моментально даже не икнув.
Ладно, наверное этот был слишком маленький, возьмём явно не человекописаный из SDK: \SDK\Windows\v7.0\Include\Mshtmlc.h — 3597Кб, 98833 строки, и тоже никаких проблем в блокноте.

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

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

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

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

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

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

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

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

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

P>Для фара это ключевой кейс, его для того и используют.
Этож надо какая неожиданность — редактор и просмотрщик использовать по их прямому назначению! Как же люди до такого догадались?

P>Наоборот. Рендеринг в консоли ничтожный по сложности, на уровне копирования строк.
А там шрифты сами появляются и рендерить их не надо что ли? Это ж самая тяжёлая операция, все остальные вспомогательные расчёты и близко не валялись.
Ты консоль с текстовым режимом видюхи часом не путаешь?

P>Вероятнее всего блеф
Стадия: отрицание.

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

P>>>Нету ничего сложного в реализации виртуального скролинга и частичной подгрузки.
CC>>Ты уж определись: нету ничего сложного или "могут не только лишь все" (С)
P>На мой взгляд это намного проще
Читать из mmaped файла не просто а ОЧЕНЬ просто.

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

P>Нисколько. На жээсе не надо пилить низкоуровневый рендеринг
P>От низкоуровнего рендеринга. Снова прочесть не можешь?

Что именно ты называешь "низкоуровневый рендеринг"?
Видеодрова свои писать? Видюху через порты конфигурить как в старые добрые времена когда были выкидыши типа Hercules?
Позвать системную функцию которая рисует строку — не низкоуровневый рендеринг.

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

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.

Или вот skia backend который использует системный DirectWrite font renderer (который кстати качеством похуже GDIшного): https://github.com/google/skia/blob/main/src/ports/SkTypeface_win_dw.cpp

P>А на плюсах ты будешь пилить свои TextOut
Мда... Уровень понимания — под плинтусом. Нафига пилить свой TextOut когда уже есть готовый системный?
Тут ещё чота подумалось: а ты часом GDI с GDI+ не путаешь? Ибо ну очень похоже на то.

P> колупаться с битмапами
Это НАСТОЛЬКО тяжело что я аж пацталом!

P>Вот-вот — низкоуровневая механика, которая, вдобавок, не гарантирует перформанс.
Ясно, ты нихрена не понимаешь в предмете. Дальше обсуждать не интересно — ты просто несёшь чушь.

P>А до кучи надо еще и селекшн запилить, и вообще весь юзер-инпут, типа курсов, клавиши и тд.
Если для тебя это очень сложно — у меня для тебя плохие новости.

P>Вот скажем однострочный редактор — вроде бы простая вещь, но вот товарищи в KDE в нулевых долго мучились
И? Какое мне дело до криворучия красноглазиков?

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

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

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

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

P>глянул бы опенсорсный редактор типа сцинтиллы.
Мне не надо смотреть на чужой код, я сам редактор писал.

P> Реализация чисто редактора + оконные приседения, юзеринпут и рендеринг занимает "всего" >500кб кода.
Потом, в scintilla кроме собственно редактора текста ещё приличная куча наворотов. Сам голый редактор именно чистого текста будет заметно меньше.

P>И это только cxx файлы. Собственно, для фара минимум 50% из всего этого не нужно.
У меня в UI FW все "оконные приседания" вместе с "юзеринпутом" и рендерером текста занимают где то 55К из 800К+ тотал объёма

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

P>На этой скриптоте пишутся приложения, например, у микрософта это Скайп, Тимс, и кучка тулов.
Не нужны

P>Итого — твоя распрекрасная ИДЕ ничем не поможет.
Я на своих IDE пишу EFI, kernel, системные тулы, просто тулы, десктопные аппы, моды для игр, которые мне интересны.
Единственная скриптота что у меня есть — в greasemonkey, чтоб бороться с криворучием веберов. Но для них никакого IDE не надо, хватает встроенного говноредатора.

P>>>С такого, что сейчас стриминг это основная доля слушателей.
CC>>Да на здоровье! Вот только электрон для этого нафига?
P>Десктопный клиент на нем.
А нафига ему вообще десктопный клиент? На десктопе и так есть браузер — зачем ещё один?

P>Вся музыка нынче слушается через стриминг.
Неа. Того, что я слушаю там просто нету, да и не было никогда.

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

P>Ну и логика — у меня два нативных, значит на жээсе ничо нет
Это опровергает твоё огульное: "а вот git UI уже на веб технологиях."

P>Всего пару лет назад не было и того, что сейчас есть.
Когда то считали что к 2000му году у каждого будет личный летающий автомобиль, и чо?

CC>>И такиж нет. Тот же гуглодок до сих пор перекашивает на элементарных вещах, которые в ворде просто работают.
P>И ничего страшно в этом нет. Далеко не все фичи ворда нужны в повседневной жизни.
Страшного то ничего, вот только и смысла в итоге пользоваться вебовским тоже никакого.
Проще тупо на макабуке во встроенном Pages накропать.

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

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

P>>На этой скриптоте пишутся приложения, например, у микрософта это Скайп, Тимс, и кучка тулов.
CC>Не нужны

Десятки или даже сотни миллионов юзеров об этом и не знают. Похоже, ты переводишь тему "мне ничо не надо". Разве мы про тебя говорим?

P>>Итого — твоя распрекрасная ИДЕ ничем не поможет.
CC>Я на своих IDE пишу EFI, kernel, системные тулы, просто тулы, десктопные аппы, моды для игр, которые мне интересны.
CC>Единственная скриптота что у меня есть — в greasemonkey, чтоб бороться с криворучием веберов. Но для них никакого IDE не надо, хватает встроенного говноредатора.

Итого — ты снова переводишь тему на свои личные хотелки

CC>>>Да на здоровье! Вот только электрон для этого нафига?
P>>Десктопный клиент на нем.
CC>А нафига ему вообще десктопный клиент? На десктопе и так есть браузер — зачем ещё один?

Забавно, разговор начинался с того, что десктоп софт уходит в веб-технологии
Пока десктоп клиент все ещё нужен, кое какие вещи в браузер не всунешь.
Со временем останется один только браузерный.

P>>Вся музыка нынче слушается через стриминг.
CC>Неа. Того, что я слушаю там просто нету, да и не было никогда.

И снова ты про себя В стриминге отсутствуют вещи, у которых есть проблемы с перевыпуском и лицензией.
Что такого ты случаешь, что нет в стриминге? Приведи парочку примеров.

P>>А что у тебя есть из рендереров музыки?
CC>Чего музыки?

А ты снова Мистер Осведомленность. Рендерер для музыки это один из вариантов сетевого проигрывателя. Раньше сетевые проигрыватели были только в варианте "всё в одном", а сейчас появился вариант "транспорт+рендерер".
Например, транспорт умеет и сидюки(дико популярен), и винил(дико популярен), и USB, и нетворк шары, и сервисы(дико популярно), и радио, и тв(дико популярно, и что хошь, а рендерер делает всё остальное.
Например, если у тебя есть ТВ + саундбар, то, внимание, у тебя есть ажно два рендерера. Посредственных, но рендерера.

P>>Ну и логика — у меня два нативных, значит на жээсе ничо нет
CC>Это опровергает твоё огульное: "а вот git UI уже на веб технологиях."

А ты снова "читатель". Я нигде не пишу "git UI пишут исключительно на веб-технологиях". Но тебе мерещится именно такое утверждение.
Зачем передергивать?

P>>И ничего страшно в этом нет. Далеко не все фичи ворда нужны в повседневной жизни.
CC>Страшного то ничего, вот только и смысла в итоге пользоваться вебовским тоже никакого.
CC>Проще тупо на макабуке во встроенном Pages накропать.

Ты снова про свои кейсы. Онлайн офисом пользуются по скромной оценке не одна сотня миллионов юзеров.

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

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

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

P>>глянул бы опенсорсный редактор типа сцинтиллы.
CC>Мне не надо смотреть на чужой код, я сам редактор писал.

Мало ли, вдруг ты подзабыл.

P>> Реализация чисто редактора + оконные приседения, юзеринпут и рендеринг занимает "всего" >500кб кода.
CC>Потом, в scintilla кроме собственно редактора текста ещё приличная куча наворотов. Сам голый редактор именно чистого текста будет заметно меньше.

Голый редактор никого не интересует — такой в любой ОС/платформе есть в виде компонента забесплатно.
Редактор с нуля пишут как раз ради тех особенных фич.

P>>И это только cxx файлы. Собственно, для фара минимум 50% из всего этого не нужно.
CC>У меня в UI FW все "оконные приседания" вместе с "юзеринпутом" и рендерером текста занимают где то 55К из 800К+ тотал объёма

Скорее всего это говорит о небогатых возможностях. Во всех фремворках, что я колупал, рендеринг и юзеринпут это бОльшая часть кода. Например, для правильного рендеринга и юзеринпута нужна внятная реактивная модель, внятный DOM, слои всякие, кеширование — всё это в 55кб кода да не С++ это нереально. Типичный код на плюсах, как например в сцинтилле, делает ровно то же, что и на жээсе, только раз в 5-10 более многословно.

Здравствуйте, 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х платформах. Что там было на тот момент с фокситом, я не помню.

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

CS>Т.е. как минимум два типа приложения (для desktop и для mobile) лепить придется. Бех лтносительно технологии UI.
Qt/QML довольно хорошо справляется.

Здравствуйте, Евгений Акиньшин, Вы писали:


S>>Кстати ты как то говорил, что в скором скайп и тимс собираются переводить на Blazor Hybrid

ЕА>Не, я такого точно не говорил.
ЕА>Меня как раз с блазором больше всего напрягает, что сам Микрософт не спешит что-то серьезное на нем делать.

Намерена перевести Microsoft Teams с фреймворка Electron на WebView2, чтобы повысить производительно работы
Введение в Microsoft Edge WebView2

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

P>Десятки мегабайт.
99МБ это тоже "десятки", нельзя ли более проверяемые цифры называть?

P>Что бы редактировать простыни в гигабайт, это представить не могу, зачем такое надо.
В жизни всякое бывает.

P>Атом справляется где то с сотней мб.
Ок. А кто должен справляться но не справляется?

P>Пример — никто в своём уме не пишет GUI игрушки на плюсах.
Что ты понимаешь под "GUI игрушки"?

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

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

P> А вот дыры ОС, браузера, бд, итд не могут и по сей день пофиксить, хотя коду 20-30 и более лет.
Какие именно? Или это опять так, для красного словца ляпнуто?

P>Ога. Сколько у тебя лет опыта было, когда ты свой фремворк пилил? Довел до прода?
Опыта в чём именно? В UI фреймворках считай никакого.

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

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

P>Ты странный — когда я попросил привести парочку примеров где жээс глючит, ты мне сходу нахамил,
Я писал про отдельные кривые сайты, где напихали скриптоты что они с трудом проворачиваются, а не про "жээс глючит". Так что это ты сам к себе претензии выдвигай, ибо обсуждать что либо в сценарии "сама придумала — сама обиделась" мне не интересно.

P> а теперь просишь аналогичную встречную услугу?
Ну т.е. нету таких аппов. Записано.

P>Насколько я помню, фар рисует через что нибудь навроде ReadConsoleOutput и WriteConsoleOutput.
А на экране оно святым духом появляется?

P>Что ты там считать собрался, если количество знаков в ширину-высоту известно заранее, размер шрифта задан заранее?
Расчёт положения это банальная арифметика, операция сложения, начальная школа. Отрисовка глифов шрифта занимает на порядки больше ресурсов чем эта ерундистика.

P>И отличия в рендеринге ты не видишь, да?
Отличия микроскопические, так что не интересно. В IDE для кода точно так же используется моноширинный шрифт, так что ты сейчас просто очередную сову мучаешь.

P>Это все еще низкоуровневый рендеринг, тк мы оперируем примитивами — строка, координаты, хендл, итд. Высокоуровневые примитивы — текст+ стили.
Если для тебя это низкоуровневый то у меня для тебя пачка забавных новостей.
Нет, это ещё не низкий уровень.

P>Сравни "нарисуй строку по координатам с цветом в такой то хендл"
Сравни рисование строки на уровне изменения цвета конкретных пикселей в памяти — вот это уже низкий уровень.

P>Нужен внятный рендеринг, что бы выглядело красиво, глаза не уставали. Большинство рендереров этого не умеют.
В pdf.js нету своего рендеринга, тупо используются функции браузера.

P>Далее, нужна частичная подгрузка, чтобы не всасывать все 20000 страниц (не знаю, зачем верстают такие книги)
Это вообще встроенная фича формата PDF

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

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

P>Скорее всего это говорит о небогатых возможностях.
Минет не делает, нет. Делает ровно то, что от него требовалось.

P>Типичный код на плюсах, как например в сцинтилле, делает ровно то же, что и на жээсе, только раз в 5-10 более многословно.

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

P>Забавно, разговор начинался с того, что десктоп софт уходит в веб-технологии
P>Пока десктоп клиент все ещё нужен, кое какие вещи в браузер не всунешь.
Вебсайт (spotify и иже с ними) никогда не был декстоп софтом.

P>Со временем останется один только браузерный.
Нет.

P>В стриминге отсутствуют вещи, у которых есть проблемы с перевыпуском и лицензией.
P>Что такого ты случаешь, что нет в стриминге?
Там нет новой музыки, которая мне бы понравилась.
Чтобы слушать то, что мне нравится, мне нахрен не упал стриминг — оно всё у меня уже есть и никакие "перевыпуски и лицензии" меня не побеспокоят.

P> Раньше сетевые проигрыватели были только в варианте "всё в одном", а сейчас появился вариант "транспорт+рендерер".
P>Например, транспорт умеет и сидюки(дико популярен), и винил(дико популярен), и USB, и нетворк шары, и сервисы(дико популярно), и радио, и тв(дико популярно, и что хошь, а рендерер делает всё остальное.
P>Например, если у тебя есть ТВ + саундбар, то, внимание, у тебя есть ажно два рендерера. Посредственных, но рендерера.
Ох уж эти аудиофильские понты

P>>>Ну и логика — у меня два нативных, значит на жээсе ничо нет
CC>>Это опровергает твоё огульное: "а вот git UI уже на веб технологиях."

P>А ты снова "читатель". Я нигде не пишу "git UI пишут исключительно на веб-технологиях". Но тебе мерещится именно такое утверждение.
"уже на" implies переход с одной технологии на другую. Чего не наблюдается.
То, что кто то где то налабал на вебе это не "уже на", а "ещё и на".

P>Ты снова про свои кейсы. Онлайн офисом пользуются по скромной оценке не одна сотня миллионов юзеров.
Да на здоровье! А оффлайн офисом сколько?

P>А что, обязательно телефон и писать монографии на тысячи страниц?
Да там простую смску порой упаришься написать, на микроскопической клаве, с очепятками, и автозаменой, которая думает что помогает.

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

P>Во вторых, бОльшая часть кейсов не требует ничего сложного — открыл, посмотрел, кое что поправил, кое что прокомментировал, отправил на печать, просмотрел предварительный результат.
А кто и на чём создал то, что "открыл, посмотрел, кое что поправил"?
Оно ж не из воздуха берётся.