Здравствуйте, Ночной Смотрящий, Вы писали:
V>>>>Была бы возможность сделать быстрый WPF, за 7 лет был бы сделан. НС>>>Докажи. V>>Это надо понимать так, что ты бы дал еще 7 лет???
НС>Это надо понимать, что твои заявления, как обычно, высосаны из пальца.
Докажи (С). А то юлить тут все горазды.
=============
Достаточно было выделить четверть ставки всего одного не самого глупого программиста на работу над эффективностью, и за год можно было бы достигнуть насыщения в плане перформанса (а если совсем не глупый, то 3-6 месяцев). Вот и доказательство — это из реальных проектов с не меньшим объемом того кода, который потребовалось бы тюнить.
А когда речь идёт о 7-ми годах, то ты тут в позе кривляющегося, разве что.
ЕА>Но вот тут х.з., сам не разбирался еще в этом вопросе, только в форумах видел жалобы, что в WinRt все нужные функции не заявлены и таки проблемы с АппСтором есть.
Блин, ты вообще понимаешь, что тебе пишут???
Раз оно доступно для АппСтора, то должно быть доступно для P-invoke.
Конкретно нейтивные GetKeyboardState и ToUnicode поддерживаются апсторным WinRT. А дотнетный p-invoke вообще сбоку и никакого эффекта в наличии функциональности не вносит — это же просто метаинформация, которая либо разресолвится дотнетным джитом, либо нет.
ЕА>Но то что из коробки нет такого события не позволяет мне считать это современной библиотекой.
Не свисти, из коробки есть CharacterReceived, т.е. ты можешь написать свой полноценный TextBox вообще с 0-ля.
ЕА>Я последний раз такой фигней с отслеживанием кнопочек страдал, когда на ассемблере прерывания клавиатуры обрабатывал.
Ясно... От IME настолько далеки, насколько это возможно. Ты здесь и сейчас изволишь путать скан-коды с высокоуровневой трансляцией.
Это же обязательная трансляция событий. Она тебе нужна будет в любом случае, если ты переводшь алфавит устройства ввода в алфавит команд. Вообрази, что ты в таче какие-то динамические зизаги захочешь использовать в кач-ве команд ввода? Попытайся мыслить шире этих несчастных кнопочек.
И сколько строчек алгоритм? 100? 200? )))
ЕА>Но только не надо мне рассказывать, что библиотека, которая собственные графические объекты не может в картинку записать, это вообще круто.
Ты сам себе противоречишь или не понимаешь происходящего.
Композиция — это и есть целевая картинка. А "проиграть" её может тебе захотеться не только на битмапе, но и на векторном формате (что более естественно) или на плоттере или в сеть отправить.
Эх... вот и выросло поколение, которое GDI не нюхало и не понимает графических абстракций...
Раньше "композиция" представляла из себя код — "черный ящик", который что-то рисует на GDI. И ты этому коду подсовывал разные абстракции для проигрывания одной и той же рисовательной последовательности. А сейчас у тебя полная свобода действий. Ты даже можешь в процессе любые эффекты и трансформации накладывать... Да вообще что угодно можно вытворять, это же не "чёрный ящик". Грех жаловаться-то...
ЕА>Обложить весь экран одинаковыми картинками это тоже самое, что заливка
Боюсь, для 3D это именно так.
Заметь, не одинаковыми картинками, а одной и той же картинкой. Ресурс-то один и тот же, ты обложишь весь экран командами рисования этого ресурса. Ферштейн? TiledBrush делала ровно то же самое.
MM>Мы раньше, блин, месаги слали, блин, сэндмессадж, блин, гетпарент, блин, никаких этих ваших РилайтивСоурс, блин. Программирование вырождается. Новый API спасение. Учите С++, блин. ТекстИнпут не могут, блин. Да раньше, блин, я его одной левой. СетВиндоуЛонг, понял!
Угу, все помнят твою реакцию на совет попробовать, наконец, DirectX, хотя бы дотнетный... бо забивать ваши гвозди этим жидким WPF г-ном у вас выходило не ахти... Ну ничо, побаловались и буде... никуда вы теперь не денетесь. Перестанете, наконец, гнать лажу и начнете делать вещи.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Зато он один и внедрён на нижний уровень всех вариаций Win8, а не добавлен в виде посторонних сервисов. Не знаю кому как, но такое воплощение вызывает больше доверия.
Да при чем тут доверие? Тут даже выбора не стоит никакого между WPF и WinRT, области их применения абсолютно не пересекаются.
НС>>Оттуда, что задача декларативного метроподобного UI уже была решена в рамках Windows Phone. При этом, что характерно, совместимость с SL там обеспечена максимальная, в отличие от WinRT.
ГВ>Вот именно — решена там, решена сям, а WinRT — единая платформа для всех
Не так. Задача была уже решена, но надо было изобрести велосипед.
ГВ>. По-моему, вполне рациональный подход, не?
Не.
ГВ> И если WinRT позиционируется в первую очередь для мобильных платформ, то тем более объяснимо: у Google свой стор+API, у Apple — свой, а MS чем хуже?
А у МС тоже уже был свой API. Правда, с фатальным недостатком.
НС>>Велосипед это WinRT. ГВ>Извини, но это чушь.
Извини, но это правда.
ГВ>Выходит, что несколько параллельных похожих друг на друга реализаций — это хорошо
Нет, это плохо.
ГВ>а одна общая замена для них — плохо?
С тобой невозможно разговаривать, ты "забываешь" все неудобные для твоих теорий факты. WinRT не является заменой ни для WPF, ни для SL (это объективно наблюдаемый факт, тут не о чем спорить), при этом полностью дублирует функционал WP API.
Здравствуйте, vdimas, Вы писали:
ЕА>>Но то что из коробки нет такого события не позволяет мне считать это современной библиотекой.
V>Не свисти, из коробки есть CharacterReceived, т.е. ты можешь написать свой полноценный TextBox вообще с 0-ля.
О точно, вру, они его таки добавили или починили. В превью версии винды были с этим какие-то проблемы.
Ладно, спасибо
ЕА>>Я последний раз такой фигней с отслеживанием кнопочек страдал, когда на ассемблере прерывания клавиатуры обрабатывал. V>Ясно... От IME настолько далеки, насколько это возможно. Ты здесь и сейчас изволишь путать скан-коды с высокоуровневой трансляцией.
Не надо понимать так буквально — я имел ввиду что давно не приходило в голову возиться с чем-то более низкоуровневом, чем уже готовый текст.
V>Это же обязательная трансляция событий. Она тебе нужна будет в любом случае, если ты переводишь алфавит устройства ввода в алфавит команд. Вообрази, что ты в таче какие-то динамические зизаги захочешь использовать в кач-ве команд ввода? Попытайся мыслить шире этих несчастных кнопочек.
И почему стандартную версию этого перевода не может делать для меня стандартная библиотека?
Или лучше спрошу так: "Почему я, тупой дотнетчик, должен радоваться исчезновению часто используемого евента, который во всех реализациях всегда был?"
Тач, кстати хороший пример — винрт предоставляет несколько уровней работы с тачем. Можно сырые нажатия отслеживать, а можно уже распознанные жесты. И приходится активно использовать и то, и другое.
Примерно так. Наверно чуток побольше — лениво смотреть.
Ну то есть, то что то, что всегда делалось в одну строчку, теперь требует 200 это улучшение?
ЕА>>Но только не надо мне рассказывать, что библиотека, которая собственные графические объекты не может в картинку записать, это вообще круто.
V>Композиция — это и есть целевая картинка. А "проиграть" её может тебе захотеться не только на битмапе, но и на векторном формате (что более естественно) или на плоттере или в сеть отправить.
Именно так, но только проигрывание на битмапе хотелось бы делать одной строчкой — это все-таки типовая операция.
ЕА>>Обложить весь экран одинаковыми картинками это тоже самое, что заливка
V>Боюсь, для 3D это именно так. V>Заметь, не одинаковыми картинками, а одной и той же картинкой. Ресурс-то один и тот же, ты обложишь весь экран командами рисования этого ресурса. Ферштейн? TiledBrush делала ровно то же самое.
По-моему это ты не понимаешь что такое абстракция — мне до лампочки как это внутри реализовано, и через что это выводиться. У меня есть абстракция — заливка, и есть места, где ее можно использовать.
Например, бекграунд кнопочки, или заливка текста, или контур произвольного Path. И использование этой заливки я могу задать в стиле, в биндинге итд.
Всем понятно, что можно весь экран ручками замостить одинаковыми элементами, но какое отношение приведенный тобой пример имеет к заливке ?
А так да, я могу DirectX-й сурфейс положить и вообще попиксельно рисовать все что мне захочеться.
Здравствуйте, Ночной Смотрящий, Вы писали:
ГВ>>Зато он один и внедрён на нижний уровень всех вариаций Win8, а не добавлен в виде посторонних сервисов. Не знаю кому как, но такое воплощение вызывает больше доверия. НС>Да при чем тут доверие? Тут даже выбора не стоит никакого между WPF и WinRT, области их применения абсолютно не пересекаются.
Угу. API схожи (http://metroapps.wikispaces.com/Delta+with+WPF), а области применения — разные.
НС>>>Оттуда, что задача декларативного метроподобного UI уже была решена в рамках Windows Phone. При этом, что характерно, совместимость с SL там обеспечена максимальная, в отличие от WinRT. ГВ>>Вот именно — решена там, решена сям, а WinRT — единая платформа для всех НС>Не так. Задача была уже решена, но надо было изобрести велосипед.
Допустим. А что на счёт десктопов? Приложения Windows Phone на десктопах работали до появления Win8?
ГВ>>. По-моему, вполне рациональный подход, не? НС>Не.
Почему?
ГВ>> И если WinRT позиционируется в первую очередь для мобильных платформ, то тем более объяснимо: у Google свой стор+API, у Apple — свой, а MS чем хуже? НС>А у МС тоже уже был свой API. Правда, с фатальным недостатком.
Угу, на десктопах не работал.
НС>>>Велосипед это WinRT. ГВ>>Извини, но это чушь. НС>Извини, но это правда.
С твоей точки зрения — может быть и правда. С моей — тоже в каком-то смысле правда, но тем не менее — чушь.
ГВ>>Выходит, что несколько параллельных похожих друг на друга реализаций — это хорошо НС>Нет, это плохо.
Ну хоть тут консенсус.
ГВ>>а одна общая замена для них — плохо? НС>С тобой невозможно разговаривать, ты "забываешь" все неудобные для твоих теорий факты.
Ты занят примерно тем же: отрицаешь всё то, где Синофски не предстаёт истеричным школьником, дорвавшимся до власти. Так что, поверь, мы стоим друг друга в этом отношении.
НС>WinRT не является заменой ни для WPF, ни для SL (это объективно наблюдаемый факт, тут не о чем спорить), при этом полностью дублирует функционал WP API.
То есть это никакой не велосипед, а перенос подходов, отработанных в WP на другую реализацию. При этом одновременно получаем ещё единый API и повышение быстродействия. Проигрываем в том, что две развитые библиотеки пришлось объявить ошибкой.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Ночной Смотрящий, Вы писали:
C>>>Вот он и не работает, на retina-display. НС>>Багрепорт уже отправил? C>Это известная проблема, не у одного меня.
Хм, у наших кастомеров всё работало... Собсна, первое, что я сделал после "а может SL прикрутим" — это накидал контролов и послал маководам.
Только на счёт ретины не в курсе.. У тебя ретина прямо в ОС вшита, может поэтому?
C>Ну и на Линуксе оно тоже нормально не работает вообще. Moonlight глючит чуть менее, чем в 100% случаев.
ГВ>Допустим. А что на счёт десктопов? Приложения Windows Phone на десктопах работали до появления Win8?
Наверное с 2005 года, Winforms приложения для Winmobile 6 запускались на десктопе, показывали окошки, лезли в сеть и т.п. Без эмулятора. Более того программисты которые писали мобильный софт для .NET, сначала на десктопе своё поделие тестировали, потому что проще и быстрее, а потом сразу на реальном железе, пропуская этап гоняния на эмуляторе.
Здравствуйте, Евгений Акиньшин, Вы писали:
V>>>>А кто тебе мешает пробежаться по графу композиции (там все открыто) и повторить на произвольной поверхности? V>>>>http://geoffwebbercross.blogspot.co.uk/2012/09/exporting-image-from-directx-2d-image_15.html ЕА>>>Ну собственно так и сделали. Для бешенной собаки сто верст не крюк. V>>И сколько строчек алгоритм? 100? 200? ))) ЕА>Примерно так. Наверно чуток побольше — лениво смотреть.
Значит вовсе не сто верст крюк, а максимум пол-дня однократной работы.
ЕА>Ну то есть, то что то, что всегда делалось в одну строчку, теперь требует 200 это улучшение?
Я думаю, что АПИ — это АПИ, а прикладные либы — это прикладные либы. Согласен, дотнетная обертка над WinRT пока не полноценная в том плане, что она пока немножко низкоуровневая, являясь фактически лишь зеркалом этого АПИ. Но ты сам себе показал, что базовые возможности фактически бесконечны, в сравнении с тем же WPF (где так просто DX-слои с XAML-слоями не перемешаешь) и тем паче в сравнении с SL. Это и есть та самая необходимая разработчикам свобода.
Ну а в прикладном плане тут возможны варианты:
— мильен третьесторонних тонюсеньких хелперов подо-все случаи жизни (ссылку на одну из таких либ уже давал);
А вот прямо компонент, тебе можно было не тратить пол-дня на написание своего элемента, а взять готовый WriteableBitmapEx.
— выпуск требуемого тебе под авторством MS в каком-нить неймспейсе WinRtExtensions в духе того, как она обычно это делает при очередном обновлении версии дотнета.
Прошло только пару месяцев, т.е. еще очень и очень рано делать выводы. На MS-сайте лежит официальный список нейтивного АПИ, еще не покрытого WinRT... Вот так — они прямо об этом и говорят, что этот АПИ доступен апсторовским приложениям. Так что, p-invoke в руки, как во времена первого дотнета и первых WinForms... Это не страшно, поверь.
V>>Композиция — это и есть целевая картинка. А "проиграть" её может тебе захотеться не только на битмапе, но и на векторном формате (что более естественно) или на плоттере или в сеть отправить. ЕА>Именно так, но только проигрывание на битмапе хотелось бы делать одной строчкой — это все-таки типовая операция.
Теперь это у тебя в одну строчку.
V>>Боюсь, для 3D это именно так. V>>Заметь, не одинаковыми картинками, а одной и той же картинкой. Ресурс-то один и тот же, ты обложишь весь экран командами рисования этого ресурса. Ферштейн? TiledBrush делала ровно то же самое.
ЕА>По-моему это ты не понимаешь что такое абстракция — мне до лампочки как это внутри реализовано, и через что это выводиться. У меня есть абстракция — заливка, и есть места, где ее можно использовать.
Правильно. Поэтому я тебе давал ссылку на полностью готовый WinRT XAML компонент, который можно использовать сразу из разметки.
ЕА>Например, бекграунд кнопочки, или заливка текста, или контур произвольного Path. И использование этой заливки я могу задать в стиле, в биндинге итд.
Дык, кто тебе мешает код по ссылке оформить в виде DependencyProperty соотв. контейнера?
Я уже молчу о том, что дух MetroUI — это всё-таки "плоская" заливка.
ЕА>Всем понятно, что можно весь экран ручками замостить одинаковыми элементами, но какое отношение приведенный тобой пример имеет к заливке ? ЕА>А так да, я могу DirectX-й сурфейс положить и вообще попиксельно рисовать все что мне захочеться.
Здравствуйте, vdimas, Вы писали:
V>Я думаю, что АПИ — это АПИ, а прикладные либы — это прикладные либы. Согласен, дотнетная обертка над WinRT пока не полноценная в том плане, что она пока немножко низкоуровневая, являясь фактически лишь зеркалом этого АПИ. Но ты сам себе показал, что базовые возможности фактически бесконечны, в сравнении с тем же WPF (где так просто DX-слои с XAML-слоями не перемешаешь) и тем паче в сравнении с SL. Это и есть та самая необходимая разработчикам свобода.
Ну тогда я думаю мы пришли к единому мнению. Твой первоначальный вопрос был — почему возмущаются дотнетчики, а мой ответ:
1) Лишили многих привычных плюшек
2) Работает только на метро стороне, поэтому почти всегда приходится держать вторую версию для сильверлайта\впф, где есть другие проблемы на которые теперь точно все забили
согласен?
V>А вот прямо компонент, тебе можно было не тратить пол-дня на написание своего элемента, а взять готовый WriteableBitmapEx.
Видел, он нам не подошел, в тот момент, когда этот вопрос решался. Кажись там функций для вывода текста не было, но точно не помню.
V>Прошло только пару месяцев, т.е. еще очень и очень рано делать выводы. На MS-сайте лежит официальный список нейтивного АПИ, еще не покрытого WinRT... Вот так — они прямо об этом и говорят, что этот АПИ доступен апсторовским приложениям. Так что, p-invoke в руки, как во времена первого дотнета и первых WinForms... Это не страшно, поверь.
Не так меня просто напугать, я и в кодах когда-то писал, и на асме, и на си. Просто сейчас мне больше не охота писать низкоуровневые велосипеды, а больше нравиться работать на высоком уровне абстракции.
ЕА>>Например, бекграунд кнопочки, или заливка текста, или контур произвольного Path. И использование этой заливки я могу задать в стиле, в биндинге итд.
V>Дык, кто тебе мешает код по ссылке оформить в виде DependencyProperty соотв. контейнера?
Не всегда так получиться, например выставляешь заливку кнопочке, а она по факту применяется внутри ее шаблона к разным подэлементам, да еще в зависимости от условий, да еще по разному в разных состояниях.
V>Именно так. Тебе доступна произвольная ф-сть. Та самая, о нехватке которой так долго говорили WPF-разработчики. Можно даже изращаться с GDI+: http://blogs.telerik.com/blogs/posts/12-05-09/gdi-in-a-windows-8-c-metro-application-experimenting-for-fun.aspx
В Windows Store с такими извращениями не пустют. И на ARM-е, скорее всего, не запустится.
Здравствуйте, michae1, Вы писали:
M>Смешно, улыбнул. Можешь привести пример при каких условиях OleView соврет, очень мне интересно поглядеть.
Конечно. Пишешь мусор в idl, компилишь, смотришь в OleView — тот же самый мусор. Ты в курсе, что в tlb часто далеко не все поддерживаемые интерфейсы прописываются ?
M>Что чушь? Что существует две идеологии информировании об ошибке? COM-объект возвращает HRESULT а уже как с ним работать — на твое усмотрение, хочешь ставь проверки, хочешь кидай ексепшн (_com_ptr позволяет это автоматизировать)
HRESULT это ручная дистетчеризация ошибок — крайне ненадежное решение.
>>>Вообще, для сведения, _com_ptr_t обертка генерирует _com_error эксепшн но ты можешь юзать CComPtr и работать с кодами ошибок. I>>Ты в курсе, что это костыль и он не покрывает всех сценариев ?
M>Нет, я не в курсе что это костыль прекросно работает. Напиши свой ну и ради интереса что ж он не покрывает?
Указатель можно передавать в другой компонент, а там про твой костыль никто не знает. А исключения будут работать в любом случае.
Здравствуйте, IT, Вы писали:
IT>Если SL работает, то он работает везде одинаково. А работает он как минимум везде, где мне когда-либо было нужно. И хватит уже тролить на эту тему. Только законченному фанату с промытыми мозгами не понятно, что как технология JS+CSS в сравнении с SL — это позапрошлый век.
Так нам что, обсуждать где тебе чего было нужно или особенности твоего восприятия ? Дела в микрософте показывают что SL уже отжил своё и его надо как минимум реанимировать.
Кстати, может, дело не в моём троллинге, а в нищебродской конторе где не бывает ни iMac, ни Macbook, ни планшетов, ни линукса, а взамен всего этого есть что нибудь навроде дресскода ?
Здравствуйте, hi_octane, Вы писали:
D>>Мда... Не надо думать, ты здесь один Д'Артаньян. Если бы я один раз установил и в последующие разы все было ОК, я бы даже и не думал сюда писать.
_>У меня похожее было — ищи косяк в настройках безопасности, или в том что аддон SL'я запрещён.
У некоторых юзеров которые сидели за Kerio Firewall всякая хрень творилась. Я даже разбираться не стал, написал что бы пробили в печень одмину.
Здравствуйте, vdimas, Вы писали:
V>Баги можно починить. А Win8 уже не починишь.
Починят с будущими апдейтами.
V>В Win8 они не дают пользоваться другими приложениями, пока сами активны. V>Таки зря отказались от перекрывающихся окошек... V>ИМХО, достаточно было подкрутить умолчательный лейаут окошеки всё, а не навязвать его отсутствие.
А какими приложениями вы пользуетесь пока другие активны не в вин8?
А вообще, если не хотите пользоваться вин8 приложениями, то пользуйтесь обычными? Это ли не свобода выбора?
Здравствуйте, Yoriсk, Вы писали:
C>>Это известная проблема, не у одного меня. Y>Хм, у наших кастомеров всё работало... Собсна, первое, что я сделал после "а может SL прикрутим" — это накидал контролов и послал маководам.
В режиме эмуляции обычного разрешения оно работает.
Y>Только на счёт ретины не в курсе.. У тебя ретина прямо в ОС вшита, может поэтому?
Т.е.? Retina display — это дисплей с двойным разрешением, и у плагинов для браузеров должна быть его поддержка. Иначе глючит. Flash и Java выпускали специальные обновления для retina.
C>>Ну и на Линуксе оно тоже нормально не работает вообще. Moonlight глючит чуть менее, чем в 100% случаев. Y>Линукс? Нет, не слышал.
Ну выучи такое слово: "Android".
