Кроссплатформа - состояние на конец 2022 - Компьютерные священные войны

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

P>Из твоего списка, наприме, IDE уже пишутся на веб-технологиях, хотя и не все.

Это только потому, что есть LSP. Но всё равно большого смысла в IDE на web пока нет (кроме интерактивных типа Jupiter notebook).

P>Для музыки и фильмов — Electron, например, или же сайтики коих пруд пруди. См. например Tidal или Spotify.

Сайтики бесполезны, только клиенты с возможностью оффлайн прослушивания считаются.

P>git — на плюсах, а вот git UI уже на веб технологиях.

Некоторые на веб технологиях, но далеко не все. Можно поискать, какие популярны, наверняка в опросах на github и SO их задавали.

P>Рисовалок в вебе уже пруд пруди, Кстати, твой Gimp есть и онлайн https://www.offidocs.com/newfilemanager01.php?username=177859#elf_l1_RG93bmxvYWRz
P>Всего несколько лет назад их было раз-два и обчелся.
P>Офисов в вебе, например, от Микрософта и Гугла. Твой LibreOffice уже есть в онлайне.

Есть и что с того? У меня картинки сотни мегабайт в сжатом виде, такое геморно в вебе редактировать.

Тот же zoom, кстати, я использую нативно (не знаю на чём оно написано). Slack тормозной, Скайп тоже — это веб технологии.

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

P>>Из твоего списка, наприме, IDE уже пишутся на веб-технологиях, хотя и не все.

N>Это только потому, что есть LSP. Но всё равно большого смысла в IDE на web пока нет (кроме интерактивных типа Jupiter notebook).

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

P>>Для музыки и фильмов — Electron, например, или же сайтики коих пруд пруди. См. например Tidal или Spotify.

N>Сайтики бесполезны, только клиенты с возможностью оффлайн прослушивания считаются.

Я ж говорю — открой десктоп-клиент для того же спотифай. Это электрон, что есть те самые веб технологии.

P>>git — на плюсах, а вот git UI уже на веб технологиях.

N>Некоторые на веб технологиях, но далеко не все. Можно поискать, какие популярны, наверняка в опросах на github и SO их задавали.

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

P>>Рисовалок в вебе уже пруд пруди, Кстати, твой Gimp есть и онлайн https://www.offidocs.com/newfilemanager01.php?username=177859#elf_l1_RG93bmxvYWRz
P>>Всего несколько лет назад их было раз-два и обчелся.
P>>Офисов в вебе, например, от Микрософта и Гугла. Твой LibreOffice уже есть в онлайне.

N>Есть и что с того? У меня картинки сотни мегабайт в сжатом виде, такое геморно в вебе редактировать.

А на кой ляд их держать локально?

N>Тот же zoom, кстати, я использую нативно (не знаю на чём оно написано). Slack тормозной, Скайп тоже — это веб технологии.

И это тоже вебтехнологии.

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

P>Наоборот, на этом уже довольно большая доля разработчиков сидит.

Или маленькая. Понятно, всё на уровне "есть такое". Тот же gitk и git gui при этом есть у всех.

P>Я ж говорю — открой десктоп-клиент для того же спотифай. Это электрон, что есть те самые веб технологии.

У нас он не работает — не могу открыть.

P>>>Офисов в вебе, например, от Микрософта и Гугла. Твой LibreOffice уже есть в онлайне.

Так пусть появляются. Есть и на брейнфаке программы.

P>А на кой ляд их держать локально?

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

P>И это тоже вебтехнологии.

Вот и тормозят. Круто, да

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

P>>Я ж говорю — открой десктоп-клиент для того же спотифай. Это электрон, что есть те самые веб технологии.

N>У нас он не работает — не могу открыть.

vpn надеюсь имеется?

P>>>>Офисов в вебе, например, от Микрософта и Гугла. Твой LibreOffice уже есть в онлайне.

N>Так пусть появляются. Есть и на брейнфаке программы.

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

А кто тебе нативный софт будет обновлять, выпускать новые версии? Уже сейчас не хватает десктопных девелоперов, хоть каких. А с С++ под десктоп днем с огнем не найдешь. А нужны не абы какие, а довольно квалифицированые.

P>>А на кой ляд их держать локально?

N>Не понял вопрос. Сколько будет стоить хранить много террабайт больших фотографий в условном облаке? Как быстро я смогу их обрабатывать?

Если так, то конечно это кейс для десктопа.

P>>И это тоже вебтехнологии.

N>Вот и тормозят. Круто, да

Скайп тормозил даже когда был безо всякого Электрона. Крику было полно прямо на этом форуме.

Когда скажем обычный виндовый Эксплорер несколько секунд распаковывает мелкий зип с отключеными антивирусами, это ровно те же тормоза, только в профиль.
Мелкий зип начиная с 80486 распаковывался мгновенно. Но вот последние несколько лет это стало рокет саенсом, похоже

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

