Здравствуйте, Sinix, Вы писали:
S>Пару лет назад баловался с подобными самплами, особых проблем не было. В продакшн ничего не ушло, говорить о 100% беспроблемности не могу.
Я уже говорил, что думаю о наивных попытках реализации видео через серию прогоняемых битмапных хендлов.
S>Ну вот, вы сами пришли к выводу, что для вашей задачи WPF (в текущем виде) абсолютно не нужен.
Так если по косточкам разобрать, то куда ни ткни — он не нужен.
От того WinForms живее всех живых. Скажу больше, до тех пор, пока забацать свой контрол будет дешевле по трудоемкости на WinForms, FPW будет оставаться поделкой. Он пока выигрывает только там, где для решения задачи потребовалось бы городить свою иерархию windowless-контролов. Что касается остального, например шаблонов данных... Мощная фича, особенно для экспериментов. Но абсолютно не нужная в продакшн, т.к. в конечном продукте той гибкости отображения никогда не будет (я не имею ввиду скины, они не требуют шаблонов данных), т.е. данные всё равно обычно отображаются согласно некоей спецификации. И где эта спецификация реализована: в шаблонах или в конкретных контролах — вовсе не принципиально с т.з. трудоемкости. И даже не принципиально с т.з. разделения труда (помнишь как они задвигали концепцию: дизайнеры GUI и программисты работают одновременно над одной и той же единицей GUI и никто друг другу не мешает? Утопия, как выяснилось. Только по очереди, как и всегда.)
Другое дело, что если бы WPF позволял бы так доопределять дизайн, как позволяет CSS применительно к HTML... Но этот флейм уже был, неохота возвращаться. Лишь выскажу опять сожаление, что в WPF не реализован такой доказавший свою жизнеспособность сценарий, что ИМХО есть вовсе ему не на пользу. Да, нечто подобное может быть допилено сверху, если рассматривать WPF как запчасти от Lego. Но работы много — раз, и что там со стандартизацией? — два.
Здравствуйте, khimiki, Вы писали:
K>Вот я хочу на WPF окне разместить холст, в котором мне нужно отрисовывать графику с аппаратным ускорением. И что оказывается? Оказывается, что .NET этого не умеет в том смысле, что штатного способа сделать это — нет. Ну разве не балайка этот .NET?
Ты насколько подробно сам разбирался в этом, чтобы давать столь хамско-снисходительные ссылки? Ведь ты же послал искать костыли, допиливания и хаки, что как бэ противоречит предыдущему громогласному заявлению насчет "матчасти". Реально, без допиливания половины рендеринга WPF, ничего путного сделать нельзя. "Родные" 2D и 3D сцены работают крайне медленно, из-за самого механизма построения сцен.
Tim Dawson, MVP:
Nothing about WPF is really "high performance". If you want to draw a lot of primitives, inherit FrameworkElement and override OnRender, using the DrawingContext to perform all your drawing.
И даже в этом случае, сливаем в 2-5 раз по сравнению с обычным DirectX.
Отображение своего видео из собственного источника — невозможно в адекватном виде. Вернее, возможно через пару хаков, но они крайне не эффективны, ибо заточены под битмап как хендл, а не под массив обычных пикселей. Чтобы иметь хоть какое-то преддставленпие о чем речь, неплохо бы ознакомиться хотя бы с чем-нить высокоуровневым, например с DirectShow. Как можно давать ссылки на пример, который предлагает 20-30 раз в секунду создавать/грохать bitmap handle для каждого видеопотока? Это я имел ввиду примеры с InteropBitmap, на которые введут много ссылок. Сто раз было уже обжеванно, что лучше всего работает классический bitmap section для GDI или surface из DirectX (оба способа умеют работать с пикселями напрямую, и объекты эти лежат чаще всего в памяти видюхи + создаются под ее родной текущий формат дисплея + драйвер пересылает пиксели через DMA зачастую), но вот это-то нам и недоступно даже через reflection, ибо рендеринг WPF идет в другом потоке и выполняется нативной либой.
На самом деле вообще нет штатных способов быстро передать данные для отображения в WPF. Эта либа может построить большую относительно статическую картинку из примитивов, но вот с динамикой сложных сцен или видео — траблы. Справедливости ради, вывод готового видео доступен в виде эдакого "черного ящика", но не доступно самое важное — граф обработки этого видео. Поэтому, можно считать что видео-возможности отсутствуют, ибо для простого вывода видео-файла по некоему URI с тем же успехом можно посадить обычный MediaPlayer ActiveX.
S>Если вербализуете ваши тайные желания — даже не поленюсь скопировать вам нужные ссылки.
Попробуй еще раз, а мы посмотрим, насколько они окажутся нужные. А то все такие важные... как дети, чесслово.
На самом деле никакой магии нет. Берем и хостим обычное виндовое окно, например пользуем хост для WinForms. В нем инициализируем DirectX или даже AVICap, берем surface для видео (или preview window для AVICap), или же сами строим сцены для DirectX обычным способом. С потоками тоже разбираемся сами (а не даем наивные сылки на примеры многопоточности рендеринга в WPF ). С оверлеями тоже разбираемся сами (кроме случая AVICap). В конечном итоге, WPF тут не при чем и никак не помогает, а только мешает, ибо контроль за временем жизни хоста зависит теперь от WPF.
Вот я хочу на WPF окне разместить холст, в котором мне нужно отрисовывать графику с аппаратным ускорением. И что оказывается? Оказывается, что .NET этого не умеет в том смысле, что штатного способа сделать это — нет. Ну разве не балайка этот .NET?
Здравствуйте, Sinix, Вы писали:
K>>Вот я хочу на WPF окне разместить холст, в котором мне нужно отрисовывать графику с аппаратным ускорением. И что оказывается? Оказывается, что .NET этого не умеет в том смысле, что штатного способа сделать это — нет. Ну разве не балайка этот .NET? S>Вброс не защитан, идите учить матчасть.
да не вброс это, это такой эффективный способ задавать реальные вопросы в КСВ — народ всё больше проникается мыслью что тут быстрее ответят
Здравствуйте, MxMsk, Вы писали:
V>>Ну дык, если у "хорошо разбирающихся" программистов столько кода (а значит времени) на простые GUI-сценарии уходит, что говорить про остальных. И что характерно... Что 90% предлагаемых решений неочевидны, не следуют из доки, а требуют быть "эльфом 80-го уровня" в этой либе. MM>Откуда эта цифра — 90%? Выглядит логичным, что на форуме спрашивают о сложных и нетривиальных решениях. По Windows Forms до сих пор появляются вопросы про BeginInvoke, хотя казалось бы, чего уж проще. Далее, ты забываешь, что "очевидность" решений Windows Forms вытекает только из того, что оно близко к ранее существовавшим аналогичным FW. Это плюс для вхождения, но минус для развития. Шаг вправо или влево от WinAPI и упираемся в кучу проблем, когда тривиальная задача комбинирования контролов превращается в геморрой.
Комбинирование не предназначенных для комбинирования контролов всегда будет гемморойным. Ибо не в HWND загвоздка, а в распространении событий. И с этим геморроем бодался лично в WPF, когда накачал кучу вариантов необходимых контролов "отовсюду" и как раз экспериментировал с комбинированием. Кто-то наверху не так зароутил событие — получи геммор на нижнем уровне.
В общем, не там проблему ищешь. Разумеется, возможности конторлов, прибитых гвоздями к HWND ограничены, и не зря были созданы когда-то windowless ActiveX. Но там более жестко отделили функциональность хоста котролов от самих контролов, т.е. возможности по комбинацию этих контролов упорядочили. А тут ничего не упорядочили и все нетипизировано. Подал для высокоуровневой структуры один шаблон данных — работает. Для дочернего узла данных другой шаблон — тоже работает. Но вот какое-то из сочетаний этих шаблонов разных уровней вдруг перестает работать, потому как по шаблонам создалось visual tree, где элементы навели друг на друга побочные эффекты. Получал сию картину в экспериментах неоднократно. И наблюдал очень интересные артефакты лейаута. И пахнет всё это какой-то лажей, потому как подобных артефактов, для примера, в том же HTML ты ни в жисть не добъешься. Ну не должен child выскакивать визуально за родителя ни при каких раскладах.
V>>Хотя и люблю "порыться" в реализациях до самого дна, как говорится, но в награду хотелось бы получать интересные найденные решения, а не сомнительной очевидности костыли "по-месту". MM>Ну я же не виноват, что ты в .Net GUI выискиваешь темы про "костыли".
Потому как для нужных мне вещей не нашлось штатных ср-в.
Посмотрев массу чужих костылей, обнаружил низкое их качество. К тому же поезд как бы немного ушел. Нормальный дизайн контролов всего пару лет как, а вменяемые инструменты для дизайна так вообще только год как. Ту-ту... Пик интереса к технологии прошел, обернулось всё пшиком. Ты бы поискал за 2005-й год, какие здесь были ново-васюковские размышлизмы от популярных на форуме спецов относительно "светлого будущего" грядущего Авалона (на тот момен ОНО так называлось). Пшик и всё... Утверждалось вплоть до того, что старый интерфейс GDI будет построен сверху Авалона для предоставления совместимости "устаревшим" приложением... А в итоге MS делает для своих продуктов DUI70.dll (С++ GUI либа поверх DirectX), и юзает только её практически во всей линейке, начиная от Эксплорера... а вы кушайте так и не выстреливший WPF.
Поверь, технологию эту ждали и возлагали надежды. И ваш покорный слуга в т.ч.
V>>Смотря что кастомизировать. Если внешний вид — то согласен. Но это никогда не было критичным с т.з. трудоемкости. А вот с т.з. поведения... Тут ты категорически не прав, ибо проще в разы. MM>Пример?
Пример заключется в том, что PretranslateMessage() хоть и беднее в разы роутинга WPF, но так же дает меньше степеней свободы для глупых ошибок. По крайней мере свой командный фреймворк с поддержкой визуального дизайн-тайм для WinForms был написан когда-то за вечер, в то время как не будь похожей функциональности у WPF, даже не понятно, стоило бы за такое браться, возникни необходимость. Ибо ни одним, ни двумя вечерами тут не обойдешься.
Здравствуйте, vdimas, Вы писали:
V>Пример заключется в том, что PretranslateMessage() хоть и беднее в разы роутинга WPF, но так же дает меньше степеней свободы для глупых ошибок. По крайней мере свой командный фреймворк с поддержкой визуального дизайн-тайм для WinForms был написан когда-то за вечер, в то время как не будь похожей функциональности у WPF, даже не понятно, стоило бы за такое браться, возникни необходимость. Ибо ни одним, ни двумя вечерами тут не обойдешься.
Блин, вот умеешь ты наваять громадный постинг, ничего по делу не сказав. С меня хватит. Пойду запускать программы...
Здравствуйте, Sinix, Вы писали:
V>>Другое дело, что если бы WPF позволял бы так доопределять дизайн, как позволяет CSS применительно к HTML... S>При прямых руках, необходимости и достаточном терпении — позволяет.
Ну дык, при желании и свой WPF нарисовать можно, мы же говорим об имеющемся.
V>> в WPF не реализован такой доказавший свою жизнеспособность сценарий, что ИМХО есть вовсе ему не на пользу. S>в WPF нет стилей?
S>>http://lmgtfy.com/?q=wpf+hosting+directx S>>http://lmgtfy.com/?q=wpf+hosting+gdi S>>http://lmgtfy.com/?q=wpf+High+performance+graphics K>Привидите, пожалуйста, официально одобренный MS способ хостинга.
Вам что надо-то? Конкретно только. Под ваш запрос все три ссылки подходят. И ответы по всем трём используют исключительно возможности фреймворка.
K>Я рабочий IT индустрии, а не шаман.
Ээээ, дорогой, с каких пор использование гугля — это шаманство???
Если вас раздражает необходимость постоянно учиться, то боюсь, с профессией вам не повезло.
Здравствуйте, vdimas, Вы писали:
S>>Речь при разделении шла совсем не об этом. Вместо "слепили в фотошопе -> разработчик изображает нечто похожее" сделали переход к "дизайн в XAML — разработчик прикручивает логику". И даже одновременно работать неплохо выходит.
V>Ты это чисто теоретически задвинул, или у вас сидит реально живой человек-дизайнер, который вместо связки дизайнерских пакетов (обычно далеко не только Фотошоп), отныне удовлетворяется убогим ExpressionBlend?
Практически Дизайнер — эт не человек, ваяющий прекрасное в избранном пакете, а человек, отвечающий за look'n'feel приложения. Соответственно, основная работа — вовсе не "сделать красиво" путём навтыкивания битмапов (в WPF такое оочень тяжело взлетит — придётся прибивать гвоздями всё что можно и низзя). Blend, при всей убогости на порядок (а со sketchflow — на два) удобнее студии для быстрого прототипирования. Дело за малым — облагородить созданный XAML
У нас реально параллельная работа была очень давно (и врядли будет ещё — весь UI разбит на workspace, так что простыней для совместной работы практически нет), но, тем не менее, особых проблем не возникало.
V>Я в эту чушь все-равно не поверю. А если действительно так, то нарезать битмапы и покрывать ими пространство можно было и в дизайнерах WinForms, бо пользоваться ими не сложней фотошопа а как бы скорее в разы наоборот.
Я пожалуй напомню вам ваше оригинальное
Ты насколько подробно сам разбирался в этом, чтобы давать столь хамско-снисходительные ссылки?
Здравствуйте, MxMsk, Вы писали:
V>>Судя по твоим вопросам и ответам по WPF в последний год-другой и прикидкам требуемого времени на все эти мелочи — скорее я прав по состоянию дел на сегодня. Реально трудоемкость высокая выходит для простейших чихов. И это вполне объективно и ожидаемо из-за большого информационного пространства, составляющего все мелочи и подробности самого WPF. Т.е. деталей слишком много получается, и мало у кого даже сегодня, спустя 4 года, получается так, чтобы написал что-то не совсем тривиальное — и оно сразу правильно и ожидаемо заработало. Для сравнения: на WinForms народ стал адекватно шустро буквально в первые месяцы. MM>Я, конечно, польщен, что мои ответы по WPF позволяют оценить состояние индустрии по части Windows Forms vs WPF.
Ну дык, если у "хорошо разбирающихся" программистов столько кода (а значит времени) на простые GUI-сценарии уходит, что говорить про остальных. И что характерно... Что 90% предлагаемых решений неочевидны, не следуют из доки, а требуют быть "эльфом 80-го уровня" в этой либе.
Много чести.
Хотя и люблю "порыться" в реализациях до самого дна, как говорится, но в награду хотелось бы получать интересные найденные решения, а не сомнительной очевидности костыли "по-месту".
MM>Написанное никак не противоречит тому, что я сказал. Если человек не разбирается в WPF, то он естественно будет долго выжимать из себя приемлемое решение.
А банальностям вообще редко что противоречит. Но и пользы от них никакой.
MM>Да и на Windows Forms серьезный контрол — такая же кропотливая работа, только это будет, как ты выражаешься, "гвоздями прибитая" реализация, кастомизация которой в итоге окажется в разы сложнее WPF-ной.
Смотря что кастомизировать. Если внешний вид — то согласен. Но это никогда не было критичным с т.з. трудоемкости. А вот с т.з. поведения... Тут ты категорически не прав, ибо проще в разы.
Здравствуйте, vdimas, Вы писали:
S>>Соответственно, основная работа — вовсе не "сделать красиво" путём навтыкивания битмапов (в WPF такое оочень тяжело взлетит — придётся прибивать гвоздями всё что можно и низзя). V>Ребрендинг без битмапов никак, увы.
Хх Если не брать в расчёт весьма специфичный софт наподобие плееров, изменение стандартных контролов — оччень плохая штука. Куда больше усилий дизайнера уходит на то чтобы создать удобное "лицо" софтины, используя лишь стандартные средства (возможно, с внесением небольших нюансов). А для специфичного софта — Expression Design
V>На одних градиентах и полупрозрачностях далеко не уедешь. Да и эффективнее битмапы минимум в 2 раза чем полупрозрачности. Так что вместо статических мест с полупрозрачностями эффективнее отрендерить заранее и нарезать готовых картинок.
Вперёд Наблюдал десятки подобных тварений на нестандартных DPI. Мягко говоря, уныло. Но, если так приспичило — кто вам запрещает использовать картинки в XAML?
S>>Blend, при всей убогости на порядок (а со sketchflow — на два) удобнее студии для быстрого прототипирования. Дело за малым — облагородить созданный XAML V>Вообще, прототипировать GUI должны аналитики, и делать это можно хоть в Visio.
Кажется я понял. Под дизайнерами вы понимаете художников, а под аналитиками — специалистов по usability, так? Иначе ваши советы имеют оочень слабое отношение к процессу создания UI для WPF-софтин. И да, визио ещё меньше подходит для прототипирования, чем студия
V> Даже скорее желательно делать в чём-то типа Visio, ибо есть поддержка аннотаций и прочих прелестей именно для целей прототипирования.
Вы таки сначала ознакомьтесь (весь сериал — по тегу).
V>И там довольно скучные квадратики выходят, ибо прототип нужен исключительно для разработки use-case относительно GUI. А вот забрендить потом это все — задача художника.
Увы, когда гуй дизайнят по квадратикам, да ещё и люди без соответствующего опыта, закономерно выходит полное УГ.
S>>Так вот...
V>Работал с "заказными" дизайнерами. Представляю как и что они делают. Скажу, что эффективно и грамотно, и не представляю ExpressionBlend в их руках, ибо это означает губить таким людям производительность их труда.
Подколка была не про это. Помимо бленда есть, в частности, Expression Design. По нужным для дизайна UI возможностям он не сильно уступает корел дрову. Если люди брезгуютЪ — есть куча конвертеров + потребуется лишние усилия для перевода нарисованного в XAML. Только толку от такого человека как от дизайнера UI — 0 и меньше.
Здравствуйте, iHateLogins, Вы писали:
HL>Здравствуйте, khimiki, Вы писали:
K>>Вот я хочу на WPF окне разместить холст, в котором мне нужно отрисовывать графику с аппаратным ускорением. И что оказывается? Оказывается, что .NET этого не умеет в том смысле, что штатного способа сделать это — нет. Ну разве не балайка этот .NET?
HL>По теме: WPF — очередной факап микрософта по части UI. Если сейчас выбирать технологию для rich client-а под винду, то WPF — последнее, что надо рассматривать. Тот же Windows.Forms стабильнее, проще и удобнее на порядок. Да и быстрее. Да что там Windows.Forms — последние браузеры (тот же IE9, например) поддерживают аппаратное ускорение отрисовки, так что "детский" HTML с "несерьезным" джаваскриптом побыстрее будет, чем монстровый WPF.
WPF вполне нормальная технология, более того я не вижу ни одной причины использовать чистый WinForms
HL>Обидно, что студию под WPF переписали. Ой, чую, придется чувакам её обратно на Windows.Forms переписывать
Здравствуйте, Sinix, Вы писали:
V>>Работал с "заказными" дизайнерами. Представляю как и что они делают. Скажу, что эффективно и грамотно, и не представляю ExpressionBlend в их руках, ибо это означает губить таким людям производительность их труда. S>Подколка была не про это. Помимо бленда есть, в частности, Expression Design. По нужным для дизайна UI возможностям он не сильно уступает корел дрову. Если люди брезгуютЪ — есть куча конвертеров + потребуется лишние усилия для перевода нарисованного в XAML. Только толку от такого человека как от дизайнера UI — 0 и меньше.
Да, спасибо за наводки. Прошелся по состоянию инструментов на сегодня. В общем, у же примерно год как есть адекватный набор инструментов как для дизайнеров, так и аналитиков. Особенно вот этот sketchflow любопытен. Удивительно, что не слышно бурных обсуждений сих продуктов и повсеместного дележа впечатлениями.
Здравствуйте, ylem, Вы писали:
Y>Хуже балалайки. На балалайке хоть струны есть и играть можно, если умеешь. Y>А на .NET-е даже не сыграешь.
Так вот и я о том же. Другими словами, балалайка выполняет предъявляемые к ней требования — производит музыку. А .NET — это скорее балалайка, но без одной струны. Издали вроде похожа на музыкальный инструмент, а возьмёшь её в руки и станет понятно, что играть на ней может только Поганини. Я, к сожалению, не Поганини.
Здравствуйте, Antikrot, Вы писали:
A>да не вброс это, это такой эффективный способ задавать реальные вопросы в КСВ — народ всё больше проникается мыслью что тут быстрее ответят
В тех форумах, где слежу, ответов всегда больше, чем вопросов. Конкуренция
... K>.. что играть на ней может только Поганини. Я, к сожалению, не Поганини.
Ой, не Поганини ты, не Поганини!!!
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
Здравствуйте, vdimas, Вы писали:
V>Ты насколько подробно сам разбирался в этом, чтобы давать столь хамско-снисходительные ссылки?
Человеку явно хотелось потрындеть. На вопросы в профильных форумах я так никогда не отвечаю.
V>Реально, без допиливания половины рендеринга WPF, ничего путного сделать нельзя. "Родные" 2D и 3D сцены работают крайне медленно, из-за самого механизма построения сцен.
Напомню постановку задачи
Вот я хочу на WPF окне разместить холст, в котором мне нужно отрисовывать графику с аппаратным ускорением.
Пару лет назад баловался с подобными самплами, особых проблем не было. В продакшн ничего не ушло, говорить о 100% беспроблемности не могу.
V>На самом деле вообще нет штатных способов быстро передать данные для отображения в WPF. Эта либа может построить большую относительно статическую картинку из примитивов, но вот с динамикой сложных сцен или видео — траблы.
Для подобных задач всегда можно захостить нативный контрол/dx surface.
V>На самом деле никакой магии нет. ... В конечном итоге, WPF тут не при чем и никак не помогает, а только мешает, ибо контроль за временем жизни хоста зависит теперь от WPF.
Ну вот, вы сами пришли к выводу, что для вашей задачи WPF (в текущем виде) абсолютно не нужен. Только при чём здесь ".Net — балалайка"?
Здравствуйте, Sinix, Вы писали:
S> V>Ты насколько подробно сам разбирался в этом, чтобы давать столь хамско-снисходительные ссылки?
S> Человеку явно хотелось потрындеть. На вопросы в профильных форумах я так никогда не отвечаю.
Так здесь для "потрындеть", как раз таки профильный
Здравствуйте, hattab, Вы писали:
V>>>Ты насколько подробно сам разбирался в этом, чтобы давать столь хамско-снисходительные ссылки? S>> Человеку явно хотелось потрындеть. На вопросы в профильных форумах я так никогда не отвечаю. H>Так здесь для "потрындеть", как раз таки профильный
Тогда тем более ответ в тему. Какие ваши претензии?
Здравствуйте, khimiki, Вы писали:
K>Вот я хочу на WPF окне разместить холст, в котором мне нужно отрисовывать графику с аппаратным ускорением. И что оказывается? Оказывается, что .NET этого не умеет в том смысле, что штатного способа сделать это — нет. Ну разве не балайка этот .NET?
Ну да, балалайка. Скажу по секрету, сейчас соотношение разработчиков в команде Silverlight и WPF 10 к одному. Не в пользу WPF, конечно
По теме: WPF — очередной факап микрософта по части UI. Если сейчас выбирать технологию для rich client-а под винду, то WPF — последнее, что надо рассматривать. Тот же Windows.Forms стабильнее, проще и удобнее на порядок. Да и быстрее. Да что там Windows.Forms — последние браузеры (тот же IE9, например) поддерживают аппаратное ускорение отрисовки, так что "детский" HTML с "несерьезным" джаваскриптом побыстрее будет, чем монстровый WPF.
Обидно, что студию под WPF переписали. Ой, чую, придется чувакам её обратно на Windows.Forms переписывать
Здравствуйте, iHateLogins, Вы писали:
HL>Ну да, балалайка. Скажу по секрету, сейчас соотношение разработчиков в команде Silverlight и WPF 10 к одному. Не в пользу WPF, конечно
Пруф?
HL>Ну да, балалайка. Скажу по секрету, сейчас соотношение разработчиков в команде Silverlight и WPF 10 к одному. Не в пользу WPF, конечно
HL>По теме: WPF — очередной факап микрософта по части UI. Если сейчас выбирать технологию для rich client-а под винду, то WPF — последнее, что надо рассматривать. Тот же Windows.Forms стабильнее, проще и удобнее на порядок. Да и быстрее. Да что там Windows.Forms — последние браузеры (тот же IE9, например) поддерживают аппаратное ускорение отрисовки, так что "детский" HTML с "несерьезным" джаваскриптом побыстрее будет, чем монстровый WPF.
HL>Обидно, что студию под WPF переписали. Ой, чую, придется чувакам её обратно на Windows.Forms переписывать
Всё это очень, очень печально. Сейчас встаёт передо мной задача по разработке софта для решения задач транспортировки крупногабаритных грузов. Концептуально это должна быть форма, на одной части которой находятся различные контролы, на другой происходит отрисовка груза с показом изгибов, деформаций и так далее. Мучительно думаю, какую среду разработки применять? Что, кам бэк ту дельфи?
Здравствуйте, Sinix, Вы писали:
S> V>>>Ты насколько подробно сам разбирался в этом, чтобы давать столь хамско-снисходительные ссылки?
S> S>> Человеку явно хотелось потрындеть. На вопросы в профильных форумах я так никогда не отвечаю.
S> H>Так здесь для "потрындеть", как раз таки профильный
S> Тогда тем более ответ в тему. Какие ваши претензии?
HL>>Ну да, балалайка. Скажу по секрету, сейчас соотношение разработчиков в команде Silverlight и WPF 10 к одному. Не в пользу WPF, конечно
HL>>По теме: WPF — очередной факап микрософта по части UI. Если сейчас выбирать технологию для rich client-а под винду, то WPF — последнее, что надо рассматривать. Тот же Windows.Forms стабильнее, проще и удобнее на порядок. Да и быстрее. Да что там Windows.Forms — последние браузеры (тот же IE9, например) поддерживают аппаратное ускорение отрисовки, так что "детский" HTML с "несерьезным" джаваскриптом побыстрее будет, чем монстровый WPF.
HL>>Обидно, что студию под WPF переписали. Ой, чую, придется чувакам её обратно на Windows.Forms переписывать
K>Всё это очень, очень печально. Сейчас встаёт передо мной задача по разработке софта для решения задач транспортировки крупногабаритных грузов. Концептуально это должна быть форма, на одной части которой находятся различные контролы, на другой происходит отрисовка груза с показом изгибов, деформаций и так далее. Мучительно думаю, какую среду разработки применять? Что, кам бэк ту дельфи?
Здравствуйте, khimiki, Вы писали:
HL>>Обидно, что студию под WPF переписали. Ой, чую, придется чувакам её обратно на Windows.Forms переписывать
K>Всё это очень, очень печально. Сейчас встаёт передо мной задача по разработке софта для решения задач транспортировки крупногабаритных
грузов. Концептуально это должна быть форма, на одной части которой находятся различные контролы, на другой происходит отрисовка груза с показом изгибов, деформаций и так далее. Мучительно думаю, какую среду разработки применять? Что, кам бэк ту дельфи?
Выбирай винформс последний + какой-нить компонент для отрисовки, их сейчас завались сколько.
Здравствуйте, henson, Вы писали:
H>Здравствуйте, iHateLogins, Вы писали:
HL>>Здравствуйте, khimiki, Вы писали:
K>>>Вот я хочу на WPF окне разместить холст, в котором мне нужно отрисовывать графику с аппаратным ускорением. И что оказывается? Оказывается, что .NET этого не умеет в том смысле, что штатного способа сделать это — нет. Ну разве не балайка этот .NET?
HL>>По теме: WPF — очередной факап микрософта по части UI. Если сейчас выбирать технологию для rich client-а под винду, то WPF — последнее, что надо рассматривать. Тот же Windows.Forms стабильнее, проще и удобнее на порядок. Да и быстрее. Да что там Windows.Forms — последние браузеры (тот же IE9, например) поддерживают аппаратное ускорение отрисовки, так что "детский" HTML с "несерьезным" джаваскриптом побыстрее будет, чем монстровый WPF.
H>WPF вполне нормальная технология, более того я не вижу ни одной причины использовать чистый WinForms
HL>>Обидно, что студию под WPF переписали. Ой, чую, придется чувакам её обратно на Windows.Forms переписывать
H>Не будет этого
Здравствуйте, blackhearted, Вы писали:
B>Здравствуйте, henson, Вы писали:
HL>>>Обидно, что студию под WPF переписали. Ой, чую, придется чувакам её обратно на Windows.Forms переписывать
H>>Не будет этого
B>Как тут любят говрить? B>Пруф?
Сначала пруф на то что будут в Windows.Forms переписывать
Здравствуйте, vdimas, Вы писали:
V>От того WinForms живее всех живых. Скажу больше, до тех пор, пока забацать свой контрол будет дешевле по трудоемкости на WinForms, FPW будет оставаться поделкой.
Это уже года два как свершилось
Материал из Википедии — свободной энциклопедии, -_*
V>Я уже говорил, что думаю о наивных попытках реализации видео через серию прогоняемых битмапных хендлов.
Вы бы ознакомились сначала Ни по первой ссылке, ни по второй нет ни одного упоминания про хендлы. Там всё, как вы и просили —
В нем инициализируем DirectX или даже AVICap, берем surface для видео (или preview window для AVICap), или же сами строим сцены для DirectX обычным способом
S>>Ну вот, вы сами пришли к выводу, что для вашей задачи WPF (в текущем виде) абсолютно не нужен. V>Так если по косточкам разобрать, то куда ни ткни — он не нужен.
Если по косточкам разобрать — никто не нужен.
V>Пока забацать свой контрол будет дешевле по трудоемкости на WinForms, FPW будет оставаться поделкой.
Хз как там в FPW, но в WPF особых проблем от рождения не было
V> Но абсолютно не нужная в продакшн, т.к. в конечном продукте той гибкости отображения никогда не будет (я не имею ввиду скины, они не требуют шаблонов данных), т.е. данные всё равно обычно отображаются согласно некоей спецификации.
Нам нужны.
V> И даже не принципиально с т.з. разделения труда (помнишь как они задвигали концепцию: дизайнеры GUI и программисты работают одновременно над одной и той же единицей GUI и никто друг другу не мешает? Утопия, как выяснилось. Только по очереди, как и всегда.)
Речь при разделении шла совсем не об этом. Вместо "слепили в фотошопе -> разработчик изображает нечто похожее" сделали переход к "дизайн в XAML — разработчик прикручивает логику". И даже одновременно работать неплохо выходит.
V>Другое дело, что если бы WPF позволял бы так доопределять дизайн, как позволяет CSS применительно к HTML...
При прямых руках, необходимости и достаточном терпении — позволяет.
V> в WPF не реализован такой доказавший свою жизнеспособность сценарий, что ИМХО есть вовсе ему не на пользу.
в WPF нет стилей?
Здравствуйте, vdimas, Вы писали:
V>Скажу больше, до тех пор, пока забацать свой контрол будет дешевле по трудоемкости на WinForms, FPW будет оставаться поделкой.
Дешевле (якобы) это только у тех, кто ничего не понимает в WPF.
Здравствуйте, MxMsk, Вы писали:
V>>Скажу больше, до тех пор, пока забацать свой контрол будет дешевле по трудоемкости на WinForms, FPW будет оставаться поделкой. MM>Дешевле (якобы) это только у тех, кто ничего не понимает в WPF.
Судя по твоим вопросам и ответам по WPF в последний год-другой и прикидкам требуемого времени на все эти мелочи — скорее я прав по состоянию дел на сегодня. Реально трудоемкость высокая выходит для простейших чихов. И это вполне объективно и ожидаемо из-за большого информационного пространства, составляющего все мелочи и подробности самого WPF. Т.е. деталей слишком много получается, и мало у кого даже сегодня, спустя 4 года, получается так, чтобы написал что-то не совсем тривиальное — и оно сразу правильно и ожидаемо заработало. Для сравнения: на WinForms народ стал адекватно шустро буквально в первые месяцы.
Здравствуйте, Sinix, Вы писали:
S>Речь при разделении шла совсем не об этом. Вместо "слепили в фотошопе -> разработчик изображает нечто похожее" сделали переход к "дизайн в XAML — разработчик прикручивает логику". И даже одновременно работать неплохо выходит.
Да, пропустил абзац при ответе.
Ты это чисто теоретически задвинул, или у вас сидит реально живой человек-дизайнер, который вместо связки дизайнерских пакетов (обычно далеко не только Фотошоп), отныне удовлетворяется убогим ExpressionBlend? Я в эту чушь все-равно не поверю. А если действительно так, то нарезать битмапы и покрывать ими пространство можно было и в дизайнерах WinForms, бо пользоваться ими не сложней фотошопа а как бы скорее в разы наоборот.
Здравствуйте, vdimas, Вы писали:
V>Судя по твоим вопросам и ответам по WPF в последний год-другой и прикидкам требуемого времени на все эти мелочи — скорее я прав по состоянию дел на сегодня. Реально трудоемкость высокая выходит для простейших чихов. И это вполне объективно и ожидаемо из-за большого информационного пространства, составляющего все мелочи и подробности самого WPF. Т.е. деталей слишком много получается, и мало у кого даже сегодня, спустя 4 года, получается так, чтобы написал что-то не совсем тривиальное — и оно сразу правильно и ожидаемо заработало. Для сравнения: на WinForms народ стал адекватно шустро буквально в первые месяцы.
Я, конечно, польщен, что мои ответы по WPF позволяют оценить состояние индустрии по части Windows Forms vs WPF. Написанное никак не противоречит тому, что я сказал. Если человек не разбирается в WPF, то он естественно будет долго выжимать из себя приемлемое решение. Да и на Windows Forms серьезный контрол — такая же кропотливая работа, только это будет, как ты выражаешься, "гвоздями прибитая" реализация, кастомизация которой в итоге окажется в разы сложнее WPF-ной.
Здравствуйте, vdimas, Вы писали:
V>Ну дык, если у "хорошо разбирающихся" программистов столько кода (а значит времени) на простые GUI-сценарии уходит, что говорить про остальных. И что характерно... Что 90% предлагаемых решений неочевидны, не следуют из доки, а требуют быть "эльфом 80-го уровня" в этой либе.
Откуда эта цифра — 90%? Выглядит логичным, что на форуме спрашивают о сложных и нетривиальных решениях. По Windows Forms до сих пор появляются вопросы про BeginInvoke, хотя казалось бы, чего уж проще. Далее, ты забываешь, что "очевидность" решений Windows Forms вытекает только из того, что оно близко к ранее существовавшим аналогичным FW. Это плюс для вхождения, но минус для развития. Шаг вправо или влево от WinAPI и упираемся в кучу проблем, когда тривиальная задача комбинирования контролов превращается в геморрой.
V>Хотя и люблю "порыться" в реализациях до самого дна, как говорится, но в награду хотелось бы получать интересные найденные решения, а не сомнительной очевидности костыли "по-месту".
Ну я же не виноват, что ты в .Net GUI выискиваешь темы про "костыли".
MM>>Написанное никак не противоречит тому, что я сказал. Если человек не разбирается в WPF, то он естественно будет долго выжимать из себя приемлемое решение. V>А банальностям вообще редко что противоречит. Но и пользы от них никакой.
Кому как.
MM>>Да и на Windows Forms серьезный контрол — такая же кропотливая работа, только это будет, как ты выражаешься, "гвоздями прибитая" реализация, кастомизация которой в итоге окажется в разы сложнее WPF-ной. V>Смотря что кастомизировать. Если внешний вид — то согласен. Но это никогда не было критичным с т.з. трудоемкости. А вот с т.з. поведения... Тут ты категорически не прав, ибо проще в разы.
Пример?
Здравствуйте, Sinix, Вы писали:
S>Практически Дизайнер — эт не человек, ваяющий прекрасное в избранном пакете, а человек, отвечающий за look'n'feel приложения.
Ну это у вас так. А дизайнеры-профи все-равно макеты накидывают совсем в других пакетах.
S>Соответственно, основная работа — вовсе не "сделать красиво" путём навтыкивания битмапов (в WPF такое оочень тяжело взлетит — придётся прибивать гвоздями всё что можно и низзя).
Ребрендинг без битмапов никак, увы. На одних градиентах и полупрозрачностях далеко не уедешь. Да и эффективнее битмапы минимум в 2 раза чем полупрозрачности. Так что вместо статических мест с полупрозрачностями эффективнее отрендерить заранее и нарезать готовых картинок.
S>Blend, при всей убогости на порядок (а со sketchflow — на два) удобнее студии для быстрого прототипирования. Дело за малым — облагородить созданный XAML
Вообще, прототипировать GUI должны аналитики, и делать это можно хоть в Visio. Даже скорее желательно делать в чём-то типа Visio, ибо есть поддержка аннотаций и прочих прелестей именно для целей прототипирования. И там довольно скучные квадратики выходят, ибо прототип нужен исключительно для разработки use-case относительно GUI. А вот забрендить потом это все — задача художника.
S>У нас реально параллельная работа была очень давно (и врядли будет ещё — весь UI разбит на workspace, так что простыней для совместной работы практически нет), но, тем не менее, особых проблем не возникало.
S>Я пожалуй напомню вам ваше оригинальное S>
S>Ты насколько подробно сам разбирался в этом, чтобы давать столь хамско-снисходительные ссылки?
S>Так вот...
Работал с "заказными" дизайнерами. Представляю как и что они делают. Скажу, что эффективно и грамотно, и не представляю ExpressionBlend в их руках, ибо это означает губить таким людям производительность их труда.
Здравствуйте, khimiki, Вы писали:
K>Так вот и я о том же. Другими словами, балалайка выполняет предъявляемые к ней требования — производит музыку. А .NET — это скорее балалайка, но без одной струны. Издали вроде похожа на музыкальный инструмент, а возьмёшь её в руки и станет понятно, что играть на ней может только Поганини. Я, к сожалению, не Поганини.
Неасилил
Сложность программы растет до тех пор, пока не превысит способности программиста
V>Да, спасибо за наводки. Прошелся по состоянию инструментов на сегодня. В общем, у же примерно год как есть адекватный набор инструментов как для дизайнеров, так и аналитиков. Особенно вот этот sketchflow любопытен.
Да не за что
Мааленькая поправка: design'у года 3 (только что нашёл — корни у него торчат из Creature House Expression, который ещё старше)
Скетчфлоу только-только появился в 4м бленде.
V>Удивительно, что не слышно бурных обсуждений сих продуктов и повсеместного дележа впечатлениями.
Потому что WPF-разработчиков с поставленным процессом ещё меньше, чем просто WPF-разработчиков. И больше, чем разработчиков с денюжками на Expression Ultimate (В сравнении со взрослыми пакетами это конеш смешные деньги. Но и смешные возможности). Порог вхождения, увы
V>>Пример заключется в том, что PretranslateMessage() хоть и беднее в разы роутинга WPF, но так же дает меньше степеней свободы для глупых ошибок. По крайней мере свой командный фреймворк с поддержкой визуального дизайн-тайм для WinForms был написан когда-то за вечер, в то время как не будь похожей функциональности у WPF, даже не понятно, стоило бы за такое браться, возникни необходимость. Ибо ни одним, ни двумя вечерами тут не обойдешься. MM>Блин, вот умеешь ты наваять громадный постинг, ничего по делу не сказав. С меня хватит. Пойду запускать программы...
Да налицо разный словарь. Я о многом говорю как о кое чем разумеющемся, а ты и о проблемах таких не слыхивал. Для тех, кто бодается с GUI хотя бы лет 10, и прошел MFC/ATL/WTL/QT/wxWindows/вписать-по-желанию, само упоминание о задаче command framework сразу объясняет многое. Тебе ничего.
Здравствуйте, vdimas, Вы писали:
V>Комбинирование не предназначенных для комбинирования контролов всегда будет гемморойным. Ибо не в HWND загвоздка, а в распространении событий. И с этим геморроем бодался лично в WPF, когда накачал кучу вариантов необходимых контролов "отовсюду" и как раз экспериментировал с комбинированием. Кто-то наверху не так зароутил событие — получи геммор на нижнем уровне.
Это в Винформс геморрой. Никто не говорил, что любые контролы можно комбинировать как попало.
Комбинировать нужно простые контролы, а не хрен знает где.
V>>>Смотря что кастомизировать. Если внешний вид — то согласен. Но это никогда не было критичным с т.з. трудоемкости. А вот с т.з. поведения... Тут ты категорически не прав, ибо проще в разы. MM>>Пример?
V>Пример заключется в том, что PretranslateMessage() хоть и беднее в разы роутинга WPF, но так же дает меньше степеней свободы для глупых ошибок.
Вот так фича то. Качни TurboVision для Дос, там еще меньше свободы для глупых ошибок.
Что бы не было ошибок, надо сначала годами втыкать в с++, мфц и вское дерьмо, и только потом у тебя будет мало ошибок.
>По крайней мере свой командный фреймворк с поддержкой визуального дизайн-тайм для WinForms был написан когда-то за вечер,
Хочешь угадаю, на ВинФормс ты поработал несколько лет и только потом забабахал командный фреймворк этот.
>в то время как не будь похожей функциональности у WPF, даже не понятно, стоило бы за такое браться, возникни необходимость. Ибо ни одним, ни двумя вечерами тут не обойдешься.
Здравствуйте, Ikemefula, Вы писали:
I>Вот так фича то. Качни TurboVision для Дос, там еще меньше свободы для глупых ошибок.
И ты думаешь роутинг команд сильно поменялся с тех пор? Там кое-какая тонкость как была, так и осталась даже в WPF. Абсолютно тот же алгоритм и в MFC и в OLE и в WinForms. Просто теперь больше шансов этот роутинг случайно запороть своими триггерами.
I>Хочешь угадаю, на ВинФормс ты поработал несколько лет и только потом забабахал командный фреймворк этот.
Не угадал. Загвоздка была в малом кол-ве работы с одной стороны, и простоте окружения с другой.
>>в то время как не будь похожей функциональности у WPF, даже не понятно, стоило бы за такое браться, возникни необходимость. Ибо ни одним, ни двумя вечерами тут не обойдешься.
I>Это потому что WPF ты не знаешь.
Чтобы ты понял о чем речь, поисследуй эту тему рефлектором в WPF, чтобы увидеть объем работ. Когда такие работы подходят к концу, то не принципиально, насколько знал либу к их началу.
I>>Хочешь угадаю, на ВинФормс ты поработал несколько лет и только потом забабахал командный фреймворк этот.
V>Не угадал. Загвоздка была в малом кол-ве работы с одной стороны, и простоте окружения с другой.
Сейчас проверим, угадал или не угадал. Сколько у тебя опыта работы когда ты писал этот фреймворк и сколько из него дотнетовского и сколько из него Winforms.
Здравствуйте, Ikemefula, Вы писали:
I>>>Хочешь угадаю, на ВинФормс ты поработал несколько лет и только потом забабахал командный фреймворк этот.
V>>Не угадал. Загвоздка была в малом кол-ве работы с одной стороны, и простоте окружения с другой.
I>Сейчас проверим, угадал или не угадал. Сколько у тебя опыта работы когда ты писал этот фреймворк и сколько из него дотнетовского и сколько из него Winforms.
Дотнетного+WinForms было 2 года, т.е. меньше чем опыта с WPF сейчас.
Только неубедительная проверка, ИМХО. Объемы сырцов более полезно сравнить. А там разница более чем в 10 раз на вскидку.
?
