Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
Основное в чем человечество сошлось — это браузер. Практически вся кроссплатформа основана на использовании браузерного рендеринга. Варианта ровно 2 — либо HTML-based либо Canvas-based.
Основные: React Native (HTML), Flutter (Canvas), Xamarin (как я понял, вызывают API ОС?)
Есть половинчатые — типа ElectronJS — не поддерживают моб.
Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Здравствуйте, Shmj, Вы писали:
S>Основное в чем человечество сошлось — это браузер. Практически вся кроссплатформа основана на использовании браузерного рендеринга.
У традиционных веб-приложений есть существенный недостаток, они не позволяют свободно манипулировать данными на клиенте. Можно, конечно, попытаться извратиться скриптами, но это будет малоэффективно. Очевидно придётся грузить эти скрипты многократно, а работать они будут просто ужасно.
По сути всё сводится:
1) К скорости доступа к памяти.
2) То, что клиент вообще сможет получить доступ к памяти.
По первому пункту, скорость идёт по убывающему от регистров процессора, озу, ssd, hdd, интернету. От наносекунд к микросекундам, от микросекунд к миллисекундам, от миллисекунд к секундам.
По второму, ну давай представим, что доступ к интернету у тебя всё же есть, но сервер из-за чего-то недоступен. А доступа может и не быть. Или возьмём убогий локальный HDD, мало того, что отклик с него будет быстрее, чем с интернета, так он ещё и всегда доступен.
Есть ещё минус веб-приложений, причём дело не в самих веб-приложениях, а в способе их реализации. Да, запускать скрипты может быть и удобно при разработке, но лично мне вся это возня с веб-серверами вроде nginx и прочих не особо нравится.
Итого, веб-приложения удобны как дополнительный интерфейс доступа к сервису, но не более. Так то разработчики очень многое теряют выпуская не десктопную или мобильную версию. А ещё браузеры устроены очень уродско, трут SSD почём зря. Они в этом плане и рядом не лежали с транзакционным доступом к базе данных.
И я бы вообще старался не употреблять слово кроссплатформа рядом со словом веб, особенно до уровня смешения. Кроссплатформа это запуск приложений на множестве платформ, под которыми понимается железо, операционные системы, способы запуска, такие как кроссплатформенная компиляция или виртуальные машины.
А веб-приложения основываются на разделении обязанностей на сервер и клиент, то есть запуск идёт не у тебя на платформе, а где-то удалённо на сервере. Это нельзя назвать кроссплатформенностью, разве что понимать под этим то, что тот же веб-сервер nginx или другой кроссплатформенны, и заставлять обычных пользователей запускать эти сервера и плагины для скриптов к ним у себя на компьютерах.
S>Основные: React Native (HTML), Flutter (Canvas), Xamarin (как я понял, вызывают API ОС?) S>Есть половинчатые — типа ElectronJS — не поддерживают моб. S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Попробую выразиться как-то помягче, это лютое говнище. Нормальные приложения на том же C/C++ будут рвать их в хламину. По мне всё очень просто, как говорил один великий мыслитель, не только лишь все могут, мало кто может это делать.
Весь этот мусор на скриптах годится для дешёвых команд говноразработчиков. Но нужно понимать, что как только придут профи с нормальными языками программирования, они натянут все эти говносервисы на скриптах на огромный болт.
Говносервисы спасает лишь то, что реально крутых программистов в мире не так уж и много. Да и в целом, почему люди не хотят замечать очевидного. Достаточно взглянуть как и на чём сделаны популярнейшие в мире программные продукты.
Нет, не нужно смотреть, что интересует всяких нубов в интернете, или что там должно стать популярным по мнению анал-итиков. И даже не то сколько вакансий на сайтах работы. Давайте просто взглянем на чём сделаны самые крутые программные продукты и вопросы отпадут сами собой.
Здравствуйте, Nuzhny, Вы писали:
N>Системное и серверное ПО — отдельно, вот всякие мессенджеры — да, вполне
Телеграм на C++/Qt написан.
Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.
Здравствуйте, Skorodum, Вы писали:
N>>Системное и серверное ПО — отдельно, вот всякие мессенджеры — да, вполне S>Телеграм на C++/Qt написан. S>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.
<Label Text="Hello, XAML!"
VerticalOptions="Center"
FontAttributes="Bold"
FontSize="18">
<Label.TextColor>
Aqua
</Label.TextColor>
</Label>
У нас есть реальный проект на этой фигне, который пытается воспроизвети интерфейс сделанный на Qt/QML. И код и интерфейс на MAUI выглядят так себе. С деплоем у них тоже какой-то геморрой.
Здравствуйте, Shmj, Вы писали:
S>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
Если реально нужна кроссплатформенность то уже лет дцать как можно использовать С++/Qt. Есть минусы:
* требует умения читать документацию и более-менее прямых рук
* коммерческая лицензия довольно дорогая
Плюсы:
* работает везде и быстро.
Я отвечаю за приложение, которое официально работает на винде, маке, линухе (x86-64 и арм). При необходимости и на андроиде и яблофоне взлетит. В исходниках платформоспецифичного кода примерно 0.1% (поддержка named pipe/fifo). Серьезные отличия только в инсталяторе, но скорее всего перейдем на IFW и там тоже отличий будет мало.
Здравствуйте, Shmj, Вы писали:
S>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
Первая, главная и принципиальная ошибка! Провозглашённая "мечта" — тупой хайп красноглазых пингвизятников, которым надоело клепать редакторы и канпелять ведро и им захотелось "серьёзного софта". Кроме пингвизятников ПРАКТИЧЕСКИ НИКТО не думает о том, что надо бы поддерживать ещё что-то.
Виндузовый мир давно укрепился на десктопе и им вообще по-барабану другие платформы. Ну а Эппл — там "своя атмосфера" — хомячки любят скруглённые углы, диктатуру и "жри чо дают", поэтому и там никто даже не пытается портировать свои плюшки вне iOS.
Возникает вопрос — кто и зачем разводит этот говнохайп "а давайте кроссплатформу"? Зачем вообще говорить об этом, если и так очевидно, что все операционки РАЗНЫЕ? Практика "амфибий" прекрасно доказала, что она и в воде — неахти, и на дороге — простигосподи. Теперь какой-то идиот пытается это запилить через софт — чего ради? Получить уродца типа Qt? Уже получили, дальше что? Победы этого тулкита до сих пор не видно, что опять доказывает — многоплатформа никому не упёрлась.
S>Основное в чем человечество сошлось — это браузер
Нет, опять фэйл, Шмж! Браузер — это не многоплатформа, как правильно заметил velkin, а тупо костыль, некая "своя отдельная и сильно ограниченная платформа".
S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Будете носиться со своей кроссплатформой — будете в тупике. Разувайте уже мозги, студота! Сколько можно теребить общественность своими глупыми мечтами? Работайте уже! Вон, есть VS — пишите нормальные FW-приложения, там работы — непочатый край.
Здравствуйте, Shmj, Вы писали:
... S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Странно читать всю эту тему... В одном топливном дивизионе одной популярной госкорпорации 1С наше всё.
"Коллеги, на 1С можно написать всё".
"Импортозамещение" называется...
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
К>"Коллеги, на 1С можно написать всё". https://1c.ru/news/info.jsp?id=29748 Поддержка процессоров архитектуры ARM с версии 8.3.22 платформы "1С:Предприятие"
Скоро уже пролоббируют обязательную её предустановку на все смартфоны?
V>Весь этот мусор на скриптах годится для дешёвых команд говноразработчиков. Но нужно понимать, что как только придут профи с нормальными языками программирования, они натянут все эти говносервисы на скриптах на огромный болт.
уже не скрипты же, вебасм уже. да, остались интеропы между апи браузера и вебасм, но в кол-во скриптинга
упало примерно до 1% от общей кодовой базы.
если клиенту не нужен прямой доступ к функциям ОС, то нормальное решение для клиента — простота обслуживания.
Здравствуйте, Shmj, Вы писали:
S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Есть такое предположение, что в итоге всё cойдется к HTML, включая нативные приложения ОС. Я имею в виду, HTML как движок UI. А логику к нему можно будет писать на любом языке, не только как сейчас на JavaScript.
Вот представьте такую штуку: возьмем известную многим концепцию WPF приложения и выкинем из него .xaml файлы, вместо них добавим .html файлы. Это, конечно же, уже не будет WPF приложением, но практически все остальные концепции и атрибуты приложения сохраняются. Из C# code behind файла дергаем HTML DOM. CSS ресурсы используем как шаблоны стилей. Тема приложения — это корневой CSS, в идеале идет из коробки и в точности повторяет общую тему ОС, в которой приложение работает.
Ништяк? Абсолютный. Не нужно никаких клиентов и серверов, все происходит как в самом обычном приложении.
HTML движок есть готовый на всех более-менее распространненых ОС. Но самое интересное это то, что реализация такой можели приложений получилась бы относительно компактной, так как львинная доля работы ложится на плечи уже готового HTML движка, который по-умолчанию брался бы из ОС и не требовал распространения в составе самого приложения.
Почему HTML? Потому что это де-факто стандарт UI. Многие конечно возразят, что нативные контролы лучше и т. д., но вы видели в каком состоянии эти контролы в последних релизах ОС? Возьмём High-DPI монитор и сможем быстро увидим, что те же Win32 сontrols — это просто динозавры, которые рендерятся в высоком разрешении с хаками и некрасивостями. Да, они были отточены для 96 DPI, но на high-DPI на них трудно смотреть без слёз.
WinRT — недостаток в том, что это только Windows, плюс эта подсистема относительно закрыта и плохо документирована, поэтому используется мало и в основном только самими Microsoft.
WPF — достойно, но не кроссплатформенно.
MAUI — ИМХО тупиковая свистоперделка основанная на каличном Xamarin'е у которой нет шансов.
Avalonia — очередной .NET-only велосипед. Хоть и кроссплатформенная, но тюрьма.
И вот он, HTML. Скоромно сияет в сторонке, как диаманд на фоне всего этого уныния вокруг и ждет своего часа.
A>Вот представьте такую штуку: возьмем известную многим концепцию WPF приложения и выкинем из него .xaml файлы, вместо них добавим .html файлы. Это, конечно же, уже не будет WPF приложением, но практически все остальные концепции и атрибуты приложения сохраняются. Из C# code behind файла дергаем HTML DOM. CSS ресурсы используем как шаблоны стилей. Тема приложения — это корневой CSS, в идеале идет из коробки и в точности повторяет общую тему ОС, в которой приложение работает.
Зачем что-то представлять, воображение напрягать? Blazor именно так и работает, вполне себе уже в продакшине используется.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Зачем что-то представлять, воображение напрягать? Blazor именно так и работает, вполне себе уже в продакшине используется.
Не совсем. Blazor — эта такая себе .NET тюрьма. А я говорю за всё множество языков, в том числе и нативных. Чтобы было так:
"UI на OCaml — легко!"
и не нужно было переучиваться под конкретную связку programming language — UI framework.
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Зачем что-то представлять, воображение напрягать? Blazor именно так и работает, вполне себе уже в продакшине используется.
A>Не совсем. Blazor — эта такая себе .NET тюрьма. А я говорю за всё множество языков, в том числе и нативных. Чтобы было так:
Ну я на предложение про WPF отвечал. WPF точно также гвоздями прибит к .net.
У Микрософт была попытка "сделать точно такой же WPF, но отвязанный от языка и платформы" — то что называлось uwp\winrt. Но на практике 95% приложений для него на шарпе писалось.
Что касается html\css то он слишком низкоуровневый — в любом случае нужен фреймворк поверх.
Мне кажется, что тупиковая. Эдакий локальный максимум. Любой инженер морщится, когда ему надо использовать семантический HTML для несемантического UI. Но для преодоления этого тупика требуется недюжинные усилия крупнейших корпораций, в первую очередь гугла и эппла.
На мой взгляд правильная кроссплатформа выглядит так: выпускается условно микро-браузер. Он умеет wasm и ряд важнейших API, в первую очередь WebGPU. Этот микро-браузер имеет малый размер и малое потребление ресурсов. Конечно у него нет никакого своего интерфейса, по сути просто рантайм, на котором запускается веб-приложение. И к этому микро-браузеру делается набор библиотек, тот же флаттер, чтобы обычные программисты могли этим пользоваться. Этот микро-браузер может и должен идти в составе гугль хрома, чтобы обновляться с ним синхронно. А установленные веб-приложения должны интегрироваться в систему на уровне обычных (иконки в пуске и тд).
Гугль может это сделать для десктопа и андроида. Но для полноценного распространения нужна заинтересованность эппла, чтобы на айфоне и макбуке оно работало так же. И желательно микрософта.
А там можно этот рантайм отпилить от бразуера и использовать независимо, если очень хочется. Хотя я считаю, что рантайм должен быть общий, это правильней. И обновлять его удобней в одном месте и ресурсов жрать меньше будет. Отпиливать его может быть уместно во встраиваемых приложениях, чтобы на каких-нибудь микроконтролерах рисовать интерфейс.
Но это всё лирика. Понятно, что сегодня кроссплатформа это обычный браузер и тут пока ничего не поделаешь.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>У Микрософт была попытка "сделать точно такой же WPF, но отвязанный от языка и платформы" — то что называлось uwp\winrt. Но на практике 95% приложений для него на шарпе писалось.
Классная идея. Но её нужно было делать вокруг открытого стандарта, потому что никто на проприетарщину подсаживаться сейчас в здравом уме уже не будет. Точнее, конкретная реализация может быть и проприетарной, но стандарт должен быть открытым. HTML как раз и претендует на роль такого стандарта.
ЕА>Что касается html\css то он слишком низкоуровневый — в любом случае нужен фреймворк поверх.
Абсолютно верно. Из коробки могло бы поставлятся только то, что умеет делать хост система, всё остальное — сторонние примочки, в том числе и коммерческие.
В WPF задумка именно такая, но реальность значительно хуже, потому что то, что там идет из коробки не достаточно приближено к UI системы и это видно невооруженным глазом. Поэтому разработчикам пол WPF ничего не остаётся как где-то брать темы, стили. Что на самом нелегко и далеко не всегда оправдано.
vsb>Но это всё лирика. Понятно, что сегодня кроссплатформа это обычный браузер и тут пока ничего не поделаешь.
На "обычном браузере" все "современные" г-сайты, надизайненные 20-летними сеньорами по паттернам, выдают только требование скачать новейший браузер не старше прошлой недели.
Здравствуйте, Aquilaware, Вы писали:
A>Ништяк? Абсолютный. Не нужно никаких клиентов и серверов, все происходит как в самом обычном приложении.
Ништяк оно будет, когда будет легко и просто собирать приложения в дизайнере форм. не думая о html тегах, думах, css, Js, и всем остальном прочем. накидал полей и кнопок, обработал события, все, интерфейс готов.
Здравствуйте, rm2, Вы писали:
rm2>Здравствуйте, Aquilaware, Вы писали:
rm2>Ништяк оно будет, когда будет легко и просто собирать приложения в дизайнере форм. не думая о html тегах, думах, css, Js, и всем остальном прочем. накидал полей и кнопок, обработал события, все, интерфейс готов.
Согласен. Для продуктивной работы это и есть суть ништяка. Но есть дилемма: концепция дизайнера подразумевает пиксельную разметку, когда достигается WYSIWYG (what you see is what you get, что ты видищь то и получаешь).
Но как быть с responsive layout (отзывчивой разметкой), которая сама подстраивается под DPI и размеры экрана? Все современные UI именно такие, и это не прихоть их разработчиков, а реальность, которая надиктована широчайшим зоопарком пользовательских устройств появившихся в последнее десятилетие.
Поэтому возникает вопрос: как сделать такой дизайнер, который бы мог обеспечить поддержку и WYSIWYG и responsive layout в одном флаконе? Есть ли существующие примеры таких дизайнеров?
Здравствуйте, Shmj, Вы писали:
S>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности. https://youtu.be/DiA2hOqoL9k?t=600
Здравствуйте, vaa, Вы писали:
S>>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности. vaa>https://youtu.be/DiA2hOqoL9k?t=600
Операционная среда Оберон. Очень интересно, но напрягает то, что опять же это тюрьма одного языка. Если я захочу использовать сервисы этой среды, например, из С#, то как это сделать? Ответа готовго нет. В этом и корневой проёб этого проекта, очередная тюрьма. Из-за такого узкого взгляда на суть вещей и имеем то, что имеем.
Но идея интересная. Операционные среды могут быть экстремально полезны.
Приведу пример по этой теме не относящийся к UI. Есть приложение работающее в области forensics. Приложение должно уметь читать архивы и прочие файловые контейнеры — само собой смотреть в .ZIP, уметь заглядывать в .MSI (который не является чистым архивом, а скорее инсталлятором). Чтобы смотреть в .MSI как следует, нужно уметь смотреть и в .CAB архивы. И т. д. насколько хватает сил.
Вопрос, как это сделать? Очевидный вариант — это натаскать библиотек по этим темам и дёргать их из кода приложения. Но получится так, что велосипед будет изобретаться вновь и вновь в каждом таком приложении. Почему бы тогда не заиспользовать функции ОС? Аргументов против этого несколько: а) таких функций зачастую нет б) эти функции могут быть нейстойчивыми из-за конфигурации/версии ОС, что будет мешать некоторым типам приложений, например, в которых сделан упор на безопасности или на работе из коробки.
И здесь на сцену выходит так называемая операционная среда (operating environment). Операционная среда — это как ОС, только она работает поверх существующего хоста.
Яркий пример — Windows 3.1 — это была операционная среда, работающая поверх операционной системы DOS. Но мало кто знает, что она имела и режим, в котором Windows выступала как operating runtime (операционная среда выполнения). В этом режиме Windows могла идти как библиотека к приложению, обеспечивая некоторые его "хотелки" такие как, например, UI. А приложение линковалось с этой "библиотекой" в момент построения. Таким образом, на выходе компилятора получался артифакт, который был способен использовать полноценный UI с окнами, кнопками и всем остальным характерным для Windows, но при этом оставался всего-лишь DOS .exe файлом способным работать на голом DOS`е без установленной Windows. Это и есть operating runtime, концепция, которая сейчас неизвестна для большинства.
Так вот. Если бы был такой operating runtime сейчас, то цены ему бы не было. Во-первых, он мог бы закрывать назревшие проблемы кроссплатформенного UI, во-вторых, решать и другие задачи как в примере с архивами. Этот operating runtime мог бы идти как набор пакетов для множества языковых экосистем. Например, хотим UI, подключаем пакет, и вуаля — всё готово, занимаемся решением своей задачи, а не изобретением очередных велосипедов. Хотим смотреть в архивы? Подключаем еще один пакет, и вуаля.
И всё это могло бы быть доступно для многих языков одновременно, а не так как сейчас — имеем тесную связку "технология X ↔ язык Y", что приводит к мультипликативному росту сложности X * Y, вместо того, чтобы оставаться X + Y.
Здравствуйте, Aquilaware, Вы писали:
A>Яркий пример — Windows 3.1 — это была операционная среда, работающая поверх операционной системы DOS. Но мало кто знает, что она имела и режим, в котором Windows выступала как operating runtime (операционная среда выполнения). В этом режиме Windows могла идти
мне казалось я знаю win 3 — 3.11 но о таком не слыхал, что это за режим ?
A>Так вот. Если бы был такой operating runtime сейчас, то цены ему бы не было. Во-первых, он мог бы закрывать назревшие проблемы кроссплатформенного UI, во-вторых, решать и другие задачи как в примере с архивами. Этот operating runtime мог бы идти как набор пакетов для множества языковых экосистем. Например, хотим UI, подключаем пакет, и вуаля — всё готово, занимаемся решением своей задачи, а не изобретением очередных велосипедов. Хотим смотреть в архивы? Подключаем еще один пакет, и вуаля.
Здравствуйте, sergey2b, Вы писали:
S>мне казалось я знаю win 3 — 3.11 но о таком не слыхал, что это за режим ?
Давно это было, подробностей уже и не припомню. Помню еще что Windows 3.1 умела в ROM образы заходить, опять же, малоизвестная фича из этой же области.
S>в docker можно писать и GUI приложения
Docker — это нечто другое, это ближе к виртуальной машине. Полезная штука, но у неё своя тема — о серверах, о воспроизводимости, о минимизации состояния машины. Для распространения маленьких и средних приложений Docker не очень подходит, только потому что в один Docker образ нельзя поставить несколько других готовых Docker-образов-приложений одновременно. Запускать же по Docker'у для каждой мелочи не получится, так как между приложениями нередко необходимо организовывать интеграцию и обмен данными, а Docker — это изолированная вещь и чтобы что-то такое накрутить нужно не слабо заморочиться.
Здравствуйте, Aquilaware, Вы писали:
A>HTML движок есть готовый на всех более-менее распространненых ОС. Но самое интересное это то, что реализация такой можели приложений получилась бы относительно компактной, так как львинная доля работы ложится на плечи уже готового HTML движка, который по-умолчанию брался бы из ОС и не требовал распространения в составе самого приложения.
Либо все ОС завязывать нужно на один движок и одной версии, либо будут интересные результаты на разных системах.
Сейчас конечно время практически победившего Blink, но пока ещё встречаются сайты, которые плывут на разных браузерах.
A>Почему HTML? Потому что это де-факто стандарт UI.
Этот стандарт без JS не жизнеспособен
A>Многие конечно возразят, что нативные контролы лучше и т. д., но вы видели в каком состоянии эти контролы в последних релизах ОС? Возьмём High-DPI монитор и сможем быстро увидим, что те же Win32 сontrols — это просто динозавры, которые рендерятся в высоком разрешении с хаками и некрасивостями. Да, они были отточены для 96 DPI, но на high-DPI на них трудно смотреть без слёз.
Нативные контролы — это привычный вид и поведение. Если человек сидит на данной ОС, значит его устраивает вид нативных контролов.
A>И вот он, HTML. Скоромно сияет в сторонке, как диаманд на фоне всего этого уныния вокруг и ждет своего часа.
Хлам, который почему-то пока лидирует.
Столько разработчиков и всяких стандартов.
Могли бы уже нормальный язык разметки и стилизации для GUI составить и внедрить во все ОС и браузеры.
Здравствуйте, Shmj, Вы писали:
S>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
FoxPro 2.6 for DOS
самое оно.
самый удобный интерфейс на HTML проиграет в скорости и удобстве ввода.
изначально HTML это способ представления знаний и данных, т.е. удобная интерактивная библиотека для ученых.
первичный интерактив HTML UI — клик мышкой по ссылке. не более. сам же HTML это вообще протокол, лишенный интерактивности по сути.
Замена нормальному интерфейсу так себе.
Достаточно попробовать день посидеть без мышки и тачпада в интернете.
я уже не говорю про веб-приложения где нужно активно вводить данные.
Здравствуйте, velkin, Вы писали:
S>>Основные: React Native (HTML), Flutter (Canvas), Xamarin (как я понял, вызывают API ОС?) S>>Есть половинчатые — типа ElectronJS — не поддерживают моб. S>>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
V>Попробую выразиться как-то помягче, это лютое говнище. Нормальные приложения на том же C/C++ будут рвать их в хламину.
Стоит заметить, что нормальных пользовательских приложений на С++ становится все меньше и меньше. Старые отживают своё, а новых не появляется. Вместо них стартуют проекты на веб-технологиях.
Весь десктоп целиком плавно перетекает в веб уже много лет.
V>Весь этот мусор на скриптах годится для дешёвых команд говноразработчиков. Но нужно понимать, что как только придут профи с нормальными языками программирования, они натянут все эти говносервисы на скриптах на огромный болт.
Этих профи надо примерно в 10...100 раз больше. Где их взять, откуда они придут, если до сих пор спрос на программистов дико перегрет?
V>Говносервисы спасает лишь то, что реально крутых программистов в мире не так уж и много.
Вот-вот. А потому технологии завязаные на таких программистов обречены на вымирание.
Здравствуйте, Pauel, Вы писали:
P>Весь десктоп целиком плавно перетекает в веб уже много лет.
Кстати, интересно было бы посмотреть на то, чем пользуются на десктопе. Как по мне, всё основное осталось на том, на чём и было написано. Оно, как правило, большое, тяжёлое, требует развитого и сложного UI.
Всё то, что проще условных Фотошопов и Автокадов, в принципе на десктопе не развивается, а уходит даже не в веб, а в приложения на телефоне: мессенджеры, ютьб, банковские приложения, даже Госуслуги. Что из десктопного уходит в веб?
vaa>FoxPro 2.6 for DOS vaa>самое оно. vaa>самый удобный интерфейс на HTML проиграет в скорости и удобстве ввода.
Кстати, текстовый режим выводится в html 1:1 практически без дополнительных трудозатрат. Почему это до сих пор не взлетело? Учитывая, с какой радостью публика восприняла чОрные лапидарные иконки и всю эту примитивизацию UI "назад в windows 1.0". Почему до сих пор микрософт не объявил это ультрасовременным подходом и не переделал обратно в текстовый режим все свои сайты и продукты?
Здравствуйте, Osaka, Вы писали:
vaa>>FoxPro 2.6 for DOS vaa>>самое оно. vaa>>самый удобный интерфейс на HTML проиграет в скорости и удобстве ввода. O>Кстати, текстовый режим выводится в html 1:1 практически без дополнительных трудозатрат. Почему это до сих пор не взлетело? Учитывая, с какой радостью публика восприняла чОрные лапидарные иконки и всю эту примитивизацию UI "назад в windows 1.0". Почему до сих пор микрософт не объявил это ультрасовременным подходом и не переделал обратно в текстовый режим все свои сайты и продукты?
ни разу не видел, даже в таких продуктах как 1c тонкий клиент и им подобным, не дотягивает даже до вин-форм.
не хватает безмышевого режима работы. после открытия страницы, нужно полчаса жать таб чтобы выйти на ввод запроса например.
вот свежее: https://demo.lsfusion.org/mycompany/
вижу customer(F5) вкладка POS
жму — и вуаля — перегрузка страницы.
веб и html не гарантирует поведение.
вообще все уже было в java web start.
почему-то мало кто знает и использует.
это было бы идеальным решением для нормального ПО.
Здравствуйте, Skorodum, Вы писали:
S>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.
VS Code, который основан на Electron совсем не лагает при вводе текста, и вообще очень отзывчивый. Это один из самых быстрых (в смысле латентности ввода) редакторов. Субъективно — намного отзывчевее Emacs'а.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, vaa, Вы писали:
vaa>вижу customer(F5) вкладка POS vaa>жму — и вуаля — перегрузка страницы. vaa>веб и html не гарантирует поведение.
UI с поддержкой горячих клавиш, правильной табуляцией, правильным автофокусом и прочим делается на HTML'e относительно легко. Другое дело, что для сайтов этим почти никогда не замарачиваются, но возможности такие есть и они довольно широкие — любая такая хотелка делается на раз-два.
HTML != сайт, подобное заблуждение должно остаться в прошлом. HTML — это язык разметки, который на сегодняшний день является де-факто стандартом построения взаимодействия с подавляющим большинством информационных систем, и не только онлайновых.
Приведу пример: приложение Apple Music на айфонах использует именно HTML для своего UI. Может ли конечный пользователь это как-то определить, может оно кривое какое-нибудь? Абсолютно нет. Всё отполировано настолько, что не подкопаешься. Поэтому когда есть такой мощный стандарт, все дисскуссии по поводу того, на чем делать тот или иной UI со временем будут уходить в небытие.
Тут пожалуй есть единственная проблема — это проблема восприятия. Многие воспринимают HTML как некий блокнот, в котором работает скриптъ, есть перегрузки страниц с потерей состояния и это всё бяка-бяка, кака-кака. Но это иллюзия идущая от вэба. На самом деле, HTML просто задаёт разметку UI, а наполнятся и моцифицироваться она может из любого языка програмирования. То же самое относится и к состоянию — оно может иметь любое время жизни. Проще всего смотреть на HTML документ как на window (окно) или даже как на элемент управления (control). Например, закрыли окно и потеряли состояние, т.к. оно более не нужно. Логично ведь? Так же происходит и в MFC, и в Windows Forms и в WPF. Открыли новое окно, UI нарисовался из разметки, приобрёл новое состояние. Дернули элемент управления — получили событие, промодифицировали свойство кнопки. Эта известные всем UI'щикам истины, и в HTML они работают точно так же.
Никаких серверов, портов и прочего для этого не нужно! Это просто опциональные надстройки для вэба. Берем окно, кладем в него HTML и дёргаем DOM. Обеспечиваем работу с ресурсами, чтобы можно было ссылатся, например, на файлы стилей прямо из исполняемого файла без всяких HTTP серверов. Всё. UI готов.
Хотим быстрого старта? Берем какой-нибудь готовый CSS ништяк, например, Bootstrap. Если буквально — кладем этот готовый скачанный CSS файл в наш проект как ресурс и ссылаемся на него из HTML. Получаем на выходе очень достойный UI за очень короткое время, c полной поддержкой high-DPI, разных форм-факторов устройств и разных платформ.
Сейчас это замутить не так просто, как я расписал, но представьте если это бы решалось одним пакетом добавленным в проект. Как легко можно заметить, JavaScript тут вообще мимо, он не используется. Его роль выполняет ваш любимый и серъёзный язык программирования. Любой!
Здравствуйте, ins-omnia, Вы писали:
IO>VS Code, который основан на Electron совсем не лагает при вводе текста
Это как бы ожидается от любого редактора.
IO> Субъективно — намного отзывчевее Emacs'а.
Это лишь говорит о том, что emacs — говно
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
IO>>VS Code, который основан на Electron совсем не лагает при вводе текста CC>Это как бы ожидается от любого редактора.
Это должно ожидаться от любого редактора по-хорошему. По факту многие популярные IDE тормозят при вводе текста. Либо из-за движка своего редактора, либо из-за довесков всякого интеллисенса. Почившим недавно в бозе Atom'ом вообще нельзя было пользоваться из-за этого. При этом его многие хвалили.
А вообще я отвечал на религиозный тезис о порочности и тормознутости веб-технологий в редакторах. По факту такие вещи могут работать намного лучше теплых ламповых изделий на нативном C.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Pauel, Вы писали:
P>Весь десктоп целиком плавно перетекает в веб уже много лет.
Бредятина из мира веб-мартышек. Сижу на десктопе, все приложения — адекватный нэйтив. Идиотизмом типа Электрона не пользуюсь в принципе. В моём мире "никто никуда не идёт". Более того — идёт инженерная борьба за скорость, чтобы юзер в Винде с 16 гигами не чувствовал себя владельцем домофона.
Здравствуйте, Aquilaware, Вы писали:
A>UI с поддержкой горячих клавиш, правильной табуляцией, правильным автофокусом и прочим делается на HTML'e относительно легко
Зачем расхваливать это "разметочное позорище", будто оно хоть как-то заменяет настоящий интерфейс?! Ерунду порете, будто UI — это кнопочки и текстовые поля! Давай, покажи мне настоящий docking на HTML! (как в VisualStudio) Или адекватный обмен данными с диалоговыми окнами. Да чё там, ты даже файл не сохранишь толком, если будешь сидеть в гипертекстовом ушлёпищще! И при всех этих недостатках находятся клоуны, которые утверждают, что HTML заменяет вендодесктоп! Студенты, ваши калькуляторы — это ещё не весь десктоп! Напишите хотя бы что-то близкое по удобству и скорости а-ля VideoPad — там посмотрим.
Здравствуйте, ins-omnia, Вы писали:
IO>По факту такие вещи могут работать намного лучше теплых ламповых изделий на нативном C.
У них ж под капотом таки С или С++ код, который и делает всю основную работу.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Baiker, Вы писали:
B>Более того — идёт инженерная борьба за скорость, чтобы юзер в Винде с 16 гигами не чувствовал себя владельцем домофона.
Зато с таким подходом люди чувствуют себя владельцами патефона. И вы почувствуете, когда наконец-то слезите c DPI 96 ppi на более высокий при покупке 4К монитора.
Здравствуйте, CreatorCray, Вы писали:
IO>>По факту такие вещи могут работать намного лучше теплых ламповых изделий на нативном C. CC>У них ж под капотом таки С или С++ код, который и делает всю основную работу.
Ну где этого нет под капотом? Там есть слой DOM и наверняка даже JS (не проверял), которые оптимальны совсем для других задач. Ну там каждое слово — отдельный спан, каждая строка див (или параграф), это всё нужно тасовать при вводе каждой буквы. Застрелиться можно.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
A>Зато с таким подходом люди чувствуют себя владельцами патефона. И вы почувствуете, когда наконец-то слезите c DPI 96 ppi на более высокий при покупке 4К монитора.
Можно раскрыть мысль? Будучи владельцем 4K монитора не понял метафоры.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, ins-omnia, Вы писали:
IO>>>По факту такие вещи могут работать намного лучше теплых ламповых изделий на нативном C. CC>>У них ж под капотом таки С или С++ код, который и делает всю основную работу. IO>Там есть слой DOM и наверняка даже JS (не проверял), которые оптимальны совсем для других задач. Ну там каждое слово — отдельный спан, каждая строка див (или параграф), это всё нужно тасовать при вводе каждой буквы.
Ну и как это подтверждает твоё утверждение что "такие вещи могут работать намного лучше теплых ламповых изделий на нативном C" если ты только что рассказал что "нативный С" код браузера должен перелопатить куда больше стороннего говна чтоб сделать то же самое что и редактор, который сразу написан на "нативном С"
IO>Застрелиться можно.
Тот же WinWord 6.0 прекрасно справлялся с редактированием текста на древних машинах, схренали вдруг на на порядки более быстрых машинах не тормозящий редактор сраного текста считается чем то магическим?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Nuzhny, Вы писали:
P>>Весь десктоп целиком плавно перетекает в веб уже много лет.
N>Кстати, интересно было бы посмотреть на то, чем пользуются на десктопе. Как по мне, всё основное осталось на том, на чём и было написано. Оно, как правило, большое, тяжёлое, требует развитого и сложного UI.
В основном браузер. У большинства юзеров нет каких то особых задач, ради которых надо тащить тот же внятный офис. А этот офис уже есть в вебе и у Гугла, и у Микрософта.
N>Всё то, что проще условных Фотошопов и Автокадов, в принципе на десктопе не развивается, а уходит даже не в веб, а в приложения на телефоне: мессенджеры, ютьб, банковские приложения, даже Госуслуги. Что из десктопного уходит в веб?
В веб. Например, банковские приложения это веб-технологии, судя по тому, что я вижу. Стоимость разработки нынче чудовищная, мейнтейнить и сайт, и мобайл это мягко говоря перебор.
Вспоминаем кейс со Сбербанком — вебка работает, а мобайл приплызд. И так много у кого, на самом деле.
Даже мобайл проще пилить на веб-технологиях, если нет какой особой изюминки типа 2D/3D графики итд.
Госуслуги, судя по размеру апк 88мб в ней сидит мобильный Хром и пару-тройку мегабайт жээса. В этом случае можно процентов 60-80 совместить с обычным вебом.
В лучшем случае в мобайле будет какой react-native, что означает веб-технологии.
Здравствуйте, CreatorCray, Вы писали:
IO>>Застрелиться можно. CC>Тот же WinWord 6.0 прекрасно справлялся с редактированием текста на древних машинах, схренали вдруг на на порядки более быстрых машинах не тормозящий редактор сраного текста считается чем то магическим?
Потому, что написать редактор сраного текста на С/С++ намного сложнее, а специалистов по такой механики раз два и обчелся. Потому нативные софтины мягко говоря большей частью не юзабельны.
Например целая куча именно нативных редакторов/читалок не могут открыть большой файл, а вот жээсные "поделки" не только открывают, но и позволяют работать.
Для примера — iBook от эппла на iOS. Вкинул туда для интересу как то пару конских epub — эта штука зависала регулярно любом действии, при чем настолько жостко, что морозилась сама ios, нельзя было выйти.
А вот жээсные аналоги позволяли и открыть, и работать с книгой. Как сейчас, не знаю, ios уже не пользую.
Поэтому что бы по дефолту нативный софт работал лучше — такого нет, т.к. сложность разработки много выше а специалистов в разы меньше.
С жээсным софтом гораздо лучше — сложность разработки ниже, специалистов много, потому можно выкрутиться разными способами.
Здравствуйте, Pauel, Вы писали:
P>В основном браузер. У большинства юзеров нет каких то особых задач, ради которых надо тащить тот же внятный офис. А этот офис уже есть в вебе и у Гугла, и у Микрософта.
Браузер, да, как новая ОС. Это ПО пишется на С/С++.
Облачными офисами пользуются на уровне заметок, как мне показалось. Основная проблема — все документы не являются твоими. В гугле банят, почту взламывают — это всё реальность, которая временами касается моих знакомых. Иногда нет возможности работать с этим по корпоративным правилам безопасности. В деревне на даче с плохим интернетом тоже нафиг. То есть полноценный офис всё равно ставить приходится.
P>В веб. Например, банковские приложения это веб-технологии, судя по тому, что я вижу. Стоимость разработки нынче чудовищная, мейнтейнить и сайт, и мобайл это мягко говоря перебор. P>Вспоминаем кейс со Сбербанком — вебка работает, а мобайл приплызд. И так много у кого, на самом деле. P>Даже мобайл проще пилить на веб-технологиях, если нет какой особой изюминки типа 2D/3D графики итд.
Тут не в курсе, но все эти примеры всё равно не иллюстрируют исход из десктопа в веб, там нет ничего десктопного. То есть разве когда-то были десктопные банковские приложения? В них же смысла нет никакого, они без интернета бесполезны.
P>Госуслуги, судя по размеру апк 88мб в ней сидит мобильный Хром и пару-тройку мегабайт жээса. В этом случае можно процентов 60-80 совместить с обычным вебом. P>В лучшем случае в мобайле будет какой react-native, что означает веб-технологии.
Ну это уже так себе примеры. На десктопе используется тот же Sciter — это веб-технология? Кажется, что да, но по сути же нет. Всё таки самое главное в этом интернет, а не HTML/CSS/JS
Здравствуйте, ins-omnia, Вы писали:
IO>Можно раскрыть мысль? Будучи владельцем 4K монитора не понял метафоры.
Большинство приложений которые не на HTML и не на WPF/WinRT — не поддерживают высокий DPI. В каких-то местах есть микроскопические иконки вместо нормальных, где-то текст не влазит, часть приложений вообще рендерится с "увеличением", из-за чего они приобретают характерную "мутность".
Вообщем, карусель-зоопарк для любителей ретро, которые еще не соориентировались что к чему.
Здравствуйте, Aquilaware, Вы писали:
A>Большинство приложений которые не на HTML и не на WPF/WinRT — не поддерживают высокий DPI.
Qt вполне себе нормально живёт. У меня ноут 15 с 4k экраном — вполне норм.
A>Вообщем, карусель-зоопарк для любителей ретро, которые еще не соориентировались что к чему.
Здравствуйте, Pauel, Вы писали:
P>Потому, что написать редактор сраного текста на С/С++ намного сложнее
Да ну!
P>специалистов по такой механики раз два и обчелся.
Не ну охренеть просто какой бином Ньютона! Интернеты поди забанены, и почитать что там умные люди за подходы такие для редактирования текстов за эти годы изобрели ну ваще никак нельзя.
P>Потому нативные софтины мягко говоря большей частью не юзабельны.
Что ты несёшь?
P>Например целая куча именно нативных редакторов/читалок не могут открыть большой файл
Ну вот гигабайт текста это уже большой файл или ещё нет? Банальный встроенный редактор в FAR такой файл грузит за пару секунд и редактирует. Просмотр так вообще мнгновенный, что в начале файла что в конце.
P> а вот жээсные "поделки" не только открывают, но и позволяют работать.
И какая же жээсная "поделка" такое файло сможет отредактировать?
Потому что хром его даже на просмотр не смог загрузить: долго пыжился, пыхтел, грузил, процесс рендерера жрал память как бесплатную и в итоге сдох, показав при наличии ещё ~50+ гигов свободной физической памяти мессагу "Aw, Snap! Something went wrong while displaying this webpage. Error code: Out of Memory". Похоже упёрся в какой то свой внутренний лимит. ProceXP показывает что его job имеет Process Memory Limit в 16 GB, что несколько объясняет premature падение.
Старенький FAR2 этот же файл просматривает легко и непринуждённо, потребление памяти подскакивает с 15 мегабайт до аж цельных 18!
Так что не, нифига не похоже чтоб "жээсные поделки" (tm) вот так уж легко смогли такой файл прожевать.
И это даже не обсуждаемый "редактор сраного текста" (С) был а так, просмотр банального txt файла, что гораздо проще редактирования оного.
P>Для примера — iBook от эппла на iOS.
Я хз что это такое, но почему то из твоего описания мне кажется что это ну ни разу не "редактор сраного текста" (С).
К чему это всё было?
P>Поэтому что бы по дефолту нативный софт работал лучше — такого нет, т.к. сложность разработки много выше а специалистов в разы меньше. P>С жээсным софтом гораздо лучше — сложность разработки ниже, специалистов много, потому можно выкрутиться разными способами.
Аргументация в стиле "отвёрткой неудобно ковырять в носу а потому слон веселее мухи"
Икемфула как всегда.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Baiker, Вы писали:
B>Разувайте уже мозги, студота!
Последуй совету первым. Говоря про кроссплатформ, говорят про серверные системы. На декстопах и мобилках свой кухня у каждого девайса. Тут кросcплатформом никто не запаривается. И серверы-это линуксы, bsd, юниксы и немного винды. Вот кроссплатформ между ними и стоит на повестке.
Здравствуйте, CreatorCray, Вы писали:
P>>Потому, что написать редактор сраного текста на С/С++ намного сложнее CC>Да ну!
Именно. И судя по твоим примерам типа FAR итд ты не в курсе, что это значит, т.к. ни разу не пилил такое самостоятельно. Но мнение имеешь.
P>>специалистов по такой механики раз два и обчелся. CC>Не ну охренеть просто какой бином Ньютона! Интернеты поди забанены, и почитать что там умные люди за подходы такие для редактирования текстов за эти годы изобрели ну ваще никак нельзя.
Почитать — можно. Но применить — нужна высокая квалификация. Никто обычно не берется, а тупо суют готовый компонент, иначе на плюсах это будет самоубийство в большинстве случаев.
У большинства тех, что пишут свой редактор или читалку большей частью выходит чтото мутное.
P>>Например целая куча именно нативных редакторов/читалок не могут открыть большой файл CC>Ну вот гигабайт текста это уже большой файл или ещё нет? Банальный встроенный редактор в FAR такой файл грузит за пару секунд и редактирует. Просмотр так вообще мнгновенный, что в начале файла что в конце.
Ты адекватен? Фар это консольное приложение. Рендеринг считай по сложности как склейка строк, нет ни gdi, ни приседаний со шрифтами, ни вычислений координат, итд итд.
То есть, в фаре изначально вообще нет ничего того, с чем придется столкнуться при написании текстового редактора или вьюера.
В консольном приложении достойный скроллинг реализованый с нуля займет пару десятков строк. Я такое даже на ассемблере писал, уложился ажно в 400 байт выполняемого файла. Размер файла был ограничен объемом доступной памяти.
P>> а вот жээсные "поделки" не только открывают, но и позволяют работать. CC>И какая же жээсная "поделка" такое файло сможет отредактировать?
Я привел свой пример, если ты не заметил.
CC>Потому что хром его даже на просмотр не смог загрузить
Ну разумеется. Он пытается вгрузить всё, а нужна частичная подгрузка и виртульный скроллинг. Пилить такое для браузера смысла нет — визгу много, а шерсти мало.
CC>Старенький FAR2 этот же файл просматривает легко и непринуждённо, потребление памяти подскакивает с 15 мегабайт до аж цельных 18!
Ты похоже не в курсе, чем отличается UI от консоли. Ты хоть раз пробовал вьюер или редактор теста писать, алё?
CC>Так что не, нифига не похоже чтоб "жээсные поделки" (tm) вот так уж легко смогли такой файл прожевать. CC>И это даже не обсуждаемый "редактор сраного текста" (С) был а так, просмотр банального txt файла, что гораздо проще редактирования оного.
Нету ничего сложного в реализации виртуального скролинга и частичной подгрузки. Сам алгоритм примитивный. Но вот приседания с памятью, апи отрисовки и прочими подобными вещами усложняют решение просто чудовищно.
В жээсе ты избавлен от низкоуровнего рендеринга, а вот в плюсах у тебя должен быть значительный опыт в этой части. Иначе — приплызд.
P>>Для примера — iBook от эппла на iOS. CC>Я хз что это такое, но почему то из твоего описания мне кажется что это ну ни разу не "редактор сраного текста" (С).
Ты снова не заметил, что я сравниваю апельсины с апельсиными, т.е. одну читалку с другой ?
CC>К чему это всё было?
К тому, что жээсный аналог iBook работает вполне себе достойно. Читалка, к твоему сведению, намного проще редактора — хватит примитивных структур данных. Формат епуб облегчает работу, предоставляет тебе всё, что необходимо. С редактированием простого txt файла граблей будет гораздо бОльше.
Я тебе больше скажу — у меня целый проект был, аналог iBook. Одна из его фишек была как раз в том, что он работал с чудовищного размерами файлов, включая pdf по 20000(двадцать тысяч) страниц. Рендериг пдф конечно не сами писали — взяли pdf.js, он справляется нормально.
Acrobat Reader не обогнали, но вот епубы работали лучше, чем нативном iBook.
Здравствуйте, velkin, Вы писали:
V>Очевидно придётся грузить эти скрипты многократно, а работать они будут просто ужасно.
Зачем их грузить многократно и почему они будут ужасно работать?
V>По сути всё сводится: V>1) К скорости доступа к памяти.
А она нужна, скорость доступа к памяти на фронте?
V>Или возьмём убогий локальный HDD, мало того, что отклик с него будет быстрее, чем с интернета, так он ещё и всегда доступен.
Ну так есть же html web storage, вот тебе и локальный HDD без интернета.
V>но лично мне вся это возня с веб-серверами вроде nginx и прочих не особо нравится.
Ты свои личные предпочтения используешь как аргумент, я верно тебя понял?
Здравствуйте, Nuzhny, Вы писали:
N>Браузер, да, как новая ОС. Это ПО пишется на С/С++. N>Облачными офисами пользуются на уровне заметок, как мне показалось. Основная проблема — все документы не являются твоими. В гугле банят, почту взламывают — это всё реальность, которая временами касается моих знакомых. Иногда нет возможности работать с этим по корпоративным правилам безопасности. В деревне на даче с плохим интернетом тоже нафиг. То есть полноценный офис всё равно ставить приходится.
Приходится. Только раньше это было 80% кейсов, а сейчас — 20.
P>>Госуслуги, судя по размеру апк 88мб в ней сидит мобильный Хром и пару-тройку мегабайт жээса. В этом случае можно процентов 60-80 совместить с обычным вебом. P>>В лучшем случае в мобайле будет какой react-native, что означает веб-технологии.
N>Ну это уже так себе примеры.
Госуслуги и банковские приложения ты сам же и притянул банковские приложения, даже Госуслуги @ Nuzhny. Ок, твой пример так себе. Так и запишем
Здравствуйте, Aquilaware, Вы писали:
A>только потому что в один Docker образ нельзя поставить несколько других готовых Docker-образов-приложений одновременно.
Это почему вдруг? multi-stage builds вроде пока никто не отменял.
A> Запускать же по Docker'у для каждой мелочи не получится, так как между приложениями нередко необходимо организовывать интеграцию и обмен данными,
И в чем проблема?
A> а Docker — это изолированная вещь и чтобы что-то такое накрутить нужно не слабо заморочиться.
Банальный TCP/IP в 2022 году это "нужно не слабо заморочиться"? Интересно девки пляшут.
Здравствуйте, CreatorCray, Вы писали:
IO>>По факту такие вещи могут работать намного лучше теплых ламповых изделий на нативном C. CC>У них ж под капотом таки С или С++ код, который и делает всю основную работу.
Берешь любой проект на гитхабе, заменяешь в домене .com на .dev, и убеждаешься, что при полной гарантии отсутствия какого либо кастомного "С или С++ код" тормозов при наборе текста по прежнему не ощущается.
Здравствуйте, CreatorCray, Вы писали:
P>>специалистов по такой механики раз два и обчелся. CC>Не ну охренеть просто какой бином Ньютона! Интернеты поди забанены, и почитать что там умные люди за подходы такие для редактирования текстов за эти годы изобрели ну ваще никак нельзя.
А ты сам то пробовал? Я вот когда то давно пробовал. Не то чтобы рокет сайнс, но повозиться придется, задачка не на пару дней.
CC>Старенький FAR2 этот же файл просматривает легко и непринуждённо, потребление памяти подскакивает с 15 мегабайт до аж цельных 18!
Старенький FAR2 работает в текстовом режиме, это очень сильно все упрощает.
Здравствуйте, Aquilaware, Вы писали:
A>Поэтому возникает вопрос: как сделать такой дизайнер, который бы мог обеспечить поддержку и WYSIWYG и responsive layout в одном флаконе? Есть ли существующие примеры таких дизайнеров?
Здравствуйте, Pauel, Вы писали:
P>Приходится. Только раньше это было 80% кейсов, а сейчас — 20.
А почему не наоборот? Статистика-то откуда?
N>>Ну это уже так себе примеры. P>Госуслуги и банковские приложения ты сам же и притянул банковские приложения, даже Госуслуги @ Nuzhny. Ок, твой пример так себе. Так и запишем
Это были примеры как раз того, что в веб ничего с десктопа не уходит. Там либо появляется что-то новое (банки, госуслуги), либо уже на мобилках (интернет-банк уже точно на телефоне удобней в разы, Госуслуги в большинстве своём тоже). Десктоп создавался изначально для работы и игр, так и держит всё что надо работе и играм. Игры в браузер уйти попытались (flash), но массово перекочевали на мобилки и остались на десктопах.
Здравствуйте, Aquilaware, Вы писали:
A>Большинство приложений которые не на HTML и не на WPF/WinRT — не поддерживают высокий DPI.
Это что за бред? Пишу на QML нет никаких проблем проблем поддерживать любой разрешение и, например, перетаскивание между экранами с разным разрешением.
Здравствуйте, Nuzhny, Вы писали:
P>>Приходится. Только раньше это было 80% кейсов, а сейчас — 20.
N>А почему не наоборот? Статистика-то откуда?
От меня
N>>>Ну это уже так себе примеры. P>>Госуслуги и банковские приложения ты сам же и притянул банковские приложения, даже Госуслуги @ Nuzhny. Ок, твой пример так себе. Так и запишем
N>Это были примеры как раз того, что в веб ничего с десктопа не уходит.
Эдак окажется, что на десктопе у тебя ничего и нет, кроме IDE и тяжелых CAD
Здравствуйте, Pauel, Вы писали:
P>Эдак окажется, что на десктопе у тебя ничего и нет, кроме IDE и тяжелых CAD
Браузер же (написан на С++). Ещё Телеграм, написанный на С++. CMake, git, компиляторы, IDE (Qt Creator тоже на C++ написан)... Для музыки и фильмов приложения тоже на С/С++... Gimp у меня, Photoshop и 3D Max у жены. LibreOffice установлен. Нормальный набор?
Здравствуйте, Nuzhny, Вы писали:
N>Браузер же (написан на С++). Ещё Телеграм, написанный на С++. CMake, git, компиляторы, IDE (Qt Creator тоже на C++ написан)... Для музыки и фильмов приложения тоже на С/С++... Gimp у меня, Photoshop и 3D Max у жены. LibreOffice установлен. Нормальный набор?
Из твоего списка, наприме, IDE уже пишутся на веб-технологиях, хотя и не все.
Для музыки и фильмов — Electron, например, или же сайтики коих пруд пруди. См. например Tidal или Spotify.
git — на плюсах, а вот git UI уже на веб технологиях.
Рисовалок в вебе уже пруд пруди, Кстати, твой Gimp есть и онлайн https://www.offidocs.com/newfilemanager01.php?username=177859#elf_l1_RG93bmxvYWRz
Всего несколько лет назад их было раз-два и обчелся.
Офисов в вебе, например, от Микрософта и Гугла. Твой LibreOffice уже есть в онлайне.
Здравствуйте, 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>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Берешь любой проект на гитхабе, заменяешь в домене .com на .dev
Т.е. https://github.com/FarGroup/FarManager -> https://github.dev/FarGroup/FarManager ?
НС> и убеждаешься, что при полной гарантии отсутствия какого либо кастомного "С или С++ код"
А куда внезапно написаный на С++ браузер делся, который мне это всё рендерит и показывает?
НС> тормозов при наборе текста по прежнему не ощущается.
Ну найди на гитхабе текстовый файл размером в гиг — посмотрим как оно работает.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Когда скажем обычный виндовый Эксплорер несколько секунд распаковывает мелкий зип с отключеными антивирусами, это ровно те же тормоза, только в профиль.
Взял Reflections_Demo.zip от NVDA, 1.3 гига
Что FAR, что WinRAR, что виндовый explorer распаковывают его за одинаковое время.
Может у тебя explorer тоже на веб технологиях?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Обсуждать просмотр разношрифтового RTF мы даже ещё и не начинали.
Даже с одним шрифтом у символов разная ширина, разное межстрочное расстояние, разный масштаб. Кроме этого нужно учитывать попиксельный клиппинг, подавление фликеринга при скроллинге, отсутствие аппаратного курсора, поддержку мыши с пиксельными координатами и т.д.
Верно
НС>> и убеждаешься, что при полной гарантии отсутствия какого либо кастомного "С или С++ код" CC>А куда внезапно написаный на С++ браузер делся, который мне это всё рендерит и показывает?
Я напомню, что разговор начался с этого:
S>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.
А VSCode был приведен в качестве примера нетормозящего Электрона.
НС>> тормозов при наборе текста по прежнему не ощущается. CC>Ну найди на гитхабе текстовый файл размером в гиг — посмотрим как оно работает.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Даже с одним шрифтом у символов разная ширина, разное межстрочное расстояние, разный масштаб.
И? Всё что тебе тут надо — 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>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
CC>>А куда внезапно написаный на С++ браузер делся, который мне это всё рендерит и показывает? НС>Я напомню, что разговор начался с этого: S>>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают. НС>А VSCode был приведен в качестве примера нетормозящего Электрона.
Электрон это ж хром + жабаскрипт. Так что браузер неизбежно присутствует.
И всей этой чехардой с отрисовкой занимается именно он.
Так что с чего бы вдруг "такие вещи могут работать намного лучше теплых ламповых изделий на нативном C." если там под капотом всё тот же "нативный С"?
НС>>> тормозов при наборе текста по прежнему не ощущается. CC>>Ну найди на гитхабе текстовый файл размером в гиг — посмотрим как оно работает. НС>Где ж я его тебе возьму?
Ну так чтоб заметить тормоза глазом надо редактор хорошенько нагрузить.
Потому редактировать небольшие файлики совсем не интересно, они просто ОБЯЗАНЫ не тормозить.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Всё это сильно зависит от типа приложения. Банальность, но тем не менее надо отметить.
Если приложение типа "одна большая красная кнопка 'Сделай мне хорошо'" то да, шанец великий что это можно на 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 (рисовалку) типа
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 раскошелились на онлайн версию.
Здравствуйте, CreatorCray, Вы писали:
НС>>Даже с одним шрифтом у символов разная ширина, разное межстрочное расстояние, разный масштаб. CC>И? Всё что тебе тут надо — GetTextExtentPoint32W и GetTextExtentExPointW CC>Системный рендерер всё расчёты сделает за тебя.
Все рассчеты он за меня не сделает. И алгоритмы при этом заметно усложняется. Я уж не говорю о том, что GetTextExtent тормозной аж пипец, так что его результаты надо активно кешировать иначе будут те самые тормоза, с которыми ты сражаешься.
НС>> Кроме этого нужно учитывать попиксельный клиппинг CC>Поскольку всё равно рисуешь в Bitmap по размеру viewport то достаточно посимвольного через GetTextExtentExPointW, всё остальное за тебя обрежет GDI renderer при вызове TextOutW.
Он, конечно, обрежет. Но будут те самые тормоза, с которыми ты сражаешься.
НС>> подавление фликеринга при скроллинге CC>Это ж вообще азбука!
Это не азбука, а конкретне, в 2022 году довольно специфические навыки, требующие соответствующего спеца. С чего, собственно, разговор и начался.
CC>BitBlt буфера, куда отрисован viewport уже очень давно не фликерит.
А теперь вспоминаем про клиппинг. На который, конечно, можно забить, но будут те самые тормоза, с которыми ты сражаешься.
НС>> отсутствие аппаратного курсора CC>А в чём проблема нарисовать свой через банальный BitBlt?
В том что это надо делать.
НС>> поддержку мыши с пиксельными координатами и т.д. CC>Да не проблема жеж вообще!
Да оно все не проблема, только в итоге набирается большая куча весьма специфического кода, который надо написать.
CC>Потом выясняешь внутри строки символьное положение через GetTextExtentExPointW
Здравствуйте, 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 НС>... который тормозит ... Ну ты понял.
Схренали он у тебя тормозит то?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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 раскошелились на онлайн версию.
Эта та же аудитория которым хватает телефона на всё что им надо. Это не для работы, это так — потыкать одним пальцем.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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, не?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>глянул бы опенсорсный редактор типа сцинтиллы.
Мне не надо смотреть на чужой код, я сам редактор писал.
P> Реализация чисто редактора + оконные приседения, юзеринпут и рендеринг занимает "всего" >500кб кода.
Потом, в scintilla кроме собственно редактора текста ещё приличная куча наворотов. Сам голый редактор именно чистого текста будет заметно меньше.
P>И это только cxx файлы. Собственно, для фара минимум 50% из всего этого не нужно.
У меня в UI FW все "оконные приседания" вместе с "юзеринпутом" и рендерером текста занимают где то 55К из 800К+ тотал объёма
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>На этой скриптоте пишутся приложения, например, у микрософта это Скайп, Тимс, и кучка тулов.
Не нужны
P>Итого — твоя распрекрасная ИДЕ ничем не поможет.
Я на своих IDE пишу EFI, kernel, системные тулы, просто тулы, десктопные аппы, моды для игр, которые мне интересны.
Единственная скриптота что у меня есть — в greasemonkey, чтоб бороться с криворучием веберов. Но для них никакого IDE не надо, хватает встроенного говноредатора.
P>>>С такого, что сейчас стриминг это основная доля слушателей. CC>>Да на здоровье! Вот только электрон для этого нафига? P>Десктопный клиент на нем.
А нафига ему вообще десктопный клиент? На десктопе и так есть браузер — зачем ещё один?
P>Вся музыка нынче слушается через стриминг.
Неа. Того, что я слушаю там просто нету, да и не было никогда.
P>>>Тидал и Спотифай встроены в каждый утюг нативно. CC>>Ни в одном из моих утюгов их нету P>А что у тебя есть из рендереров музыки? Чего музыки?
P>Ну и логика — у меня два нативных, значит на жээсе ничо нет
Это опровергает твоё огульное: "а вот git UI уже на веб технологиях."
P>Всего пару лет назад не было и того, что сейчас есть.
Когда то считали что к 2000му году у каждого будет личный летающий автомобиль, и чо?
CC>>И такиж нет. Тот же гуглодок до сих пор перекашивает на элементарных вещах, которые в ворде просто работают. P>И ничего страшно в этом нет. Далеко не все фичи ворда нужны в повседневной жизни.
Страшного то ничего, вот только и смысла в итоге пользоваться вебовским тоже никакого.
Проще тупо на макабуке во встроенном Pages накропать.
P>А раньше все эти юзеры вынуждены были десктопный офис юзать. Больше он им не нужен.
Я как представлю редактировать документ на телефоне так сразу ну нафиг.
Не ну, пусть корячатся, если им так хочется.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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
ЕА>Не, я такого точно не говорил. ЕА>Меня как раз с блазором больше всего напрягает, что сам Микрософт не спешит что-то серьезное на нем делать.
Здравствуйте, 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х платформах. Что там было на тот момент с фокситом, я не помню.
Ты так и не ответил на вопрос.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Скорее всего это говорит о небогатых возможностях.
Минет не делает, нет. Делает ровно то, что от него требовалось.
P>Типичный код на плюсах, как например в сцинтилле, делает ровно то же, что и на жээсе, только раз в 5-10 более многословно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Забавно, разговор начинался с того, что десктоп софт уходит в веб-технологии P>Пока десктоп клиент все ещё нужен, кое какие вещи в браузер не всунешь.
Вебсайт (spotify и иже с ними) никогда не был декстоп софтом.
P>Со временем останется один только браузерный.
Нет.
P>В стриминге отсутствуют вещи, у которых есть проблемы с перевыпуском и лицензией. P>Что такого ты случаешь, что нет в стриминге?
Там нет новой музыки, которая мне бы понравилась.
Чтобы слушать то, что мне нравится, мне нахрен не упал стриминг — оно всё у меня уже есть и никакие "перевыпуски и лицензии" меня не побеспокоят.
P> Раньше сетевые проигрыватели были только в варианте "всё в одном", а сейчас появился вариант "транспорт+рендерер". P>Например, транспорт умеет и сидюки(дико популярен), и винил(дико популярен), и USB, и нетворк шары, и сервисы(дико популярно), и радио, и тв(дико популярно, и что хошь, а рендерер делает всё остальное. P>Например, если у тебя есть ТВ + саундбар, то, внимание, у тебя есть ажно два рендерера. Посредственных, но рендерера.
Ох уж эти аудиофильские понты
P>>>Ну и логика — у меня два нативных, значит на жээсе ничо нет CC>>Это опровергает твоё огульное: "а вот git UI уже на веб технологиях."
P>А ты снова "читатель". Я нигде не пишу "git UI пишут исключительно на веб-технологиях". Но тебе мерещится именно такое утверждение.
"уже на" implies переход с одной технологии на другую. Чего не наблюдается.
То, что кто то где то налабал на вебе это не "уже на", а "ещё и на".
P>Ты снова про свои кейсы. Онлайн офисом пользуются по скромной оценке не одна сотня миллионов юзеров.
Да на здоровье! А оффлайн офисом сколько?
P>А что, обязательно телефон и писать монографии на тысячи страниц?
Да там простую смску порой упаришься написать, на микроскопической клаве, с очепятками, и автозаменой, которая думает что помогает.
P>Во первых, есть и планшеты.
На которых один хрен неудобно потому что одна рука занята его держать и набирать ей не получается.
А если его куда ставить то нахрена тогда вообще нужен планшет — бери ноут, там и клава хоть и говёная но таки физическая и можно быстро печатать вслепую, и софт для редактирования есть нормальный а не вебговно.
P>Во вторых, бОльшая часть кейсов не требует ничего сложного — открыл, посмотрел, кое что поправил, кое что прокомментировал, отправил на печать, просмотрел предварительный результат.
А кто и на чём создал то, что "открыл, посмотрел, кое что поправил"?
Оно ж не из воздуха берётся.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Официальная версия MAUI будет поставляться с .NET 7, но на основе .NET 6 с улучшенными инструментами и производительностью.
Рекомендуемое чтение — что такое .NET MAUI
Гибридная поддержка Blazor позволяет нам использовать существующие компоненты Blazor, такие как компоненты Blazorise или приложения WPF или WinForms, и объединять их в настольное приложение, используя элемент управления webview с доступом ко всем базовым аппаратным API. Это позволит разработчикам использовать веб-технологии для создания настольных приложений с доступом к системным ресурсам, таким как локальная файловая система или веб-камера.
Думаю в .Net 7 все же будут переходить.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Aquilaware, Вы писали:
A>Поэтому возникает вопрос: как сделать такой дизайнер, который бы мог обеспечить поддержку и WYSIWYG и responsive layout в одном флаконе? Есть ли существующие примеры таких дизайнеров?
Qt Designer/Design Studio.
Здравствуйте, CreatorCray, Вы писали:
P>>Десятки мегабайт. CC>99МБ это тоже "десятки", нельзя ли более проверяемые цифры называть?
Читаем вместе ответ на твой вопрос:
P>>Атом справляется где то с сотней мб. CC>Ок. А кто должен справляться но не справляется?
P>>Пример — никто в своём уме не пишет GUI игрушки на плюсах. CC>Что ты понимаешь под "GUI игрушки"?
Известно что. Например, весь hud. Щас ты наверное скажешь, что "а на самом деле рендеринг на плюсах!!!!!!11111qqqqaaaa"
P>>Не стоит забывать, что бОльше всего багов и уязвимостей находится именно в нативном коде... CC>Не стоит забывать что это твои фантазии, ничем не подкреплённые.
Это азбучные истины. Смысл разделения на скрипты и нативный код в т.ч. и мЕньшее количество уязвимостей.
В том же жээсе бОльшая часть уязвимостей на самом деле в нативной части. Собственно так со всеми скриптами.
В том же дотнете/джаве бОльше всего уязвимостей или в нативной части, или в связке с нативным кодом.
Загляни в списке CVE-xxxx-yyyyy, всё в открытом доступе. Берем линукс кернел, смотрим вместе, первые ссылки на сегодняшний день
A null pointer dereference issue was discovered in fs/io_uring.c in the Linux kernel before 5.15.62
drivers/scsi/stex.c in the Linux kernel through 5.19.9
An issue was discovered in the Linux kernel through 5.19.8. drivers/firmware/efi/capsule-loader.c has a race condition with a resultant use-after-free.
CC>>>Нет, икемфула, чтоб родить что либо сносно на вебе шевелящееся тоже понадобится квалификация. P>>...при чем именно в том коде, который писали светила индустрии. CC>на жабаскрипте, попрошу заметить
А я говорю о том, что странно видеть обилие уязвимостей в нативном коде, когда его писали светила индустрии.
P>> А вот дыры ОС, браузера, бд, итд не могут и по сей день пофиксить, хотя коду 20-30 и более лет. CC>Какие именно? Или это опять так, для красного словца ляпнуто?
А тебе ктото запрещает CVE-XXXX-YYYYY посмотреть?
P>>Ога. Сколько у тебя лет опыта было, когда ты свой фремворк пилил? Довел до прода? CC>Опыта в чём именно? В UI фреймворках считай никакого.
Всего опыта в разработке сколько было на плюсах?
P>>Логическая ошибка. Скитера не было "в каждой книге по программированию". CC>То, что я написал тоже не было "в каждой книге по программированию"
А я пишу о том, что UI фремворк это хороший тренировочный материал, потому в книгах он встречался регулярно.
Я это проделывал и на паскале, и на ассемблере, и на Си, и на Си++, и Сишарпе.
P>>Твой фремворк кроме тебя кто нибудь тестировал? Кто, кроме тебя использовал, сколько команд? CC>Я его под нужды своего личного проекта написал.
В таком случае странно использовать это как аргумент. У нас нет никакой возможности оценить качество твоего фремворка, как с т.з. кода, так и с т.з. заявленых возможностей, сроков, сложности сопровождения итд.
То есть, аргумент понятный исключительно одному тебе.
P>>Ты странный — когда я попросил привести парочку примеров где жээс глючит, ты мне сходу нахамил, CC>Я писал про отдельные кривые сайты, где напихали скриптоты что они с трудом проворачиваются, а не про "жээс глючит". Так что это ты сам к себе претензии выдвигай, ибо обсуждать что либо в сценарии "сама придумала — сама обиделась" мне не интересно.
Ты или смысла слов не понимаешь, или не готов отвечать за свои слова:
Юг там, вьюноша. Впрочем судя по тону твоего вопроса ты и так хотел туда прогуляться.
Вот это прямое оскорбление, только завуалированое.
P>>Насколько я помню, фар рисует через что нибудь навроде ReadConsoleOutput и WriteConsoleOutput. CC>А на экране оно святым духом появляется?
Нас интересует не внутреннее устройство этих функций, а сложности рендеринга на стороне приложения.
UI в таком духе, как в ФАР, используя эти функции, это уровень лабораторной работы примерно 2й-3й курс, когда только начинают Winapi изучать.
P>>Что ты там считать собрался, если количество знаков в ширину-высоту известно заранее, размер шрифта задан заранее? CC>Расчёт положения это банальная арифметика, операция сложения, начальная школа. Отрисовка глифов шрифта занимает на порядки больше ресурсов чем эта ерундистика.
Именно. И ФАР ничем таким не занимается, т.к. это консольное приложение. Все что он делает, это посылает туда сюда буферы вида "строка"-"цвет фон-символ".
P>>И отличия в рендеринге ты не видишь, да? CC>Отличия микроскопические, так что не интересно. В IDE для кода точно так же используется моноширинный шрифт, так что ты сейчас просто очередную сову мучаешь.
Ровно наоборот — в консоли сложность рендеринга считай равняется сложности склейки строк. IDE рисует совсем не так, как фар.
А теперь смотрим вместе, сколько когда занимает рендеринг в той же Сцинтилле — по самой скромной оценке десятки килобайт кода. И там много разных нюансов.
P>>Это все еще низкоуровневый рендеринг, тк мы оперируем примитивами — строка, координаты, хендл, итд. Высокоуровневые примитивы — текст+ стили. CC>Если для тебя это низкоуровневый то у меня для тебя пачка забавных новостей. CC>Нет, это ещё не низкий уровень.
Текст+стили — это высокий. Всё остальные — низкий.
Очевидно, в твоем TextOutput ничего высокоуровнего нет и быть не может.
P>>Сравни "нарисуй строку по координатам с цветом в такой то хендл" CC>Сравни рисование строки на уровне изменения цвета конкретных пикселей в памяти — вот это уже низкий уровень.
Низкость-высокость это про уровень абстракций прежде всего. Высокий уровень это такой, когда бы рисуем в единицах абстракций пользователя, то есть, текст, стили, итд. Все остальное — низкий.
P>>Нужен внятный рендеринг, что бы выглядело красиво, глаза не уставали. Большинство рендереров этого не умеют. CC>В pdf.js нету своего рендеринга, тупо используются функции браузера.
Снова Мистер Осведомленность Кто мешает тебе открыть страничку https://mozilla.github.io/pdf.js/web/viewer.html
и кликнуть правой кнопкой мыши на странице? Появляется "Save image". А если вбить в devtools document.querySelectorAll('canvas'), то увидишь кучку канвасов, каждый из которых соответствует какой то странице на экране
Кто, по твоему, создает эти картинки?
на самом деле в pdf.js два рендерера
1. изображение, обычная 2D графика, canvas растет отсюда
2. текстовый слой, для селекшна, поиска и тд. Рендерится DOM-дерево.
Отсюда ясно, что здесь не просто швыряние текста, а прорисовка букв со сглаживанием.
P>>Далее, нужна частичная подгрузка, чтобы не всасывать все 20000 страниц (не знаю, зачем верстают такие книги) CC>Это вообще встроенная фича формата PDF
И давно у тебя формат сам себя загружает? Обычно это делает конкретная либа, которая или грузит всё, или по частям. И вот большинство идут по варианту "грузить всё" т.е. предполагают что документ обычно небольшой.
P>>>>Пока что никто не смог обогнать акробат адобовский, ни на чем. CC>>>Foxit, не? P>>Проект длился много лет и закончился в 17м после n версий на 4х платформах. Что там было на тот момент с фокситом, я не помню. CC>Ты так и не ответил на вопрос.
На какай именно? Чем закончилась проверка Foxit я не в помню. Остановились на pdf.js для мака/винды и еще по одному для ios и android, не помню какие. Проект то был аналог Киндла — магазин, библиотека, приложение для чтения разных форматов, заметки, редактирование, лицензии, подписки, итд, а не просто открывалка для пдф.
Здравствуйте, CreatorCray, Вы писали:
P>>Забавно, разговор начинался с того, что десктоп софт уходит в веб-технологии P>>Пока десктоп клиент все ещё нужен, кое какие вещи в браузер не всунешь. CC>Вебсайт (spotify и иже с ними) никогда не был декстоп софтом.
Ога. Тут надо вспомнить, что всего 10 лет назад такой софт был десктопным. Такого было валом. Сейчас аналоги aimp/winapmp/foobar/apollo проросли в веб и спокойно
P>>Со временем останется один только браузерный. CC>Нет.
Уже бОльшая часть такого контента потребляется через веб-интерфейс. Олдфаги вроде тебя еще сто лет будут файлики собирать.
P>>Что такого ты случаешь, что нет в стриминге? CC>Там нет новой музыки, которая мне бы понравилась.
Это и ежу понятно. Пример у тебя есть? Что за музыка-альбом-исполнитель, которого нет в стриминге? Я в курсе, что такое бывает — обычно из за лицензий как правило. А что бы массово — это разве что "я и васька под пиво на гитаре".
CC>Чтобы слушать то, что мне нравится, мне нахрен не упал стриминг — оно всё у меня уже есть и никакие "перевыпуски и лицензии" меня не побеспокоят.
А новые вещи ты где брать собираешься?
P>>А ты снова "читатель". Я нигде не пишу "git UI пишут исключительно на веб-технологиях". Но тебе мерещится именно такое утверждение. CC>"уже на" implies переход с одной технологии на другую. Чего не наблюдается.
Я и не говорил про "переход" Это само собой произойдет, т.к. нативный десктопный софт уже писать тупо некому.
P>>Ты снова про свои кейсы. Онлайн офисом пользуются по скромной оценке не одна сотня миллионов юзеров. CC>Да на здоровье! А оффлайн офисом сколько?
Максимум столько же. Более того, даже те, что юзают оффлайн офис, так же юзают и онлайн по ряду причин.
Простой пример — редактируем корпоративный док. Залочили, скачали док, отредактивровали, сохранили, вкомитали обратно.
С онлайн-офисом это тупо быстрее и удобнее — кликнули, отредактировали, закрыли окно, не надо ничего лочить, никуда переключаться. Можно даже с домашнего компа. А вот полиси может и не позволять поставить корпоративную лицензию на домашний софт и запрещать редактирование чем то иным, кроме как официальной корпоративной лицензией.
P>>А что, обязательно телефон и писать монографии на тысячи страниц? CC>Да там простую смску порой упаришься написать, на микроскопической клаве, с очепятками, и автозаменой, которая думает что помогает.
Это какие то твои особенности. У меня небольшой телефон, чуть больше самого маленького iphone, и то все форумы-мессенгеры перевел на него, кроме рсдн и некоторых олдскульных, что не умеют responsive.
P>>Во первых, есть и планшеты. CC>На которых один хрен неудобно потому что одна рука занята его держать и набирать ей не получается.
То смс на телефоне не набирается, то текст на планшете Похоже, что дело в руках или нежелании приобретать новые привычки.
P>>Во вторых, бОльшая часть кейсов не требует ничего сложного — открыл, посмотрел, кое что поправил, кое что прокомментировал, отправил на печать, просмотрел предварительный результат. CC>А кто и на чём создал то, что "открыл, посмотрел, кое что поправил"?
Обычный браузер. И все это вместо десктопного офиса. Мелочовка спокойно делается телефоном.
Здравствуйте, Pauel, Вы писали:
P>Ога. Тут надо вспомнить, что всего 10 лет назад такой софт был десктопным.
Это какие же 10 лет назад были десктопные стриминговые софтины?
P> Такого было валом. Сейчас аналоги aimp/winapmp/foobar/apollo проросли в веб и спокойно
Нет, икемфула, это не то что не аналоги, это вообще ортогональные вещи. Ничего не проросло, всё осталось как есть. Банально в оффлайновые проигрыватели добавилась возможность сосать из интернетов.
P>Это и ежу понятно. Пример у тебя есть? Что за музыка-альбом-исполнитель, которого нет в стриминге?
Отредактированной под мои вкусы нету, икемфула. Изрядная часть той музыки, что мне понравилась, отредактирована чтоб осталось только то, что мне понравилось.
P>А новые вещи ты где брать собираешься?
Мне надо оффлайн файл, который я режу под себя, а не "стримь отсюда" и жри в том виде, как дали.
P>нативный десктопный софт уже писать тупо некому.
Вот так уж и некому
P>Максимум столько же.
Минимум, икемфула, минимум.
P>То смс на телефоне не набирается, то текст на планшете Похоже, что дело в руках или нежелании приобретать новые привычки.
Банально набор на физической клаве быстрее на порядок. Нет смысла корячиться на крохотной экранной, где вслепую многопальцево набирать банально невозможно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Известно что. Например, весь hud. P> Щас ты наверное скажешь, что "а на самом деле рендеринг на плюсах!!!!!!11111qqqqaaaa"
Ты не поверишь!
P>Это азбучные истины. Смысл разделения на скрипты и нативный код в т.ч. и мЕньшее количество уязвимостей.
Нет. Смысл в другом. Меньше багов от этого не становится, скорее наоборот.
P>В том же жээсе бОльшая часть уязвимостей на самом деле в нативной части. Собственно так со всеми скриптами.
"жээс" в браузере это и есть его нативная часть, сам браузер не на жээсе написан. И баги в JS VM это баги таки самого JS.
P>Загляни в списке CVE-xxxx-yyyyy, всё в открытом доступе. Берем линукс кернел, смотрим вместе, первые ссылки на сегодняшний день P>io_uring.c in the Linux kernel P>stex.c in the Linux kernel P>Linux kernel capsule-loader.c
Вижу Си и луноход
Писать на голых сях вместо плюсов и удивляться тому что там постоянно военно морским методом что то там протеривается — это к верховному пЫнгвину претензии надо предъявлять.
P>А я говорю о том, что странно видеть обилие уязвимостей в нативном коде, когда его писали светила индустрии.
Это луникс то пишут светила индустрии?
CC>>Какие именно? Или это опять так, для красного словца ляпнуто? P>А тебе ктото запрещает CVE-XXXX-YYYYY посмотреть?
Я за тебя должен искать что ты там под XXXX и YYYYY имеешь в виду?
P>>>Ога. Сколько у тебя лет опыта было, когда ты свой фремворк пилил? Довел до прода? CC>>Опыта в чём именно? В UI фреймворках считай никакого. P>Всего опыта в разработке сколько было на плюсах?
Ты сейчас судорожно пытаешься нащупать с какой стороны на глобус начать натягивать очередную сову.
P>А я пишу о том, что UI фремворк это хороший тренировочный материал, потому в книгах он встречался регулярно.
Ты похоже что то своё понимаешь под "UI фремворк".
P>У нас нет никакой возможности оценить качество твоего фремворка
А должна быть?
P>Ты или смысла слов не понимаешь, или не готов отвечать за свои слова:
Ты банально приписываешь мне свои фантазии. С какого перепугу я должен за твои фантазии что либо отвечать?
P>Нас интересует не внутреннее устройство этих функций, а сложности рендеринга на стороне приложения. P>UI в таком духе, как в ФАР, используя эти функции, это уровень лабораторной работы примерно 2й-3й курс, когда только начинают Winapi изучать.
В консольном приложении рендерингом занимается console host. Так что там дополнительная прослойка есть в виде эмуляции консоли.
Но в итоге что так что эдак вызывается в общем то одна и та же системная функция.
P>Текст+стили — это высокий. Всё остальные — низкий.
Я как системщик знаю что там до настоящего низкого ещё срать и срать.
P>Кто, по твоему, создает эти картинки?
Код рендерера в браузере, икемфула.
JS не рендерит ничего сам, он просто пихает элементы в Path2D — высокоуровневый JS API, а потом уже native код в браузере занимается реальной отрисовкой.
P>https://github.com/mozilla/pdf.js/blob/master/src/core/font_renderer.js P>Отсюда ясно, что здесь не просто швыряние текста, а прорисовка букв со сглаживанием.
И в какой же именно строке осуществляется эта самая "прорисовка букв со сглаживанием"?
Вижу только напихивание элементов для скармливания в Path2D
P>На какай именно? Чем закончилась проверка Foxit я не в помню.
Вопрос был оказался ли Foxit на уровне акробата или нет?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Ога. Тут надо вспомнить, что всего 10 лет назад такой софт был десктопным. CC>Это какие же 10 лет назад были десктопные стриминговые софтины?
Нет юзкейса стриминг. Есть юзкейс послушать музыку. Раньше были файлики и aimp/winapm/foobar/apollo, а сейчас Spotify/Tidal/Qobuz/Deezer/Roon. Файлики перекочевали из локального хдд на домашние сервера.
P>> Такого было валом. Сейчас аналоги aimp/winapmp/foobar/apollo проросли в веб и спокойно CC>Нет, икемфула, это не то что не аналоги, это вообще ортогональные вещи. Ничего не проросло, всё осталось как есть.
Юзкейс ровно один и тот же — послушать музыку. Потому, например, нынешний ренесанс винила, когда проигрыватели чуть не в гастрономах продают, это уход от всяких аимпов-винампов.
> Банально в оффлайновые проигрыватели добавилась возможность сосать из интернетов.
Олдфаги в основном там и остались. Новые поколения пользователей ничем таким не пользуются, ставят спотифай, itunes, amazon итд и слушают. Начорта им вообще чтото офлайновое?
Запустил Shazam, узнал что играет, и уже через минуту этот же трек играет у тебя.
P>>А новые вещи ты где брать собираешься? CC>Мне надо оффлайн файл, который я режу под себя, а не "стримь отсюда" и жри в том виде, как дали.
Это называется "звуки" а не музыка Это нетипичный кейс что 20 лет назад, что сейчас.
P>>нативный десктопный софт уже писать тупо некому. CC>Вот так уж и некому
Именно. Всего 10 лет назад именно десктопных разработчиков было валом в вакансиях. Куда ни ткни — win32/gdi/mfc/atl/com или winforms/devexpress/msoffice или wpf/mssql. Сейчас это уже экзотика. И если на дотнете/джаве иногда таки бывают десктопные вакансии, то на С++ уже точно всё.
Фактически, десктоп чистом виде остался только у единичных контор — ОС, офис, сапр, итд.
P>>То смс на телефоне не набирается, то текст на планшете Похоже, что дело в руках или нежелании приобретать новые привычки. CC>Банально набор на физической клаве быстрее на порядок. Нет смысла корячиться на крохотной экранной, где вслепую многопальцево набирать банально невозможно.
Это экономия на спичках. бОльше всего времени уходит не на набор текста, а на обдумывание проблемы. Речь то ведь не про восьмичасовой рабочий день в телефон, а минуту-две-три-пять вида
— прочитал текст
— подумал
— написал "надо пересмотреть требования"
— через час "с требованиями всё в порядке, вернемся к вопросу, когда я из отпуска вернусь"
Здравствуйте, CreatorCray, Вы писали:
P>>Это азбучные истины. Смысл разделения на скрипты и нативный код в т.ч. и мЕньшее количество уязвимостей. CC>Нет. Смысл в другом. Меньше багов от этого не становится, скорее наоборот.
Ровно наоборот. Если дать этим же разработчикам С++, то багов будет на порядок-другой больше или же софт вообще не заработает. C этим ты согласен?
Следовательно, использование жээса уменьшает количество багов и улучшает результат.
P>>В том же жээсе бОльшая часть уязвимостей на самом деле в нативной части. Собственно так со всеми скриптами. CC>"жээс" в браузере это и есть его нативная часть, сам браузер не на жээсе написан. И баги в JS VM это баги таки самого JS.
Если некий C++ разработчик имплементит null dereference, то это ошибка в С++ коде, и совсем не важно, откуда мы это вызываем.
А тебя послушать, так это ошибка в жээс, потому что это код жээс вм.
CC>Вижу Си и луноход CC>Писать на голых сях вместо плюсов и удивляться тому что там постоянно военно морским методом что то там протеривается — это к верховному пЫнгвину претензии надо предъявлять.
В винде ровно то же. И в макоси. И в андройде. И иос.
P>>А я говорю о том, что странно видеть обилие уязвимостей в нативном коде, когда его писали светила индустрии. CC>Это луникс то пишут светила индустрии?
Именно. Типичные разработчики ядра линукса имеют квалификацию на порядки выше той, что у 90% фронтендов.
CC>>>Какие именно? Или это опять так, для красного словца ляпнуто? P>>А тебе ктото запрещает CVE-XXXX-YYYYY посмотреть? CC>Я за тебя должен искать что ты там под XXXX и YYYYY имеешь в виду?
Известно что — https://cve.mitre.org/
Вбиваешь кейворд и смотришь, что там такого и насколько оно древнее.
P>>Всего опыта в разработке сколько было на плюсах? CC>Ты сейчас судорожно пытаешься нащупать с какой стороны на глобус начать натягивать очередную сову.
Как правило, новички в винапи сливаются очень быстро по ряду причин:
1 долгое вхождение в сам с++
2 долгое вхождение в winapi, и в частности gdi. Нудно, муторно, коряво.
P>>А я пишу о том, что UI фремворк это хороший тренировочный материал, потому в книгах он встречался регулярно. CC>Ты похоже что то своё понимаешь под "UI фремворк".
Как и все — контрольчики, стейтменеджмент, юзеринпут.
P>>У нас нет никакой возможности оценить качество твоего фремворка CC>А должна быть?
Если ты приводишь это как аргумент на форуме, то да. Каким образом мне понять, что это вообще за аргумент?
P>>Ты или смысла слов не понимаешь, или не готов отвечать за свои слова: CC>Ты банально приписываешь мне свои фантазии. С какого перепугу я должен за твои фантазии что либо отвечать?
Какие же фантазии? "Послать на юг", это "послать на йух", произносится примерно одинаково. Дальше объяснять?
CC>В консольном приложении рендерингом занимается console host. Так что там дополнительная прослойка есть в виде эмуляции консоли. CC>Но в итоге что так что эдак вызывается в общем то одна и та же системная функция.
Забавно виляешь — мы про сложность рендеринга в пользовательском консольном приложении типа фар, а не сложность написания системного console host.
В самом консольном приложении сложность рендеринга чуть выше склейки-копирования строк, надо помнить про прямоугольные блоки. И всё.
P>>Текст+стили — это высокий. Всё остальные — низкий. CC>Я как системщик знаю что там до настоящего низкого ещё срать и срать.
Низкий уровень начинается с потери пользовательской абстракции, а не записи в порт значения регистра eax.
P>>https://github.com/mozilla/pdf.js/blob/master/src/core/font_renderer.js P>>Отсюда ясно, что здесь не просто швыряние текста, а прорисовка букв со сглаживанием. CC>И в какой же именно строке осуществляется эта самая "прорисовка букв со сглаживанием"? CC>Вижу только напихивание элементов для скармливания в Path2D
Забавно — если жээс вызывает Path2d, то "всё рендерит С++".
А если бага "в жээс вм", то бага в жээсе
Идея понятна: фичи наши, баги — ваши.
Технически — логику, т.е. что рисовать, реализует сам жээс, и он же определяет, как всё будет выглядет. Это и есть рендерер, т.к. любой рендерер это функция вида данные->репрезентация. Можно сказать, что жээс рендерит в path2d. Это ничего не меняет.
С++ отвечает за нижние слои — как именно рисовать конкретные пикселы.
P>>На какай именно? Чем закончилась проверка Foxit я не в помню. CC>Вопрос был оказался ли Foxit на уровне акробата или нет?
Близко к нему, но на мой взгляд послабее. Я несколько лет пользовался фокситом, потом вернулся на акробат.
Здравствуйте, Pauel, Вы писали:
P> Нет юзкейса стриминг. Есть юзкейс послушать музыку.
Допустим.
P> Раньше были файлики и aimp/winapm/foobar/apollo, а сейчас Spotify/Tidal/Qobuz/Deezer/Roon.
И сейчас файлики
P> Файлики перекочевали из локального хдд на домашние сервера.
При этом они точно так же доступны по NFS/SMB/iSCSI как и локальные файлы.
В облака, где стриминг, не перекочевало ничего, особенно у тех же аудиофилов, где FLAC коллекции занимают нынче уже терабайты. Никто в здравом уме такое стримить не будет.
P>- написал "надо пересмотреть требования" P>- через час "с требованиями всё в порядке, вернемся к вопросу, когда я из отпуска вернусь"
Эти пара букв ж вообще ни о чём. Их даже текстом назвать сложно
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Ровно наоборот. Если дать этим же разработчикам С++, то багов будет на порядок-другой больше или же софт вообще не заработает.
Если дать в руки обезьяне вместо ножовки циркулярную пилу то она себе что нить отрежет, да.
Но это не проблема циркулярки, это проблема безмозглой обезьяны
P>Следовательно, использование жээса уменьшает количество багов и улучшает результат.
Нет
Багов всё ещё туевы хучи, просто памперсы managed языков тратят тонны нефти на то, чтоб с этими багами бороться, и не давать этому "коду" совсем уж развалиться под весом насранного макаками говна.
CC>>Писать на голых сях вместо плюсов и удивляться тому что там постоянно военно морским методом что то там протеривается — это к верховному пЫнгвину претензии надо предъявлять. P>В винде ровно то же. И в макоси. И в андройде. И иос.
Тоже мне новость: везде где есть голый си будут характерные для голого си проблемы
CC>>Это луникс то пишут светила индустрии? P>Именно. Типичные разработчики ядра линукса имеют квалификацию на порядки выше той, что у 90% фронтендов.
Таки да, но это не делает их "светилами"
P>Как правило, новички в винапи сливаются очень быстро по ряду причин: P>1 долгое вхождение в сам с++
У WinAPI — С API. Пиши на чём хочешь, хоть на ассемблере.
P>2 долгое вхождение в winapi, и в частности gdi. Нудно, муторно, коряво.
Там ж настолько всё элементарно что если кто то не в состоянии это освоить то наверное ему в целом с CS не по пути.
CC>>Ты похоже что то своё понимаешь под "UI фремворк". P>Как и все — контрольчики, стейтменеджмент, юзеринпут.
Это то, что над капотом, со стороны пользователя FW
P>>>>Ты странный — когда я попросил привести парочку примеров где жээс глючит CC>>>Я писал про отдельные кривые сайты, где напихали скриптоты что они с трудом проворачиваются, а не про "жээс глючит". P>>>Ты или смысла слов не понимаешь, или не готов отвечать за свои слова: CC>>Ты банально приписываешь мне свои фантазии. С какого перепугу я должен за твои фантазии что либо отвечать? P>Какие же фантазии?
Что я писал "жээс глючит", тогда как речь была про "отдельные кривые сайты, где напихали скриптоты что они с трудом проворачиваются"
CC>>В консольном приложении рендерингом занимается console host. Так что там дополнительная прослойка есть в виде эмуляции консоли. CC>>Но в итоге что так что эдак вызывается в общем то одна и та же системная функция. P>Забавно виляешь — мы про сложность рендеринга в пользовательском консольном приложении типа фар Если ты не понимаешь как работает pipeline — это не мои проблемы.
P>В самом консольном приложении сложность рендеринга чуть выше склейки-копирования строк, надо помнить про прямоугольные блоки. И всё.
И? Чем это отличается от вызова API функции "нарисуй мне в этом месте строку"?
P>Забавно — если жээс вызывает Path2d, то "всё рендерит С++".
Потому что от напихивания кривых в Path2D до появления в битмапе заполненного контура с антиалиасингом происходит много всего разного и довольно таки заморочного. И это ещё примитивный подход, тупо кривые, без учёта хинтинга.
P>Технически — логику, т.е. что рисовать, реализует сам жээс, и он же определяет, как всё будет выглядет.
Он просто зовёт высокоуровневый API.
P> Это и есть рендерер
Ну тогда FAR это тоже рендерер
P>Можно сказать, что жээс рендерит в path2d.
Можно сказать что консольная аппа рендерит в консоль
А чо, чем symbol + fgColor + bgColor хуже чем Path2D?
P>>>На какай именно? Чем закончилась проверка Foxit я не в помню. CC>>Вопрос был оказался ли Foxit на уровне акробата или нет?
P>Близко к нему, но на мой взгляд послабее.
По вспомогательным функциям типа редактирования, речь же была про отображение собственного готового PDF.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Ровно наоборот. Если дать этим же разработчикам С++, то багов будет на порядок-другой больше или же софт вообще не заработает. CC>Если дать в руки обезьяне вместо ножовки циркулярную пилу то она себе что нить отрежет, да. CC>Но это не проблема циркулярки, это проблема безмозглой обезьяны
Чья проблема — дело десятое. Важно, что с джаваскриптом у этих же людей получается много лучше чем у них же с С++. Следовательно, джаваскрипт уменьшает количество багов.
P>>Следовательно, использование жээса уменьшает количество багов и улучшает результат. CC>Нет CC>Багов всё ещё туевы хучи, просто памперсы managed языков тратят тонны нефти на то, чтоб с этими багами бороться, и не давать этому "коду" совсем уж развалиться под весом насранного макаками говна.
Логическая ошибка. Нужно сравнивать количество багов при скриптовании на разных языках у одних и тех же людей, а не просто по баклогу. В 90х и даже 00х скриптовать пробовали на плюсах, буквально. Этим занимались целые конторы в т.ч. в браузере и офисе. Ни к чему хорошему это не приводило:
1 затраты времени чудовищные. Вещи, которые сейчас каждый джун по сто раз на дню выполняет, тогда пилили синьоры неделями и даже месяцами.
2 количество багов было еще бОльшим, чем сейчас, по ряду причин, разумеется, в пересчете на страницу/форму. При этом страницы/формы были на порядок проще.
Типичные баги — указатели, строки, память, стек, утечки. И такое можно было обнаружить даже в продакшне.
Когда эти же люди пересели на жээс, то их приложения резко стали больше, лучше, стабильнее.
Ты когда нибудь пробовал заскриптовать среднюю страничку на плюсах?
P>>В винде ровно то же. И в макоси. И в андройде. И иос. CC>Тоже мне новость: везде где есть голый си будут характерные для голого си проблемы
В плюсах не на много то и лучше. Принципиальной разницы нет.
P>>Именно. Типичные разработчики ядра линукса имеют квалификацию на порядки выше той, что у 90% фронтендов. CC>Таки да, но это не делает их "светилами"
Именно это и делает светилами. Даже больше — разработчики ядра в среднем много выше по квалификации большинства обычных сиплюсников.
P>>2 долгое вхождение в winapi, и в частности gdi. Нудно, муторно, коряво. CC>Там ж настолько всё элементарно что если кто то не в состоянии это освоить то наверное ему в целом с CS не по пути.
Это какой то юношеский максимализм. Всё становится элементарным после того, как освоишь. Вопрос в том, сколько времени/усилий надо инвестировать в освоение.
Что бы сходу влезть в WINAPI — я такого ни раз не видел. Попытки делают многие, но результата как то не появляется. И объяснение достаточно простое — все примеры даже ничтожных фич как правило простыни кода. Открываешь книгу и листаешь страницы кода на каждый пример.
Уже в дотнете на system.drawing кодить надо было примерно на порядок меньше. В canvas браузера в 2D еще будет раза в два-три меньше кода. Зато если откроешь весь плюсовый код браузера для реализации таких функций, увидишь, что все эти простыни как были, так и остались, только что упакованы в конкретную библиотеку.
Отсюда ясно, почему на чистом gdi никто в своём уме не пишет. Берут обычно какую высокоуровневую оболочку.
P>>Как и все — контрольчики, стейтменеджмент, юзеринпут. CC>Это то, что над капотом, со стороны пользователя FW
Разумеется. Именно это и называется фремворком — фремворк то разрабатывается для решения задач консумеров, а не загибания пальцев на форуме.
Итого — сколько у тебя было опыта на плюсах к тому времени и сколько времени ты потратил?
CC>Что я писал "жээс глючит", тогда как речь была про "отдельные кривые сайты, где напихали скриптоты что они с трудом проворачиваются"
Жээс глючит — это общее утверждение, про жээс. А подразумеваешь только некоторые сайты. То есть — логическая ошибка.
P>>В самом консольном приложении сложность рендеринга чуть выше склейки-копирования строк, надо помнить про прямоугольные блоки. И всё. CC>И? Чем это отличается от вызова API функции "нарисуй мне в этом месте строку"?
Например, нет необходимости ни в каких вычислениях.
P>>Забавно — если жээс вызывает Path2d, то "всё рендерит С++". CC>Потому что от напихивания кривых в Path2D до появления в битмапе заполненного контура с антиалиасингом происходит много всего разного и довольно таки заморочного. И это ещё примитивный подход, тупо кривые, без учёта хинтинга.
Ты внимательно посмотри на результат, алё! Кто тебе мешает ссылку то открыть?
P>>Технически — логику, т.е. что рисовать, реализует сам жээс, и он же определяет, как всё будет выглядет. CC>Он просто зовёт высокоуровневый API.
Я в курсе. Ты думал америку открыл? Жээс работает на верхнем слое, очевидно, что он рендерит текст в примитивы нижнего уровня.
P>> Это и есть рендерер CC>Ну тогда FAR это тоже рендерер
Я именно про это и говорю уже в который раз. Спасибо, что наконец догадался. При этом Фар это примитивный рендерер, т.к. использует две или три тривиальных функции, которые в общем и вычислений не требуют.
CC>Можно сказать что консольная аппа рендерит в консоль CC>А чо, чем symbol + fgColor + bgColor хуже чем Path2D?
Рендерит. Консольное приложение никак не может управлять тем, как будет выглядеть результат — это обязанность console host. Один шрифт на всю консоль и всё.
А вот рендерер pdf.js именно тем и занят, что выдает правильное сглаживание и хинтинг и тд.
P>>Близко к нему, но на мой взгляд послабее. CC>По вспомогательным функциям типа редактирования, речь же была про отображение собственного готового PDF.
Я ушел с фоксита много лет назад. Когда уходил, фоксит был похуже.
Здравствуйте, CreatorCray, Вы писали:
P>> Нет юзкейса стриминг. Есть юзкейс послушать музыку. CC>Допустим.
P>> Раньше были файлики и aimp/winapm/foobar/apollo, а сейчас Spotify/Tidal/Qobuz/Deezer/Roon. CC>И сейчас файлики
Нет смысла хранить файлы локально или на домашнем сервере по ряду причин
1. поиск новой музыки был востребованым во все времена. Файлы на диске не решают это никак. Стриминговые сервисы дают это прямо искаропки.
2. Юзеры используют тучи устройств, в т.ч. вне дома
3. Люди слушают много и разного, меняют предпочтения постоянно. Услышал где то — добавил себе.
4. Стриминг много дешевле покупки музыки
5. Качество контента выше всего именно в стриминге
6. стриминговые сервисы имеют хорошие рекомендательные алгоритмы, например, Spotify здесь вообще сказка.
7. в стриминге нет смысла тратить время-пространство на организацию хранилища
Поэтому стриминг сейчас пихают вообще везде.
При этом, кое кто таки сидит именно на файлах:
1. коллекционеры, у таких редкие альбомы типа Black Sabbath'89 "Headless Cross", форматы типа DSD512, hi-res и подобные вещи
2. те, у кого один комп
3. те, у кого проблемы с интернетом
4. любители контролировать каждую ножку у гусеницы, навроде тебя
5. любители CD, они большей частью перегоняют на NAS и слушают уже оттуда. Типичный NAS чаще всего идет с такой возможностью.
Таких в общей массе как то совсем немного. Любителей винила по моим ощущениям куда как больше.
CC>В облака, где стриминг, не перекочевало ничего, особенно у тех же аудиофилов, где FLAC коллекции занимают нынче уже терабайты. Никто в здравом уме такое стримить не будет.
Аудиофилов, у кого коллекции занимают терабайты, единицы процентов в общей массе аудиофилов. На каждый проданый NAS приходится сотни или тысячи проданых стримеров.
Сейчас на аудиофильских форумах основные вопросы такие
1. перехожу на винил
2. перехожу на стриминг
P>>- написал "надо пересмотреть требования" P>>- через час "с требованиями всё в порядке, вернемся к вопросу, когда я из отпуска вернусь" CC>Эти пара букв ж вообще ни о чём. Их даже текстом назвать сложно
Веб приложения позволяют тебе работать откуда угодно, и не быть привязаным к конкретному устройству. Телефон, мобила, рабочая мобила, планшет, ноутбук, рабочий комп, да хоть телевизор — разные обязанности можно выполнять с разных устройств. Десктопный офис в эту модель никак не вписывается.
Отсюда и появление офиса в онлайн версии, в виде сайта. И эта вещь дико популярна, работает вообще везде.
Здравствуйте, Pauel, Вы писали:
P>с джаваскриптом у этих же людей получается много лучше чем у них же с С++.
Верно
P>Следовательно, джаваскрипт уменьшает количество багов.
Категорически неверно
P>их приложения резко стали больше, лучше, стабильнее.
P>Ты когда нибудь пробовал заскриптовать среднюю страничку на плюсах?
угу, через CGI. Кстати замечательно работало, ещё и быстро как из пулемёта, в те времена то.
P>В плюсах не на много то и лучше. Принципиальной разницы нет.
Нет. С++ имеет таки принципиальную разницу, которая позволяет писать куда более чистый и безопасный код.
P>Даже больше — разработчики ядра в среднем много выше по квалификации большинства обычных сиплюсников.
Ты сравниваешь средних сфероконей в вакууме.
P>Это какой то юношеский максимализм. Всё становится элементарным после того, как освоишь.
Я это освоил ещё в универе, а это было чёрти когда. Так что не надо мне рассказывать про сложности освоения букваря, меня такие байки только веселят.
P>Что бы сходу влезть в WINAPI — я такого ни раз не видел.
Почему то раньше влезали без проблем.
P>В canvas браузера в 2D еще будет раза в два-три меньше кода.
Да такие же вызовы MoveTo, LineTo...
И да, это ж не WinAPI а GDI.
P>Отсюда ясно, почему на чистом gdi никто в своём уме не пишет. Берут обычно какую высокоуровневую оболочку.
Которая просто заворачивает GDI в чуть более удобный С++ интерфейс.
Я у себя сделал точно так же, просто потому что их плюсов таким пользоваться удобнее. Но это по сути прокси.
CC>>Что я писал "жээс глючит", тогда как речь была про "отдельные кривые сайты, где напихали скриптоты что они с трудом проворачиваются" P>Жээс глючит — это общее утверждение, про жээс.
Это не моё а твоё утверждение. И ты сам же с ним тут споришь.
CC>>И? Чем это отличается от вызова API функции "нарисуй мне в этом месте строку"? P>Например, нет необходимости ни в каких вычислениях.
В каких именно?
P>>> Это и есть рендерер CC>>Ну тогда FAR это тоже рендерер P>При этом Фар это примитивный рендерер, т.к. использует две или три тривиальных функции, которые в общем и вычислений не требуют.
CC>>Можно сказать что консольная аппа рендерит в консоль CC>>А чо, чем symbol + fgColor + bgColor хуже чем Path2D? P>Рендерит. Консольное приложение никак не может управлять тем, как будет выглядеть результат — это обязанность console host. Один шрифт на всю консоль и всё.
P>А вот рендерер pdf.js именно тем и занят, что выдает правильное сглаживание и хинтинг и тд.
Нет там ни сглаживания ни хинтинга, он просто тупо собирает контур, без каких либо попыток в хинты, а рендеринг и заливка этого контура со сглаживанием и прочими приседаниями происходит уже внутри С++ кода браузера.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>1. поиск новой музыки был востребованым во все времена.
Спасибо, Кэп!
P> Файлы на диске не решают это никак.
Файлы на диске это уже НАЙДЕННАЯ музыка. Причём именно нужного альбома, нужной редакции и т.п.
У меня как то коллега залил свою музыку в облако, которое просто по названиям песен заменило то, что он залил, редкую версию альбома, на генерик версию того же альбома.
Так что нет, файлы и только файлы. Ты не владеешь тем, что не контролируешь.
P>Стриминговые сервисы дают это прямо искаропки.
Что они дают искаропки?
P>2. Юзеры используют тучи устройств, в т.ч. вне дома
И? В машину у меня залиты те же файлы что и дома. На рабочем компе через Syncthing прилетают те же файлы что и дома.
P>3. Люди слушают много и разного, меняют предпочтения постоянно.
То, чем набит стриминг у меня не вызывает никаких положительных эмоций, скорее отрицательные.
P>Услышал где то — добавил себе.
И какая проблема добавить себе файл?
P>4. Стриминг много дешевле покупки музыки
Музыка мне с бОльшего бесплатно достаётся за Amazon day бонусы.
P>5. Качество контента выше всего именно в стриминге
Радикально нет!
P>6. стриминговые сервисы имеют хорошие рекомендательные алгоритмы, например, Spotify здесь вообще сказка.
Пользовался многими, все они в лучшем случае выдавали то, что у меня уже есть. А вот чтоб что новое подсунуть так я чаще на coub с прикольной темой натыкался чем один из этих сервисов мне что предлагал.
P>7. в стриминге нет смысла тратить время-пространство на организацию хранилища
Тоже мне проблема!
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>с джаваскриптом у этих же людей получается много лучше чем у них же с С++. CC>Верно
P>>Следовательно, джаваскрипт уменьшает количество багов. CC>Категорически неверно
Неверный вывод. Ты согласился с тем, что у одних и тех же людей с жээс получается лучше. Следовательно, жээс уменьшает количество багов.
В этом давно убедились в 90х и 00х, когда пытались скриптовать на С++.
P>>Ты когда нибудь пробовал заскриптовать среднюю страничку на плюсах? CC>угу, через CGI. Кстати замечательно работало, ещё и быстро как из пулемёта, в те времена то.
Я говорю о скриптовании внутри страницы браузера, а не склейку строк. Т.е. прямой эквивалент жээса, ровно те же задачи, только на плюсах. Так пилились например всякие плагины-аддоны-сайдбары-меню для интернет-эксплорера, dhtml-диалоги и многие другие вещи.
Сейчас вся эта кунсткамера уже не нужна — жээсом пишется пяток строк вместо пяти страниц, и с бОльшим качеством.
P>>В плюсах не на много то и лучше. Принципиальной разницы нет. CC>Нет. С++ имеет таки принципиальную разницу, которая позволяет писать куда более чистый и безопасный код.
С++ позволяет писать как угодно, что видно по репозиториям. Например, если товарищи используют указатели в плюсах, то у них будет полно ошибок с указателями.
Соответсвенно ты путаешь "можно", "нужно" и "как на самом деле"
P>>Это какой то юношеский максимализм. Всё становится элементарным после того, как освоишь. CC>Я это освоил ещё в универе, а это было чёрти когда. Так что не надо мне рассказывать про сложности освоения букваря, меня такие байки только веселят.
Ты так и не сказал, сколько у тебя опыта было, когда ты начал фремворк пилить.
P>>Что бы сходу влезть в WINAPI — я такого ни раз не видел. CC>Почему то раньше влезали без проблем.
"Без проблем" это долго и нудно ради простых вещей, с регулярными ошибками — стек, указатели, итд.
P>>В canvas браузера в 2D еще будет раза в два-три меньше кода. CC>Да такие же вызовы MoveTo, LineTo...
Такие да не такие. Разница в количестве мелких приседаний примерно в 10 раз. Потому в жээсе ты можешь рендерить безо всяких врапперов, а в плюсах в норме используются именно врапперы. В своём уме голый GDI никто не использует.
CC>И да, это ж не WinAPI а GDI.
А GDI это часть WINAPI
P>>Отсюда ясно, почему на чистом gdi никто в своём уме не пишет. Берут обычно какую высокоуровневую оболочку. CC>Которая просто заворачивает GDI в чуть более удобный С++ интерфейс.
Не просто "чуть более удобный", а полностью убирает простыни кода.
CC>Я у себя сделал точно так же, просто потому что их плюсов таким пользоваться удобнее. Но это по сути прокси.
Вот-вот, о чем и речь.
CC>>>Что я писал "жээс глючит", тогда как речь была про "отдельные кривые сайты, где напихали скриптоты что они с трудом проворачиваются" P>>Жээс глючит — это общее утверждение, про жээс. CC>Это не моё а твоё утверждение. И ты сам же с ним тут споришь.
Мне не трудно найти точную цитату "Глючит всеми цветами радуги, срёт под себя, хрипит и корчится, но как то ползёт — вот нынешний идеал софтостроения!"
Узнёешь? И раз ты ехидничаешь "нынешний идеал софтостроения", то речь, очевидно, не про одно приложение, и даже не про семейство.
CC>>>И? Чем это отличается от вызова API функции "нарисуй мне в этом месте строку"? P>>Например, нет необходимости ни в каких вычислениях. CC>В каких именно?
В любых.
P>>А вот рендерер pdf.js именно тем и занят, что выдает правильное сглаживание и хинтинг и тд. CC>Нет там ни сглаживания ни хинтинга, он просто тупо собирает контур, без каких либо попыток в хинты, а рендеринг и заливка этого контура со сглаживанием и прочими приседаниями происходит уже внутри С++ кода браузера.
Ну пусть так. Тем не менее выглядит достойно. Скажем, уже такой результат обеспечивают далеко не все компоненты. У многих вообще сглаживания нет, а потому смотрится вырвиглазно.
То есть, на пдфжээсе можно делать вещи, которые на большинстве нативных компонентов просто недоступны.
Здравствуйте, CreatorCray, Вы писали:
P>> Файлы на диске не решают это никак. CC>Файлы на диске это уже НАЙДЕННАЯ музыка. Причём именно нужного альбома, нужной редакции и т.п.
Именно что найденная. А поиск это фича номер один. Стриминг как правило интегрирован с вещами типа Shazam, а вот твои файлы — нет. Гы-гы.
CC>Так что нет, файлы и только файлы. Ты не владеешь тем, что не контролируешь.
Нас интересует не физический вариант хранения, а вопрос, кто управляет файлами библиотеки — ты сам, или сервис.
Когда переходят на стриминг, то папочка "моя музыка" больше не нужна, и не надо ничего копировать, сихронизировать, итд.
Все что тебе надо — плейлисты в сервисе, которые доступны отовсюду на всех устройствах в нужном качестве.
Вместо плейлистов ты предлагаешь ручное управление файлами — копирование, сихронизацию и прочий геморрой.
Это уже каменный век. Сейчас юзеры в основной массе уходят от "файлы-копирование-синхронизация"
P>>Стриминговые сервисы дают это прямо искаропки. CC>Что они дают искаропки?
Ты как типичный "системщик" к концу фразы забываешь о чем речь. Как ты с указетелями то справляешься? Цитирую себя:
1. поиск новой музыки был востребованым во все времена. Файлы на диске не решают это никак. Стриминговые сервисы дают это прямо искаропки.
P>>2. Юзеры используют тучи устройств, в т.ч. вне дома CC>И? В машину у меня залиты те же файлы что и дома. На рабочем компе через Syncthing прилетают те же файлы что и дома.
А разве речь про тебя? Это твой личный выбор колупаться с файлами и вручную управлять библиотекой. Ты ж вообще всё контролируешь, даже закат солнца
P>>3. Люди слушают много и разного, меняют предпочтения постоянно. CC>То, чем набит стриминг у меня не вызывает никаких положительных эмоций, скорее отрицательные.
А ты его и не пробовал.
P>>Услышал где то — добавил себе. CC>И какая проблема добавить себе файл?
Зачем вообще с файлами колупаться? Тапнул Shazam, тапнул на иконку Spotify или iTunes, и уже слушаешь музыку.
На кой ляд тут заморачиваться с файлами? 5-10 раз послушал и скорее всего к этому треку не вернешься. А если он тебе по прежнему нужен, то нажал сердечко и он у тебя в плейлисте сам собой объявится.
P>>4. Стриминг много дешевле покупки музыки CC>Музыка мне с бОльшего бесплатно достаётся за Amazon day бонусы.
С чего ты взял, что все юзеры такие? Большинство как раз амазоном не хотят пользоваться по ряду причин.
P>>5. Качество контента выше всего именно в стриминге CC>Радикально нет!
Наоборот. В стриминге нет только самопальных треков, как у тебя, и тех, что имеют ограничения по лицензии.
Это я тебе как коллекционер с большим стажем говорю — я в стриминге понаходил %95 всех редких альбомов, которые когда либо хотел заполучить.
P>>6. стриминговые сервисы имеют хорошие рекомендательные алгоритмы, например, Spotify здесь вообще сказка. CC>Пользовался многими, все они в лучшем случае выдавали то, что у меня уже есть.
И снова переводишь речь на себя. Мы то про рынок, как он устроен, а не про твои личные предпочтения.
P>>7. в стриминге нет смысла тратить время-пространство на организацию хранилища CC>Тоже мне проблема!
Здравствуйте, Pauel, Вы писали:
P>Стриминг как правило интегрирован с вещами типа Shazam, а вот твои файлы — нет.
А нафига мне что то в моих файлах шазамом искать? Я прекрасно знаю что у меня есть и где оно лежит.
Такой поиск нужен для того чтоб найти название неизвестной композиции и потом по названию скачать себе в хорошем, не стримовом качестве.
P>Нас интересует не физический вариант хранения, а вопрос, кто управляет файлами библиотеки — ты сам, или сервис.
Всегда только сам. Тут никаких вопросов вообще не может быть.
P>Когда переходят на стриминг, то папочка "моя музыка" больше не нужна, и не надо ничего копировать, сихронизировать, итд.
Всё просрут без твоего участия, ага
Спасибо, но нафиг нафиг.
P>Все что тебе надо — плейлисты в сервисе, которые доступны отовсюду на всех устройствах в нужном качестве.
У меня это всё уже есть, без каких либо сервисов.
P>>>Стриминговые сервисы дают это прямо искаропки. CC>>Что они дают искаропки? P>1. поиск новой музыки был востребованым во все времена. Файлы на диске не решают это никак. Стриминговые сервисы дают это прямо искаропки.
Ещё раз, для икемфул. Что именно они дают "искаропки". С поиском новой музыки для меня ни один сервис справиться не сумел. Я больше интересной музыки нашёл тупо листая раздел "лучшее" на coub.com
P>Ты ж вообще всё контролируешь, даже закат солнца
Не, я ещё далёк от совершенства
P>Зачем вообще с файлами колупаться?
Потому что попав на мою машину он никуда больше не денется. Никакие правообладатели или решение закрыть сервис меня не затронут. У меня будет именно та версия песни и именно с той версии альбома, которая мне понравилась.
P> Тапнул Shazam, тапнул на иконку Spotify или iTunes, и уже слушаешь музыку.
Там тупо нет того, что я слушаю. У меня много музыки отредактированной. Есть и бутлеги, которые в легальных интернетах просто тупо не найти уже давно.
P>5-10 раз послушал и скорее всего к этому треку не вернешься.
С какого это вдруг перепугу?
P> А если он тебе по прежнему нужен, то нажал сердечко и...
... тебе показывают половой орган, ибо всё, больше нету его в стриминге.
P> Большинство как раз амазоном не хотят пользоваться по ряду причин.
И что же это за ряд причин?
P>Наоборот. В стриминге нет только самопальных треков, как у тебя, и тех, что имеют ограничения по лицензии.
Ну т.е там нету процентов так 80 музыки, которые я добавил в коллекцию за последние 10-15 лет.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Ты согласился с тем, что у одних и тех же людей с жээс получается лучше.
Я согласился что они менее сурово косячат.
P> Следовательно, жээс уменьшает количество багов.
Мда. С логикой ты не дружишь.
P>Я говорю о скриптовании внутри страницы браузера
P>Так пилились например всякие плагины-аддоны-сайдбары-меню для интернет-эксплорера
Это не "скриптование"
P> dhtml-диалоги и многие другие вещи.
А где в dhtml был client-side C++?
P>Ты так и не сказал, сколько у тебя опыта было, когда ты начал фремворк пилить.
"Nor must I" (C)
P>Не просто "чуть более удобный", а полностью убирает простыни кода.
Большинство операций как были однострочными так и остаются.
P>Мне не трудно найти точную цитату "Глючит всеми цветами радуги, срёт под себя, хрипит и корчится, но как то ползёт — вот нынешний идеал софтостроения!"
Это был ответ на "А сейчас то же банковское приложение коих пруд пруди при всех его глюках, стектрейсах итд позволяет выполнить основную функцию"
P>речь, очевидно, не про одно приложение, и даже не про семейство.
Про "банковское приложение коих пруд пруди", да.
P>Скажем, уже такой результат обеспечивают далеко не все компоненты.
Этот результат обеспечивает рендерер браузера.
P> У многих вообще сглаживания нет, а потому смотрится вырвиглазно.
Это функция рендерера а не PDF парсера. Прикрути к ним да хоть тот же DirectWrite backend и будет тебе и сглаживание и даже GPU acceleration.
P>То есть, на пдфжээсе можно делать вещи, которые на большинстве нативных компонентов просто недоступны.
Тут нет ни малейшей заслуги JS per se, рендеринг выполняется нативным кодом браузера.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Стриминг как правило интегрирован с вещами типа Shazam, а вот твои файлы — нет.
... CC>Такой поиск нужен для того чтоб найти название неизвестной композиции и потом по названию скачать себе в хорошем, не стримовом качестве.
Ну наконец то тебя пробило! Итак — поиск тебе тоже нужен. И кто же умеет его лучше стриминга? гы-гы.
Что за "хорошее, не стримовое качество" ?
CD качество 16/44khz тебя не устраивает? А hi-res, например, 24/192khz?
P>>Нас интересует не физический вариант хранения, а вопрос, кто управляет файлами библиотеки — ты сам, или сервис. CC>Всегда только сам. Тут никаких вопросов вообще не может быть.
И снова подмена темы — речь не про тебя.
P>>Когда переходят на стриминг, то папочка "моя музыка" больше не нужна, и не надо ничего копировать, сихронизировать, итд. CC>Всё просрут без твоего участия, ага
Какая то ненаучная фантастика. Как часто такое случается ну вот на том же Spotify, который лидер рынка ?
P>>Все что тебе надо — плейлисты в сервисе, которые доступны отовсюду на всех устройствах в нужном качестве. CC>У меня это всё уже есть, без каких либо сервисов.
И снова — ты в переводишь тему, подменяя кейс своими хотелками.
CC>Ещё раз, для икемфул. Что именно они дают "искаропки". С поиском новой музыки для меня ни один сервис справиться не сумел. Я больше интересной музыки нашёл тупо листая раздел "лучшее" на coub.com
Читаем вместе "Coub is a video streaming platform..." Т.е. coub не просто сервис, а тот самый стриминг, хотя и видео.
Следовательно, ты нашел музыку используя именно сервис, и не абы какой, а стриминговый.
P>>Зачем вообще с файлами колупаться? CC>Потому что попав на мою машину он никуда больше не денется. Никакие правообладатели или решение закрыть сервис меня не затронут. У меня будет именно та версия песни и именно с той версии альбома, которая мне понравилась.
Крайне редкий кейс. Ты в который раз подмянешь тему, переводя разговор на себя.
P>> Тапнул Shazam, тапнул на иконку Spotify или iTunes, и уже слушаешь музыку. CC>Там тупо нет того, что я слушаю. У меня много музыки отредактированной. Есть и бутлеги, которые в легальных интернетах просто тупо не найти уже давно.
Бутлеги это синоним пиратских записей.
P>>5-10 раз послушал и скорее всего к этому треку не вернешься. CC>С какого это вдруг перепугу?
Такие вот новые поколения юзеров.
P>> А если он тебе по прежнему нужен, то нажал сердечко и... CC>... тебе показывают половой орган, ибо всё, больше нету его в стриминге.
Это какие то страхи. За последние 2 года ни разу такого не было.
P>> Большинство как раз амазоном не хотят пользоваться по ряду причин. CC>И что же это за ряд причин?
Пудозреваю, что кривое апи и всё анально огорожено, раз его толком никто и не умеет поддерживать. Спотифай всунули в каждый утюг. Тидал — близко к этому. А еще есть Deezer, Qobuz, Apple Music итд итд.
У любителей амазона вечный вайн — "у меня не работает, что делать"
P>>Наоборот. В стриминге нет только самопальных треков, как у тебя, и тех, что имеют ограничения по лицензии. CC>Ну т.е там нету процентов так 80 музыки, которые я добавил в коллекцию за последние 10-15 лет.
И снова речь не про тебя. Ты в очередной раз пытаешься подменить тему, переводя разговор на себя.
Здравствуйте, CreatorCray, Вы писали:
P>>Ты согласился с тем, что у одних и тех же людей с жээс получается лучше. CC>Я согласился что они менее сурово косячат.
Именно. Речь идет именно про этот эффект — "менее сурово косячат". Менее — значит где есть и более. И разница исключительно в ЯП, раз уже люди одни и те же.
P>> Следовательно, жээс уменьшает количество багов. CC>Мда. С логикой ты не дружишь.
Читай себя выше: "менее сурово косячат"
P>>Я говорю о скриптовании внутри страницы браузера CC>
Сравниваем яблоки с яблоками, а не скриптинг внутри страницы со склейкой строк в CGI.
P>>Так пилились например всякие плагины-аддоны-сайдбары-меню для интернет-эксплорера CC>Это не "скриптование"
Это и есть скриптование. Отталкиваемся от задачи, а не языка. Скриптование — это логика самого верхнего уровня.
Пример — подписаться на эвенты, обеспечить байндинг, динамику, поведение страницы, подтягивать данные из бд/сети/другой страницы.
P>> dhtml-диалоги и многие другие вещи. CC>А где в dhtml был client-side C++?
В MFC, например. Цельный CDHTMLDialog. Там писали вообще всю логику формы на C++. Аналогичная механика была и в ATL/WTL.
Чаще конечно IE использовали как компонент, обмазывали его С++ кодом см. пример выше.
Типичный кейс — сайдбар для IE. Это плагин к IE, который содержит IE как компонент.
Очевидно, все скриптование делалось на С++ используя COM.
Логика ровно та же, что в примере выше ну или в нынешних скриптах на greasemonkey например или плагинах для хрома.
P>>Не просто "чуть более удобный", а полностью убирает простыни кода. CC>Большинство операций как были однострочными так и остаются.
Нужно сравнить решение какой типовой задачи, а не вызов одиночного метода.
Я в свое время взял и сравнил.
P>>Скажем, уже такой результат обеспечивают далеко не все компоненты. CC>Этот результат обеспечивает рендерер браузера.
Каждый уровень рендерит в единицах нижележащих уровней — иначе не бывает. Мне казалось, что это очевидно.
Забавно, что ты все стараешься подменить тему на "не жээс записывает eax в порт xyz"
P>> У многих вообще сглаживания нет, а потому смотрится вырвиглазно. CC>Это функция рендерера а не PDF парсера. Прикрути к ним да хоть тот же DirectWrite backend и будет тебе и сглаживание и даже GPU acceleration.
Похоже, у тебя только то рендерер, что "на С++ и чтото там рисует и начинается с class Renderer:"
Рендерер это функция вида репрезентация=>репрезентация, т.е. мы можем pdf рендерить во что угодно — в текст, в примитивы 2d графики, в пикселы, xml, json, итд итд
А wav мы можем рендерить как в синусоиду на экране, так и в сигнал в аналоговом тракте усилителя.
P>>То есть, на пдфжээсе можно делать вещи, которые на большинстве нативных компонентов просто недоступны. CC>Тут нет ни малейшей заслуги JS per se, рендеринг выполняется нативным кодом браузера.
Заслуга жээса в том, что он позволяет обеспечить такое вот скриптование и дает хороший перформанс и годный АПИ. Факт, что большинство нативных компонентов вот так не могут.
Собственно, видно что pdfjs это немаленький проект. Аналогичный код на плюсах у большинства авторов выходит почему то дырявым и корявым.
Здравствуйте, Pauel, Вы писали:
P>Речь идет именно про этот эффект — "менее сурово косячат".
Это всего то означает что их косяки перехватывает памперс и старается минимизировать ущерб.
Меньше косяков от этого не становится, скорее наоборот расслабляет и позволяет не париться говнокодом.
P> И разница исключительно в ЯП, раз уже люди одни и те же.
Не, разница что один рантайм ошибки сжёвывает и прощает, другой — сразу бьёт ими по морде.
P>В MFC, например. Цельный CDHTMLDialog. Там писали вообще всю логику формы на C++. Аналогичная механика была и в ATL/WTL. P>Чаще конечно IE использовали как компонент, обмазывали его С++ кодом см. пример выше.
Этож по сути был свой браузер, какое это к вебу имеет отношение?
P>Похоже, у тебя только то рендерер, что "на С++
Для меня рендерер это то, что превращает высокоуровневые примитивы типа bezier curves в конкретные пиксели.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>И кто же умеет его лучше стриминга? гы-гы.
Дык в том то и дело что стриминг его не умеет. Подсовывает уже то, что у меня и так есть, а вот что то новое предложить — никак не получалось.
Куда лучше выходило найти на совершенно не имеющих отношения к стримингу сайтам.
P>Читаем вместе "Coub is a video streaming platform..."
Вот именно что
Если убрать маркетинговое словоблудие то Coub это хостинг коротких зацмкленных видео, которые туда закачивают пользователи. Сам он никакого контента не предоставляет, просто площадка для размещения юзерского контента.
И да, никакого поиска музыки там отродясь не было. Наоборот, когда находишь какую нить тему то приходится скармливать её распознавалкам ибо крайне редко там есть хинты что это за музыка вообще.
P>Бутлеги это синоним пиратских записей.
Бутлеги это банально то, что не было официально релизнуто, по разным причинам.
P>>>5-10 раз послушал и скорее всего к этому треку не вернешься. CC>>С какого это вдруг перепугу? P>Такие вот новые поколения юзеров.
А мне до них какое дело? У меня то всё не так. И меня интересует чтоб было удобно мне.
P>Это какие то страхи. За последние 2 года ни разу такого не было.
У меня так коллега потерял редкие записи пару лет назад.
P>>> Большинство как раз амазоном не хотят пользоваться по ряду причин. CC>>И что же это за ряд причин? P>Пудозреваю, что кривое апи
Какое нафиг кривое АПИ? В магазине треки в корзину шлёп, кнопу "купить" тык, кнопу "скачать" тык, готово!
P>И снова речь не про тебя.
Когда ты мне рекламируешь сервисы я их рассматриваю исключительно с точки зрения моего удобства.
И мне они не удобны, о чём я тебе и говорю.
Если тебе они ок — пользуйся сам на здоровье.
Но ты ж хочешь доказать что это серебряная пуля и решатель всех проблем.
Удачи, чо.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>И кто же умеет его лучше стриминга? гы-гы. CC>Дык в том то и дело что стриминг его не умеет.
Твой коуб конечно же ничего внятного и не умеет.
> Подсовывает уже то, что у меня и так есть, а вот что то новое предложить — никак не получалось.
Не знаю, что там у тебя не получается
— Song radio, Album radio, Artist radio и там часы контента из которого почти всё новое.
— Made for you
— Charts
— New releases
— подборки по жанрам
— разные тематические подборки, "soft jazz", "sleep", "gym"
Такая механика есть во всех стриминговых сервисах. Работает само, остаётся только снять корону с головы.
Кроме того, Радио + Shazam дает тебе еще один вариант поиска. Например Bluesflac регулярно подкидыват новый контент. Надо только избавиться от привычки слушать звуки, как ты делаешь.
CC>Куда лучше выходило найти на совершенно не имеющих отношения к стримингу сайтам.
Из "не имеющих отношения к стримингу сайтам" сoub оказался вдруг тем самым стриминговым сервисом. Гы-гы.
P>>Читаем вместе "Coub is a video streaming platform..." CC>Вот именно что CC>Если убрать маркетинговое словоблудие то Coub это хостинг коротких зацмкленных видео, которые туда закачивают пользователи. Сам он никакого контента не предоставляет, просто площадка для размещения юзерского контента.
Тем не менее, это просто вариант стриминга.
CC>И да, никакого поиска музыки там отродясь не было. Наоборот, когда находишь какую нить тему то приходится скармливать её распознавалкам ибо крайне редко там есть хинты что это за музыка вообще.
Ну вот ты нашел вариант стриминга с ручным приводом, что бы побольше контролировать руками.
P>>Бутлеги это синоним пиратских записей. CC>Бутлеги это банально то, что не было официально релизнуто, по разным причинам.
Именно. При чем релизилось в обход правообладателей. Потому и bootleg — термин, обозначающий контрабандиста.
P>>Такие вот новые поколения юзеров. CC>А мне до них какое дело? У меня то всё не так. И меня интересует чтоб было удобно мне.
Мы про то, куда идут технологии, и почему они туда идут. При чем здесь контректно ты?
P>>Это какие то страхи. За последние 2 года ни разу такого не было. CC>У меня так коллега потерял редкие записи пару лет назад.
Крайне редкий кейс. Топ жалоб на стриминг это что нибудь "не работает из под vpn в моей стране", "не дает зарегистрироваться без vpn"
P>>Пудозреваю, что кривое апи CC>Какое нафиг кривое АПИ? В магазине треки в корзину шлёп, кнопу "купить" тык, кнопу "скачать" тык, готово!
Похоже, ты себя в большинство записал. Читаем вместе:
"Большинство как раз амазоном не хотят пользоваться"
Чем пользуется большинство?
Правильно — стримингом.
Вот здесь и появляется АПИ. Если разрабы стримера не могут добавить поддержку, то и покупатели стримера не будут пользоваться амазоном.
P>>И снова речь не про тебя. CC> CC>Когда ты мне рекламируешь сервисы я их рассматриваю исключительно с точки зрения моего удобства.
Мы все еще говорим о том, почему музыкальные проигрыватели ушли на веб-технологии. Причины в изменении поведения аудитории, и оказалось быстрее и проще запилить на веб-технологиях, чем продавливать старую идею "скачайте аимп, накопируйте файлов, купите NAS, настройте, синхронизируйте".
Ты постоянно переводишь разговор на себя. Очевидно, что ты застрял где то в нулевых. Странно думать, что и другие застряли там же.
CC>Но ты ж хочешь доказать что это серебряная пуля и решатель всех проблем.
Здравствуйте, CreatorCray, Вы писали:
P>>Речь идет именно про этот эффект — "менее сурово косячат". CC>Это всего то означает что их косяки перехватывает памперс и старается минимизировать ущерб.
Именно про это и речь — минимизация ущерба происходит не магией, а за счет исключения целых классов ошибок.
CC>Меньше косяков от этого не становится, скорее наоборот расслабляет и позволяет не париться говнокодом.
По баклогу что ли? Очевидно, что на жээсе я заскриптую десять страничек за то же время, что раньше на С++ одну еле-еле. А может и все 100.
При этом:
1. багов будет много меньше, чем если бы я эти 10...100 страниц заскриптовал на С++ в браузере
2. в пересчете на единицу времени, по баклогу доля жээсных будет больше, т.к. 10...100 страниц больше, чем 1
3. при этом жээс исключает целые классы багов, т.е. баклог будет состоть из мелочевки, которую можно отдать фиксать студентам или вообще лицам без образования, а можно и оставить как есть, что часто и происходит.
У меня ощущения, что ты сумеешь прочесть только один из этих пунктов. Статистика-с.
P>> И разница исключительно в ЯП, раз уже люди одни и те же. CC>Не, разница что один рантайм ошибки сжёвывает и прощает, другой — сразу бьёт ими по морде.
ЯП и есть его рантайм, в частности. Решение идентичных задач, типа прикрутить эвенты, байндинг, динамику, поведение итд, даёт нам отличия в десяток другой раз по количествоу кода.
Это всё проходили в 90х и 00х, когда люди пытались IE и Офис скриптовать на плюсах.
P>>Чаще конечно IE использовали как компонент, обмазывали его С++ кодом см. пример выше. CC>Этож по сути был свой браузер, какое это к вебу имеет отношение?
Прямое — страничка браузера это и есть те самые веб-технологии. Браузер то ничего кроме странички не умеет показывать, он работает одинаково вне зависимости от того, что за страница. Вопрос только в том, как ты заскриптуешь эту страницу — жээсом или плюсами.
P>>Похоже, у тебя только то рендерер, что "на С++ CC>Для меня рендерер это то, что превращает высокоуровневые примитивы типа bezier curves в конкретные пиксели.
Высокоуровневые примитивы это текст, стили, шрифты, анимация, картинки, лаёут, то есть, то как это понимает юзер.
bezier curver это уже деталь реализации, которая юзеру не видна, соотвенно это уже низкоуровневый примитив.
Соответсвенно нам всегда нужен такой рендерер, который превращает самый верхний уровень, "тест, стили, шрифты, анимация, картинки, лаёут", в низкие.
Сколько там будет низкоуровневых слоёв — уже не интересно.
Здравствуйте, Pauel, Вы писали:
CC>>Дык в том то и дело что стриминг его не умеет. P>Твой коуб конечно же ничего внятного и не умеет.
И тем не менее коуб мне дал куда больше понравившейся мне музыки чем все эти "обучающиеся на том что ты слушаешь" стриминги.
P> — Song radio, Album radio, Artist radio и там часы контента из которого почти всё новое.
Если у меня уже есть такой альбом или такой исполнитель то всё остальное из их творчества я считай уже нашёл и ознакомился. Что понравилось — положил в коллекцию либо как есть либо отредактированное.
Мне как раз надо кто то новый.
P> — Made for you
Это как вообще?
P> — Charts
Там полное говно, я такое не слушаю совсем.
P> — New releases
Тоже очень много шлака
P> — подборки по жанрам
для этого мне и стриминг не нужен, сам в состоянии.
Впрочем у меня вкус не жанровый а "понравилось или нет", а по жанрам разброс довольно широкий.
P> — разные тематические подборки, "soft jazz", "sleep", "gym"
Ну вот у меня в одном и том же плейлисте рядом лежат отдельные композиции от Heilung, Phantogram, Cradle of Filth, Anathema, Opeth, Iggy Pop, Muse, The Obeliske, Monplat, Hidden Citizens, LittleV, The Heavy, Twenty One Pilots, Kai Engel, London Symphony Orchestra (ага!), Luca Stricagnoli, Archive, Nightcore, Feder, And One, Amon Amarth, Behemoth, Amorphis, Covenant, Doom VS, In Flames, Thy Catafalque, Summoning, PilotPriest, Minenwerfer...
К какой тематической подборке кроме как "сборная солянка" это можно отнести?
P>Такая механика есть во всех стриминговых сервисах. Работает само, остаётся только снять корону с головы.
Пробовал 4 разных — результат нулевой.
P>Надо только избавиться от привычки слушать звуки, как ты делаешь. Отойди от лужи, она уже газирована достаточно.
P>Из "не имеющих отношения к стримингу сайтам" сoub оказался вдруг тем самым стриминговым сервисом. Гы-гы.
Не ну с таким подходом torrents.ru это тоже будет стриминговый сервис
P>Тем не менее, это просто вариант стриминга.
Ты лучше скажи что нынче не стриминг?
P>Именно. При чем релизилось в обход правообладателей. Потому и bootleg — термин, обозначающий контрабандиста.
То, что сами музыканты записали но в альбом не вошло это тоже бутлег.
У меня таких треков от знакомых музыкантов имеется пачка. К примеру у меня есть есть одна из начальных версий трека, которая понравилась мне но по какой то причине не устроила их, так что они трек заметно переделали и выпустили в другом виде, под тем же названием.
P>"Большинство как раз амазоном не хотят пользоваться" P>Чем пользуется большинство? Правильно — стримингом.
У амазона кроме магазина свой стриминг тоже есть, если ты вдруг не знал.
P>Вот здесь и появляется АПИ. Если разрабы стримера не могут добавить поддержку, то и покупатели стримера не будут пользоваться амазоном.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pauel, Вы писали:
P>Именно про это и речь — минимизация ущерба происходит не магией, а за счет исключения целых классов ошибок.
За счёт попыток восстановиться и подтереть обосранную жопу юзерскому коду, когда он опять наступил себе на бороду и упал рожей в навоз.
CC>>Не, разница что один рантайм ошибки сжёвывает и прощает, другой — сразу бьёт ими по морде. P>ЯП и есть его рантайм, в частности.
Его рантайм это native код песочницы внутри браузера, который на плюсах.
P>Высокоуровневые примитивы это текст, стили, шрифты, анимация, картинки, лаёут, то есть, то как это понимает юзер.
Нет, всё перечисленное кроме картинок это не примитивы а абстракции, которые потом декомпозируются на собственно примитивы (название то говорящее)
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Твой коуб конечно же ничего внятного и не умеет. CC>И тем не менее коуб мне дал куда больше понравившейся мне музыки чем все эти "обучающиеся на том что ты слушаешь" стриминги.
Это потому, что ты нормальными стриминговыми сервисами не пользовался.
P>> — Song radio, Album radio, Artist radio и там часы контента из которого почти всё новое. CC>Если у меня уже есть такой альбом или такой исполнитель то всё остальное из их творчества я считай уже нашёл и ознакомился. Что понравилось — положил в коллекцию либо как есть либо отредактированное. CC>Мне как раз надо кто то новый.
Эта фича как раз дает тебе НОВЫЙ контент. Ты похоже спотифай пользовал на уровне login page или home page максимум.
P>> — Made for you CC>Это как вообще?
А ты вообще пользовался, раз задаешь такие вопросы?
P>> — Charts CC>Там полное говно, я такое не слушаю совсем.
Ну да, ты вручную булшитишь юзерские чарты на coub.
P>> — New releases CC>Тоже очень много шлака
И снова "не в курсе, но наверняка чтото плохое"
P>> — подборки по жанрам CC>для этого мне и стриминг не нужен, сам в состоянии.
И откуда ж ты без стриминга найдешь тонны нового контента? Будешь скачивать сотни файлов, что бы разнобразить музыку?
P>> — разные тематические подборки, "soft jazz", "sleep", "gym" CC>Ну вот у меня в одном и том же плейлисте рядом лежат отдельные композиции от Heilung, Phantogram, Cradle of Filth, Anathema, Opeth, Iggy Pop, Muse, The Obeliske, Monplat, Hidden Citizens, LittleV, The Heavy, Twenty One Pilots, Kai Engel, London Symphony Orchestra (ага!), Luca Stricagnoli, Archive, Nightcore, Feder, And One, Amon Amarth, Behemoth, Amorphis, Covenant, Doom VS, In Flames, Thy Catafalque, Summoning, PilotPriest, Minenwerfer... CC>К какой тематической подборке кроме как "сборная солянка" это можно отнести?
Made for you в spotify подкидывает тебе согласно твоим предпочтениям.
P>>Такая механика есть во всех стриминговых сервисах. Работает само, остаётся только снять корону с головы. CC>Пробовал 4 разных — результат нулевой.
Ты чуть выше почти буквально сказал, что не юзал. См cвой коммент про Artist Radio
P>>Из "не имеющих отношения к стримингу сайтам" сoub оказался вдруг тем самым стриминговым сервисом. Гы-гы. CC>Не ну с таким подходом torrents.ru это тоже будет стриминговый сервис
Торрентс как раз файловый сервис, т.к. стримить не позволяет.
P>>Тем не менее, это просто вариант стриминга. CC>Ты лучше скажи что нынче не стриминг?
Торренты, скачивание файлов, синхронизация файлов, CD, винил
P>>Именно. При чем релизилось в обход правообладателей. Потому и bootleg — термин, обозначающий контрабандиста. CC>То, что сами музыканты записали но в альбом не вошло это тоже бутлег.
Именно — такой контент не релизился, распространение его равносильно пиратству.
P>>"Большинство как раз амазоном не хотят пользоваться" P>>Чем пользуется большинство? Правильно — стримингом. CC>У амазона кроме магазина свой стриминг тоже есть, если ты вдруг не знал.
Браво — я именно про него и говорю.
P>>Вот здесь и появляется АПИ. Если разрабы стримера не могут добавить поддержку, то и покупатели стримера не будут пользоваться амазоном. CC>
Погугли на предмет поддержки амазоновского стриминга в девайсах и софте и сравни с прямыми конкурентами.
Здравствуйте, CreatorCray, Вы писали:
P>>Именно про это и речь — минимизация ущерба происходит не магией, а за счет исключения целых классов ошибок. CC>За счёт попыток восстановиться и подтереть обосранную жопу юзерскому коду, когда он опять наступил себе на бороду и упал рожей в навоз.
За счет того:
1. нет прямого доступа к памяти и подобным вещам
2. примерно в 10 раз более короткий код
Забавно, что упоминание жээса вызыает у тебя фекальные ассоциации. Прямо травма какая то.
CC>>>Не, разница что один рантайм ошибки сжёвывает и прощает, другой — сразу бьёт ими по морде. P>>ЯП и есть его рантайм, в частности. CC>Его рантайм это native код песочницы внутри браузера, который на плюсах.
Я в курсе. Нас интересует конкретная логика страницы.
P>>Высокоуровневые примитивы это текст, стили, шрифты, анимация, картинки, лаёут, то есть, то как это понимает юзер. CC>Нет, всё перечисленное кроме картинок это не примитивы а абстракции, которые потом декомпозируются на собственно примитивы (название то говорящее)
Это уже непринципиально. Рендерер на самом верху определяет, что должно быть нарисовано, с какими эффектами, стилями итд и тд. Нижележащие слои определяют как именно это будет нарисовано. Вот это и есть разница — что/как эквивалентна высокий/низкий.
Здравствуйте, Pauel, Вы писали:
P>Это потому, что ты нормальными стриминговыми сервисами не пользовался.
Дадада, "это всё был неправильный коммунизм" (С)
P>Эта фича как раз дает тебе НОВЫЙ контент.
Вот как раз нового контента мне ничего так и не дало. Мне надоело это повторять.
P>>> — Made for you CC>>Это как вообще? P>А ты вообще пользовался, раз задаешь такие вопросы?
Ты лучше объясни что под этим понимается? Потому как ничего интересного там не было вообще.
P>Made for you в spotify подкидывает тебе согласно твоим предпочтениям.
А вот хрен там. Иногда даёт то, что уже и так до дыр заслушано, но в большинстве своём я такое не слушаю.
P>>>Такая механика есть во всех стриминговых сервисах. CC>>Пробовал 4 разных — результат нулевой. P>Ты чуть выше почти буквально сказал, что не юзал.
Ещё раз, для не умеющих читать: я пробовал 4 разных стриминг сервиса.
P>Торрентс как раз файловый сервис, т.к. стримить не позволяет.
Ошибаешься. Есть плейеры которые умеют играть контент напрямую из торрента.
Так что тоже стриминг
P>>>Тем не менее, это просто вариант стриминга. CC>>Ты лучше скажи что нынче не стриминг? P>Торренты, скачивание файлов, синхронизация файлов
Это всё стриминг
P>CD, винил
Вот только это не стриминг
CC>>То, что сами музыканты записали но в альбом не вошло это тоже бутлег. P>Именно — такой контент не релизился, распространение его равносильно пиратству.
Ага, ага, музыканты спиратили свой же контент
Не неси чушь.
P>Погугли на предмет поддержки амазоновского стриминга в девайсах и софте и сравни с прямыми конкурентами.
Да насрать в общем то. Все стримеры играются из браузера, где можно резать их тупорылую рекламу.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Это потому, что ты нормальными стриминговыми сервисами не пользовался. CC>Дадада, "это всё был неправильный коммунизм" (С)
Это видно по твоим неверным предположениям. Вместо того, что бы глянуть и разобраться, ты выдаёшь какие то странные заключения.
У тебя подход ровно из 90х — на помойках находили какие то треки, слушали, если нравилось, скачивали весь альбом, колупались с синхронизацией и тд.
Сейчас люди поступают принципиально иначе, только ты все время переводишь разговор на себя. Никакой логики в этом нет — так мы точно не узнаем, почему появился новый софт с другими возможностями, просто потому, что ты это новое в упор видеть отказываешься.
P>>Эта фича как раз дает тебе НОВЫЙ контент. CC>Вот как раз нового контента мне ничего так и не дало. Мне надоело это повторять.
Ты снова переводишь вопрос на себя. Мы то не про тебя говорим. Такая фича, как радио трека/альбома/исполнителя, есть просто тематика определенной направленности. Там будет часов 5 музыки, среди которой этот испольнитель/альбом/трек будет примерно 1 из 10 или реже.
То есть, нашел чтото интересное, включаешь радио для этого же трека и слушаешь все, что подходит по направлению.
И эти вещи регулярно обновляются, как ни странно.
Итого — нет необходимости специально рыться и отслушивать материал, как ты это делаешь со своим coub.
P>>Made for you в spotify подкидывает тебе согласно твоим предпочтениям. CC>А вот хрен там. Иногда даёт то, что уже и так до дыр заслушано, но в большинстве своём я такое не слушаю.
В спотифае надо время, пока он разберется с твоими предпочтениям. И потом уже не нужно тратить время на поиск и отслушивание материала.
P>>Торрентс как раз файловый сервис, т.к. стримить не позволяет. CC>Ошибаешься. Есть плейеры которые умеют играть контент напрямую из торрента. CC>Так что тоже стриминг
Это всего лишь твой стример поддерживает файловые хранилища типа торрента.
P>>Торренты, скачивание файлов, синхронизация файлов CC>Это всё стриминг
Стриминг прежде всего означает, что тебе не надо ничего хранить локально. А вот приложение для стриминга может брать источником самые разные хранилища.
Например, у стримера может быть всего несколько килобайт памяти, буквально, и этого достаточно что бы работать с любыми стриминговыми сервисам.
P>>Именно — такой контент не релизился, распространение его равносильно пиратству. CC>Ага, ага, музыканты спиратили свой же контент CC>Не неси чушь.
Релиз, официальный или нет, это вообще любое распространение записи от имени правообладателя. А бутлегом называется именно такой вариант, когда распространяется запись для того не предназначенная, например, репетиция, концерт, закрытое представление и тд.
Например, музыканты могут подарить запись тебе, просто скинув трек в мессенджер. Но если ты начинаешь распространять его сам, это и есть пиратство.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Даже с одним шрифтом у символов разная ширина, разное межстрочное расстояние, разный масштаб. CC>И? Всё что тебе тут надо — GetTextExtentPoint32W и GetTextExtentExPointW CC>Системный рендерер всё расчёты сделает за тебя.
Хмм. Неужто и плавный зум обеспечит? С каких пор у нас TextOut и его друзья научились делать зум на 110% без рывков ширины?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pauel, Вы писали:
P>Вместо того, что бы глянуть и разобраться, ты выдаёшь какие то странные заключения.
Глянул, разобрался, мне не подходит.
P>Сейчас люди поступают принципиально иначе
Да пусть хоть говно жрут, мне то до их заморочек какое дело?
P> только ты все время переводишь разговор на себя.
Потому что мне надо решать мои задачи, способами которыми они таки решаются. Что там у других — мне слабо интересно.
P>ты это новое в упор видеть отказываешься.
Это твои фантазии.
P>Ты снова переводишь вопрос на себя.
Потому что мне надо решать мои задачи.
P>Такая фича, как радио трека/альбома/исполнителя, есть просто тематика определенной направленности. Там будет часов 5 музыки, среди которой этот испольнитель/альбом/трек будет примерно 1 из 10 или реже.
От жеж спасибо, кэп! А то я года два таким говном пользовался и не знал как оно работает. А работает оно так: meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, это у меня уже есть skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip, meh skip...
P>включаешь радио для этого же трека и слушаешь все, что подходит по направлению. P>нет необходимости отслушивать материал
Взаимоисключающие параграфы detected
P>В спотифае надо время, пока он разберется с твоими предпочтениям.
За джва (tm) года с небольшим четыре разных сервиса так и не разобрались.
CC>>Так что тоже стриминг P>Это всего лишь твой стример поддерживает файловые хранилища типа торрента.
Т.е. стриминг.
P>Стриминг прежде всего означает, что тебе не надо ничего хранить локально.
Т.е. всё, что можно слушать качая откуда то — стриминг. Т.е. торрент это тоже стриминг.
P>Но если ты начинаешь распространять его сам, это и есть пиратство.
Ты опять дофантазируешь то, чего не было.
Я ничего не распространяю.
Мне эта сказка про белого бычка уже надоела. Подветка помечена, ответов я не увижу.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали: S>>Хмм. Неужто и плавный зум обеспечит? CC>А нафига козе баян?
Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>Хмм. Неужто и плавный зум обеспечит? CC>>А нафига козе баян? S>Ну как бы PDF
В этой подветке обсуждается редактор txt файлов:
P>Потому, что написать редактор сраного текста на С/С++ намного сложнее
S>Поэтому рассуждения о том, что можно рендерить PDF
В этой подветке нет рассуждений о PDF.
S>отдают, ммм, неполным профессионализмом.
Чувак, ну ты бы хоть посмотрел на ветку, куда отвечаешь.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
P>>Вместо того, что бы глянуть и разобраться, ты выдаёшь какие то странные заключения. CC>Глянул, разобрался, мне не подходит.
Ну ок, не подходит. Что твой единичный пример говорит о состоянии дел в кроссплатформенной разработке?
Мы то говорили о наличии и причинах изменений.
P>>Сейчас люди поступают принципиально иначе CC>Да пусть хоть говно жрут, мне то до их заморочек какое дело?
Мы обсуждаем сосстояние кроссплатформенной разработки. Причины этих изменений следующие
1. изменение поведения пользователей. Очевидно, тут ты захочешь сказать "а у меня 20 лет ничо и не менялось"
2. изменение платформ и операционок, в частности, дикая фрагментация
3. чудовищная стоимость разработки, а пилить то надо см. п2 на 3-6 платформ, в зависимости от подхода.
Итого — прощ, дешевле, надежнее пилить кроссплатформенное приложение на веб-технологиях и обеспечить процентов 60-80% общего кода на все 3-6 платформ.
А если захочешь на С++ — см п3 и п2. Более того, нет сиплюсников на такие проекты, они все в нишах сидят, навроде твоей. Чем риски найма будешь затыкать?
P>> только ты все время переводишь разговор на себя. CC>Потому что мне надо решать мои задачи, способами которыми они таки решаются. Что там у других — мне слабо интересно.
Мы обсуждаем состояние дел в кроссплатформенной разработке.
P>>Ты снова переводишь вопрос на себя. CC>Потому что мне надо решать мои задачи.
Вероятно, ты забыл про что речь. Цитирую "Кроссплатформа — состояние на конец 2022"
P>>включаешь радио для этого же трека и слушаешь все, что подходит по направлению. P>>нет необходимости отслушивать материал CC>Взаимоисключающие параграфы detected
Отслушивать это значит целенаправлено сидеть, слушать, скипать как ты это описал — loop {meh skip}.
А можно просто в фоне включить и стриминговый сервис сделает всё сам за тебя.
P>>Это всего лишь твой стример поддерживает файловые хранилища типа торрента. CC>Т.е. стриминг.
Торрент от этого не станет стриминговым сервисом. Стриминг обеспечит само устройство, если умеет скачивать файлы и у него будет должный объем памяти, а торрент как был торрентом, так и останется.
P>>Стриминг прежде всего означает, что тебе не надо ничего хранить локально. CC>Т.е. всё, что можно слушать качая откуда то — стриминг. Т.е. торрент это тоже стриминг.
Расскажи, как в твоем торренте реализовать радио, лайвстрим и тд. Торрент это скачивание. Стриминг сервис принципиально умеет обходиться без такого скачивания.
Мне вот интересно, каким чудом ты сорганизуешь стриминг с торрента имея всего несколько килобайт доступного стораджа.
CC>Мне эта сказка про белого бычка уже надоела. Подветка помечена, ответов я не увижу.
Все ответы дадены. С кроссплатформеной разработки ты съехал на обсуждение себя и своих методов. Для тебя может и есть смысл, только мы тут за кроссплатформенную разработку.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Nuzhny, Вы писали:
N>>Системное и серверное ПО — отдельно, вот всякие мессенджеры — да, вполне S>Телеграм на C++/Qt написан. S>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.
Qt — хорошая вещь, но именно такие обычно не приживаются, побеждает отстой, хорошо заметно, как bowser applications всё вытесняют. И мобильный приложения, написанные не на каком-нибудь Cordova — всё большая редкость.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Потому что хром его даже на просмотр не смог загрузить P>>Ну разумеется. Он пытается вгрузить всё, а нужна частичная подгрузка и виртульный скроллинг. CC>Редактор в FAR, которому надо файл таки менять а не просто показывать, тем не менее справляется.
Не на 56мб а на весь файл в одну строку длиной в 56мб.
Ради интересу побырому, на коленке, сделал из своих гигабайтных csv 56метровый файлик в одну строку путём truncate и замены 0x0a -> 0x20, и открыл его в редакторе Far2 1807.
При открытии Far призадумался секунд так на десяток но потом таки открыл и всё показал, ProceXp показывал что всё это время он что то делал внутри colorer.dll.
Так что думается что у него там colorer своими регекспами пытался этот пц распарсить.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Там скорее с ОЗУ и/или производительностью узкое место. Иногда нет времени ждать, чем позволить себе больше памяти или ядер.
Если временно отключить Colorer, то редактор фары существенно бафает на произодительность.
В папке плагина FarColorer\bin есть hrcsettings.xml с настройками.
maxlinelength (5000) отвечает за максимальную длину строки, backparse (6000) за количество строк от начала.
Мне обычно приходилось их увеличивать дописыванием ноликов, чтобы красить длинные строки (500000) и многострочные файлы(600000).
Здравствуйте, akasoft, Вы писали:
A>Иногда нет времени ждать, чем позволить себе больше памяти или ядер.
Ээээ? чо?
A>Если временно отключить Colorer, то редактор фары существенно бафает на произодительность.
Как раз colorer там и жевал это всё.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Ээээ? чо?
Многие считают "зависло", если приложение не отвечает пару минут. Но дать приложению ядер, частоты или памяти многие не считают. А это напрямую влияет на "зависло".
CC>Как раз colorer там и жевал это всё.
Я знаю.
Здравствуйте, Sinclair, Вы писали: S>Хмм. Неужто и плавный зум обеспечит? С каких пор у нас TextOut и его друзья научились делать зум на 110% без рывков ширины?
Здравствуйте, Sinclair, Вы писали: M>>О каких рывках ширины ты сейчас говоришь? S>Выглядит неплохо. Это в каких кеглях выведено?
Это не в кеглях. У меня HDC MapMode в пикселях. И да, используется самый что ни на есть тупейший GDIшный TextOut. А кегли в пиксели пересчитать с учетом масштабирования даже третьекласник справится. Так что
S>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.
А эти рассуждения чем отдают?
ЗЫ некоторая неравномерность думаю объясняется тем, что я не брал проценты от текущего размера, а тупо в цикле уменьшал на константу.
ЗЫЫ GDI на самом деле весьма неплохо работает со шрифтами
ЗЫЫЫ Вывел с шагом *=0.97 — на самом деле — некоторая неравномерность таки есть, но имхо отрендерить PDF не помешает
Здравствуйте, Marty, Вы писали: M>Это не в кеглях. У меня HDC MapMode в пикселях. И да, используется самый что ни на есть тупейший GDIшный TextOut. А кегли в пиксели пересчитать с учетом масштабирования даже третьекласник справится.
Дело не в третьекласснике. Дело в конкретных размерах. Пусть будет в пикселах — какие параметры использовались? M>А эти рассуждения чем отдают?
Давайте сначала получим картинку. M>ЗЫЫ GDI на самом деле весьма неплохо работает со шрифтами M>ЗЫЫЫ Вывел с шагом *=0.97 — на самом деле — некоторая неравномерность таки есть, но имхо отрендерить PDF не помешает
Есть несколько нюансов. Возможно, они уже устранены, а я отстал от жизни, но это маловероятно. M>
Это, конечно, здорово, вот только размеры шрифта в десятки пикселов не очень интересны. Там более-менее любой растеризатор справится.
Попробуйте взять реалистичные размеры для чтения текста с экрана — ну, там, 6-7-8-9-10-11-12pt. И посмотрим, насколько линейно меняется ширина текста.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Marty, Вы писали:
M>ЗЫЫ GDI на самом деле весьма неплохо работает со шрифтами
Очень хорошо на самом деле, в разы лучше чем более новомодные реализации в DirectWrite
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Shmj, Вы писали:
S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
java ME
java Applet
java SE
java web start
java EE
все это уже было, помню кнопочную нокию.
ничего не тормозило. все летало.
не имея никакого опыта за пару дней собрал пару приложений
одно из них управляло мышкой на пк через блютуз.
Здравствуйте, Shmj, Вы писали:
S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Нужны наборы стандартных контролов уровня mvs хотя бы, и скорости на больших наборах данных.
Иначе вся эта хрень подходит только для онлайн магазинов и всякого такого, а разные там ansys, компас, солидворкс, 3dmax — Туда никогда не переедут.
Здравствуйте, Sinclair, Вы писали: M>>Это не в кеглях. У меня HDC MapMode в пикселях. И да, используется самый что ни на есть тупейший GDIшный TextOut. А кегли в пиксели пересчитать с учетом масштабирования даже третьекласник справится. S>Дело не в третьекласснике. Дело в конкретных размерах. Пусть будет в пикселах — какие параметры использовались?
Стало поприятнее S>Это, конечно, здорово, вот только размеры шрифта в десятки пикселов не очень интересны. Там более-менее любой растеризатор справится. S>Попробуйте взять реалистичные размеры для чтения текста с экрана — ну, там, 6-7-8-9-10-11-12pt. И посмотрим, насколько линейно меняется ширина текста.
Размер шрифта у меня float, пересчитывается в пиксели по курсу какой укажу
Скачки есть, но фатального ничего не вижу
Померял у себя на экране — размер 4 — 56 мм, размер 2.047 (по двойку только) — 28 мм
Здравствуйте, Marty, Вы писали:
M>Стало поприятнее
Ну, как я и ожидал — чудес не бывает.
S>>Это, конечно, здорово, вот только размеры шрифта в десятки пикселов не очень интересны. Там более-менее любой растеризатор справится. S>>Попробуйте взять реалистичные размеры для чтения текста с экрана — ну, там, 6-7-8-9-10-11-12pt. И посмотрим, насколько линейно меняется ширина текста.
M>Размер шрифта у меня float, пересчитывается в пиксели по курсу какой укажу
M>Скачки есть, но фатального ничего не вижу
И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство.
Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.
И когда вы делаете ей зум-фактор 80%, то пользователь ожидает, что все строчки станут короче на 20%, а не так, что кто-то — на 15%, а кто-то — на 22%. M>Померял у себя на экране — размер 4 — 56 мм, размер 2.047 (по двойку только) — 28 мм
Двукратное изменение размеров — нетрудное упражнение. Всегда сложнее сделать 95% так, чтобы это было именно 95%.
Почитайте классику: http://rastertragedy.com/
Именно поэтому Adobe рендерят текст сами, без помощи системы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Marty, Вы писали:
M>Перечитал доку — оказалось, что ANTIALIASED_QUALITY работает только если глобальная настройка в системе включена
Вроде как нет, по крайней мере при достаточно больших размерах шрифта ANTIALIASED_QUALITY делает края заметно сглажеными даже когда cleartype в системе выключен
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sinclair, Вы писали: M>>Стало поприятнее S>Ну, как я и ожидал — чудес не бывает.
Особо ничего не поменялось, просто отображение шрифтов стало более приятным глазу
S>>>Это, конечно, здорово, вот только размеры шрифта в десятки пикселов не очень интересны. Там более-менее любой растеризатор справится. S>>>Попробуйте взять реалистичные размеры для чтения текста с экрана — ну, там, 6-7-8-9-10-11-12pt. И посмотрим, насколько линейно меняется ширина текста. M>>Размер шрифта у меня float, пересчитывается в пиксели по курсу какой укажу M>>Скачки есть, но фатального ничего не вижу S>И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство. S>Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом. S>И когда вы делаете ей зум-фактор 80%, то пользователь ожидает, что все строчки станут короче на 20%, а не так, что кто-то — на 15%, а кто-то — на 22%. M>>Померял у себя на экране — размер 4 — 56 мм, размер 2.047 (по двойку только) — 28 мм S>Двукратное изменение размеров — нетрудное упражнение. Всегда сложнее сделать 95% так, чтобы это было именно 95%.
Я просто напомню:
S>Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
S>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.
Слушай, мне, если честно, хотелось спросить, что ты съешь — галстук или шляпу, но я не стал обострять, думал, до тебя дойдёт и ты сам признаешься в своей неправоте. Хотя бы и не публично, а для себя. Но ты сам полез в залупу.
Посиди с линейкой перед экраном, поизмеряй, посчитай-посравнивай.
S>Почитайте классику: http://rastertragedy.com/ S>Именно поэтому Adobe рендерят текст сами, без помощи системы.
Тебе никто не обещал, что GDI выдаст тебе в любом масштабе абсолютно идентичную картинку.
Но на GDI можно сделать рендерер PDF, и 99 процентов пользователей ничего не заметит по сравнению с адобовским.
S>Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
S>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.
S>Двукратное изменение размеров — нетрудное упражнение. Всегда сложнее сделать 95% так, чтобы это было именно 95%.
ЗЫ Понимаю, что требовать съесть шляпу от тебя — бесполезно
Здравствуйте, CreatorCray, Вы писали:
M>>Перечитал доку — оказалось, что ANTIALIASED_QUALITY работает только если глобальная настройка в системе включена CC>Вроде как нет, по крайней мере при достаточно больших размерах шрифта ANTIALIASED_QUALITY делает края заметно сглажеными даже когда cleartype в системе выключен
Согласен, на больших размерах GDI выглядит лучше, чем GDI+, в котором я не сделал
S>>Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
S>>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.
M>Слушай, мне, если честно, хотелось спросить, что ты съешь — галстук или шляпу, но я не стал обострять, думал, до тебя дойдёт и ты сам признаешься в своей неправоте. Хотя бы и не публично, а для себя. Но ты сам полез в залупу.
M>Посиди с линейкой перед экраном, поизмеряй, посчитай-посравнивай.
Ну что за детский сад — экран, линейка.
Берём текст, берём шрифт, берём GetTextExtentPoint32.
Сравниваем:
Текст
Width, Times New Roman 12pt
Width, Times New Roman 24pt
Ratio
Delta
The Quick Brown Fox Jumps over the Lazy Dog
295
612
2.08
22px
Иван Родил Девчонку, Велел Тащить Пелёнку.
320
647
2.02
7px
The Text Width сan Vary Quite Dramatically
269
569
2.12
31px
M>Тебе никто не обещал, что GDI выдаст тебе в любом масштабе абсолютно идентичную картинку.
Хм. Вот эта табличка иллюстрирует мою цитату, которую вы любезно привели выше. Вы готовы привести формулу для ширины текста в 24 кегле, основываясь на его ширине в 12м?
M>Но на GDI можно сделать рендерер PDF, и 99 процентов пользователей ничего не заметит по сравнению с адобовским.
Прекрасно заметят, когда текст, который был выровнен, начнёт плавать при кручении колёсика зума.
M>
S>>Ну как бы PDF требует выводить текст не абы как, а WYSIWYG. И если вы показываете страничку в 50% зуме, то ожидается, что у неё границы слов будут там же, где и в 100%, а не как в TextOut, где ширина текста 24 кеглем не связана сколь-нибудь приемлемой формулой с шириной текста 12 кеглем.
S>>Поэтому рассуждения о том, что можно рендерить PDF просто выплёвывая строчки в TextOut отдают, ммм, неполным профессионализмом.
M>
S>>Двукратное изменение размеров — нетрудное упражнение. Всегда сложнее сделать 95% так, чтобы это было именно 95%.
M>ЗЫ Понимаю, что требовать съесть шляпу от тебя — бесполезно
Нет, отчего же. Но для начала нужно всё-таки опровергнуть моё утверждение
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, c-smile, Вы писали:
CS>Т.е. HTML там испоьзуется как layout manager и одновременно рисовальщик статиков : текста, картинок и пр. CS>Как резюме: реалистично говорить о кросплатформе в кторой 70-90% кода шарится между платформами. CS>!00% серебрянной пули нет по условиям задачи
А в это время Unity спокойно шарашит на все мыслимые платформы даже в html.javascript...
Здравствуйте, akasoft, Вы писали:
CC>>Ээээ? чо? A>Многие считают "зависло", если приложение не отвечает пару минут. Но дать приложению ядер, частоты или памяти многие не считают. А это напрямую влияет на "зависло".
Так и представляю — подзавис фар, встал и пошел покупать другой ноутбук, раза в два дороже.
Здравствуйте, Marty, Вы писали:
M>Тебе никто не обещал, что GDI выдаст тебе в любом масштабе абсолютно идентичную картинку. M>Но на GDI можно сделать рендерер PDF, и 99 процентов пользователей ничего не заметит по сравнению с адобовским.
На самом деле — наоборот. Рендерер сделать можно — их полно, только вот страница будет выглядеть совсем иначе. У адоба читать страницу очень легко, глаза не устают. А вот в рендерере где страница сделана через textout, читать неприятно, устаёшь уже через пару минут.
Акробат умеет менять масштаб на 1%, а вот у тебя точно видно, что этого нет и не будет в обозримом будущем.
Здравствуйте, Pauel, Вы писали:
P>Так и представляю — подзавис фар, встал и пошел покупать другой ноутбук, раза в два дороже.
И такое бывает.
Приходят, жалуются, система лагает, сёрфинг тупит, 3d max не едет, полечи. Смотришь, а там 2 ядра 4Г памяти.
Здравствуйте, Pauel, Вы писали: P>Акробат умеет менять масштаб на 1%, а вот у тебя точно видно, что этого нет и не будет в обозримом будущем.
Без шансов. Коллега нахамил, а когда его ткнули носом в неудачный результат, убежал обратно в политику.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство. S>Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.
Редакторы верстают страницы в памяти без всякого GetTextExtentPoint32 и им подобных тормозных вызовов, ес-но.
Один раз кешируются размеры глифов символов шрифта данного размера под некий высокий DPI (стандартом в вёрстке журналов на тот момент было, вроде, 300 DPI), причём, этот размер фиксирован для каждого символа конкретного абзаца, поэтому, вёрстка в памяти происходит точно. Текст в памяти был представлен 16-тибитными индексами соотв.глифов из кеша (ага, в старых Вордах более 64к вариантов глифов в одном док-те не получалось).
А вот вёрстка на экране может быть уже не столь точной, ес-но.
Только это не заметно, т.к. при выравнивании по ширине играют шириной пробелов, поэтому правый край будет выровнен.
А при отсутствии выравнивания (допустим, нет выравнивания справа) — оно и вовсе незаметно, т.к. не с чем сравнить, если все строки имеют разную ширину.
При печати же обычно оперируют другим DPI (300, 600, 1200) и там точность получше экранных 96 DPI.
В общем, вы обсуждаете ту проблему, которой в реальности для редакторов текста никогда не существовало.
Взять даже текст в таблице, при некотором масштабе символы на экране могут соприкасаться с линиями-границами ячеек, но работавшим на старых мониторах обычно было понятно, что вывод на экран оперирует невысоким разрешением, и что округление происходит грубо.
В те годы за компами вообще дураков было поменьше. ))
В конце 90-х пошли уже "бытовые" (т.е. дешевые) лазерные принтеры с разрешением 600 DPI и струйные 1200 DPI, тут уже последним дуракам стало ясно, что на печати текст выглядит вовсе не как на экране, а в разы чётче. А на экране для проверки некоей области док-та его просто просматривали под нужным увеличением.
Здравствуйте, Sinclair, Вы писали:
M>>Но на GDI можно сделать рендерер PDF, и 99 процентов пользователей ничего не заметит по сравнению с адобовским. S>Прекрасно заметят, когда текст, который был выровнен, начнёт плавать при кручении колёсика зума.
Каким образом?
Это надо чтобы текст был без пробелов?
Тогда это, скорее всего, одинаковый текст в строках, т.е. строки будут идентичными при любом зуме.
Здравствуйте, vdimas, Вы писали: V>Каким образом?
Очень простым. V>Это надо чтобы текст был без пробелов?
Не обязательно. Достаточно просто пользоваться TextOut. V>Тогда это, скорее всего, одинаковый текст в строках, т.е. строки будут идентичными при любом зуме.
Не обязательно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство. S>>Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.
V>Редакторы верстают страницы в памяти без всякого GetTextExtentPoint32 и им подобных тормозных вызовов, ес-но. V>Один раз кешируются размеры глифов символов шрифта данного размера под некий высокий DPI (стандартом в вёрстке журналов на тот момент было, вроде, 300 DPI), причём, этот размер фиксирован для каждого символа конкретного абзаца, поэтому, вёрстка в памяти происходит точно. Текст в памяти был представлен 16-тибитными индексами соотв.глифов из кеша (ага, в старых Вордах более 64к вариантов глифов в одном док-те не получалось).
Это бесценная информация об устройстве Word, особенно, если она правдива.
То, что в режиме редактирования приходится идти на компромиссы — общеизвестно.
Но при отображении PDF такие вольности себе позволять нельзя. Попробуйте открыть в акробате любой документ и покрутите зумом — вы убедитесь, что интервалы между словами вовсе не плавают. Как это было бы, если бы акробат делал так, как вы предлагаете — компенсировал рывки ширины глифов изменением размера пробелов.
Вы лучше ответьте на вопросы про индексы — я жажду знаний про уникальность time-series, и про отличия n-tree от B-tree.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
P>>У адоба читать страницу очень легко, глаза не устают.
V>Наоборот, на мониторах с плохим разрешеним читать PDF в Акробате было невозможно из-за мылкости. V>Зато в Ворде — читабельно.
Типичный монитор он с хорошим разрешением. Напомню — сегодня почти 2023й год.
Где найти тот, что с плохим- не представляю.
Здравствуйте, Sinclair, Вы писали:
S>Но при отображении PDF такие вольности себе позволять нельзя. Попробуйте открыть в акробате любой документ и покрутите зумом — вы убедитесь, что интервалы между словами вовсе не плавают.
Ес-но, поэтому текст в Акробате такой мылкий на мониторах с невысоким разрешением, поэтому такой трудночитабельный.
Но речь шла о редакторах, и там техника относительно проста.
Одно время было достаточно инфы о представлении данных в редакторах текста, об индексировании глифов и наличии в АПИ операционок ф-ий по выводу цепочек глифов (в X11 и в Windows GDI такие АПИ присутствуют, в новом АПИ WinRT, которая начиная с Win8, — тоже).
И ничего с тех пор не изменилось — примерно так же обстоят дела в библиотеке рендеринга FB2/FB3, разработанной русскими программистами — никакой мылкости.
Т.е. в приоритете чёткость изображений букв, а не попиксельная точность вёрстки.
S>Как это было бы, если бы акробат делал так, как вы предлагаете — компенсировал рывки ширины глифов изменением размера пробелов.
Эта особенность была не только Акробате, но и в другой популярной на тот момент проге по верстке печатного материала — в Word Press.
И все прекрасно понимали, почему так — потому что это инструмент для вёрстки, а не для работы над текстом.
Текстовые блоки помещались в Word Press уже в готовом виде.
В то время как MS Word — это text processor.
Соотв, приоритеты расставлены чуть иначе — чёткость изображений букв на первом месте.
Я вообще ХЗ о чём тут спор, это же азы любой инженерии — анализ сценариев, постановка задачи.
Плюс, приоритет задач по верстке печатного материала уже давно достаточно низкий, т.к. сейчас всё больше инфы живёт онлайн, и браузеры ведут себя примерно как MS Word. ))
S>Вы лучше ответьте на вопросы про индексы — я жажду знаний про уникальность time-series, и про отличия n-tree от B-tree.
Если бы ты не кривлялся там, а был настроен на предметный разговор, я бы читал твои ответы.
Но как только опять начинаешь маяться хернёй — просто облом тратить время, бо а смысл?
Я там допустил только одну ошибку — в оценке размера реального дерева, на основе бинарного, которое со сжатией информации.
Оно там оценочного размера N/K, где K порой достаточно большое, а не log N.
Но это несущественная неточность, т.к. мы рассуждали о сжатии информации и оно, существенное сжатие, всё-равно присутствует.
Здравствуйте, vdimas, Вы писали:
V>Эта особенность была не только Акробате, но и в другой популярной на тот момент проге по верстке печатного материала — в Word Press. V>И все прекрасно понимали, почему так — потому что это инструмент для вёрстки, а не для работы над текстом.
Ну, то есть коненсус. Ок.
V>Если бы ты не кривлялся там, а был настроен на предметный разговор, я бы читал твои ответы. V>Но как только опять начинаешь маяться хернёй — просто облом тратить время, бо а смысл? V>Я там допустил только одну ошибку — в оценке размера реального дерева, на основе бинарного, которое со сжатией информации.
Размер реального дерева, хоть бинарного, хоть B-дерева, это O(N) от исходных данных. V>Оно там оценочного размера N/K, где K порой достаточно большое, а не log N.
Ну, то есть логарифма нет. V>Но это несущественная неточность, т.к. мы рассуждали о сжатии информации и оно, существенное сжатие, всё-равно присутствует.
Непонятно, о каком сжатии идёт речь.
На всякий случай напомню, что в обычном дереве ровно столько ссылок на сами данные, сколько записей в исходных данных.
Ваша идея про то, что можно одной ссылкой из дерева сослаться сразу на X записей исходных данных, в целом верна, хоть и лажает в деталях.
Например, кластерные индексы в MS SQL именно так и устроены — только они не зависят от наличия непрерывных диапазонов в значениях первичного ключа в исходных данных. Достаточно простой упорядоченности.
Просто "листьями" кластерного индекса являются сами страницы данных. Т.е. они тоже являются частью дерева, и никакого "сжатия" не происходит — в частности, алгоритмы split/merge при вставке и удалении записей применяются не только к branch-нодам, но и к страницам данных. И, тоже в частности, если таблица с кластерным индексом целиком влезает в одну страницу, то никаких дополнительных страниц на индекс не выделяется — сама эта страница и является корнем индекса. Если считать по вашей методике, это означает бесконечный "коэффициент сжатия" — нулевой размер "индекса" при ненулевом размере данных.
А если считать по общепринятой, то по-прежнему имеем O(N).
Страницы предыдущего уровня в ссылках на страницы данных никаких "длин диапазонов" не хранят — достаточно просто хранить PageRef на страницу данных и минимальное значение ключа на ней. Это позволяет увеличить branch factor по сравнению с вашей идеей.
Для time series, которые вам кажется удобно хранить просто в виде "отсортированного списка" напомню, что поиск по B-дереву всё ещё эффективнее бинарного поиска по отсортированному массиву, даже если его удалось поднять в память одним непрерывным блоком — из-за локальности кэша. Так что никаких отдельных "time-series" индексов не существует за ненадобностью.
Про мелкие ошибки в виде забытых значений ключей в branch-страницах B-дерева я уже и вовсе молчу — это можно списать на опечатки при наборе.
Самое главное-то в том, что PGM индекс по-прежнему уделывает B-деревья, эффективнее которых для диапазонных запросов за предыдущие 30+ лет ничего не придумали.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>На всякий случай напомню, что в обычном дереве ровно столько ссылок на сами данные, сколько записей в исходных данных.
И кто мешает дорабатывать структуры данных?
S>Ваша идея про то, что можно одной ссылкой из дерева сослаться сразу на X записей исходных данных, в целом верна, хоть и лажает в деталях.
Нет там никакой лажи, натуральная физическая сортировка записей по первичному ключу вводится в БД именно за этим.
S>Например, кластерные индексы в MS SQL именно так и устроены — только они не зависят от наличия непрерывных диапазонов в значениях первичного ключа в исходных данных. Достаточно простой упорядоченности.
Да, в терминах MS SQL этот индекс назвали "кластерным".
От замечания про прерывность или непрерывность диапазонов поржал, конечно.
Ты разве не в курсе про самые первые алгоритмы сжатия графики в GIF и ICO форматах?
Непрерывные последовательности пикселов одинакового цвета кодируются одной записью.
Понятно, что таких записей будет больше, если "диапазоны" прерываются.
Подобные способы сжатия информации — одни из очевиднейших, используются со времён царя Гороха.
И тут ты даёшь ссылки на "новейшее исследование" по давно известному. ))
В общем, опять попёр от тебя примитив какой-то, опять резко стало скучно, дальше не читал...
Здравствуйте, Sinclair, Вы писали:
V>>Чем не устроил ExtTextOut? S>Он с точки зрения обсуждаемых вопросов ничем от TextOut не отличается.
Отличается принципиально — вёрстка документа выполняется не ср-вами GDI в момент вывода текста (где GDI TextOut вынужден каждый раз расчитывать лейаут выводимого текста перед прорисовкой, отчего тормоза), а эта вёрстка выполняется предварительно в некоей "виртуальной" модели док-та и, с т.ч. задач отображения, статична.
Именно поэтому даже старенькие Ворды довольно шустро листали док-т (т.е. шустро обновляли его изображение на экране), что задача вёрстки была отделена от задачи отображения.
Ты это упустил в рассужениях, поэтому лажал. ))
Если бы помнил о таком разделении, то с полутыка догадался бы, что "виртуальная вёрстка" в памяти происходит точно, а на экране отображается с учётом допущений, связанных с низким разрешением экрана, где приоритет был отдан чёткости изображения букв перед позиционированием.
Плюс мои рассуждения про отыгрывание выравнивания пробелами, в общем, задача отобразить док-т достаточно точно не выглядела неразрешимой — выравнивание по правому и левому краях в Ворде и других редакторах всегда было идеальным. Поэтому спор заведомо бестолковый.
Здравствуйте, Sinclair, Вы писали:
V>>Текст в памяти был представлен 16-тибитными индексами соотв.глифов из кеша (ага, в старых Вордах более 64к вариантов глифов в одном док-те не получалось). S>Это бесценная информация об устройстве Word, особенно, если она правдива.
Кстате, в какой-то момент они перешли на прорисовку ср-вами DirectX.
Вряд ли это было ускорения ради, т.к. ср-вами GDI шрифты рисовались драйверами этого GDI более чем эффективно.
Думаю, это была попытка обойти ограничение на 16-битные индексы глифов в GDI, бо в DX можно кешировать произвольное кол-во глифов.
А всякие 3D эффекты текста и плоских фигур появились после перехода на DirectX, ИМХО, "потому что теперь так можем". ))
Здравствуйте, vdimas, Вы писали:
V>Отличается принципиально — вёрстка документа выполняется не ср-вами GDI в момент вывода текста (где GDI TextOut вынужден каждый раз расчитывать лейаут выводимого текста перед прорисовкой, отчего тормоза), а эта вёрстка выполняется предварительно в некоей "виртуальной" модели док-та и, с т.ч. задач отображения, статична.
Вы сейчас про параметр lpDx? Не вполне улавливаю ход вашей мысли.
V>Именно поэтому даже старенькие Ворды довольно шустро листали док-т (т.е. шустро обновляли его изображение на экране), что задача вёрстки была отделена от задачи отображения.
Ну, если честно, то нет, не шустро. Когда я свой диплом бакалавра верстал в Word 2.0, то перелистывание страницы (PgDn) в нём занимало около 40 секунд, на 486 машинке.
V>Плюс мои рассуждения про отыгрывание выравнивания пробелами, в общем, задача отобразить док-т достаточно точно не выглядела неразрешимой — выравнивание по правому и левому краях в Ворде и других редакторах всегда было идеальным. Поэтому спор заведомо бестолковый.
Вот тут согласен.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Отличается принципиально — вёрстка документа выполняется не ср-вами GDI в момент вывода текста (где GDI TextOut вынужден каждый раз расчитывать лейаут выводимого текста перед прорисовкой, отчего тормоза), а эта вёрстка выполняется предварительно в некоей "виртуальной" модели док-та и, с т.ч. задач отображения, статична. S>Вы сейчас про параметр lpDx? Не вполне улавливаю ход вашей мысли.
TextOut должен унутре вызвать GetTextAlign, GetObject, GetCharacterPlacement, затем внутренний аналог ExtTextOut.
1. Жуткие тормоза.
2. Управлять позиционированием символов никак.
3. Сколько в строке содержится разных начертаний шрифта или разных шрифтов — столько раз при каждой их смене вдоль строки надо вызвать эту ф-ию.
В отличие от, ExtTextOut сразу переходит к прорисовке с поданными координатами символов (координаты можно подавать по x, либо по xy, в зависимости от флагов).
За один раз можно вывести абзац, состоящий из разных шрифтов.
И не надо вычислять лейаут каждый божий раз.
И вообще, лейаут док-та в процессе редактирования вычисляется весьма эффективно, потому что каждый блок имеет относительные от родителя координаты.
Пересчёт лейаута довольно тяжеловесный при изменениях, касающихся всего док-та, например, при изменении полей.
V>>Именно поэтому даже старенькие Ворды довольно шустро листали док-т (т.е. шустро обновляли его изображение на экране), что задача вёрстки была отделена от задачи отображения. S>Ну, если честно, то нет, не шустро. Когда я свой диплом бакалавра верстал в Word 2.0, то перелистывание страницы (PgDn) в нём занимало около 40 секунд, на 486 машинке.
Какая забавная чушь.
Аж рассмеялся от неожиданности.
На моей 286-й 20 MHz, 8 метров оперативы в Windows 2.11 в 1994-м году страница перелистывалась менее секунды.
На соседней 386-й 27 MHz страница листалась примерно с идентичной скоростью.
И откуда ты в своём бакалавриате взял Word 2.0, если на тот момент уже можно было достать только 6.0 или 7.0?
А главное, даже если достал откуда-то 2.0 — то нафига? ))
И да, скорость листания не зависела от размера док-та, диплом тянул легко.
При том что у системотехников дипломы обычно чуть увесистей, чем на других направлениях, т.к. включают достаточно много исходников с пояснениями, блок-схем алгоритмов и прочее.
Разве что на той 486-й стояла древняя картейка VGA (даже не XGA) без 2D ускорителя?
У вас там какой-нить хитрый техник спёр картейку с ускорителем домой, подменив на шлак конца 80-х? ))
На моей 286-й стоял ускоритель, то ли ATI Mach 32, то какой еще, не помню точно картейку именно на 286-м, но это не принципиально, бо почти все они тогда были совместимы с 8514, который являлся де-факто стандартом для ускорителей 2D графики в первой половине 90-х.
Когда у тебя был бакалавриат, тогда уже ускорители просто летали, причём уже со встроенным 3D, уже пошли S3, 3dfx, ATI Rage.
Здравствуйте, vdimas, Вы писали:
V>И откуда ты в своём бакалавриате взял Word 2.0, если на тот момент уже можно было достать только 6.0 или 7.0?
Не в бакалавриате, а в 94м году. Скажем, в нашей общаге в Минске(1200 человек) в конце 95го года было ровно три компа, один их которых в нашей комнате. Софта для компов было кот наплакал, и пользовались древними вещами времён 80х. Word 2.0 — именно оттуда, это мсдос версия.
V>А главное, даже если достал откуда-то 2.0 — то нафига? ))
Я добавлю к словам Синклера, что не только Ворд 2.0 медленно листал, а многие редакторы, которые пытались вручную прорисовывать шрифты, тоже медленно листали. К 6му ворде всё стало быстро — за счет аппаратного ускорения, которое в мсдос просто отсутствовало. Но надо учитывать не только поколение процессора, но и частоту, sx/dx, шину и перформанс видеокарты, и объем доступной памяти.
V>И да, скорость листания не зависела от размера док-та, диплом тянул легко.
А я помню,что вордом то и не пользовался из за его тормозов до конца 90х где то.
V>Разве что на той 486-й стояла древняя картейка VGA (даже не XGA) без 2D ускорителя?
МСДОС.
V>Когда у тебя был бакалавриат, тогда уже ускорители просто летали, причём уже со встроенным 3D, уже пошли S3, 3dfx, ATI Rage.
V>Поэтому — не верю! (С)
Здравствуйте, vdimas, Вы писали:
P>>Типичный монитор он с хорошим разрешением. Напомню — сегодня почти 2023й год.
V>Сам себе противоречишь — с хорошим монитором и у MS Word позиционирование точнее.
У нас некий вдимас вещает про разрешение. Читаем вместе:
P>У адоба читать страницу очень легко, глаза не устают.
Наоборот, на мониторах с плохим разрешеним читать PDF в Акробате было невозможно из-за мылкости.
Зато в Ворде — читабельно.
V>У 24" — 91.
Я в 11м году купил HP z24 1920x1200. Читать в адобе было одно удовольствие, даже мелкий текст. Аналогичного размера шрифт в ворде, ну, мягко говоря, так себе — глаза устают. С 13го по 17й годы у меня был проект — специализированый ридер. Я столько всего сравнил с адобом, что перечислять вспотею. И ни один рендерер на моем мониторе к этому адобу вплотную не приблизился, да собственно и на других мониторах/таблетках/телефонах тоже. Монитор продал ажно в этом году, кстати говоря.
Ближе всего был фоксит, но и он далековато от адоба.
Здравствуйте, Pauel, Вы писали:
P>Не в балакавриате, а в 94м году. Скажем, в нашей общаге в Минске(1200 человек) в конце 95го года было ровно три компа, один их которых в нашей комнате. Софта для компов было кот наплакал, и пользовались древними вещами времён 80х. Word 2.0 — именно оттуда, это мсдос версия.
В Белоруссии границы дырявыми не были? ))
У нас в 1995-м бывало в некоторых комнатах общаги по 2-3 компа, а общая сетка в общаге была уже в 1994-м.
В 1996-м году уже был выход в интернет, а студенты вовсю рубились в кваку по общажной сети.
Дефицит машинного времени на IBM-совместимых компах лично я последний раз ощущал в 93-м году.
Хотя, спокойно компенсировал ДВК-4, для моей основной работы на кросс-асме с эмулятором микроконтроллера они показывали себя лучше чем IBM AT.
Что касается версий Word, то напутал ты порядочно.
Word 2.0 for DOS был выпущен в 1985-м, работал в текстовом режиме, был у нас крайне непопулярен, т.к. входу был более мощный Лексикон, тоже работающий в текстовом режиме, в котором я редактировал почти все тексты примерно до 94-го, пока окончательно не перелез на графику.
В 1994-м году уже все сидели на Word 6.0, но нужна была Win 3.11 для рабочих групп.
До этого был Word 2.0 for Windows от 1991-го, который прекрасно пахал на моей 286-й, которой обзавёлся в 1994-м (первый купленный за свои деньги абсолютно новый комп, стоил порядка $500 в конфигурации 20 MHz, 8 MB RAM, 520 MB HD).
Особенностью офиса было то, что активнее всего шло развитие его GUI-приложений под Мак.
MS Word там был уже в версии 5.0, и так получилось, что следующая версия в 1993-м вышла в том числе под Windows, т.е. конкретно в виндах был прыжок версий от 2.0 до 6.0.
Собсно, с версии 6.0 MS Word стал стандартом текстового процессора де-факто.
V>>А главное, даже если достал откуда-то 2.0 — то нафига? )) P>Я добавлю к словам Синклера, что не только Ворд 2.0 медленно листал
Синклер или забыл, или ему подменили карту.
Он говорит уже о временах после 1995-го, а в эти годы НЕ БЫЛО 486-х без графического ускорителя.
Поэтом я я там предположил, что у них там в ВУЗ-е (или где еще) какой-то хмырь-лаборант-техник тупо спионерил родную графическую карту себе домой, подменив на шлак из середины 80-х.
P>а многие редакторы, которые пытались вручную прорисовывать шрифты, тоже медленно листали. К 6му ворде всё стало быстро — за счет аппаратного ускорения, которое в мсдос просто отсутствовало.
Не могу ничего сказать про GUI редакторы под DOS, т.к. не пользовался.
Зато под Windows тектовые редакторы листали и прорисовывали текст шустро даже на 286-й.
Word был достаточно тяжеловесен, запускался некоторое время.
Зато Writer запускался мгновенно (предшественник WordPad), и для большинства случаев RTF-текста было достаточно.
P>Но надо учитывать не только поколение процессора, но и частоту, sx/dx, шину и перформанс видеокарты, и объем доступной памяти.
Я уверен, Синклер всё-равно привирает, даже если там была VGA-карта от 1985-х годов, потому что на тот момент разница быстродействия аппаратной и софтовой графики была еще не столько катастрофической. В единицы секунд еще поверю (меньше 5), в 40 секунд — нет.
V>>И да, скорость листания не зависела от размера док-та, диплом тянул легко. P>А я помню,что вордом то и не пользовался из за его тормозов до конца 90х где то.
Под DOS? ))
Ты как из параллельной вселенной вещаешь...
Я уже вовсю делал сложные приложухи на MS Access в 1997-м на втором пне 233 MHz.
Word там давно просто летал.
Как и MS Access.
Да и вообще, тогда развитие IT шло семимильными шагами, каждый год как эпоха.
Первые эксперименты с написанием GUI-приложений на WinAPI я делал еще в 1994-м, а в 1996-м запросто уже делал свои ActiveX-контролы на плюсах, уже инструментарий был вполне адекватным, и эти ActiveX до MS Access пользовал в приложениях на VisualBasic, который использовался как "клей верхнего уровня", типа современных скриптовых движков, хотя был на самом деле компиллируемый в нейтив (не путать с p-машинкой VBA) и в strict-режиме типизации давал весьма эффективный код, т.е. даже лучше, чем когда обыгрывать COM-объекты на плюсах на смарт-поинтерах, т.к. на смарт-поинтерах были избыточные парные AddRef/Release, а компилятор VB эту избыточность запросто убирал.
V>>Разве что на той 486-й стояла древняя картейка VGA (даже не XGA) без 2D ускорителя? P>МСДОС.
Для тех годов на 486-й — чушь.
V>>Когда у тебя был бакалавриат, тогда уже ускорители просто летали, причём уже со встроенным 3D, уже пошли S3, 3dfx, ATI Rage. V>>Поэтому — не верю! (С) P>Ты привык сочинять, думаешь и все так делают?
Ты бредишь, реально.
Рассказываешь о конце 90-х как о начале 90-х, а там уже 3 полноценных поколения техники и ПО сменились.
Здравствуйте, Pauel, Вы писали:
P>Я в 11м году купил HP z24 1920x1200. Читать в адобе было одно удовольствие, даже мелкий текст. Аналогичного размера шрифт в ворде, ну, мягко говоря, так себе — глаза устают.
Это у тебя со зрением что-то ))
Или забыл включить Clear Type.
Здравствуйте, vdimas, Вы писали:
P>>Я в 11м году купил HP z24 1920x1200. Читать в адобе было одно удовольствие, даже мелкий текст. Аналогичного размера шрифт в ворде, ну, мягко говоря, так себе — глаза устают.
V>Это у тебя со зрением что-то )) V>Или забыл включить Clear Type.
Здравствуйте, vdimas, Вы писали:
P>>Не в балакавриате, а в 94м году. Скажем, в нашей общаге в Минске(1200 человек) в конце 95го года было ровно три компа, один их которых в нашей комнате. Софта для компов было кот наплакал, и пользовались древними вещами времён 80х. Word 2.0 — именно оттуда, это мсдос версия.
V>В Белоруссии границы дырявыми не были? ))
Винду в универе увидел первый раз после 95го или 96го.
V>У нас в 1995-м бывало в некоторых комнатах общаги по 2-3 компа, а общая сетка в общаге была уже в 1994-м. V>В 1996-м году уже был выход в интернет, а студенты вовсю рубились в кваку по общажной сети.
И ты решил, что так у всех должно было быть?
V>Дефицит машинного времени на IBM-совместимых компах лично я последний раз ощущал в 93-м году.
А у нас это было где то до 97го
P>>Я добавлю к словам Синклера, что не только Ворд 2.0 медленно листал
V>Синклер или забыл, или ему подменили карту. V>Он говорит уже о временах после 1995-го, а в эти годы НЕ БЫЛО 486-х без графического ускорителя.
По твоему, 94 был после 95го?
V>Не могу ничего сказать про GUI редакторы под DOS, т.к. не пользовался.
Ну так ворд 2.0 первым вышел под мсдос и там не было никакого ускорения.
V>Я уверен, Синклер всё-равно привирает, даже если там была VGA-карта от 1985-х годов, потому что на тот момент разница быстродействия аппаратной и софтовой графики была еще не столько катастрафической. В единицы секунд еще поверю (меньше 5), в 40 секунд — нет.
А кто мешает тебе уточнить, что именно он имеет ввиду?
V>Под DOS? ))
Именно.
V>Ты как из параллельной вселенной вещаешь...
Да, я помню твою телепатию про кофе-машины у меня за углом.
V>Я уже вовсю делал сложные приложухи на MS Access в 1997-м на втором пне 233 MHz. V>Word там давно просто летал. V>Как и MS Access.
И что это говорит про ворд 2.0 в мсдос?
V>Первые эксперименты с написанием GUI-приложений на WinAPI я делал еще в 1994-м
А я писал в основном на ассемблере под мсдос года до 2000го.
Здравствуйте, Pauel, Вы писали:
V>>В Белоруссии границы дырявыми не были? )) P>Винду в универе увидел первый раз после 95го или 96го.
Т.е. первая виденная винда была уже 95-я?
А специальность какая?
У нас "..., системы, сети", 2201.
Уже в 1993-м в лабах кафедры вовсю протягивали сетку на основе серваков Novell NetWare, рабочие станции Windows 3.11 для рабочих групп.
Одно из самых ярких воспоминаний — на сетевой диск инфа сохранялась намного быстрее, чем на локальный жёсткий диск, т.е. практически мгновенно.
В 94-м году уже вовсю разворачивали сетевые службы на основе Windows NT.
Никакого IP тогда, понятно, сетка была IPX.
V>>У нас в 1995-м бывало в некоторых комнатах общаги по 2-3 компа, а общая сетка в общаге была уже в 1994-м. V>>В 1996-м году уже был выход в интернет, а студенты вовсю рубились в кваку по общажной сети. P>И ты решил, что так у всех должно было быть?
Я решил обратное, бо видел обратное, что у нас захолустье, а в том же Харькове или Киеве всё было чуть интересней.
С другой стороны, первые крупные городские сетки в Севастополе появились как объединения самопальных сетей из жилых кварталов, где эти сетки прокидывали просто энтузиастами.
Я сам кабель коаксиал тянул в два соседних дома как-то. ))
Поэтому, из-за особенности "толкания" реальности энтузиастами, в Севастополе приличная общегородская сеть появилась одной из первых.
V>>Дефицит машинного времени на IBM-совместимых компах лично я последний раз ощущал в 93-м году. P>А у нас это было где то до 97го
Ну да, эффект закрытых границ.
Зато у вас всегда было что пожрать и что носить.
Я в Белоруссии в 94-95-х годах жрал от пуза в кафешках почти за бесценок, по нашим меркам.
А к нам везли б/у технику составами примерно до 93-го года.
Причём, в те годы устаревшее б/у — это которому пару лет от силы, бо всё слишком быстро менялось.
Иногда и вовсе годичной давности.
Размен б/у технологий на холодильник.
Примерно к 93/94-м годам случился перелом, стали завозить в основном комплектующие и собирать компы здесь.
Никто никогда у нас не покупал готовый комп от лейбла, брали всегда рассыпуху (материнка, проц, память, диски, графика) и собирали в корпусе.
А корпуса уже давно делали на месте.
Мой 286-й был уже новенький, местной сборки.
И это было последнее самое продвинутое поколение 286-х.
Вкладываться в более дорогую технику не стал по двум соображениям:
— лишние 300 бакинских для студента на дороге не валялись;
— бессмысленность вложений из-за быстрого устаревания техники в те годы.
Мои задачи комп покрывал более чем, а работал заметно шустрее многих 386-х, потому что я взял быстрый диск с большим кешем (всего 20 бакинских разница цены диска).
В общем, когда собираешь технику с пониманием или без — разные вещи. ))
Монитор мне достался бесплатно нерабочий EGA, я ему перемотал обмотку блока отклонения на частоты VGA и прекрасно пользовался.
Качество ЭЛТ-мониторов зависело от размера зерна, и это зерно не было кратно разрешению, в отличие от LCD, а зерно там было OK для VGA.
В общем, голь на выдумки хитра, все "увлеченные" изворачивались как могли.
И что характерно, у кого были богатые папики, которые покупали новейшие 486-е своим чадам (сокурсникам), из тех вменяемым спецом никто так и не стал.
Хотя, одно время в дисциплине "продвинутый пользователь" важно опережали, конечно. ))
Один, вроде бы совсем со светлой головой скатился во второй половине 90-х на админа юнихов, а потом и вовсе бросил IT, стал фотографом.
А подавал нехилые надежды, как грится.
Халява расслабляет! ))
V>>Синклер или забыл, или ему подменили карту. V>>Он говорит уже о временах после 1995-го, а в эти годы НЕ БЫЛО 486-х без графического ускорителя. P>По твоему, 94 был после 95го?
У него бакалавриат был в 96-м, если не ошибаюсь.
Но в 94-м тоже не было 486-х без ускорителя.
Это у него было что-то не то, кто-то нахимичил, причём, нахимичил по-тупому. ))
Потому что не было смысла экономить на спичках (цена картейки), угробливая мощщу дорогущего 486-го.
V>>Не могу ничего сказать про GUI редакторы под DOS, т.к. не пользовался. P>Ну так ворд 2.0 первым вышел под мсдос и там не было никакого ускорения.
При чём тут проги из 80-х годов и середина 90-х? ))
Мы все сидели на пиратках, в середине 90-х уже давно у всех (у очень многих так точно) в компах стояли CD-W/R, этого пиратского софта было хоть попой ешь самого новейшего.
Поэтому, я в упор не понимаю, какой был смысл пользоваться неактуальным софтом?
Всё еще склоняюсь к тому, что за давностью лет Синклер что-то путает.
Здравствуйте, paradok, Вы писали:
P>А в это время Unity спокойно шарашит на все мыслимые платформы даже в html.javascript...
Давай примеры кроссплатформенных приложений на Unity.
Здравствуйте, vdimas, Вы писали:
P>>Винду в универе увидел первый раз после 95го или 96го.
V>Т.е. первая виденная винда была уже 95-я?
3.0
Я имел в виду — в университете, т.е. в лабораториях. Там компы были очень так себе, ес1841..3, иногда 286, редко — 386, софт древний.
Мой 286й самолично собранный был довольно крут, т.к. у большинства на тот момент вообще ничего не было. Вот гдето в 99м уже было по 0.7 компа на человека в общаге.
V>А специальность какая? V>У нас "..., системы, сети", 2201.
Вмсис
P>>И ты решил, что так у всех должно было быть?
V>Всё еще склоняюсь к тому, что за давностью лет Синклер что-то путает.
А я вот полностью с ним согласен. Графический редактор текста в дос листал документ очень долго.
Здравствуйте, SаNNy, Вы писали:
SNN>Здравствуйте, paradok, Вы писали:
P>>А в это время Unity спокойно шарашит на все мыслимые платформы даже в html.javascript... SNN>Давай примеры кроссплатформенных приложений на Unity.
любой пример из их обучалки — сделай экспорт в html и запускай везде где есть браузеры.
но кажется ты никогда не видел в глаза иде юнити...
ну поставь ее — сделай хэло ворлд, скомпиль в андроид и виднду и позапукай...
Здравствуйте, paradok, Вы писали:
P>любой пример из их обучалки — сделай экспорт в html и запускай везде где есть браузеры. P>но кажется ты никогда не видел в глаза иде юнити... P>ну поставь ее — сделай хэло ворлд, скомпиль в андроид и виднду и позапукай...
Давай примеры реальных приложений, а не вот это всё.
Здравствуйте, SаNNy, Вы писали:
SNN>Здравствуйте, paradok, Вы писали:
P>>любой пример из их обучалки — сделай экспорт в html и запускай везде где есть браузеры. P>>но кажется ты никогда не видел в глаза иде юнити... P>>ну поставь ее — сделай хэло ворлд, скомпиль в андроид и виднду и позапукай...
SNN>Давай примеры реальных приложений, а не вот это всё.
Здравствуйте, vdimas, Вы писали:
V>>>У нас "..., системы, сети", 2201. P>>Вмсис
V>ВМКСиС ))
Не совсем понятно, что ты хотел сказать, но у меня специальность — ВМСиС, что легко гуглится. Хотя не удивлюсь, если ты снова лучше знаешь, что у меня за кофе в кофейне.
Здравствуйте, Pauel, Вы писали:
V>>>>У нас "..., системы, сети", 2201. P>>>Вмсис V>>ВМКСиС )) P>Не совсем понятно, что ты хотел сказать, но у меня специальность — ВМСиС, что легко гуглится. Хотя не удивлюсь, если ты снова лучше знаешь, что у меня за кофе в кофейне.
Здравствуйте, Pauel, Вы писали:
P>Винду в универе увидел первый раз после 95го или 96го.
Я ещё до 95й винды админил Novell Netware IPX сетку из бездисковых 486х, рубились на ней в дума
А так была 3.11 на всём, что её могло тянуть (386/486)
И это даже не в Минске.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Я ещё до 95й винды админил Novell Netware IPX сетку из бездисковых 486х, рубились на ней в дума CC>А так была 3.11 на всём, что её могло тянуть (386/486) CC>И это даже не в Минске.
В университете который БГУИР в 95м году были ЕС1841..3, иногда, крайне редко — 1861. Собственно, в 98-99м этих 1841..3 было все еще полно, около половины. Например, когда я перевелся на ВМСиС, это 98й, мы сидели на 1841 и подобных и почти все лабы на ассемблере были именно на таких сделаны.
В 2й общаге БГУИР в 95м году было 3(три) компа не считая спектрумов. Может и больше, но про них никто не знал. В соседней, 1й общаге, компов было куда больше, и там была сетка и всё такое.
Здравствуйте, Pauel, Вы писали:
P>В университете который БГУИР в 95м году были ЕС1841..3, иногда, крайне редко — 1861.
Да там всегда было говно мамонта а не оборудование. Я в своё время фейспалмил от этого хлама, просто музей антиквариата какой то а не ВУЗ.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Shmj, Вы писали:
S>Основное в чем человечество сошлось — это браузер. Практически вся кроссплатформа основана на использовании браузерного рендеринга. Варианта ровно 2 — либо HTML-based либо Canvas-based.
S>Основные: React Native (HTML), Flutter (Canvas), Xamarin (как я понял, вызывают API ОС?)
React Native — это нативные контролы, также как и Xamarin. Flutter не использует canvas, он работает также как Java Swing или QT. В итоге в вашем списке браузерного рендеринга нет вообще.
Здравствуйте, Baiker, Вы писали:
B>Здравствуйте, Aquilaware, Вы писали:
A>>UI с поддержкой горячих клавиш, правильной табуляцией, правильным автофокусом и прочим делается на HTML'e относительно легко
B>Давай, покажи мне настоящий docking на HTML! (как в VisualStudio) Или адекватный обмен данными с диалоговыми окнами.
даю, показываю — смотри панель управления администратора американской системы управления кол-центрами Genesys
все есть + еще чего много
Здравствуйте, CreatorCray, Вы писали: CC>Загрузи туда PSD от верстальщиков с кучей слоёв — посмеёмся.
Кстати, по поводу верстальщиков и кучи слоёв — недавно был вынужден ознакомиться с фигмой.
Офигенная вещь — бесконечный канвас, плавный зум и, самое главное — совместная работа. То есть мы берём мокап, нарисованный дизайнером для вёрстки (на основе дизайн-системы, ессно, так что при смене, скажем, шрифта заголовков или шапки приложения все связанные мокапы обновляются автоматически), садимся в zoom и интерактивно исправляем в нём всё, что нужно. При этом у нас с дизайнером — 4 часа разницы во времени, так что прийти и сесть рядом с ним за стол я физически не могу. Дизайнер там дизайнит быстрее, чем я говорю. Можно и без интерактива — скажем, я медленно просматриваю вариант дизайна, оставляю комментарии ко всему, что меня не устраивает, и потом дизайнер самостоятельно вносит запрошенные правки.
Ну вот после нескольких таких сессий я его спросил: а в чём вы раньше дизайнили гую? Он говорит: в PSD. И как, спрашиваю, процесс был устроен? Через боль, страдание, унижение — вот как-то так.
Потому, что PSD весит овердохрена, его надо постоянно пересылать туда-сюда, да ещё и постоянные косяки из-за того, что к верстальщику попала позапрошлая версия.
Не, я понимаю, что в каких-то сценариях Фотошоп по-прежнему рулит. Искренне верю, что именно художественную продукцию, где надо умело пользоваться всякими фильтрами, зачастую ещё и купленными за денежку, в фигме либо совсем не изготовишь, либо опять же через боль, страдания и унижение. Но вот подготовка морд для вёрстки веб-сайтов и приложений в фигме на порядок продуктивнее любого десктопного фотошопа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, smeeld, Вы писали:
S>Последуй совету первым. Говоря про кроссплатформ, говорят про серверные системы. На декстопах и мобилках свой кухня у каждого девайса. Тут кросcплатформом никто не запаривается. И серверы-это линуксы, bsd, юниксы и немного винды. Вот кроссплатформ между ними и стоит на повестке.
Угу. Так проблема кроссплатформы вот-вот переродится в проблему совместимости между разными линуксами, потому как где они те юниксы? Винды немного. Про bsd
