Здравствуйте, vdimas, Вы писали:
V>·>Это только в C# не было дефрагметации, что вызывало серьёзные проблемы: V>·>
I've had managers point to LOH fragmentation as justification for choosing some other technology
V>·>И они наконец-то пофиксили начиная с 4.5.1: LargeObjectHeapCompactionMode V>·>Ты теперь видишь, надеюсь, что твои убеждения не соответствуют фактам. V>Не надоело еще пальцем в небо? )) V>Задачи дефрагментации LOH и основной кучи GC сильно разные.
Покажи в чём разница дефрагментации больших объектов в Java? Ссылку только, а не фантазии.
V>Для второй дефрагментация нужна для целей быстрого выделения объектов через простой инкремент.
V>Для первой — для самой возможности выделения объектов. V>Например, ты выделил 10 тыс элементов по 100 кБ из LOH (всего гиг), исчерпав его адресное пространство (допустим такое для 32-хразрядной системы). V>Затем освободил каждый 4-й элемент. И, хотя у тебя свободной памяти нарисовалось аж четверть гига, вполне может случится так, что ты не сможешь затем выделить элемент размером всего 200 кБ.
Я знаю что такое дефрагментация кучи. Да, в дотнете разница есть, он дефрагментировать LOH не умел. В java — нет никакого LOH, есть только OG, который таки дефрагментируется.
V>·>А кто эту пулю обещал? LL почти всегда даётся ценой throughput. V>В нейтиве такого ограничения нет.
В нейтиве кучу нельзя дефрагметировать, т.к. объекты двигать нельзя.
V>>>Если ты начинаешь плясать вокруг выделений памяти в джава, то джава становится резко не нужна. )) V>·>Мнение. Будто бы в нативных приложениях танцев с памятью не бывает. V>В нейтиве танцевать с памятью на порядки проще, трудозатраты несравнимы.
Мнение.
V>·>Ну в Джаве большие объекты в OG выделяются V>На твой манер — ссылку? V>Они "отправляются в OG", а не выделяются там.
Да я тебе уже давал эту. Ты читай хотя бы ссылки которые я даю, иначе позоришься по полному:
When a nursery is used, the large objects are allocated directly in old space.
Ну чтобы второй раз не вставать, а то ты вдруг придерёшься что old space это некий "честный аллокатор" или "магическая ДРУГАЯ куча", нет это синоним OG:
The heap is sometimes divided into two areas (or generations) called the nursery (or young space) and the old space.
V>В кавычках — абстрактное (упрощенное) описание происходящего.
А ссылочку?
V>На самом деле ничего никуда не отправляется, просто объект так помечается или ссылка на него заносится в некий список GC и т.д.
Под отправкой обычно понимается копирование данных, когда например объекты отправляются из S1 в S2 или наоборот.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>В любом случае, в современных процессорных узлах столько памяти, что своп тупо отключают и всё описанное становится не более чем бесполезным фетишем, бо оно и так в точности аналогично работает в отсутствии свопа. ·>Я подробностей не знаю почему именно они не использовали стандартный api.
Ядерный модуль в Zing нужен для write barrier'а. Основная функциональность — быстро менять флаги защиты страниц и следить за страницами, которые были изменены.
В теории то, что он делает, можно реализовать с помощью mprotect/mlock и userspace-инфраструктуры обработки page faults. На практике это будет работать примерно на 2 порядка медленнее, чем специально заточенная под эту задачу подсистема внутри ядра.
Здравствуйте, Serginio1, Вы писали:
_>>Так я не понял что конкретно ты предлагаешь, добавить выпуск приложения под UWP параллельно с выпуском win32 приложения или же заменить win32 на UWP? _>>В первом случае получается поддержка дополнительный платформы (а это совсем не дёшево) ради совершенно незначительного числа потенциальных пользователей. _>>А во-втором случае получается вообще сужение потенциальной аудитории в разы, т.к. UWP не работает на старых версиях винды (которые до сих пор в разы популярнее win10). S> Еще раз. UWP не работают по win 7, но win32 несложно перенести в UWP? что не ясно?
Т.е. ты предлагаешь параллельно поддерживать две целевые платформы (win32 и UWP), я правильно понял?
S> То есть десятки миллионов (XBOX и WinMO) это совершенно незначительное число? да вы батенька много кушаете.
Где ты там насчитал десятки миллионов устройств на WinMobile10? ) Ну а xbox — это отдельная тема для узкой аудитории топовых игроделов.
Здравствуйте, vdimas, Вы писали:
V>>>Контролы в Андроиде реализованы в нейтиве. V>>>А порта нет по другой причине — почти вся другая инфраструктура нифига не нейтивная. _>>О какие интересные новости... Может тогда ещё и подскажешь какой заголовочный файл из NDK подключить, V>#include <native_window.h> V>Искать по ANativeWindow, ANativeActivityCallbacks, DisplayEventReceiver и т.д.
Ну и где там функции создания кнопкок, полей ввода, менюшек и т.п. контролов? ) Которые согласно твоей цитате "в Андроиде реализованы в нейтиве".
V>Рисовать крайне просто: V>...
Рисовать контролы, самому? А ты забавный... Если следовать твоей логике, то окажется что и у DOS'a (или даже вообще у BIOS'a) был встроеннный GUI, т.к. там была возможность рисовать на экран. )))
_>>чтобы вызывать функции, создающие стандартные андроидные формочки, менюшки и т.п.? ) V>Не надо жульничать. "Стандартные андроидные менюшки" — это не "родные контролы", это джавовский библиотечный элемент, который рисует пикселы в нативное окно.
О, я смотрю ты как обычно... Подставился на банальном незнание базовых вещей, а когда понял это, то пытаешься замять тему с помощью вранья. Но тут это не выйдет — все твои цитаты записаны. Так что будь любезен предъявить нативные контролы Андроида, о которых ты писал. Или хоть раз покажи себя мужчиной, признав свою очевидную некомпетентность.
V>>>Сервелат полноценно пашет под маком. _>>
_>>В 2012 году Microsoft назначила конец жизненного цикла Silverlight 5 на 10 декабря 2021 года. В 2013 году Microsoft объявила, что они прекратили развитие Silverlight, за исключением выпуска исправлений ошибок. Silverlight более не поддерживается в браузерах Opera, Mozilla Firefox, Google Chrome, так как в 2015 году в этих браузерах была отключена по умолчанию или полностью прекращена поддержка плагинов формата NPAPI.
_>>Спасибо, но не надо, некрофилией не увлекаемся. V>И опять передёргивание. V>До 2021-го года будут исправляться ошибки. V>После 2021-го года это будет одна из самых безбаговых платформ, вестимо. V>У меня вообще складывается ощущение, что для вас публиковать никакие road maps, потому что вы не понимаете сути публикуемого.
Смысл сильверлайта был в работе в браузерах. После того, как его перестали поддерживать ведущие браузеры, он стал абсолютно мёртвой платформой. Даже если бы MS и не закрыла его сама. Так что твоё предложение использовать его в 2016-ом году выглядит просто как троллинг — ну не можешь же ты быть настолько некомпетентным.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Так я не понял что конкретно ты предлагаешь, добавить выпуск приложения под UWP параллельно с выпуском win32 приложения или же заменить win32 на UWP? _>>>В первом случае получается поддержка дополнительный платформы (а это совсем не дёшево) ради совершенно незначительного числа потенциальных пользователей. _>>>А во-втором случае получается вообще сужение потенциальной аудитории в разы, т.к. UWP не работает на старых версиях винды (которые до сих пор в разы популярнее win10). S>> Еще раз. UWP не работают по win 7, но win32 несложно перенести в UWP? что не ясно?
_>Т.е. ты предлагаешь параллельно поддерживать две целевые платформы (win32 и UWP), я правильно понял?
Я ничего не предлагаю. Каждый решает сам
Потратить небольшое время на конвертацию и получать дополнительную прибыль. Каждый должен решить для себя стоит ли овчинка выделки.
S>> То есть десятки миллионов (XBOX и WinMO) это совершенно незначительное число? да вы батенька много кушаете.
_>Где ты там насчитал десятки миллионов устройств на WinMobile10? ) Ну а xbox — это отдельная тема для узкой аудитории топовых игроделов.
Еще раз для нечитателей. XBOX поддерживает приложения UWP, а значит полноценный компьютер.
Ты можешь не только в игры играть, но и смотреть видео, презентации разговаривать по скайпу, итд и тп.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Т.е. ты предлагаешь параллельно поддерживать две целевые платформы (win32 и UWP), я правильно понял? S> Я ничего не предлагаю. Каждый решает сам S>Потратить небольшое время на конвертацию и получать дополнительную прибыль. Каждый должен решить для себя стоит ли овчинка выделки.
Вот это уже разумный разговор. Так вот, моё мнение заключается в том, что большинство разработчиков решит не заниматься созданием UWP приложений, т.к. это не имеет для них смысла.
Да, и кстати насчёт конвертации... Ты не верно прочитал документацию на Desktop App Converter. Он не делает из WIN32 приложений UWP. Он просто переупаковывает win32 приложение в контейнер appx (по сути вместо msi), как раз для распространения через магазин. Но после инсталляции это получается обычное win32 приложение со всеми его полноценными возможностями (в отличие от UWP приложения, которое исполняется в песочнице и вследствие этого имеет набор ограничений).
Вообще это появление Desktop App Converter как раз напоминает на проигрыш MS в навязывание UWP. Который они осознали и попытались спасти хотя бы идею магазина, сведя всё к по сути новой системе распространения и инсталляции обычных win32 приложений.
S>>> То есть десятки миллионов (XBOX и WinMO) это совершенно незначительное число? да вы батенька много кушаете. _>>Где ты там насчитал десятки миллионов устройств на WinMobile10? ) Ну а xbox — это отдельная тема для узкой аудитории топовых игроделов. S> Еще раз для нечитателей. XBOX поддерживает приложения UWP, а значит полноценный компьютер. S>Ты можешь не только в игры играть, но и смотреть видео, презентации разговаривать по скайпу, итд и тп.
Вот у тебя похоже вечная проблема во всех дискуссиях. Ты постоянно путаешь понятия "можно" и "нужно". Можно очень много разных извращений. Разные гики этими частенько развлекаются. Но это не значит, что это нужно какому-то ощутимому числу пользователей.
_>Да, и кстати насчёт конвертации... Ты не верно прочитал документацию на Desktop App Converter. Он не делает из WIN32 приложений UWP. Он просто переупаковывает win32 приложение в контейнер appx (по сути вместо msi), как раз для распространения через магазин. Но после инсталляции это получается обычное win32 приложение со всеми его полноценными возможностями (в отличие от UWP приложения, которое исполняется в песочнице и вследствие этого имеет набор ограничений).
Вот некоторые из преимуществ преобразования классического приложения для Windows.
Процедура установки вашего приложения становится значительно удобнее для пользователей. Вы можете разворачивать такие приложения на компьютерах, использующих загрузку неопубликованного приложения (см. Загрузка неопубликованных бизнес-приложений в Windows 10), и после их удаления не остается каких-либо остаточных файлов. В долгосрочной перспективе вы также сможете опубликовать свое приложение в Магазине Windows.
Поскольку ваше преобразованное приложение обладает идентификатором пакета, вы сможете вызывать дополнительные API-интерфейсы UWP даже из раздела с полным доверием. См. полный список Поддерживаемых API UWP для преобразованных классических приложений.
Вы можете на свое усмотрение добавлять в пакет приложения возможности UWP, такие как пользовательский интерфейс на языке XAML, обновления живых плиток, фоновые задачи UWP, службы приложений и многое другое. Все возможности, доступные любому другому приложению UWP, также доступны для вашего приложения. Если вы решите переместить все возможности своего приложения из раздела с полным доверием приложения в раздел с контейнером приложения, то ваше приложение сможет выполняться на любом устройстве с Windows 10. Будучи приложением UWP, ваше приложение обладает всеми возможностями классического приложения для Windows. Приложение взаимодействует с виртуализированным представлением реестра и файловой системы, которое неотличимо от фактических реестра и файловой системы.
Ваше приложение может взаимодействовать со встроенными средствами лицензирования и автоматического обновления Магазина Windows Автоматическое обновление— очень надежный и эффективный механизм, поскольку загружаются только измененные части файлов.
Преобразованные классические приложения могут использовать широкий спектр API универсальной платформы Windows (UWP), даже если они не полностью преобразованы в приложение UWP. В этой статье перечисляются доступные классы, которые может использовать ваше преобразованное приложение.
Большинство API UWP хорошо работают с преобразованными классическими приложениями. Однако некоторые функциональные области пока еще не прошли полное тестирование или работают неправильно.
Преобразованные приложения не могут выполняться на мобильных устройствах, пока они не будут полностью перенесены в UWP.
Convert your existing desktop app, which continues to run exactly as it did before, with the added benefit of using the universal Windows packaging model to deliver the app to users
Enhance your existing codebase with UWP API calls to implement new functionality, such as Live Tiles, notifications and roaming app data
Extend your existing codebase with a new App Container process, which can be used to add things like XAML UI and app services, while still being able to use your existing desktop app’s functionality through two-way communication between the App Container process and the desktop app process
After the third phase, you can continue to migrate more code to the App Container process over time, resulting in a UWP app that can reach all Windows 10 devices.
Вобщем то перенести WPF приложение не сложно https://msdn.microsoft.com/ru-ru/library/windows/apps/xaml/br229571.aspx
В любом случае посмотрим, что они в новом обновлении Win 10 сделают. Там .Net Core 2 выйдет, и NetStsndard 2. Сейчас люмии они не выпускают. Говорят об корпоративных пользователях. Посмотрим, что они выпустят.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
V>>Рисовать крайне просто: _>Рисовать контролы, самому? А ты забавный...
Не рисуй. Возьми одну из кучи либ, которые живут поверх OpenGL, DirectX и т.д.
Всем этим либам нужно простое — рисовать в некий "канвас" и получать сигналы (мыши и клавы) от окна и от системы.
Вот, малюсенькая либа: https://github.com/wjakob/nanogui
V>>Не надо жульничать. "Стандартные андроидные менюшки" — это не "родные контролы", это джавовский библиотечный элемент, который рисует пикселы в нативное окно. _>О, я смотрю ты как обычно... Подставился на банальном незнание базовых вещей, а когда понял это, то пытаешься замять тему с помощью вранья.
Мде? Нарезав на цитаты можно до чего угодно дойти, угу.
Зачем ты скипнул неудобное тебе?
В линухах контролы нифига не нативные. Они всегда библиотечные.
_>Так что будь любезен предъявить нативные контролы Андроида, о которых ты писал.
_>Или хоть раз покажи себя мужчиной, признав свою очевидную некомпетентность.
Поперла субстанция... ))
Я лучше покажу твою очевидную некомпетентность:
Коллега: Есть универсальная обёртка с поддержкой XAML над нативными для платформ фреймворками https://github.com/picoe/Eto .
Ты: Хыхы, попытка работать через нативные контролы на всех платформах — некое слабое подобие wxWidgets.
Я: В линухах контролы нифига не нативные. Они всегда библиотечные.
Далее ты пишешь:
вызывает большие проблемы при столкновение с платформами, на которых родной GUI недоступен из нативного кода. Именно поэтому у wxWidgets так и нет нормального порта для Андроида. И у этих товарищей тоже нет (и скорее всего не будет).
Даже не потрудившись пройти по ссылке и обнаружить:
Eto.iOS.dll — Xamarin.iOS platform
Eto.Android.dll — Xamarin.Android platform
Но это всё управляемая платформа. Я же тебе отвечал конкретно на это:
>Именно поэтому у wxWidgets так и нет нормального порта для Андроида.
Контролы в Андроиде реализованы в нейтиве.
А порта нет по другой причине — почти вся другая инфраструктура нифига не нейтивная.
Т.е. ты уже заранее слажал, потому что упомянул wxWidgets, но эта либа конкретно на линухах нифига не на неких "встроенных контролах" сидит, а поверх "другой" либы.
Так вот, сюрпрайз! Вот та "другая" либа уже портирована под Андроид: https://github.com/eugals/GTKAndroid
А теперь будь мужчиной и признай, что ты спорол несусветную чушь минимум дважды:
— подразумевая некие "встроенные" контролы под Linux, окромя сущности "окна" и его событий;
— требуя из нейтивного wxWidgets вызывать явовский код.
Последнее вообще жесть...
Ты программист или как?
V>>После 2021-го года это будет одна из самых безбаговых платформ, вестимо. V>>У меня вообще складывается ощущение, что для вас публиковать никакие road maps, потому что вы не понимаете сути публикуемого. _>Смысл сильверлайта был в работе в браузерах.
ActiveX WebControl, слышал о таком?
Продолжаем позориться.
Смысл был в минималистической и довольно шустрой платформы а-ля .Net + богатое мультимедиа + непробиваемая песочница.
Я участвовал как-то в живом проекте на Сервелате, всё живо и работает до сих пор. Интранетная система, поднимается интранетный же ASP-сервак, клиентская приложуха работает как раз на основе WebControl, а в ней крутится сервелат. Именно такой необычный сценарий и стал одним из популярных для сервелата и именно для таких корпоративных применений он и будет поддерживаться и далее. А даже там, где запускается прямо из браузера, то стоит корпоративный IE 11, в нем пара корпоративнух же плагинов (опять на сервелате писанных) и никто тебя не спросит, с какого "ведущего браузера" тебе хочется заходить в корпоративную приложуху. Тем более, что эти "ведущие браузеры" стартуют бесконечное время и жрут бесконечную память, в отличие от.
_>После того, как его перестали поддерживать ведущие браузеры
Ведущие браузеры плохо подходят для интранета. Увы и ах.
_>он стал абсолютно мёртвой платформой.
Ага, больше, больше эпитетов!
Основная фишка сервелата была в том, что это был единственный способ в рамках дотнета накидать приложение, которое будет брать видео из камеры и звук из микрофона, а так же стримить это всё обратно. Причем, работать при этом из полноценной песочницы и намного порядок быстрее джавовских апплетов или Flash.
Альтернативой сервелату по мультимедиа были только обертки над COM DirectAudio и DirectShow — а это застрелиться ваще.
Кароч, если бы ты был хоть немного в теме, ты бы не исходил на пену. Потому что всё происходит не просто так, для появления сервелата в своё время были весомые причины. В первую очередь — это богатое медиа и шустрое исполнение кода (в сравнении с Flash и джава-апплетов). А не получил он развитие не из-за "ведущих браузеров", а из-за падения популярности десктопов в пользу мобильного рынка. И если плагины под Adobe Flash оперативно выпускали сами производители таких платформ, то Сервелат должна была выпускать MS для всех.
И она бы справилась, я не сомневаюсь... Если бы не одно "но" — Андроидом занимался именно Гугл, т.е. самоназванный враг №1, ы-ы-ы.
Кароч, со стороны всё выглядело и продолжает выглядеть смешно. Почему? Adobe Flash — это убогое г-но мамонта, сервелат лучше в миллионы... нет, в миллиарды раз. Это единственное, что очевидно во всей этой теме. Но есть такая херь — NIH. Согласно ему, Гугл продвигает собственное видение, а именно — встроить мультимедиа-технологии прямо в браузеры, закрепив их в стандартах интернета.
Дело благородное, ес-но, да вот только развитие сложных стандартов — это дело весьма и весьма не быстрое. На это время надо было дать технологии для "здесь и сейчас". Однако, такие гавнюки как Гугл скорее будут находиться десяток лет в положении стервозной сучки на сене, чем дадут клиентам то, что им действительно нужно.
В итоге, ты там назвал сервелат мертвой платформой, ы?
А теперь, барабанная дробь... ты сможешь назвать хоть одну альтернативную технологию, подходящую для интернета и дающую сравнимую эффективность? Очевидно, что НЕ сможешь.
Фишка в том, что уже лет 5-6 в интернете происходит какое-то безвременье:
— Новые стандарты интернета еще не приняты.
— Браузеры еще не готовы.
— Гугл еще не довела свою технологию до промышленного кач-ва.
— Индустрия в целом практически еще не использует новомодные мультимедиа-возможности стандарта HTML.
— для чего-то сложного Flash использовать невозможно от слова совсем.
Кароч, такая ситуация продлится, вангую, еще лет 5 минимум, пока, наконец, индустрия не сдастся и не позволит гавнюку-вредителю-Гуглу протащить СВОЮ версию байткодной машинки+АОТ (PNaCl) в кач-ве стандарта W3C (с пафосным названием ныне WebAssembly). Рука-лицо бесконечное кол-во раз.
Т.е., посмотри что происходит — из-за своей грубой попытки КОНТРОЛЛИРОВАТЬ развитие интернета, одна богатая и ОЧЕНЬ гавнистая контора вставляет палки в колёса всей индустрии.
Современная проблема WebAssembly в том, что это крайне сырая технология. Т.е. Гугл что-то там сляпал на коленке из гавна и палок и понёсся, используя всё своё влияние (включая откровенный подкуп и коррупцию) с этим г-ном наперевес, лишь бы занять место на олимпе создателей стандартов интернета.
И вот уже кучу лет эта WebAssembly натурально буксует. Такое ощущение, что потребность самого Гугла в этой технологии не сильно-то и большая. Лично я теперь, спустя несколько лет вижу это так, что нас развели как кроликов. Это был лишь трюк Гугла с целью выдавить ЛЮБЫХ конкурентов с рынка мультимедиа в интернете и подстраховаться насчет их появлений в будущем. Вот сейчас некто захочет разработать некую эффективную интернет-технологию для мультимедиа-приложух в браузере, а ему: "Зачем? Вот-вот уже совсем скоро будет WebAssembly!" — "А, ну да"...
Это "скоро" длится уже лет 5 и еще столько же, если не больше, будет длиться.
Дебилы, Б. (C)
_>Так что твоё предложение использовать его в 2016-ом году выглядит просто как троллинг — ну не можешь же ты быть настолько некомпетентным.
Ну и что я должен ответить на это человеку, который прилюдно хвастается тем, что он не в теме по обсуждаемому, никогда в этой теме не был и ему даже неинтересно узнать, как оно сейчас и почему именно так?
Здравствуйте, Serginio1, Вы писали:
S>Но можно сделать полный перенос. S>...
Можно. Но не нужно. Потому что этим действием ты потеряешь большую часть аудитории (сравни количество пользователей win10 и остальных версий винды), приобретя взамен всего лишь несколько извращенцев (владельцев win10 mobile).
Здравствуйте, vdimas, Вы писали:
_>>Рисовать контролы, самому? А ты забавный... V>Не рисуй. Возьми одну из кучи либ, которые живут поверх OpenGL, DirectX и т.д. V>Всем этим либам нужно простое — рисовать в некий "канвас" и получать сигналы (мыши и клавы) от окна и от системы. V>Вот, малюсенькая либа: V>https://github.com/wjakob/nanogui
А DOS'е тоже можно было взять готовую удобную библиотечку (например TurboVision) и получить все нужные контролы. Тогда следуя твоей забавной логике (ну хотя понятно, что ты на самом деле так не считаешь, а всего лишь пытаешься сохранить лицо с помощью демагогии) получается что и в DOS у нас встроено GUI? ))) Или всё же между Windows (Android/OSX/iOS и т.д. и т.п.) и DOS'ом есть какая-то разница в этом смысле? )))
V>>>Не надо жульничать. "Стандартные андроидные менюшки" — это не "родные контролы", это джавовский библиотечный элемент, который рисует пикселы в нативное окно. _>>О, я смотрю ты как обычно... Подставился на банальном незнание базовых вещей, а когда понял это, то пытаешься замять тему с помощью вранья. V>Мде? Нарезав на цитаты можно до чего угодно дойти, угу. V>Зачем ты скипнул неудобное тебе? V>
V>В линухах контролы нифига не нативные. Они всегда библиотечные.
Причём тут линух? Речь шла конкретно про Андроид и в твоей точной цитате упомянуты именно нативные контролы Андроида. Дать ссылку на это твоё сообщение? )
_>>Так что будь любезен предъявить нативные контролы Андроида, о которых ты писал. V>Мильоны их: V>http://cegui.org.uk/features V>https://www.juce.com/features
А вот тут уже всё гораздо интереснее (см. ниже).
V>Конкретно мне очень импонирует nanogui, которую уже портанули на SDL, а та уже пашет на Андроиде. V>(SDL — это тонкая абстракция над графическим окном)
nanogui — это действительно отличная современная GUI библиотека по своей архитектуре. Только вот во-первых она пока работает только на десктопных ОС (Windows/OSX/Linux), а во-вторых опять же рисует контролы сама (через OpenGL), а не использует системные. Так что она дважды не относится к теме нашего обсуждения.
V>Далее ты пишешь: V>
V>вызывает большие проблемы при столкновение с платформами, на которых родной GUI недоступен из нативного кода. Именно поэтому у wxWidgets так и нет нормального порта для Андроида. И у этих товарищей тоже нет (и скорее всего не будет).
V>Даже не потрудившись пройти по ссылке и обнаружить: V>Eto.iOS.dll — Xamarin.iOS platform V>Eto.Android.dll — Xamarin.Android platform
Ой, ну вот чего врать то так напрямую? Ведь каждый может банально открыть ссылку (https://github.com/picoe/Eto) и прочитать всё сам. Там чётко написано, что Android и WinRT у них только в мечтах, а поддерживаются в данный момент только Window/OSX/Linux/iOS. Что же касается iOS, то про неё никто и не говорил, что там есть какие-то проблемы (там вам весь системный api вполне доступен из нативного кода).
V>Но это всё управляемая платформа. Я же тебе отвечал конкретно на это: V>
>>Именно поэтому у wxWidgets так и нет нормального порта для Андроида.
V>Контролы в Андроиде реализованы в нейтиве.
V>А порта нет по другой причине — почти вся другая инфраструктура нифига не нейтивная.
V>Т.е. ты уже заранее слажал, потому что упомянул wxWidgets, но эта либа конкретно на линухах нифига не на неких "встроенных контролах" сидит, а поверх "другой" либы.
В Линухе действительно нет стандартного GUI (и это кстати одна из больших проблем этой платформы на десктопах). Поэтому библиотеки типа wxWidgets (использующие нативных контролы на остальных платформах) решают эту проблему реализацией под несколько (не только GTK!) самых популярных в Линухе вариантов GUI.
V>Так вот, сюрпрайз! Вот та "другая" либа уже портирована под Андроид: V>https://github.com/eugals/GTKAndroid
Ну "портирована" — это громко сказано (частично функционирующая версия 0.1alpha). Но даже если бы и так, то непонятно какое это имеет отношение о обсуждаемой теме контролов Андроида (GTK то всё равно будет рисовать свои).
V>А теперь будь мужчиной и признай, что ты спорол несусветную чушь минимум дважды: V>- подразумевая некие "встроенные" контролы под Linux, окромя сущности "окна" и его событий;
Ха, вообще то Qt (да и Xamarin вроде тоже, судя по их описанию — сам руками не проверял) именно так и работает. Ты даже этого не знал? ))) Для этого в Qt написали (на Java) универсальную обёртку, которая предоставляет нативному коду доступ ко всему API Андроида. Хотя при этом часть контролов они рисуют сами (в начале запросив все параметры системных через ту самую обёртку и полностью эмулируя их внешний вид), т.к. это их стандартный подход, но далеко не все (некоторые системные тут так просто не реализовать).
V>>>После 2021-го года это будет одна из самых безбаговых платформ, вестимо. V>>>У меня вообще складывается ощущение, что для вас публиковать никакие road maps, потому что вы не понимаете сути публикуемого. _>>Смысл сильверлайта был в работе в браузерах. _>>После того, как его перестали поддерживать ведущие браузеры V>Ведущие браузеры плохо подходят для интранета. Увы и ах.
_>>он стал абсолютно мёртвой платформой. V>В итоге, ты там назвал сервелат мертвой платформой, ы? V>А теперь, барабанная дробь... ты сможешь назвать хоть одну альтернативную технологию, подходящую для интернета и дающую сравнимую эффективность? Очевидно, что НЕ сможешь.
Я правильно понял, что ты из тех, кто готов в 2016-ом году начать новый проект на SilverLight? Будет потом чем доказать знакомым, что такие действительно существуют... )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>Но можно сделать полный перенос. S>>...
_>Можно. Но не нужно. Потому что этим действием ты потеряешь большую часть аудитории (сравни количество пользователей win10 и остальных версий винды), приобретя взамен всего лишь несколько извращенцев (владельцев win10 mobile).
XBOX, Холонез. При этом заметь игры под них делают и не жужжат.
_>Кстати, забавная свеженькая новость в тему обсуждения: http://www.playground.ru/blogs/call_of_duty_infinite_warfare/zapusk_call_of_duty_infinite_warfare_v_windows_store_epicheski_provalilsya-220579/. Причём я даже не в курсе (не играю в такое) как конкретно они реализовали там свою игрушку (UWP или просто WIN32 упакованный в appx) — похоже магазин хреново работает в любом случае.
Здравствуйте, IID, Вы писали:
C>>Ядерный модуль в Zing нужен для write barrier'а. Основная функциональность — быстро менять флаги защиты страниц IID>Мууууу!!! IID>Image: dirty-cow.jpeg
В частности и из-за этого. Обычный механизм для отображения страниц достаточно громоздкий, так как написан для общего случая.
В Zing тупо выделяется линейный блок физической памяти, что упрощает очень многое.
Здравствуйте, alex_public, Вы писали:
_>А DOS'е тоже можно было взять готовую удобную библиотечку (например TurboVision) и получить все нужные контролы.
Именно так.
Linux изначально разрабатывалась как сугубо текстово-консольная операционка.
_>Тогда следуя твоей забавной логике (ну хотя понятно, что ты на самом деле так не считаешь, а всего лишь пытаешься сохранить лицо с помощью демагогии)
Сейчас выкручиваться пытаешься уже ты, а я лишь ржу над твоими попытками. ))
Ладно бы я где-то рядом напомнил особо прытким, что в линухах контролы всегда идут как юзверская либа, еще бы можно было попытаться натянуть сову на глобус. Но когда это было сказано в этом же самом сообщении и удалено тобой из цитирования, то это всё уже попахивает или глупостью или троллизмом 80-го лвл. И судя по отсутствию хладнокровности и последовательности — вряд ли второе.
_>получается что и в DOS у нас встроено GUI? )))
GUI идёт идёт в прикладном уровне, а не в ОС.
_>Или всё же между Windows (Android/OSX/iOS и т.д. и т.п.) и DOS'ом есть какая-то разница в этом смысле? )))
Для того, кто вот так группирует, разницы нет, вестимо.
С одной стороны у нас стоит Linux, DOS и им подобные, с другой стороны у нас Windows от Win95 и выше, OSX, iOS, PalmOS, Symbian OS и т.д. В них графика обрабатывается даже шедуллером задач (учитывается время ожидания окном возможности обработки входящих сообщений, борьба с "замороженными" окнами и т.д.).
_>Причём тут линух? Речь шла конкретно про Андроид
И эти люди запрещают мне ковыряться в носу.
Вернее, пытаются обвинить меня в дилетанстве, ы-ы-ы.
Кароч, с тех пор как ветка Андроид слилась с основной веткой Линукс (черти когда уже) последние спекуляции на эту тему должны были исчезнуть. С тех пор Андроид является сугубо библиотекой-оболочкой, точно так же как KDE, Gnome или даже Eclipse.
_>и в твоей точной цитате упомянуты именно нативные контролы Андроида. Дать ссылку на это твоё сообщение? )
Ну ты его целиком прочитай, а не только одну строчку. Т.е., включив голову и не потеряй контекст.
_>Это всё рисует свои контролы (через OpenGL), а не Андроида.
Не обязательно. Есть порт nanogui на SDL, а последняя давно живет везде.
Андроид тоже через нейтив рисует. Что помешало тебе пройтись по какому-нить онлайн-браузеру исходников андроида и посмотреть?
Это большая-пребольшая редкость, когда контролы в Андроиде рисуются прямо в Джаве, то бишь в пикселы некоего промежуточного битмапа, а потом эти пикселы перегоняются на Canvas одной нейтивной операцией. Так делают только нубы какие-нить на коленках.
Встроенные же контролы там рисуются через нейтивные же рисовальщики конкретной темы, а контролы из каких-нить профессиональных библиотек, типа Telerik, рисуются через JNI.
Кароч. С тех пор как Андроид влился в основной Linux через поддержку протокола Wayland, на Андроиде может пахать любая Wayland-based GUI-библиотека.
V>>QT _>А вот тут уже всё гораздо интереснее (см. ниже).
Ничего интересного.
_>nanogui — это действительно отличная современная GUI библиотека по своей архитектуре. Только вот во-первых она пока работает только на десктопных ОС (Windows/OSX/Linux), а во-вторых опять же рисует контролы сама (через OpenGL), а не использует системные. Так что она дважды не относится к теме нашего обсуждения.
Продолжаем спекулировать, ню-ню. ))
В линухах любая библиотека рисует сама.
Это ты в программистком споре будешь оперировать ссылками для домохозяек?
Повторюсь — потрать малость времени на просмотр исходников Андроида.
Это я уже молчу о том, что тонны приложух на Андроиде идут на базе контрола WebView, т.е. рисуют свой интерфейс через HTML, а этот контрол — это тот самый нейтивный WebKit собственной персоной. ))
_>Да, и кстати обрати внимание на то, что за сайт перед тобой, чтобы не было больше глупостей про "некую java библиотеку". Кстати, а мне вот интересно, ты действительно собирался реализовывать через NativeActivity например такой https://developer.android.com/guide/topics/ui/notifiers/notifications.html элемент GUI? )))
Боюсь, у меня для тебя плохие новости.
Ты дал ссылку на систему регистрации обработчиков URI, а она там нейтивная и в андроиде как два пальца об асфальт зарегить нейтивный обработчик для т.н. "Intent" (см. доку). В этом смысле джавовский класс Intent — это тонкая обертка над нейтивной функциональностью. Этот механизм аналог виндового DDE.
_>Ха, вообще то Qt (да и Xamarin вроде тоже, судя по их описанию — сам руками не проверял) именно так и работает.
Дык, Xamarin — это управляемый код, а ты говоришь про QT.
_>Для этого в Qt написали (на Java) универсальную обёртку, которая предоставляет нативному коду доступ ко всему API Андроида. Хотя при этом часть контролов они рисуют сами (в начале запросив все параметры системных через ту самую обёртку и полностью эмулируя их внешний вид)
Боюсь, тут без ссылок на конкретные исходные файлы не обойтись. Потому что т.н. "системные параметры" — это наборы чисел, хендлов на битмапы и таблицы цветов.
_>т.к. это их стандартный подход, но далеко не все (некоторые системные тут так просто не реализовать).
Ну так контролы рисует джавовский код или, таки нейтивный? А у джавовского они лишь хендл канваса запрашивают у текущей Activity, ы?
V>>А теперь, барабанная дробь... ты сможешь назвать хоть одну альтернативную технологию, подходящую для интернета и дающую сравнимую эффективность? Очевидно, что НЕ сможешь. _>Я правильно понял, что ты из тех...
Так и запишем — ответить на прямой вопрос не в состоянии, сел в лужу.
А сколько было пафоса.
В общем, вопрос в силе и вопрос не праздный. Он в силе сейчас и в ближайшие лет 5 (минимум) тоже будет.
Как найдёшь ответ по-существу — приходи.
А до тех пор надо сделать шатап и решать текущие задачи клиентов на том, что есть, а не обещать им кисельные берега через 5-10 лет.
Юзверям на твои личные предпочтения вообще положить. А наши СВ, буде прочтя их, они вообще сочтут за ярмарку дебилов. Это положа руку на и будуи честным с самими собой. У них там дело, бизнес, деньги и срочные задачи, а тут эдакие незамутнённые личности, неспешно ковыряясь в носу рассуждают о том, что их величествам нравится, а от чего они носик морщат. С т.з. остальных людей — это эльфизм 80-го лвл. )))
Здравствуйте, ·, Вы писали:
V>>Потому что две очереди образуют структуру данных "Circular Linked List" с такой же точно семантикой. ·>Неправда, ты опять толком не разобрался.
Здравствуйте, vdimas, Вы писали:
_>>А DOS'е тоже можно было взять готовую удобную библиотечку (например TurboVision) и получить все нужные контролы. V>Именно так. V>Linux изначально разрабатывалась как сугубо текстово-консольная операционка.
Вообще то такой операционки как Linux не существует. Есть ядро Linux. И сотни различных ОС построенных на его основе. С очень разными целевыми нишами и внутренними спецификациями. В том числе и в области GUI. Существуют ОС (на базе ядра Linux) без GUI вообще, с опциональным GUI на выбор, с формализованным системным GUI. Так вот Андроид (и кстати он не только один такой) относится как раз к последнему виду ОС.
_>>получается что и в DOS у нас встроено GUI? ))) V>GUI идёт идёт в прикладном уровне, а не в ОС.
ОС, в которой GUI является появляется только в прикладном ПО (типа DOS'а), должна соответственно предоставлять весь набор своей функциональности без GUI. Т.е. ты можешь продемонстрировать нам пример нормального функционирующего без GUI Андроида? )))
_>>Или всё же между Windows (Android/OSX/iOS и т.д. и т.п.) и DOS'ом есть какая-то разница в этом смысле? ))) V>Для того, кто вот так группирует, разницы нет, вестимо. V>С одной стороны у нас стоит Linux, DOS и им подобные, с другой стороны у нас Windows от Win95 и выше, OSX, iOS, PalmOS, Symbian OS и т.д. В них графика обрабатывается даже шедуллером задач (учитывается время ожидания окном возможности обработки входящих сообщений, борьба с "замороженными" окнами и т.д.).
Хы, с тем, кто называет Linux ОС, вообще смешно говорить о какой-то группировке. )))
_>>Причём тут линух? Речь шла конкретно про Андроид V>И эти люди запрещают мне ковыряться в носу. V>Вернее, пытаются обвинить меня в дилетанстве, ы-ы-ы. V>Кароч, с тех пор как ветка Андроид слилась с основной веткой Линукс (черти когда уже) последние спекуляции на эту тему должны были исчезнуть. С тех пор Андроид является сугубо библиотекой-оболочкой, точно так же как KDE, Gnome или даже Eclipse.
Повторяю ещё раз для особо медленно понимающих. В семейство ОС с ядром LInux входят и ОС без GUI вообще (и это там формализовано!), и ОС с выбираемым пользователем GUI (многие десктопные версии), и ОС с формализованным системным GUI. Поэтому обсуждение некого абстрактного "Linux" в этом контексте мягко говоря смешно (хотя понятно, что на самом деле это всего лишь твоя жалкая попытка замять свой откровенный косяк). А вот обсуждать какую-то конкретную ОС вполне можно. Например обсуждаемый тут Андроид имеет формализованное системное GUI.
_>>и в твоей точной цитате упомянуты именно нативные контролы Андроида. Дать ссылку на это твоё сообщение? ) V>Ну ты его целиком прочитай, а не только одну строчку. Т.е., включив голову и не потеряй контекст.
Какой ещё контекст? Твоя фраза "Контролы в Андроиде реализованы в нейтиве." полностью однозначна и никакой контекст не способен поменять её смысл.
V>Андроид тоже через нейтив рисует. Что помешало тебе пройтись по какому-нить онлайн-браузеру исходников андроида и посмотреть? V>Это большая-пребольшая редкость, когда контролы в Андроиде рисуются прямо в Джаве, то бишь в пикселы некоего промежуточного битмапа, а потом эти пикселы перегоняются на Canvas одной нейтивной операцией. Так делают только нубы какие-нить на коленках. V>Встроенные же контролы там рисуются через нейтивные же рисовальщики конкретной темы, а контролы из каких-нить профессиональных библиотек, типа Telerik, рисуются через JNI.
Для нашей дискуссии абсолютно не принципиально как оно там устроенно внутри (хоть на ассемблере, хоть на баше), если к этому нет физического доступа (нет никакого нативного API) из нативного кода. Доступ к значительной части системного API Андроида (в том числе и системному GUI) есть только из Java кода и это просто факт. Или может хочешь поспорить с этим? )))
V>>>https://www.enlightenment.org/ _>>EFL на Андроиде? Бредим? ))) V>А ты случаем не имел ввиду Enlightenment Desktop? V>EFL содержит кучу библиотек: V>https://www.enlightenment.org/about-efl
Ну понятно, можно фиксировать слив. )))
_>>Да, и кстати обрати внимание на то, что за сайт перед тобой, чтобы не было больше глупостей про "некую java библиотеку". Кстати, а мне вот интересно, ты действительно собирался реализовывать через NativeActivity например такой https://developer.android.com/guide/topics/ui/notifiers/notifications.html элемент GUI? ))) V>Боюсь, у меня для тебя плохие новости. V>Ты дал ссылку на систему регистрации обработчиков URI, а она там нейтивная и в андроиде как два пальца об асфальт зарегить нейтивный обработчик для т.н. "Intent" (см. доку). В этом смысле джавовский класс Intent — это тонкая обертка над нейтивной функциональностью. Этот механизм аналог виндового DDE.
Не прикидывайся дурачком. Речь не о том, как потом вызвать функцию приложения из уведомления. А о том как показать само уведомление. Банальная GUI операция с установкой иконки, заголовка и текста сообщения, выводимого в специальной области Андроида.
_>>Ха, вообще то Qt (да и Xamarin вроде тоже, судя по их описанию — сам руками не проверял) именно так и работает.
V>Дык, Xamarin — это управляемый код, а ты говоришь про QT.
Xamarin — это конечно управляемый код, только вот не совместимый с управляемым кодом Андроида. Поэтому для доступа к системному API Андроида ему необходимо производить точно такие же действия (написание специальной Java прокладки), как и обычному нативному коду.
_>>Для этого в Qt написали (на Java) универсальную обёртку, которая предоставляет нативному коду доступ ко всему API Андроида. Хотя при этом часть контролов они рисуют сами (в начале запросив все параметры системных через ту самую обёртку и полностью эмулируя их внешний вид) V>Боюсь, тут без ссылок на конкретные исходные файлы не обойтись. Потому что т.н. "системные параметры" — это наборы чисел, хендлов на битмапы и таблицы цветов.
Ну да, правильно, цвета, шрифты, размеры и т.п. Кстати, в Qt оно ещё и оптимизировано — анализ происходит при первом запуске приложения и в дальнейшем эти данные кэшируются в области данных приложения на диске.
_>>т.к. это их стандартный подход, но далеко не все (некоторые системные тут так просто не реализовать). V>Ну так контролы рисует джавовский код или, таки нейтивный? А у джавовского они лишь хендл канваса запрашивают у текущей Activity, ы?
В Qt? Смотря какие контролы. Какие могут, они рисуют сами. А какие не могут, вызывают Java код.
V>>>А теперь, барабанная дробь... ты сможешь назвать хоть одну альтернативную технологию, подходящую для интернета и дающую сравнимую эффективность? Очевидно, что НЕ сможешь. _>>Я правильно понял, что ты из тех... V>Так и запишем — ответить на прямой вопрос не в состоянии, сел в лужу. V>А сколько было пафоса.
Повторюсь снова, для совсем плохо читающих. Твой вопрос смешон уже в самой своей формулировке, потому как Silverlight уже не является "подходящей для интернета" технологией. Хотя бы в силу того, что он уже больше не работает в современных браузерах.
Да, так и не понял... Ты всё же готов применить ЭТО в новом проекте в 2016? )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Кстати, забавная свеженькая новость в тему обсуждения: http://www.playground.ru/blogs/call_of_duty_infinite_warfare/zapusk_call_of_duty_infinite_warfare_v_windows_store_epicheski_provalilsya-220579/. Причём я даже не в курсе (не играю в такое) как конкретно они реализовали там свою игрушку (UWP или просто WIN32 упакованный в appx) — похоже магазин хреново работает в любом случае. S>> Это говорит о том, что особо то эта игра никому не нужна.
_>В том то и дело, что у людей купивших её через Steam нет никаких проблем с поиском команды для игры. В отличие от пары инвалидов из Windows Store. )))
А вот скоро будут программы только под UWP ии?
Все зависит от контента. Если MS создаст программы только для UWP, то все будут перелезать на Win 10. Просто пока такого контента немного. Но и Win 10 всего год с небольшим.
Заметь, что покемонов портировали энтузиасты.
Сейчас кстати займусь UWP и портированием старых WPF приложений. Посмотрю, что это за зверь.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Ок, не ответил, значит фиксируем слив.
Спорить с Serginio1 [edited] НЕ СТОИТ [/edited]. Адекватного ответа или обсуждения не будет, будут мусорные простыни с надерганными отовсюду цитатами, к месту и не к месту.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, alex_public, Вы писали:
_>>Ок, не ответил, значит фиксируем слив.
ARK>Спорить с Serginio1 [edited] НЕ СТОИТ [/edited]. Адекватного ответа или обсуждения не будет, будут мусорные простыни с надерганными отовсюду цитатами, к месту и не к месту.
Для того что бы быть адекватным надо быть в теме. А ни я ни alex_public такими не являюемся. Другое дело что UWP пишутся. Сколько их неизвестно. Нет статистики.
Все остальное это только предположения как с моей так и с его стороны
и солнце б утром не вставало, когда бы не было меня
