Здравствуйте, 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 переписывать
Здравствуйте, Sinix, Вы писали:
S>Пару лет назад баловался с подобными самплами, особых проблем не было. В продакшн ничего не ушло, говорить о 100% беспроблемности не могу.
Я уже говорил, что думаю о наивных попытках реализации видео через серию прогоняемых битмапных хендлов.
S>Ну вот, вы сами пришли к выводу, что для вашей задачи WPF (в текущем виде) абсолютно не нужен.
Так если по косточкам разобрать, то куда ни ткни — он не нужен.
От того WinForms живее всех живых. Скажу больше, до тех пор, пока забацать свой контрол будет дешевле по трудоемкости на WinForms, FPW будет оставаться поделкой. Он пока выигрывает только там, где для решения задачи потребовалось бы городить свою иерархию windowless-контролов. Что касается остального, например шаблонов данных... Мощная фича, особенно для экспериментов. Но абсолютно не нужная в продакшн, т.к. в конечном продукте той гибкости отображения никогда не будет (я не имею ввиду скины, они не требуют шаблонов данных), т.е. данные всё равно обычно отображаются согласно некоей спецификации. И где эта спецификация реализована: в шаблонах или в конкретных контролах — вовсе не принципиально с т.з. трудоемкости. И даже не принципиально с т.з. разделения труда (помнишь как они задвигали концепцию: дизайнеры GUI и программисты работают одновременно над одной и той же единицей GUI и никто друг другу не мешает? Утопия, как выяснилось. Только по очереди, как и всегда.)
Другое дело, что если бы WPF позволял бы так доопределять дизайн, как позволяет CSS применительно к HTML... Но этот флейм уже был, неохота возвращаться. Лишь выскажу опять сожаление, что в WPF не реализован такой доказавший свою жизнеспособность сценарий, что ИМХО есть вовсе ему не на пользу. Да, нечто подобное может быть допилено сверху, если рассматривать WPF как запчасти от Lego. Но работы много — раз, и что там со стандартизацией? — два.
Здравствуйте, 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.
Здравствуйте, Sinix, Вы писали:
V>>Другое дело, что если бы WPF позволял бы так доопределять дизайн, как позволяет CSS применительно к HTML... S>При прямых руках, необходимости и достаточном терпении — позволяет.
Ну дык, при желании и свой WPF нарисовать можно, мы же говорим об имеющемся.
V>> в WPF не реализован такой доказавший свою жизнеспособность сценарий, что ИМХО есть вовсе ему не на пользу. S>в WPF нет стилей?
Здравствуйте, MxMsk, Вы писали:
V>>Скажу больше, до тех пор, пока забацать свой контрол будет дешевле по трудоемкости на WinForms, FPW будет оставаться поделкой. MM>Дешевле (якобы) это только у тех, кто ничего не понимает в WPF.
Судя по твоим вопросам и ответам по WPF в последний год-другой и прикидкам требуемого времени на все эти мелочи — скорее я прав по состоянию дел на сегодня. Реально трудоемкость высокая выходит для простейших чихов. И это вполне объективно и ожидаемо из-за большого информационного пространства, составляющего все мелочи и подробности самого WPF. Т.е. деталей слишком много получается, и мало у кого даже сегодня, спустя 4 года, получается так, чтобы написал что-то не совсем тривиальное — и оно сразу правильно и ожидаемо заработало. Для сравнения: на WinForms народ стал адекватно шустро буквально в первые месяцы.
Здравствуйте, Sinix, Вы писали:
S>Речь при разделении шла совсем не об этом. Вместо "слепили в фотошопе -> разработчик изображает нечто похожее" сделали переход к "дизайн в XAML — разработчик прикручивает логику". И даже одновременно работать неплохо выходит.
Да, пропустил абзац при ответе.
Ты это чисто теоретически задвинул, или у вас сидит реально живой человек-дизайнер, который вместо связки дизайнерских пакетов (обычно далеко не только Фотошоп), отныне удовлетворяется убогим ExpressionBlend? Я в эту чушь все-равно не поверю. А если действительно так, то нарезать битмапы и покрывать ими пространство можно было и в дизайнерах WinForms, бо пользоваться ими не сложней фотошопа а как бы скорее в разы наоборот.
Здравствуйте, vdimas, Вы писали:
S>>Речь при разделении шла совсем не об этом. Вместо "слепили в фотошопе -> разработчик изображает нечто похожее" сделали переход к "дизайн в XAML — разработчик прикручивает логику". И даже одновременно работать неплохо выходит.
V>Ты это чисто теоретически задвинул, или у вас сидит реально живой человек-дизайнер, который вместо связки дизайнерских пакетов (обычно далеко не только Фотошоп), отныне удовлетворяется убогим ExpressionBlend?
Практически Дизайнер — эт не человек, ваяющий прекрасное в избранном пакете, а человек, отвечающий за look'n'feel приложения. Соответственно, основная работа — вовсе не "сделать красиво" путём навтыкивания битмапов (в WPF такое оочень тяжело взлетит — придётся прибивать гвоздями всё что можно и низзя). Blend, при всей убогости на порядок (а со sketchflow — на два) удобнее студии для быстрого прототипирования. Дело за малым — облагородить созданный XAML
У нас реально параллельная работа была очень давно (и врядли будет ещё — весь UI разбит на workspace, так что простыней для совместной работы практически нет), но, тем не менее, особых проблем не возникало.
V>Я в эту чушь все-равно не поверю. А если действительно так, то нарезать битмапы и покрывать ими пространство можно было и в дизайнерах WinForms, бо пользоваться ими не сложней фотошопа а как бы скорее в разы наоборот.
Я пожалуй напомню вам ваше оригинальное
Ты насколько подробно сам разбирался в этом, чтобы давать столь хамско-снисходительные ссылки?
Здравствуйте, vdimas, Вы писали:
V>Судя по твоим вопросам и ответам по WPF в последний год-другой и прикидкам требуемого времени на все эти мелочи — скорее я прав по состоянию дел на сегодня. Реально трудоемкость высокая выходит для простейших чихов. И это вполне объективно и ожидаемо из-за большого информационного пространства, составляющего все мелочи и подробности самого WPF. Т.е. деталей слишком много получается, и мало у кого даже сегодня, спустя 4 года, получается так, чтобы написал что-то не совсем тривиальное — и оно сразу правильно и ожидаемо заработало. Для сравнения: на WinForms народ стал адекватно шустро буквально в первые месяцы.
Я, конечно, польщен, что мои ответы по WPF позволяют оценить состояние индустрии по части Windows Forms vs WPF. Написанное никак не противоречит тому, что я сказал. Если человек не разбирается в WPF, то он естественно будет долго выжимать из себя приемлемое решение. Да и на Windows Forms серьезный контрол — такая же кропотливая работа, только это будет, как ты выражаешься, "гвоздями прибитая" реализация, кастомизация которой в итоге окажется в разы сложнее WPF-ной.
Здравствуйте, MxMsk, Вы писали:
V>>Судя по твоим вопросам и ответам по WPF в последний год-другой и прикидкам требуемого времени на все эти мелочи — скорее я прав по состоянию дел на сегодня. Реально трудоемкость высокая выходит для простейших чихов. И это вполне объективно и ожидаемо из-за большого информационного пространства, составляющего все мелочи и подробности самого WPF. Т.е. деталей слишком много получается, и мало у кого даже сегодня, спустя 4 года, получается так, чтобы написал что-то не совсем тривиальное — и оно сразу правильно и ожидаемо заработало. Для сравнения: на WinForms народ стал адекватно шустро буквально в первые месяцы. MM>Я, конечно, польщен, что мои ответы по WPF позволяют оценить состояние индустрии по части Windows Forms vs WPF.
Ну дык, если у "хорошо разбирающихся" программистов столько кода (а значит времени) на простые GUI-сценарии уходит, что говорить про остальных. И что характерно... Что 90% предлагаемых решений неочевидны, не следуют из доки, а требуют быть "эльфом 80-го уровня" в этой либе.
Много чести.
Хотя и люблю "порыться" в реализациях до самого дна, как говорится, но в награду хотелось бы получать интересные найденные решения, а не сомнительной очевидности костыли "по-месту".
MM>Написанное никак не противоречит тому, что я сказал. Если человек не разбирается в WPF, то он естественно будет долго выжимать из себя приемлемое решение.
А банальностям вообще редко что противоречит. Но и пользы от них никакой.
MM>Да и на 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 в их руках, ибо это означает губить таким людям производительность их труда.
Здравствуйте, 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 и меньше.