P>>>специалистов по такой механики раз два и обчелся.
CC>>Не ну охренеть просто какой бином Ньютона! Интернеты поди забанены, и почитать что там умные люди за подходы такие для редактирования текстов за эти годы изобрели ну ваще никак нельзя.
НС>А ты сам то пробовал?
Пробовал.

НС>Старенький FAR2 работает в текстовом режиме, это очень сильно все упрощает.
Ну и чем текстовый режим отличается от не-текстового режима при просмотре .txt файла?
Икемфула там соскакивает на просмотр pdf, что на самом деле ЕЩЁ проще, потому как формат структурирован с упором на именно что частичную подгрузку и файл уже заранее нарезан на страницы, у которых есть заранее известные размеры, потому спозиционироваться в середину файла куда как проще чем с просмотром того же txt, где как минимум надо знать в каком месте файла будет начинаться та самая "середина".

Обсуждать просмотр разношрифтового RTF мы даже ещё и не начинали.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

НС>Берешь любой проект на гитхабе, заменяешь в домене .com на .dev
Т.е. https://github.com/FarGroup/FarManager -> https://github.dev/FarGroup/FarManager ?

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

НС> тормозов при наборе текста по прежнему не ощущается.
Ну найди на гитхабе текстовый файл размером в гиг — посмотрим как оно работает.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P>он работал с чудовищного размерами файлов, включая pdf по 20000(двадцать тысяч) страниц. Рендериг пдф конечно не сами писали — взяли pdf.js, он справляется нормально.
2х

Ты поди не в курсе как устроен сам формат PDF, где даже парсить весь этот текст не надо а объект каждой страницы и её размеры можно найти в заботливо подготовленной метадате в PDF файле. Что позволяет грузить в память только то, что нужно, потому что сам формат заточен под такой сценарий работы. Так что та самая "частичная подгрузка" уже встроена в формат файла.
Ну и "взяли готовый просмотрщик" не считается за написание оного.

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

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

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

P>Для музыки и фильмов — Electron
С какого перепугу?
AIMP и MPC-HC наше всио!

P> например, или же сайтики коих пруд пруди. См. например Tidal или Spotify.
Дык говно что то что другое

P>git — на плюсах
Гы, нет.

P> а вот git UI уже на веб технологиях.
О чём ты вообще?

P>Кстати, твой Gimp есть и онлайн https://www.offidocs.com/newfilemanager01.php?username=177859#elf_l1_RG93bmxvYWRz
Чем бы дитё не тешилось...
Загрузи туда PSD от верстальщиков с кучей слоёв — посмеёмся.

P>Офисов в вебе, например, от Микрософта и Гугла.
Полное говно оба. Годятся для заметок, если надо полнофукнциональный офис то таки надо ставить декстопный офис.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

N>Slack тормозной
Слак ужасен...

N> Скайп тоже — это веб технологии.
Я на него и вовсе забил, испортили окончательно.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

P>Когда скажем обычный виндовый Эксплорер несколько секунд распаковывает мелкий зип с отключеными антивирусами, это ровно те же тормоза, только в профиль.
Взял Reflections_Demo.zip от NVDA, 1.3 гига

Что FAR, что WinRAR, что виндовый explorer распаковывают его за одинаковое время.

Может у тебя explorer тоже на веб технологиях?

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

CC>Обсуждать просмотр разношрифтового RTF мы даже ещё и не начинали.

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

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

НС>>Берешь любой проект на гитхабе, заменяешь в домене .com на .dev
CC>Т.е. https://github.com/FarGroup/FarManager -> https://github.dev/FarGroup/FarManager ?

Верно

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

Я напомню, что разговор начался с этого:

S>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.

А VSCode был приведен в качестве примера нетормозящего Электрона.

НС>> тормозов при наборе текста по прежнему не ощущается.
CC>Ну найди на гитхабе текстовый файл размером в гиг — посмотрим как оно работает.

Где ж я его тебе возьму?

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

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

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

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

НС> подавление фликеринга при скроллинге
Это ж вообще азбука!
BitBlt буфера, куда отрисован viewport уже очень давно не фликерит.

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

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

Банальный поиск в какой сегмент текста попадаешь путём поиска в каком RECT находятся мышиные координаты.
RECT для каждого сегмента ты уже получил когда их рисовал во viewport.
Потом выясняешь внутри строки символьное положение через GetTextExtentExPointW и всё.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

CC>>А куда внезапно написаный на С++ браузер делся, который мне это всё рендерит и показывает?
НС>Я напомню, что разговор начался с этого:
S>>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.
НС>А VSCode был приведен в качестве примера нетормозящего Электрона.

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

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

