Официальная версия 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>То смс на телефоне не набирается, то текст на планшете Похоже, что дело в руках или нежелании приобретать новые привычки.
Банально набор на физической клаве быстрее на порядок. Нет смысла корячиться на крохотной экранной, где вслепую многопальцево набирать банально невозможно.
Здравствуйте, 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 на уровне акробата или нет?
Здравствуйте, 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>- через час "с требованиями всё в порядке, вернемся к вопросу, когда я из отпуска вернусь"
Эти пара букв ж вообще ни о чём. Их даже текстом назвать сложно
Здравствуйте, 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.
Здравствуйте, 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 именно тем и занят, что выдает правильное сглаживание и хинтинг и тд.
Нет там ни сглаживания ни хинтинга, он просто тупо собирает контур, без каких либо попыток в хинты, а рендеринг и заливка этого контура со сглаживанием и прочими приседаниями происходит уже внутри С++ кода браузера.
Здравствуйте, Pauel, Вы писали:
P>1. поиск новой музыки был востребованым во все времена.
Спасибо, Кэп!
P> Файлы на диске не решают это никак.
Файлы на диске это уже НАЙДЕННАЯ музыка. Причём именно нужного альбома, нужной редакции и т.п.
У меня как то коллега залил свою музыку в облако, которое просто по названиям песен заменило то, что он залил, редкую версию альбома, на генерик версию того же альбома.
Так что нет, файлы и только файлы. Ты не владеешь тем, что не контролируешь.
P>Стриминговые сервисы дают это прямо искаропки.
Что они дают искаропки?
P>2. Юзеры используют тучи устройств, в т.ч. вне дома
И? В машину у меня залиты те же файлы что и дома. На рабочем компе через Syncthing прилетают те же файлы что и дома.
P>3. Люди слушают много и разного, меняют предпочтения постоянно.
То, чем набит стриминг у меня не вызывает никаких положительных эмоций, скорее отрицательные.
P>Услышал где то — добавил себе.
И какая проблема добавить себе файл?
P>4. Стриминг много дешевле покупки музыки
Музыка мне с бОльшего бесплатно достаётся за Amazon day бонусы.
P>5. Качество контента выше всего именно в стриминге
Радикально нет!
P>6. стриминговые сервисы имеют хорошие рекомендательные алгоритмы, например, Spotify здесь вообще сказка.
Пользовался многими, все они в лучшем случае выдавали то, что у меня уже есть. А вот чтоб что новое подсунуть так я чаще на coub с прикольной темой натыкался чем один из этих сервисов мне что предлагал.
P>7. в стриминге нет смысла тратить время-пространство на организацию хранилища
Тоже мне проблема!
Здравствуйте, 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 лет.
Здравствуйте, 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, рендеринг выполняется нативным кодом браузера.
Кто мешает тебе открыть страничку