НС>>> тормозов при наборе текста по прежнему не ощущается.
CC>>Ну найди на гитхабе текстовый файл размером в гиг — посмотрим как оно работает.

НС>Где ж я его тебе возьму?
Ну так чтоб заметить тормоза глазом надо редактор хорошенько нагрузить.
Потому редактировать небольшие файлики совсем не интересно, они просто ОБЯЗАНЫ не тормозить.

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

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

Всё это сильно зависит от типа приложения. Банальность, но тем не менее надо отметить.
Если приложение типа "одна большая красная кнопка 'Сделай мне хорошо'" то да, шанец великий что это можно на 100% кроссплатформой сделать.
Тот же Sciter например. В частности Sciter.Quark.

S>Великая мечта — пишешь один раз, ~~отлаживаешь~~ используешь везде — все-таки приближается к реальности.

Если приложение для desktop OS, то да, в принципе можно 96% кроссплатформой сделать.
Если приложение и для desktop и для mobile то шансов на 100% вообще нет.

Разные форм факторы и типы ввода. На mobiles объективно говоря толком только кнопочный интерфейс работает.
Т.е. нажми кнопку тут или там. Ну еще на mobiles скролировать можно. Всё остальное — это только юзера напрягать.
Проекция pointer device (ака палец) на экран соизмерима с размером девайса, т.е. никаких там photoshop'ов особых на мобильниках ожидать не надо.

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

S>Основное в чем человечество сошлось — это браузер. Практически вся кроссплатформа основана на использовании браузерного рендеринга. Варианта ровно 2 — либо HTML-based либо Canvas-based.

На самом деле три.

В Sciter например можно одновременно:

1. DOM rendering, a.k.a. retained mode rendering;
2. <canvas> style rendering: buffered rendering — это когда canvas это журнал (batch) GPU комманд которые проигрываются на каждом WM_PAINT.
3. immediate mode painting в стиле ImGUI : это когда ты вешаешь на элемент paint handler (рисовалку) типа

[С++]
element.paintForeground = function(gfx) {....}
[/С++]

и оно отрисовывается вместе с DOM деревом.

1 и 2 это в browsers;
1,2 и 3 это в Sciter — bests of both worlds что называется.

S>Основные: React Native, Flutter (Canvas), Xamarin (как я понял, вызывают API ОС?)

Можно еще один вариант который был сделан в HTMLayout изначально.

HTML контейнер в котором все input элементы это native widgets от OS.
Т.е. HTML там испоьзуется как layout manager и одновременно рисовальщик статиков : текста, картинок и пр.

Как резюме: реалистично говорить о кросплатформе в кторой 70-90% кода шарится между платформами.
!00% серебрянной пули нет по условиям задачи.

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

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

Покажи как твоя native ide сможет отлажить node+react приложение, запускать тамошние скрипты, обеспечивать весь интелисенс для этого и тд.

CC>С какого перепугу?

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

P>> например, или же сайтики коих пруд пруди. См. например Tidal или Spotify.
CC>Дык говно что то что другое

Ога, не пробовал, но знаешь

Тидал и Спотифай встроены в каждый утюг нативно. Твой аимп здесь просто не нужен. Все что надо — сказать коробочке, пусть она играет "вон тот трек".

P>> а вот git UI уже на веб технологиях.
CC>О чём ты вообще?

Для git пишут UI с тех пор как появился сам git. Раньше писали на плюсах тех же, потом на джаве-дотнете, сейчас — на электроне. Никакого бенефита от плюсов здесь нет, что очевидно.

P>>Кстати, твой Gimp есть и онлайн https://www.offidocs.com/newfilemanager01.php?username=177859#elf_l1_RG93bmxvYWRz
CC>Чем бы дитё не тешилось...
CC>Загрузи туда PSD от верстальщиков с кучей слоёв — посмеёмся.

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

P>>Офисов в вебе, например, от Микрософта и Гугла.
CC>Полное говно оба. Годятся для заметок, если надо полнофукнциональный офис то таки надо ставить декстопный офис.

Доля этих кейсов "если надо" сократилась в разы и продолжает сокращаться.
А вот доля тех, кому хватает онлайн версии выросла чудовищно, настолько, что даже LibreOffice раскошелились на онлайн версию.

	От:	Skorodum
	Дата:	14.09.22 11:51
	Оценка:

От:	Pauel	http://blogs.rsdn.org/ikemefula
Дата:	14.09.22 12:02
Оценка:

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	14.09.22 12:12
Оценка:

От:	Pauel	http://blogs.rsdn.org/ikemefula
Дата:	14.09.22 12:28
Оценка:	+1

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	14.09.22 12:39
Оценка:

	От:	Ночной Смотрящий
	Дата:	14.09.22 19:12
	Оценка:	+2

	От:	c-smile
	Дата:	14.09.22 21:58
	Оценка:	3 (1) +1